Inside a Production Agent Harness

01Where Episode 01 left us

Why Your Agent Fails began with 1,500 invoices sitting behind a green dashboard.

The model completed the records it received. The system fetched one page of a larger queue and accepted the model's final sentence as proof that the job was done.

We left with four verbs:

• ModelProposes.
• HarnessDecides.
• ToolActs.
• EnvironmentConstrains.

Those verbs locate a failure. They do not yet show what lives inside each box.

This episode opens them.

02Draw the system before you debug it

Three days after the invoice failure, the team draws the agent on a whiteboard.

The model is easy. So is the invoice API. Then the room slows down.

Where does retry state live? Who decides the queue is empty? Which file survives a restart? What blocks a refund above the approval limit? Where can on-call see the exact information that reached the model?

Twenty minutes in, the board has four boxes and eleven question marks.

The silence is useful. A system nobody can draw is a system nobody can assign or improve.

A production harness is a control plane. It decides what the model sees, what happens after the response, which actions may proceed, what counts as complete, and what the next release learns.

03The sixty-second anatomy

Three views describe the same system. Use the one that answers the question in front of you.

Do not merge the views into one list. They solve different problems.

04View 1: four responsibilities

Model

The model receives text or other supported input and produces a proposed response or action.

Products may package memory, tools, browsing, and code execution beside the model. Those features live in the product runtime, not in the learned model weights.

That distinction matters in an incident. "The model remembered" may mean four different things:

1. A session stored an event.
2. Retrieval found it.
3. Context assembly placed it in the current prompt.
4. The model used it correctly.

Only the fourth is model reasoning.

Harness

The harness runs the loop around the model.

It assembles the prompt, exposes tools, processes the response, routes tool calls, records events, handles retries, and decides whether to continue, escalate, or stop.

OpenAI describes the Codex harness as the core agent loop and execution logic beneath Codex experiences. Anthropic describes the harness in Managed Agents as the loop that calls the model and routes tool calls to infrastructure.

Tools

A tool is a bounded operation the agent can request: read a file, query an invoice, draft a refund, run tests, or create a pull request.

The harness selects and routes the operation. The tool owns its contract: input, output, permission, failure behavior, and verification.

The Tool Is the Contract develops that boundary in full.

Environment

The environment is the world where tools execute and state persists: filesystem, process, network, credentials, runtime packages, and storage.

The harness decides that an action should happen. The environment limits what the action can reach.

The World Around the Agent explains the operate-side boundary. This episode keeps only the ownership split.

05The runtime underneath

The four layers still need somewhere to run.

A production runtime provides the operational services short demos can ignore:

• StateDurable sessions, checkpoints, and restart.
• FlowQueues and cancellation.
• IsolationMulti-tenancy and secret handling.
• EvidenceTrace transport.
• ReleaseDeployment and rollback.
• LimitsResource and cost ceilings.

A runtime keeps the system alive. A harness decides how the system behaves.

Some vendors sell both. Ask which parts your team can inspect, configure, export, and replace.

06View 2: five decisions inside the harness

The names matter less than the jobs. Every production system makes these decisions somewhere, even if the code is scattered across prompts, utility files, vendor defaults, and spreadsheets.

07Identity: what contract starts the run?

For invoice reconciliation, the contract may say:

Some lines guide judgment. Others need controls outside the prompt.

Instruction"Flag an ambiguous match" can live in the prompt.

Control"Never alter bank details" needs tool permissions and environment policy.

Identity states the contract. Interception and the outer layers enforce the parts that cannot depend on model obedience.

Identity is not an encyclopedia

Teams often put every useful fact into one permanent system prompt.

The prompt grows to include old incidents, coding standards, every tool, customer policy, and instructions for unrelated tasks. Important rules become harder to notice. Temporary workarounds become permanent because nobody remembers why they were added.

A stable identity answers who the agent is, what job it performs, and which operating contract applies. Task-specific skills and tools should appear when needed.

OpenAI reported a similar lesson from its Codex-generated repository. One large AGENTS.md consumed context and became stale. The team replaced it with a short map into structured repository knowledge.

Give the agent a map first. Reveal the relevant detail when the work reaches it.

08Memory policy: what earns space now?

The model's context window is not the agent's history.

• Context windowThe desk holding what the model can use now.
• Session logThe archive recording what happened.
• RetrievalThe clerk bringing selected material back to the desk.

A larger desk helps. It does not remove the archive or the clerk.

Anthropic's Managed Agents architecture keeps the session as an append-only event log outside the model context. The harness can retrieve slices, rewind to events before a decision, or resume from durable state after a failure.

Compaction, which summarizes old context to make room, is lossy. If the summary is the only surviving copy, the system has guessed which details no future step will need.

1. Keep the durable record outside the model context.
2. Let the harness assemble a view for the current turn.
3. Never make a summary the only copy of important state.

Context quality beats context volume

Memory policy decides what loads at startup, what gets trimmed, which source is authoritative, and what becomes a durable artifact.

A weak policy loads everything because deletion feels risky. The context becomes a warehouse. Old output and stale plans compete with the current task.

A strong policy maximizes current, useful evidence rather than raw token volume.

Workarounds need expiry dates

Anthropic describes a model-specific context-reset rule that fixed premature stopping in Claude Sonnet 4.5. The behavior disappeared in Opus 4.5, so the reset became dead weight.

The fix was correct for the model that needed it. Keeping it after the assumption expired would have been wrong.

Label every model-specific workaround with:

• ScopeModel or version.
• CauseFailure addressed.
• ExitEvidence required to retire it.

Episode 04 turns this into the scaffolding-versus-permanence paradox.

09Orchestration: what happens next?

Every model response creates a fork.

The system may call a tool, retry with new evidence, delegate, ask a human, pause, or stop.

The model can recommend. The harness owns the lifecycle.

A turn in plain language

1. The harness gives the model the objective, context, and available tools.
2. The model replies or requests a tool.
3. The harness checks the request.
4. The tool runs.
5. The result returns to the session.
6. The harness decides whether another turn is needed.

A production loop adds six questions:

• AuthorityIs the action permitted?
• ResultDid the tool succeed?
• ProgressDid the result move the task forward?
• CompletionHas external completion passed?
• BudgetHas the run hit a time, cost, or risk limit?
• DurabilityWhat state must survive before the next step?

Completion is evidence, not confidence

The failed invoice workflow treated "the model returned a final answer" as completion.

The corrected rule is visible to a PM:

The model may say it is done. The control plane checks whether the business state agrees.

Delegation creates a merge problem

Several agents add value when work has clear boundaries. They also create distributed state.

Each worker sees a version of the task. Those versions can diverge. A mature design defines inputs, outputs, shared state, conflict rules, and completion for every worker.

Multiple agents are useful only when the system can attribute a failure and reconcile their results without guessing.

10Interception: which crossing needs inspection?

A hook is a checkpoint in the loop. It can observe, validate, modify, pause, block, or redirect.

A rule asks; a control enforces

A prompt can say, "Do not issue refunds above the limit."

A permission check can block the refund tool. IAM can prevent the session identity from issuing it. The environment can keep payment credentials outside the process.

Use prose for conventions and judgment. Use enforceable controls for properties that must hold.

Use the cheapest verifier that works

Do not use another model to check what code can prove. Do not force code to judge what requires interpretation.

Vendor harnesses are product surfaces

Microsoft's 2026 GitHub Copilot integration shows a common architecture. Copilot owns the specialist coding loop. Agent Framework adds instructions, tools, middleware, approvals, streaming, and telemetry around it.

The build-versus-buy question has changed. A team can buy the specialist loop and keep local policy, evals, and approvals around it.

Ask two questions in every vendor review:

1. What does your harness own on every turn?
2. What can our team version, export, observe, and override?

A vague second answer means the vendor owns part of your product judgment.

11Observability and evals: what did the run mean?

• TraceRecords what happened.
• EvalJudges whether that behavior was acceptable.
• Feedback loopChanges the system based on that judgment.

A useful trace records task and tenant identity, model and harness version, context sources, tool calls, permission decisions, state changes, retries, cost, and completion evidence.

Sensitive payloads need separate access and retention. "Log everything" can create a second leak.

An invoice eval may ask:

1. Was the correct invoice selected?
2. Did evidence meet the matching rule?
3. Did the agent remain inside tenant scope?
4. Did every exception receive a valid state?
5. Did the final count match the ledger?

A dashboard can show that a call happened. An eval says whether the behavior was good.

Deep measurement design lives in AI Evals. The harness must make the run observable and connect the judgment to release decisions.

12View 3: Session, Harness, Sandbox

Runtime engineers need concrete service boundaries.

If the sandbox dies, the harness records a tool failure and can provision another environment.

If the harness dies, another worker can read the session and continue.

If model context fills, the harness can compact the view without deleting the durable event history.

MHTE tells you who owns a failure. Session, Harness, and Sandbox tell engineers which runtime service holds the state, decision, or execution involved.

13One file, four lenses

Take AGENTS.md in a coding repository.

• At restIt is a file in the environment.
• At startupThe harness reads it.
• In context assemblySelected text becomes model input.
• LaterA file tool may read or modify it.

The file has one primary home and several roles over time.

Ownership answers where it belongs. Lifecycle explains how its effect traveled through the run.

A stale rule can begin on disk, become inevitable when injected, become visible when the model follows it, and create a consequence when a tool acts.

14In practice: draw your system

Create one page with four columns: Model, Harness, Tools, Environment. Put Runtime underneath.

Inside Harness, add five rows: Identity, Memory Policy, Orchestration, Interception, Observability and Evals.

For each row, fill four fields:

Do not fix anything during the first pass.

A component with no owner is organizational debt. A decision with no component is accidental behavior.

You can now draw the machine. The next question is which small changes produce visible reliability gains without replacing the model. Episode 03 returns to the invoice workflow and changes four decisions: what a retry learns, which output shapes are allowed, which tools the model sees, and what evidence permits completion.