Microsoft’s Agent Framework documentation describes the same layer as runtime scaffolding that turns a model into an agent. The model supplies language and reasoning. The harness supplies the operating environment that makes those abilities useful across a real task.
The model proposes what to do next. The harness controls what the agent can see, execute, remember, and recover.
What does an agent harness control?
An agent harness assembles the model client, prompt and message history, tool definitions, files, persistent state, and the interface through which a person follows progress. It decides which capabilities are available on every turn and how their results return to the model. Agent middleware can add logging, retries, or policy checks around calls. Agent skills contribute task-specific procedures without changing the underlying runtime.
The harness also owns practical limits. It can cap iterations, time, or spend, restrict filesystem and network access, and require tool approval before a sensitive operation. These controls must remain outside the model’s instructions because the model cannot be the authority that grants itself permission.
How does the harness run an agent loop?
The harness sends the current context to the model, receives a proposed response or tool call, validates it, executes an allowed action, and returns the observation. The loop continues until the task is complete, the agent needs a person, or a deterministic stop condition fires. The harness turns each model response into one controlled transition in a longer process.
That separation makes failures diagnosable. A weak plan may be a model problem. A malformed tool result may be an integration problem. A missing approval or runaway retry is a harness problem. LLM tracing records those transitions so a team can see which layer failed.
Is an agent harness the same as an agent framework?
No. A framework provides components and APIs for building agents. A harness is the configured runtime those components form when an agent actually works. A team can use one framework to create several harnesses with different permissions, tools, and recovery behavior. An agentic workflow describes the steps and branches for a job, while the harness is the environment that executes them.
Why does the harness matter for long tasks?
A growing history eventually collides with the context window, while a long process eventually meets a timeout, deployment, or failed dependency. A production harness preserves the minimum state needed to continue safely. It can apply context compaction, persistent working files, and durable execution so progress survives beyond one process or context window.
That combination separates a robust deep agent from a model call wrapped in an unrestricted loop. Our deep agents in production guide explains why planning, memory, subagents, and recovery belong in the runtime rather than in one increasingly long prompt.