From demo to production: what an agent harness actually adds
The piece frames an agent as "model + harness" and splits the harness into a development half (memory, tools and MCP, retrieval, prompt orchestration) and an operations half (observability, evals, guardrails, routing, cost control, deployment and scaling) — capabilities the model itself does not provide. It then builds the same finance agent, FinBot, two ways: a managed Amazon Bedrock AgentCore Harness configured via CreateHarness/InvokeHarness calls, with per-session Firecracker microVMs, managed memory and automatic tracing; and a self-managed LangChain agent on the reader's own Kubernetes cluster behind the open-source Agent Router (formerly Envoy AI Gateway). The trade-offs come down to where provider credentials live, who carries the operational burden, and whether you pay a vendor bill or infrastructure plus engineering time.
For teams moving agents from demo to production, the harness around the model often determines whether the system can actually ship.
搭一个 AI Agent Demo，可能一个下午就够了。但要把它真正做到可以投入生产，完全是另一回事。
一个生产级 Agent 必须稳定在线、足够安全、控制好成本，而且当它不可避免地出问题时，你还得有足够的可观测性去弄清楚到底哪里出了错。这些能力几乎都不是模型本身提供的，而是来自你围绕模型搭出来的所有东西：记忆、工具访问、模型路由、护栏、成本控制，以及当 Agent 开始乱来时，你不得不翻进去排查的各种 trace。
这一层，就是我们所说的 Agent Harness。
#Amazon Bedrock AgentCore#Agent Router#Envoy AI Gateway#Amazon Bedrock#LangChain#LangGraph#Kubernetes#AWS