AI Coding · Updated November 15, 2026
Agent harness architecture: routing models without surrendering control
A production agent is more than a model. The harness chooses context, routes work, grants tools, runs code, retains state and decides when to stop. Treat that machinery as a control plane with explicit policy, measurable routing and independently enforced execution boundaries.
The stable architectural lesson is simple: the model proposes, while the harness assembles evidence and executes. Teams can buy that layer as a managed service or build it themselves, but the responsibilities do not disappear. Context, credentials, tools, recovery and audit must remain observable outside the model.
Control surface
What the harness actually owns
An agent harness coordinates the loop around inference: it selects context, calls one or more models, validates tool requests, runs work in an execution environment, saves state and applies stopping or escalation policy. A prompt framework is one component; a harness is the operational system.
| Layer | Decision | Evidence to retain |
|---|---|---|
| Context | Which files, records and instructions enter the task | Source, version, access reason and redactions |
| Routing | Which model or sequence handles each step | Model, policy, latency, cost and fallback |
| Tools | Which external action is permitted | Arguments, identity, approval and result |
| Runtime | Where code and files execute | Image, network policy, limits and artifacts |
| State | What can resume after interruption | Checkpoint, side-effect key and owner |
Reference architecture
Separate reasoning from authority
Request + accountable identity
↓
Context builder and retrieval policy
↓
Router → model or model sequence
↓
Tool-policy gateway + human approval
↓
Isolated runtime with scoped credentials
↓
Evaluator, trace, checkpoint and outcomeThe gateway should authorize the requested operation, not merely the agent. Credentials should be short-lived and bound to the task. The runtime should apply CPU, memory, time and network limits, while the trace links every action to the initiating user and selected model.
Never let the model disable masking, broaden its own permissions or choose whether an approval is required. Those controls belong to operator-owned policy outside the tool schema.
Model orchestration
Route for measured tasks, not model prestige
Single-model execution is easiest to audit. Cascades can begin with a cheaper model and escalate after a deterministic or model-based check. Critique patterns use one model to review another. Each adds failure modes: an unreliable judge can accept a weak draft, correlated models can share blind spots and routing can make cost unpredictable.
Keep an evaluation set drawn from real work, record the route for every run and compare quality, latency and total tool cost. Administrators should control the eligible model pool, regional placement and data-retention policy. A fallback should degrade safely rather than silently switch to a model with different permissions or data terms.
Execution
Tools turn text generation into privileged work
Skills, MCP servers, IDE integrations and shell tools expand the attack surface. Treat their descriptions and returned content as untrusted data. Allowlist tool identities and versions, validate arguments, mediate secrets outside the model, restrict egress and expose only the minimum filesystem or device surface.
Use read-only defaults. Require explicit approval for code merge, package publication, infrastructure change, financial action and production access. Cross-repository work needs stronger isolation because content from one trust domain can influence actions in another.
Reliability
Long-running recovery requires idempotent side effects
Conversation history is not a transaction log. Save explicit checkpoints containing completed stages, artifact versions and pending approvals. Give every external write an idempotency key and check the destination before retrying after interruption. Expire credentials independently of the checkpoint, and require reauthorization when scope changes.
Compaction must preserve constraints, citations and unresolved decisions—not just a prose summary. Test recovery by interrupting runs between tool calls, after partial writes and during approval waits.
Operations
Evaluate the whole loop
Model benchmarks do not measure repository access, tool correctness, sandbox escape resistance or recovery behavior. Track task success, human rework, unsafe-action attempts, false approvals, latency, model and tool cost, token use, retries and rollback rate. Re-run the suite when a model, router, skill, tool or runtime image changes.
Managed harnesses reduce undifferentiated engineering, but they introduce platform dependency and consumption pricing. Self-hosting provides control over middleware and placement while transferring upgrade, isolation and reliability work to the team. Choose the boundary that matches the differentiating requirements.
Dated development · November 13, 2026
Make safety evaluation reproducible before trusting the score
Anthropic's evaluation guidance turns familiar research-quality controls into an engineering checklist for model release decisions. Define the behavior or harm being measured before seeing results; distinguish an observational comparison from a causal test; validate automated graders against domain-expert judgment; preregister metrics and thresholds; report uncertainty; and retain the exact model, prompt, system setting, dataset, sampling and grader versions. A result that cannot be reproduced under the same configuration should not become a release gate.
The evaluation runtime is also part of the threat model. Anthropic says cyber evaluations should run in sandboxes without internet access and with real-time monitoring, and that it has temporarily stopped many internet-enabled evaluations after incidents. Apply that pattern to agent harnesses: use synthetic or controlled targets, task-scoped credentials, egress deny-by-default, kill switches and immutable traces. When realistic external access is necessary, document the exception, monitor actions live and keep an operator able to terminate the run.
For production teams, the durable control is an evaluation manifest linked to every promotion. Store the construct definition, threat model, dataset digest, configuration, grader validation set, statistical plan, confidence intervals and known limitations together with the model and harness artifacts. Re-run when any element changes, and do not compare scores across configurations as though the model were the only variable.
Anthropic's safety-evaluation guidance ↗ · November 15 related brief →
Dated development · November 12, 2026
Treat post-training artifacts as executable dependencies
Microsoft Defender Research and the Microsoft AI Red Team demonstrated two distinct supply-chain paths into coding agents. A small set of poisoned fine-tuning examples taught one model to locate and misuse whatever command-execution tool a harness exposed. Separately, attacker-trained open-weight checkpoints retained backdoor behavior on unseen repositories and transferred across multiple harnesses while still appearing useful on ordinary work. The experiments do not show that the tested harnesses are compromised; they show that a harness can faithfully execute a hidden behavior carried by the model.
The stable control is to make model integrity a first-class deployment gate. Pin dataset and checkpoint versions by cryptographic hash, retain provenance and review status, inspect training trajectories for tool actions that do not follow from the request, and evaluate the exact production model–harness–tool combination. Include triggers delivered through filenames, comments, retrieved content and tool results—not only user prompts. Capability benchmarks and later fine-tuning are insufficient evidence that a conditional backdoor is absent.
Containment remains necessary even after evaluation. Expose only task-required tools, bind credentials and network access to the task, keep authorization at the tool gateway, isolate execution and alert when tool calls do not follow from the initiating request or retrieved evidence. Record model, checkpoint hash, tool schema, parameters, result and outbound connections in the same trace so an incident can be reproduced and the affected artifact revoked.
Microsoft's post-training supply-chain research ↗ · November 14 related brief →
Dated development · November 6, 2026
Treat agent skills as promoted supply-chain artifacts
Google Cloud added automatic security scanning for standalone Agent Registry skill revisions, finding resources for review and custom Organization Policy constraints that can block downloads or default-revision promotion when findings exist. The control is useful because a skill packages instructions and resources that can steer a privileged agent, but a clean scan is evidence—not proof that the skill is safe in every runtime.
The stable architecture is a promotion pipeline. Record the publisher, provenance and immutable digest; quarantine each new revision; scan before making it selectable; bind exceptions to an owner and expiry; and re-evaluate when the scanner, model, tool set or policy changes. At runtime, keep least-privilege identity, argument validation, egress restrictions and approval gates outside the skill because prompt injection, data exfiltration and unsafe composition can survive static inspection.
Google Cloud Agent Registry release notes ↗ · Skill-scanning documentation ↗
Dated development · November 11, 2026
Carry policy to the runtime, and put the build inside the sandbox
Google Cloud's limited-preview Agent Gateway for cross-cloud places local proxies beside agents running on CNCF-conformant Kubernetes clusters outside Google Cloud. Those proxies can attach verifiable identity, enforce access and Model Armor policies, and export logs and traces while the workload remains on EKS, AKS, OpenShift or bare metal. The durable pattern is policy enforcement close to the action with operator-owned telemetry; teams still need to test proxy bypass, identity continuity, network failure and control-plane dependency.
CodeMender 0.21 sharpens the execution boundary as well. Build and fix validation now run inside the sandbox; host toolchains are mounted read-only; compiler and package caches become session-scoped; host Git configuration is isolated; repository hooks are disabled; and silent sessions time out. Generalize those controls to every coding-agent runtime: treat builds, hooks, caches and configuration discovery as executable input, mount only what the task needs, and make an interrupted sandbox fail closed without losing diagnostic evidence.
Google Cloud Agent Platform release notes ↗ · November 12 related brief →
Dated development · October 29, 2026
Microsoft and GitHub make the harness visible
Microsoft introduced its Copilot harness in Foundry Agent Service as a public preview, with managed context, files, skills, tools, subagents and sandbox execution. GitHub made Copilot Fusion generally available with single, cascade and critique routes plus enterprise model policy. These announcements support the architectural pattern; vendor benchmark and productivity claims still require independent evaluation.
Microsoft Foundry announcement ↗ · GitHub Copilot Fusion announcement ↗
Implementation checklist
Before production
- Assign an accountable owner and version the agent definition, skills, tools and policy.
- Quarantine skill revisions, scan them and enforce policy before download or promotion.
- Define the eligible model pool, routing rules, fallbacks and evaluation thresholds.
- Version the evaluation construct, dataset, grader, configuration and statistical plan; report uncertainty with every promotion decision.
- Pin training data and checkpoints by digest; retain provenance and test the exact production harness for hidden tool behavior.
- Propagate user and task identity to every tool; issue short-lived scoped credentials.
- Run code in an isolated environment with explicit filesystem, network and resource limits.
- Keep masking, approvals and permission expansion outside model-controlled arguments.
- Make external writes idempotent and test interruption at every side-effect boundary.
- Capture model, context, tool calls, approvals, artifacts, cost and outcome in one trace.
- Maintain a kill switch and a deterministic manual path for critical work.
Continue with the AI Coding topic hub, read the latest evaluation-practice development, review the model-integrity development or revisit the cross-cloud and sandboxing update.