Suraj Khaitan

Posted on Sep 27

Agent Harness : Complete Guide

#ai #claude #agents #rag

The model decides what to do next. The harness decides what the agent can see, where it can act, what survives a crash, which actions require approval, and whether the result can be trusted. In 2026, that surrounding system is becoming the real platform for agentic software.

Research and product status checked September 27, 2026.

The Model Did Not Fail. The System Around It Did.

Imagine an agent working through a six-hour task.

It has read a repository, changed fourteen files, opened a browser, called two internal APIs, generated a report, and paused for approval before publishing it.

Then the process crashes.

What happens next?

Does the agent resume from a durable checkpoint, or start over? Are the fourteen modified files still available? Does it remember that the publishing action was approved? Can it tell which API call completed before the crash? Will it accidentally perform the same payment, deployment, or customer update twice? Can an operator reconstruct what happened without reading private reasoning traces?

None of those questions is answered by the model.

They are answered by the agent harness.

For the last two years, the industry conversation has concentrated on model intelligence: reasoning scores, coding benchmarks, context windows, multimodality, and tool-use accuracy. Those things matter. But as agents move from short demonstrations to work that lasts minutes or hours, the bottleneck is shifting.

The hard problem is no longer just getting a model to choose the next action. It is building a runtime that can safely carry thousands of actions across failures, context resets, approval pauses, changing infrastructure, and model upgrades.

That is why the most important agent releases of 2026 look increasingly like operating-system work:

Anthropic's Managed Agents separates the session, harness, and sandbox so each can fail or be replaced independently.
OpenAI's Agents SDK now includes sandbox agents, manifests, persistent workspaces, snapshots, permissions, memory, compaction, tracing, and resumable execution.
Google ADK 2.0 moved from a hierarchical agent executor to an event-driven graph runtime with retries, state, human pauses, and resumability.
Microsoft Agent Framework now includes an explicitly named Harness Agent for long, multi-step tasks alongside durable workflows and OpenTelemetry.
LangGraph describes itself as an orchestration runtime and distinguishes that layer from higher-level agent harnesses.

Different vendors use different names, but they are converging on the same architecture.

The model is becoming a replaceable decision engine. The harness is becoming the application runtime.

This article explains what that means, which components belong in a modern harness, where the current platforms differ, and how to design one that survives more than a demo.

TL;DR

An agent is not just a model with tools. In production, it is a model running inside a harness that owns execution, state, context, permissions, verification, and recovery.
A harness is broader than an agent loop. The loop asks the model what to do next. The harness determines where that action runs, whether it is allowed, how its result is recorded, and how the task resumes.
The session must outlive the process. Durable event history, checkpoints, and artifacts should survive harness crashes, worker replacement, human pauses, and context compaction.
The session is not the context window. The session is the recoverable source of truth. The context is a temporary, selected view assembled for one model turn.
The workspace is separate state. Files, repositories, generated artifacts, and installed dependencies need their own lifecycle, isolation, snapshot, and retention rules.
Tool protocols are not harnesses. MCP standardizes how tools and context are exposed. A2A standardizes communication between agents. Neither supplies the complete runtime, policy, recovery, or evaluation layer.
Resume implies distributed-systems semantics. Tools may execute at least once. Side-effecting actions therefore need idempotency keys, deduplication, and recorded outcomes.
Security depends on architecture, not prompt wording. Credentials should remain outside untrusted sandboxes, privileges should be scoped per session and tool, and consequential actions should cross explicit approval gates.
Evaluation must cover trajectories. A correct final answer can hide wasteful, unsafe, or accidental behavior. Evaluate tool selection, state transitions, retries, approvals, cost, and the final outcome.
Portability is layered. Models, tools, skills, state, traces, and deployment each have different switching costs. A provider-neutral model adapter does not make the whole agent portable.
The strategic asset is the harness contract. Models will keep changing. Durable state, tool contracts, policies, evals, and operational evidence are what let a team adopt better models without rebuilding the product.

First, Stop Calling Everything an Agent Framework

The agent ecosystem has accumulated overlapping terms: SDK, framework, harness, runtime, workflow, protocol, platform, and agent.

Treating them as synonyms creates architectural confusion.

Layer	Primary job	Typical examples
Model	Predict or reason about the next response or action	Claude, GPT, Gemini, open-weight models
Agent	Combine a model, instructions, and tools around a goal	Researcher, coding agent, support agent
Workflow	Define an explicit path between steps	Sequence, branch, parallel fan-out, approval flow
Framework / SDK	Give developers abstractions to define agents and workflows	OpenAI Agents SDK, Google ADK, Microsoft Agent Framework
Harness	Supply the opinionated behavior around an agent	Planning, context policy, tools, memory, verification, permissions
Runtime	Execute and operate agent work over time	Scheduling, events, persistence, resume, sandbox lifecycle, telemetry
Protocol	Standardize communication across boundaries	MCP for tools and context; A2A for agent communication

The boundaries are not perfectly clean. A product can provide several layers. OpenAI's Agents SDK includes both agent abstractions and runtime behavior. Claude Managed Agents provides a configurable harness plus managed infrastructure. Google ADK combines framework and runtime. LangGraph intentionally stays lower-level, while Deep Agents adds a more opinionated harness above it.

The distinction still matters because each layer answers a different question.

The model asks: what should happen next?
The workflow asks: which paths are permitted?
The harness asks: what capabilities, context, and controls shape the work?
The runtime asks: how does that work execute reliably over time?
The protocol asks: how do components communicate without custom integration for every pair?

In a toy agent, these layers fit inside one Python process. In a production agent, they become separate systems with separate failure modes.

What Changed in 2026

Early agent implementations often looked like this:

while not done:
    response = model(messages, tools=tools)
    result = execute(response.tool_call)
    messages.append(result)

That loop is still present. It is just no longer the interesting part.

The current generation of platforms is building around four realities that simple loops hide.

1. Work outlives one model context

A long task can cross several context windows. Compaction helps, but it is lossy. A summary that seemed unimportant at hour one may contain the detail required at hour five.

Modern systems therefore persist a complete or recoverable session outside the prompt and construct each context from that durable history.

2. Work outlives one process

Containers crash. Deployments roll. WebSockets disconnect. Humans take hours to approve an action. A harness that keeps its only state in memory cannot support serious asynchronous work.

The execution process must become disposable while the task remains durable.

3. Work changes the environment

An agent does not only produce messages. It edits files, installs packages, creates artifacts, opens browser sessions, and changes external systems. Conversation history alone cannot recreate that world.

The runtime needs an explicit workspace lifecycle: initialize, isolate, inspect, snapshot, resume, and destroy.

4. Work crosses trust boundaries

Tool output can contain prompt injection. Generated code can be hostile by accident or design. Credentials can escape through shell access. Retried actions can duplicate side effects.

The harness has become a security and transaction boundary, not just an orchestration helper.

This is the shift: agent engineering is becoming runtime engineering.

The Reference Architecture: Brain, Harness, Session, and Hands

Anthropic's April 2026 Managed Agents architecture offers the clearest vocabulary for this transition.

It separates four things:

Brain: the model making decisions.
Harness: the loop that assembles context, calls the model, and routes actions.
Session: the durable event log recording what happened.
Hands: sandboxes and tools that perform work.

Conceptually:

                         +----------------------+
                         | Human / Application  |
                         +----------+-----------+
                                    |
                              events / control
                                    |
                         +----------v-----------+
                         | Durable Session Log  |
                         | state, approvals,    |
                         | outputs, checkpoints |
                         +----------+-----------+
                                    |
                              wake(session_id)
                                    |
        +---------------------------v---------------------------+
        |                    Stateless Harness                  |
        | context assembly | model calls | policy | routing     |
        +-----------+--------------------+----------------------+
                    |                    |
             inference request       typed tool call
                    |                    |
             +------v------+      +------v----------------------+
             |    Model    |      | Replaceable Hands           |
             |   Brain     |      | sandbox | browser | MCP/API |
             +-------------+      +-----------------------------+

The important property is replaceability.

If a sandbox dies, the harness receives a failed tool result and can provision another environment. If the harness process dies, another worker can reload the session and continue. If the model changes, the runtime contract can remain stable. If a customer needs execution in its own VPC, the hands can move without forcing the brain to move with them.

Anthropic reports that decoupling these components reduced p50 time to first token by roughly 60 percent and p95 by more than 90 percent because a sandbox no longer had to be provisioned before every session could begin. Those figures describe Anthropic's own architecture, not a general benchmark, but the design lesson transfers:

Do not make expensive, stateful infrastructure a prerequisite for a model turn that may not need it.

Provision hands lazily. Persist the session independently. Treat harness workers as replaceable.

The Session Is Not the Context Window

This is the most important boundary in a long-running harness.

A session is the recoverable history of the task.

A context window is the temporary material selected for the next model call.

They should not be the same object.

The session may contain:

every user and agent event;
tool calls and validated results;
approval requests and decisions;
state transitions and checkpoints;
references to files and artifacts;
model, prompt, policy, and tool versions;
errors, retries, and stop reasons; and
summaries or memory artifacts derived from earlier work.

The context should contain only what the current turn needs:

the active goal and current plan;
relevant constraints and policies;
selected recent events;
retrieved facts or files;
compacted history;
available tool descriptions; and
unresolved errors or approval state.

Anthropic's Managed Agents stores the session as a durable event stream and lets the harness select slices of it. LangGraph separates thread-scoped checkpoints from cross-thread stores. Google ADK's runner processes events and commits state through services before execution resumes. OpenAI separates conversational sessions, runner state, sandbox session state, workspace snapshots, and file-based memory.

The products differ, but the principle is consistent:

Durability preserves the truth. Context engineering chooses the useful view of that truth.

If compaction overwrites the only copy of old messages, recovery depends on a lossy summary. If raw history is always replayed, cost and distraction grow without bound. Keeping durable history and prompt context separate lets the harness change its context strategy as models improve.

That matters because harness assumptions expire. Anthropic described adding context resets to address premature stopping in an earlier model, then finding that the same workaround became unnecessary with a later model. The durable session should remain stable while context policies evolve.

The Workspace Is a First-Class Runtime Object

Conversation state tells the agent what happened. Workspace state contains the work itself.

For coding, document processing, data analysis, and research, the workspace may include:

a checked-out repository;
user-provided documents;
generated source files;
intermediate datasets;
installed dependencies;
screenshots and browser artifacts;
test reports; and
the final deliverables.

OpenAI's current Sandbox Agents model makes this boundary explicit:

A SandboxAgent defines instructions and capabilities.
A Manifest defines the starting workspace contract.
A sandbox session is the live environment where commands and edits occur.
SandboxRunConfig determines whether to create, inject, or resume that environment.
Session state reconnects to a particular backend.
A snapshot seeds a fresh environment with previously saved workspace contents.

This is more than an SDK convenience. It forces useful design decisions.

What belongs in the initial workspace?

Only the files, repositories, mounts, task specifications, and helper material required for the job. A narrow manifest improves security, startup time, and model legibility.

What must persist?

Final artifacts, accepted edits, progress records, and anything required to resume. Temporary caches and package directories usually do not deserve indefinite retention.

Who owns cleanup?

The runtime can own a sandbox for one run, or the application can retain it across several runs. Ownership must be explicit so environments do not leak resources or disappear before outputs are collected.

What does "sandbox" actually guarantee?

The name is not the guarantee. OpenAI's documentation warns that its Unix-local backend on Linux runs commands as host processes without OS-level confinement. Separate directories are not equivalent to container or VM isolation. For untrusted work, use a properly configured Docker or hosted backend and control network access as well as filesystem access.

The broader lesson is simple:

A workspace is a security boundary, a state boundary, and a billing boundary. Treat it as an API, not a temporary folder.

Durable Execution Changes the Meaning of a Tool Call

Once an agent can resume after failure, tool execution becomes a distributed-systems problem.

Suppose a payment tool charges a card successfully, but the worker crashes before recording the result. On resume, the harness sees an incomplete step and calls the tool again.

The model did nothing irrational. The runtime lacked a reliable transaction boundary.

Google ADK's resumability documentation makes the issue explicit: completed tool results can be reinstated, but tools are guaranteed to run at least once, not exactly once. A tool interrupted around the persistence boundary may run more than once after resume.

Exactly-once execution is usually an application-level illusion built from several controls:

Assign a stable operation ID before executing the side effect.
Pass that ID as an idempotency key to the downstream system.
Record intent before dispatch where appropriate.
Record the result and external transaction ID durably.
On retry, query or deduplicate instead of blindly executing again.
Require reconciliation for ambiguous outcomes.

A production tool contract should therefore include more than a name and JSON schema.

Tool Contract
  identity        stable tool and operation names
  authorization   actor, session, scopes, policy decision
  input           typed and validated parameters
  idempotency     operation key and duplicate behavior
  timeout         maximum execution time
  retry policy    retryable errors and backoff
  result          typed success, failure, and ambiguity states
  evidence        external IDs, receipts, logs, or artifact references
  compensation    reversal or recovery path when available

Read-only search can tolerate loose semantics. Payments, deployments, customer messages, access changes, and deletion cannot.

If a framework advertises resumability, ask the next question immediately:

"What are the replay and side-effect semantics of my tools?"

Security: Keep Credentials Away From the Hands

An agent sandbox processes untrusted material and may execute model-generated code. Putting broad credentials inside it turns any successful prompt injection into a credential-theft path.

Anthropic's Managed Agents architecture addresses this structurally. Repository credentials can be attached during initialization without being exposed as general-purpose tokens. MCP OAuth credentials remain in a vault and are used by a proxy outside the sandbox. The harness and generated code do not need direct access to the secret.

A strong production pattern looks like this:

Agent proposes action
        |
        v
Harness validates schema and policy
        |
        v
Credential broker checks:
  user + session + environment + tool + resource + approval
        |
        v
Broker performs call or issues a narrow, short-lived credential
        |
        v
Sanitized result returns to agent

This creates several useful properties:

The sandbox cannot enumerate every credential available to the platform.
A tool receives only the authority needed for one operation or short session.
Approval can be bound to the exact action rather than a broad capability.
Revoking one session does not require rotating a developer's personal token.
Audit records can connect the human initiator, agent session, policy decision, and external side effect.

Prompt instructions such as "never reveal secrets" are still useful, but they are not a security boundary. The architecture should make secret theft difficult even when the model is confused or manipulated.

Human Approval Must Be Durable Too

Human-in-the-loop is often presented as a button: approve or reject.

In a long-running harness, approval is a state machine.

The runtime needs to persist:

the exact proposed action;
the normalized parameters;
the policy that triggered review;
the requesting agent and session;
the approver's identity and decision;
expiration or revocation conditions; and
whether the approved action was actually executed.

The action presented for approval must be the action executed afterward. If the model can change the recipient, amount, command, or target environment after approval, the gate is decorative.

A robust flow binds approval to a hash or immutable operation object:

PROPOSED -> POLICY_REVIEW -> WAITING_FOR_HUMAN
                                  |
                         approve / reject / expire
                                  |
                    APPROVED -> EXECUTING -> RECORDED

The harness process may disappear while waiting. The session must not. When a worker wakes the task later, it should resume from the recorded state rather than ask the model to reconstruct what was approved.

This is another reason in-memory chat history is not enough.

Frameworks Are Converging, but Their Centers of Gravity Differ

The current platforms increasingly provide the same primitives, but they do not make the same tradeoffs.

Platform	Center of gravity	Notable current capabilities
Claude Managed Agents	Managed long-horizon harness and infrastructure	Durable event history, cloud or self-hosted sandboxes, built-in tools, MCP, persistent files, compaction, steering, interruption, scheduling
OpenAI Agents SDK	Lightweight SDK growing into a workspace-aware runtime	Agent loop, handoffs, guardrails, sessions, HITL, tracing, MCP, sandbox manifests, permissions, snapshots, resume, memory, compaction
Google ADK 2.0	Multi-language graph and event runtime	Graph workflows, dynamic routing, events, services, sessions, state, artifacts, resumability, retries, observability, trajectory evaluation, A2A
Microsoft Agent Framework	Enterprise agent and workflow framework	Harness Agent, planning, todo tracking, compaction, files, memory, tool approvals, middleware, graph workflows, checkpointing, HITL, OpenTelemetry, hosted deployment
LangGraph	Low-level orchestration runtime	Durable execution, checkpoints, stores, streaming, interrupts, time travel, stateful graphs, deployment; higher-level harnesses sit above it

This is not a winner table. It is a boundary table.

Claude Managed Agents is attractive when a team wants the provider to operate the loop and sandbox infrastructure for asynchronous work. Its current beta has data-retention implications: Anthropic states that Managed Agents is not presently eligible for Zero Data Retention or HIPAA BAA coverage because session history, sandbox state, and outputs persist server-side.

OpenAI's SDK gives developers more direct control over agent and sandbox lifecycle, including local, Docker, hosted, and mounted-workspace patterns. That flexibility also means the developer must understand what each backend actually isolates.

Google ADK 2.0 makes workflow state and routing central. Python 2.0 became generally available on May 19, Go on June 30, and TypeScript on August 21, 2026. Its migration to a graph runtime is evidence of the broader shift: agents, tools, and functions are now nodes managed by an execution engine rather than objects inside a simple hierarchy.

Microsoft's current documentation, updated in August 2026, goes further in naming the product boundary. Its Harness Agent packages planning, todo tracking, context compaction, file access, memory, reusable tool approvals, and observability for long tasks, while workflows provide explicit graph control and durability.

LangGraph remains intentionally lower-level. It provides persistence, human interrupts, and durable graph execution without prescribing the agent's planning or filesystem behavior. LangChain's own documentation describes Deep Agents as a harness built above LangGraph.

Choose based on the control boundary you need, not the length of the feature list.

MCP Is a Port, Not the Operating System

MCP is now present across most serious agent stacks. That does not make it an agent harness.

MCP standardizes how a client discovers and calls tools, reads resources, and uses prompt-like capabilities exposed by a server. The current official specification release is dated July 28, 2026.

That solves an important integration problem. A team can expose GitHub, databases, internal services, or SaaS applications through a common protocol instead of writing a bespoke adapter for every agent client.

But MCP does not decide:

which model sees which tools;
how tool descriptions fit into a finite context;
whether a call requires approval;
where credentials are stored;
how retries and idempotency work;
how session state is checkpointed;
where generated code executes;
when a task is considered complete; or
how traces and evaluations are retained.

Those are harness responsibilities.

The same applies to A2A. It can standardize how independently hosted agents communicate and delegate. It does not define the internal runtime or security posture of either participant.

A useful analogy is:

MCP is a peripheral and service interface.
A2A is a process-to-process communication interface.
The harness is the operating environment using those interfaces.

Protocols reduce integration coupling. They do not remove the need for runtime design.

Evaluation Must Test the Journey, Not Only the Answer

Traditional model evaluation often scores the final response. An agent can produce the correct response through an unacceptable trajectory.

It might:

call a privileged tool unnecessarily;
retrieve data from the wrong tenant;
retry an expensive operation twelve times;
expose sensitive content to an external model;
skip a required approval;
complete by accident after ignoring tool errors; or
spend $40 on a task worth $2.

Google ADK's evaluation system reflects this difference by separating final-response evaluation from tool-trajectory evaluation. It supports expected tool paths, rubric-based tool-use quality, multi-turn task success, trajectory quality, groundedness, and conformance testing against recorded behavior.

A harness evaluation suite should cover at least five dimensions:

Outcome

Did the task complete correctly? Did deterministic acceptance checks pass? Are artifacts complete and usable?

Trajectory

Were the right tools chosen in a reasonable order? Did the agent recover from injected failures? Did it avoid prohibited paths?

Safety and policy

Were tenant boundaries, approvals, data handling, and privilege constraints respected?

Reliability

Could the task resume after process failure, sandbox replacement, model timeout, or human delay without corrupting state or duplicating actions?

Economics

What were the turns, tokens, tool calls, wall-clock time, infrastructure cost, and human review time per verified success?

The unit under test is not the prompt or model response.

It is the model-harness pair operating against a task and environment.

This also changes model selection. A model that scores slightly lower in isolation may produce better production outcomes because it uses your tools more reliably, follows approval boundaries, compacts cleanly, or recovers from structured errors with fewer turns.

Portability Is Not One Checkbox

Many platforms advertise model flexibility. That is valuable, but switching the model endpoint is only the first layer of portability.

An agent system has at least six portability surfaces:

Surface	Portable when...	Common source of lock-in
Model	Requests, tool schemas, and outputs have stable adapters	Provider-specific reasoning, caching, or tool APIs
Tools	Contracts use standard schemas or MCP and preserve semantics	Hosted tools with unique behavior or auth models
Skills / instructions	Knowledge is stored in files with clear discovery rules	Proprietary packaging and hidden system prompts
State	Sessions, checkpoints, and artifacts can be exported and replayed	Opaque managed threads and vendor-only event formats
Policy and approval	Decisions live in an external policy layer	Guardrails embedded only in SDK callbacks
Observability and evals	Traces use open schemas and eval sets are framework-independent	Platform-only spans, judges, and dashboards

The goal is not zero dependency. Managed runtimes can remove enormous operational burden. The goal is intentional dependency.

Keep the parts that express business truth portable:

acceptance scenarios;
tool contracts;
policy rules;
idempotency behavior;
audit requirements;
artifact formats; and
representative evaluation cases.

Those assets let you test a new model or runtime honestly. Without them, "multi-provider support" means little because you cannot tell whether the replacement behaves correctly.

Build or Buy the Harness?

There are now three sensible choices.

Use a managed harness

Choose this when speed, long-running execution, managed sandboxes, and minimal infrastructure matter more than complete runtime control.

Best fit:

asynchronous research or coding tasks;
teams without an agent-platform group;
standard tool and workspace requirements;
workloads compatible with the provider's retention and compliance model.

Questions to ask:

Can sessions and artifacts be exported or deleted?
Can execution run in our infrastructure?
Where do credentials live?
What is the isolation boundary?
What are pause, resume, retry, and billing semantics?

Use an SDK or orchestration runtime

Choose this when you need custom state, policies, workflows, infrastructure, or model routing but still want tested primitives for turns, tools, checkpoints, tracing, and human input.

This is where OpenAI Agents SDK, Google ADK, Microsoft Agent Framework, and LangGraph are strongest, with different levels of opinion.

Build the critical runtime yourself

Choose this only when requirements justify owning scheduling, event persistence, sandbox provisioning, credential brokerage, policy enforcement, and recovery.

Reasons may include:

strict data residency;
unusual execution environments;
deeply custom transaction semantics;
provider-independent control planes;
regulated audit requirements; or
scale where platform economics materially change.

Building an agent loop is easy. Building a secure, resumable, observable runtime is not. Be honest about which one you are volunteering to maintain.

A Production Blueprint

A practical harness can be designed as eight cooperating planes.

1. Definition plane

Version the agent's model policy, instructions, tools, skills, output schema, and acceptance criteria. A running session should reference immutable versions so an incident can be reproduced.

2. Session plane

Store an append-only or equivalently auditable event history. Include state transitions, approvals, tool outcomes, checkpoints, model and policy versions, and artifact references.

3. Context plane

Construct each model input from the goal, current state, relevant events, retrieved knowledge, compacted summaries, and available tools. Measure context size and retrieval quality.

4. Execution plane

Provision isolated workspaces and route tool calls. Separate trusted control code from model-generated code. Define snapshot, resume, retention, and cleanup behavior.

5. Identity and policy plane

Bind each run to a human or service identity. Apply least privilege, network policy, data classification, tool authorization, and immutable approval objects.

6. Reliability plane

Use timeouts, retry classes, idempotency keys, checkpoints, dead-letter handling, cancellation, and explicit terminal states. Test worker and sandbox failure deliberately.

7. Evidence plane

Capture structured traces, logs, metrics, costs, artifacts, policy decisions, and external transaction IDs. Redact sensitive content without destroying operational usefulness.

8. Evaluation plane

Run outcome, trajectory, safety, recovery, and economic evaluations against versioned task sets. Compare model-harness combinations, not marketing benchmark rows.

No individual plane needs to be elaborate on day one. Each needs an explicit owner and contract.

Seven Questions to Ask Before Production

1. Can the task survive the loss of any worker?

If not, identify which state remains process-local and move it to a durable session, checkpoint, or artifact store.

2. Can the context policy change without rewriting history?

Preserve raw or recoverable events separately from summaries and prompt assembly.

3. Can every side effect be retried safely?

If not, add idempotency, deduplication, preconditions, or a human reconciliation state.

4. Can generated code reach credentials?

If yes, redesign the boundary. Prefer brokers and proxies that perform authorized actions without revealing reusable secrets.

5. Can an approval be replayed against a different action?

Bind the decision to immutable normalized parameters, scope, approver, and expiration.

6. Can you explain a failure from external evidence?

You should not need hidden chain-of-thought. Events, tool calls, results, state changes, policy decisions, and stop reasons should reconstruct the operational story.

7. Can you evaluate a model replacement before migrating?

Keep representative tasks and harness-level metrics. Otherwise model portability is a hope, not a capability.

What I Would Build in the First 30 Days

Week 1: Define the contracts

Choose one bounded, valuable task.
Write deterministic acceptance criteria where possible.
Define typed tool inputs, outputs, error classes, and side-effect semantics.
Classify data and actions by risk.
Decide what the session, context, workspace, and long-term memory each contain.

Week 2: Make execution durable and contained

Persist events and explicit run states.
Add cancellation, deadlines, turn and cost limits.
Run tools in an appropriate sandbox or brokered service boundary.
Add idempotency keys to consequential tools.
Test resume after killing the harness process mid-task.

Week 3: Add control and evidence

Introduce policy checks before tool execution.
Implement durable human approval for high-impact actions.
Export structured traces with model, tool, state, and cost events.
Store final artifacts separately from conversational history.
Test secret exposure and prompt-injection paths.

Week 4: Evaluate the complete system

Build a small set of normal, edge, adversarial, and recovery scenarios.
Score outcomes and trajectories.
Inject tool timeouts, malformed results, duplicate delivery, and sandbox failure.
Compare at least two model configurations inside the same harness.
Establish a release gate based on verified task success, safety, and cost.

At the end of the month, the goal is not maximum autonomy. It is a system whose failures are bounded, recoverable, and explainable.

The Real Moat Is Not the Wrapper Code

Calling the harness a moat can sound like claiming that a few orchestration functions are strategically valuable.

They are not.

The durable advantage is the accumulated operational knowledge encoded around them:

which context helps on each task;
which tool interfaces the model uses correctly;
which actions require human judgment;
which errors are safe to retry;
which state must survive;
which tests define real completion;
which traces predict failure;
and which model-harness combinations deliver verified outcomes at an acceptable cost.

That knowledge compounds because it survives model upgrades.

A stronger model can be dropped into a mature harness and immediately benefit from years of tool design, policy, evaluation, and operational evidence. A frontier model dropped into an immature harness still lacks reliable state, safe authority, recovery, and proof.

This is why benchmark leadership does not automatically become product leadership. The deployed unit is not the model. It is the model plus its harness, tools, data, policies, and runtime.

Final Take

The first generation of agent development asked whether a model could reason, use a tool, and repeat.

The current generation asks harder questions:

Can the work survive a crash?
Can it resume without duplicating side effects?
Can the execution environment be replaced independently?
Can credentials remain outside untrusted code?
Can a human pause, inspect, approve, and redirect the task?
Can the system prove what happened?
Can a new model be evaluated without rebuilding the application?

Those are runtime questions.

The major agent platforms are converging because production pressure leaves little choice. Durable sessions, event-driven execution, isolated workspaces, resumability, policy gates, tracing, and trajectory evaluation are moving from advanced features to baseline infrastructure.

Models will continue to improve quickly. Harness assumptions will become obsolete. Tools and protocols will evolve. The winning architecture is therefore not the one with the most elaborate fixed scaffold.

It is the one with stable boundaries:

session separate from context;
brain separate from hands;
policy separate from generated code;
approval separate from execution;
durable truth separate from temporary workers;
and business evaluation separate from any one vendor.

The model supplies intelligence.

The harness turns that intelligence into a system you can operate.

In 2026, the harness is no longer the wrapper around the product. The harness is the product's runtime.