Agent Harnesses Are a Layer, Not the Whole AI System

The term agent harness is becoming one of the most important—and most overloaded—ideas in AI architecture.

OpenAI is describing a shift toward harness engineering. Anthropic is publishing increasingly detailed work on long-running harnesses and managed agents. DeepSeek has released an open-source harness built around replaceable plugins. Agent SDKs now package loops, tools, sessions, guardrails, tracing, handoffs, sandboxes, and other runtime capabilities.

A terminology warning matters: these sources do not all use “harness” at exactly the same architectural scope. OpenAI's harness-engineering article focuses on the environment, knowledge, constraints, and feedback loops around coding agents; Anthropic and DeepSeek use the term more directly for runtime/orchestration machinery. This article treats them as related evidence about agent-system boundaries, not as one standardized definition.

This is useful progress. It also creates an architecture risk: treating the harness as if it were the entire AI system.

This article is a comparative synthesis, not a claim that Decision Crafters has invented or empirically validated a proprietary harness architecture. The purpose is to compare current patterns, make the ownership boundaries explicit, and state which conclusions remain open.

Decision Crafters' current view is more cautious.

A harness is best understood as an agent execution/runtime layer: the machinery that surrounds a model so it can receive context, call tools, observe results, continue across turns, and produce useful work. Depending on the implementation, the harness may also own sessions, retries, tracing, guardrails, handoffs, and other runtime responsibilities.

But many enterprise concerns do not disappear simply because the agent loop is sophisticated.

Identity, authority, policy, canonical business state, provenance, human acceptance, organizational memory, and outcome learning may need to exist outside or around that harness.

The architecture question therefore is not simply:

"Which agent harness should we use?"

It is:

"Which responsibilities should the harness own, which should remain separate, and how will the complete system preserve control and evidence as agent capability grows?"

What current implementations tell us

There is no single industry architecture for an agent harness today. That is a feature of the market worth understanding, not a gap to hide.

OpenAI: runtime abstractions around the loop

OpenAI's Agents SDK provides agents, tools, handoffs, guardrails, sessions, human-in-the-loop mechanisms, sandbox agents, and tracing around a built-in execution loop. Its documentation also makes the ownership boundary explicit: developers who want to own the loop, tool dispatch, and state handling can use the underlying Responses API directly.

That tells us something important: the harness is an architectural choice about runtime ownership, not merely a model wrapper.

Anthropic: separate session, harness, and sandbox

Anthropic's Managed Agents work draws an especially useful boundary. It models a session as the durable event log, the harness as the loop that calls Claude and routes tool calls, and the sandbox as the execution environment.

That decomposition makes failure and replacement easier to reason about. A harness can fail and restart because the durable session exists outside it. A sandbox can be replaced because it is treated as an execution environment rather than the source of truth.

Anthropic also makes another point architecture teams should pay attention to: harness logic can encode assumptions about model limitations, and those assumptions can go stale. A mechanism introduced to compensate for one model's behavior may become dead weight as later models improve.

This means a harness should not only be extensible. It should also be simplifiable.

DeepSeek: everything is a plugin

DeepSeek Harness takes a different approach. Its model adapter, tool registry, session log, agent loop, and other subsystems are replaceable through its plugin architecture.

That is a compelling example of composability. It should not be mistaken for a universal requirement. "Everything is a plugin" is one answer to the extensibility problem, not proof that every production harness should expose the same boundary.

DeepSeek itself currently describes the project as developer preview and warns that compatibility-breaking changes should be expected. That makes it valuable architecture evidence and an interesting ecosystem, while also arguing against treating current implementation details as settled standards.

A practical architecture map

For architecture reviews, Decision Crafters finds it useful to separate at least four layers conceptually:

1. Model layer
   reasoning / generation / model-native capabilities

2. Agent harness / runtime layer
   context assembly / turn loop / tool routing / runtime state / recovery / tracing

3. Execution and platform-control layer
   sandboxing / credentials / infrastructure / network boundaries / policy enforcement / integrations

4. Governed application / organizational layer
   identity / canonical domain state / authority / approvals / provenance / decision history / outcome learning

This is a review model, not a claim that every system requires four products or four separately deployed services.

A small internal assistant might collapse several layers into one application. A high-consequence enterprise agent may need explicit boundaries between them.

The value of the model is that it forces the architecture team to ask who owns each responsibility.

Questions an architecture team should ask

1. What survives a harness restart?

If the harness process disappears, which state is durable?

Can the system reconstruct what happened, or does important truth exist only in model context or process memory?

2. Who decides what the agent is allowed to do?

Does the model effectively grant itself capability by selecting a tool, or is there an independent permission/policy boundary?

For low-consequence tasks, simple runtime checks may be sufficient. For higher-consequence tasks, identity, authority, approval, and policy often deserve explicit treatment.

3. Where are credentials and execution isolated?

If the agent executes generated code, accesses files, or calls production systems, what limits the blast radius?

Anthropic's separation of harness and sandbox and DeepSeek's confinement work both reinforce the idea that execution boundaries should be reasoned about independently from model reasoning.

4. What is context, and what is canonical state?

A context window is not a database. Retrieval is not automatically memory. A session transcript is not automatically an accepted business decision.

Architecture teams should define which information is transient working context and which information must become durable, governed state.

5. How will you know whether the agent actually succeeded?

A fluent final answer is not the same as a correct outcome.

Anthropic's evaluation guidance makes this distinction explicit: the transcript is what the model and tools did; the outcome is the resulting state of the environment. Evaluation infrastructure should measure the latter when the task has externally verifiable effects.

6. Which harness mechanisms are compensating for today's models?

Every additional planner, retry loop, context reset, evaluator, checkpoint, or routing heuristic should have a reason to exist.

As model behavior changes, some of those mechanisms may become unnecessary. Architecture review should therefore include a complexity-removal test, not only a feature-addition path.

Build, adopt, or compose

Decision Crafters does not assume that building a custom harness is the sophisticated choice.

Adopt

Use an established runtime when it provides the capabilities you need, fits your security and portability requirements, and reduces undifferentiated engineering.

Build

Build a custom harness when runtime semantics themselves are strategic or unusual—for example, when the organization needs a specific provider-neutral loop, deterministic state machine, policy boundary, execution model, or experimental architecture that existing frameworks cannot represent cleanly.

Compose

Compose smaller services when the harness should not become the owner of the entire AI system. A team may deliberately keep state, policy, evaluation, sandboxing, or business workflow outside the harness behind stable interfaces.

The correct answer is evidence-dependent.

When a reference implementation is warranted

Decision Crafters does not believe every architecture article needs a homegrown framework attached to it.

A reference implementation becomes useful when code can materially strengthen, narrow, or falsify an architectural claim.

For example, if research suggests that durable session state should survive independently of the harness, a small reference implementation could test recovery behavior across harness failure. If research suggests that policy enforcement must remain separate from the agent loop, a reference system could test whether that separation materially improves containment, auditability, or portability.

That is different from building "another agent framework" because the topic is popular.

The reference application is evidence first. Productization, open-source maintenance, and commercial investment are separate decisions.

The Decision Crafters position today

Our current synthesis is deliberately modest:

Treat the agent harness as a replaceable execution/runtime layer within a larger AI-system architecture. Let the problem determine whether state, policy, sandboxing, evaluation, authority, and organizational memory belong inside the harness or behind separate interfaces. Prefer the smallest architecture that preserves the required control and evidence.

This is not a claim that every AI application needs a full governance platform. Some systems need only a lightweight loop and a few tools.

It is a claim that architecture teams should avoid allowing framework convenience to decide system boundaries accidentally.

As the harness ecosystem matures, those boundaries will continue to move. That makes the subject worth tracking as architecture—not just as tooling news.

What remains unresolved

Several questions are still open enough that Decision Crafters would not treat today's synthesis as settled doctrine:

whether session state should usually remain outside the harness or whether integrated runtime state is sufficient for many workloads;
when policy and authorization need an independently governed service rather than runtime guardrails;
which sandbox/confinement boundaries remain portable across coding, browser, infrastructure, and business-process agents;
which harness mechanisms are durable architectural primitives versus temporary compensations for current model behavior;
and whether emerging platform-harness patterns will converge on a stable boundary between agent runtime and enterprise control planes.

These are research questions, not reasons to delay using existing harnesses where they already fit the problem.

If you are reviewing an AI system

If your organization already has agents, agent SDKs, MCP integrations, orchestration frameworks, or custom runtimes, the useful question may not be whether to replace them.

It may be whether the current architecture makes the right responsibilities explicit:

what the model reasons about;
what the harness controls;
what the execution environment permits;
what state is canonical;
what evidence is retained;
where human or organizational authority enters;
and what can be replaced without destabilizing the rest of the system.

That is the kind of question the Decision Crafters AI & Platform Architecture Diagnostic is designed to examine: the architecture you actually have, the constraints you actually operate under, and the smallest defensible changes worth considering.