Microsoft’s Agent Harness Shows What Production-Ready AI Agents Actually Need
Microsoft’s latest Agent Framework guidance treats an AI agent as a production system: observable, governed, deployable and continuously evaluated, with dangerous capabilities deliberately constrained.
Microsoft’s August 27 Agent Framework update is useful because it moves the discussion beyond whether an agent can call tools. The production question is whether teams can observe what it did, control what data it touches, deploy the same behavior consistently and detect regressions before they reach users.
The reference architecture uses one shared agent factory with separate console, hosted-service and evaluation hosts. That matters operationally: telemetry, governance and evals attach to the same agent definition instead of drifting across environment-specific copies.
Observability is built around OpenTelemetry. The harness emits spans for model turns and tool calls plus token-usage metrics and structured logs, while teams choose where those signals are exported. In Foundry-hosted deployments, the runtime can wire telemetry into Application Insights automatically. This makes runaway tool loops, unexpected cost increases and failing skills much easier to investigate.
Governance is optional but explicit. Microsoft shows Purview middleware screening prompts and responses against organizational policy and preserving an audit trail. That is especially relevant for agents that operate on regulated or confidential data, because policy enforcement sits in the request path rather than being left to prompt instructions alone.
The strongest engineering point is the treatment of high-risk capabilities. The hosted sample disables filesystem access and shell execution because arbitrary file and command access creates risks such as exfiltration, tampering and persistence. Where files are genuinely needed, Microsoft recommends an external governed file store instead of depending on ephemeral container storage.
The same caution applies to CodeAct. Microsoft states that LocalCodeAct is not itself a sandbox: generated Python should run only inside an externally sandboxed environment such as the hosted-agent container, or CodeAct should be disabled. That distinction is important for teams that might otherwise mistake a process boundary for a security boundary.
Finally, the architecture makes evaluation part of delivery. Fast local checks can run in CI, while hosted Foundry evaluations add model-graded measures such as relevance and coherence. The broader lesson is that agent quality is not a one-time benchmark; it becomes an operating loop connecting traces, policy controls, deployment configuration and regression tests.
For enterprise teams, this is a more realistic model of agent engineering than simply adding more tools. The production harness becomes the control plane around the model: capabilities stay useful, but observability and least privilege determine whether they are safe enough to operate at scale.
This article is built from the source material below. Open the originals for full context and the latest updates.