Agent harness
Also known as: managed harness, harness, agent runtime harness
When you build an agent from scratch, you write the loop yourself: call the model, check whether it wants to use a tool, run the tool, feed the result back, repeat until done. An agent harness abstracts all of that away. You declare what the agent should be (model choice, instructions, available tools) and the harness takes care of running it, including things like context management, error recovery, streaming responses, and session isolation.
The distinction from an agent framework is meaningful. A framework (like LangGraph or CrewAI) gives you primitives and patterns you assemble into your own loop in code. A harness goes further: it is the managed infrastructure that actually executes the loop, the same way a web server handles HTTP so you do not write socket code. AWS AgentCore's managed harness, Microsoft Agent Framework's hosted agents, and Google's Gemini Enterprise Agent Platform all ship harness-style runtimes where you define the agent and they run it, including scaling, observability, and security policies.
Harnesses gained significant traction in mid-2026 as teams found that hand-rolling the agent loop was the biggest source of reliability bugs in production. The trade-off is control: when a harness manages the loop, you trade flexibility for reliability and faster time to deploy. Builders choosing a harness should understand what the harness exposes for customization and what it locks in, especially around tool calling order, context compaction strategy, and human-in-the-loop approval flows.