Agent Harness Architecture:
Convergence

§1. What is a harness: the 9-component model

"A harness is not designed for humans to build agents. A harness is designed for the agent to accomplish almost any task."

The modern agent harness was born bottom-up, from coding agents solving real tasks. Cursor, Claude Code, Windsurf, and Codex independently arrived at strikingly similar architectures. A harness is not a framework: it ships as a working agent. The iteration loop, context management, tool registry, and safety layer are already configured and running. There is no assembly step.

The harness closes the open loop of an LLM. Without a harness, the model is a one-shot text generator: it responds and stops. A model inside a harness can read a file, edit it, run tests, see errors, read the log, fix the code, and run tests again. Act → Observe → Adjust, a closed feedback loop.

"These nine components are not a wishlist. They are what every successful harness converged on independently. That convergence is the signal."

§2. Context management: the hardest subsystem

"Every agent harness runs into the same limit: the context window is too small for everything the model might want to remember."

Context management is where the real engineering lives. It's not about "what fits in the prompt." It's about a multi-layered system: file read caps, tool result budgets, offset/limit pagination, compaction triggers, deduplication, and memory persistence. The key design question: how much context management happens inside the harness, and how much does the model do itself.

All four analyzed harnesses (Pi, OpenClaw, Claude Code, Letta) make different choices, but converge on the same patterns. This is the most striking finding of the comparative analysis, not the differences, but the degree of agreement.

"50 years of computing taught us that the best memory management is the kind the program never thinks about. Registers, cache lines, page tables, swap. Each layer managed by the system, each invisible to the layer above."

§3. Session compaction: LLM summarization across 4 harnesses

"The goal is not to show the model everything. It is to give it the right working set at the right time and allow it to dynamically make decisions to manage its own context."

Compaction policy determines whether a long-running agent remains coherent or gradually degrades. Four harnesses demonstrate a spectrum of approaches, from simple head-tail split (Pi) to multi-stage staged summarization with reflection subagents (Letta).

Pi established the baseline pattern: LLM summarization, head-tail split (truncating old messages), token-based trigger. OpenClaw added a second layer: bootstrap caps + tool result budgets + multi-pass staged summarization. Claude Code introduced pre-query optimization (tool results to disk, 2KB previews) and a 9-section structured compaction prompt with re-attachment of up to 5 recently read files. Letta moved compaction server-side and added reflection subagents with a budget of 16,000 tokens.

Compaction in Hermes: lineage chain

Hermes implements a unique approach. Instead of repeatedly rewriting one transcript, on each compaction:

1. The current session row in SQLite is closed
2. A child session is created, seeded with the summary (seed: summary)
3. Session ID is rotated
4. Parent-child lineage is recorded

Summary budget: ~20% of compressed content, with a floor of 2,000 tokens and a ceiling of 12,000 tokens. The result, a lineage chain instead of one repeatedly rewritten transcript. This is unique relative to other architectures.

"If a long conversation compresses multiple times, you get a lineage chain instead of one repeatedly rewritten transcript. This is pretty unique relative to other harness architectures we've reviewed."

§4. Sub-agents and isolation

Sub-agents are the fourth component of the harness model. Patterns of spawning, isolation, and context inheritance differ, but the foundational principles are convergent.

Letta: 7 sub-agent types

Letta stands out with the richest set of built-in sub-agent types (7). Each type has isolated context, a specific tool allowlist, and a token budget. The reflection subagent is the most interesting: it runs every 25 messages, analyzes history, and updates the agent's persistent memory in MemFS.

Claude Code: 2 paths

Claude Code offers two paths for sub-agents: blank conversation (clean spawn) and fork (copying the parent transcript). The fork path is critical for tasks where the sub-agent needs the parent's context, for example, continuing a refactoring in the same codebase.

Hermes: delegate_task with future headroom

Hermes implements delegate_task with task ID and structured returns. Recursion is capped (configurable depth). But steering is block → return. Durable child-run control (run IDs, external steering, cleanup after parent exits) is an explicitly identified gap and "the most natural next architectural step."

§5. Swarm Management: delegation vs orchestration

"One thing has become clear: swarm management is the next real systems problem in AI. Not single agents. Not one-off tool calls. Managing swarms of long-running agents."

Delegation is not swarm management. Most frameworks can spawn sub-agents. That is the beginning of the problem, not its end. The real question: what happens after the child agent is created? Where does it live? Who owns it? Can it be addressed? Can it be steered? Can it complete after the parent has gone?

OpenClaw is the best example of swarm management in the ecosystem. Its sub-agents become gateway sessions with durable session keys, run IDs, lifecycle records, parent-child lineage, cleanup policy, and push-based completion.

"They treat completion as a return value. In a swarm manager, completion is a routing problem."

"Every swarm manager eventually becomes a cleanup system."

§6. Hermes: architectural deep-dive

"Hermes is one of the best open-source harnesses in the ecosystem right now."

Hermes implements all 9 components of the harness model, and adds three additional subsystems: messaging gateway, profile system, and cron as a first-class subsystem. The details are in how the components are implemented, and in what lies beyond this framework.

"Hermes already has excellent execution quality and a strong systems foundation for an open harness. It is probably one of the best open model harnesses in the ecosystem."

§7. iii Worker Model (Mike Piccolo)

"A harness is not a thing you install. A harness is a set of jobs your system has to do for an agent to run durably, safely and observably."

Mike Piccolo argues: the traditional harness form is wrong. It's not one thing, it's 10-12 different things bundled together. Every long-running agent team eventually rewrites their harness from scratch because frameworks ship it as a monolith. iii's bet: workers on a shared bus, each replaceable, each independently versioned.

The model: 15 jobs (tasks a production harness must perform) → 11 workers (independent processes) on a WebSocket bus. Each worker registers functions and triggers. Every layer is reachable via 1-2 function IDs on the bus.

Turn FSM: 7 states

The turn finite state machine has been collapsed from 11 to 7 states in the production version:

provisioning → assistant_streaming → function_execute → function_awaiting_approval → steering_check → (loop back or finishSession)

5 policy replacement examples (policy engine)

The policy engine is a replaceable worker. Any can be swapped without changing the rest of the system:

1. OpenAI safety classifier, worker calling the moderation endpoint
2. OPA (Open Policy Agent). Rego rules integrated via policy::check_permissions
3. Cedar (AWS), declarative access policies
4. Human-in-the-loop via Slack, approval-gate worker with Slack integration
5. Budget-aware routing, llm-budget worker decides which model to use

"That's the property the composition gives you: a major internal rewrite of one worker is a self-contained change because every neighbour talks to it through bus-level function ids."

"You don't adopt the iii harness. You install the workers you want, write the ones you need, and end up with a harness shaped exactly like your system."

§8. Sandboxes: from disposable evals to long-running swarms

"The harness is the application. The sandbox is the server."

The harness-to-sandbox relationship is the same as application-to-server. The harness reasons and calls tools; the sandbox provides isolated execution. They can be swapped independently. Sandbox evolution proceeds in two phases:

The two artifacts of restartability

Two things make a harness restartable:

1. Trajectory, the full record: questions, tool calls, decisions. The most valuable artifact.
2. Local data (filesystem), everything created/modified in the sandbox.

Anthropic frames this as "decoupling the brain from the hands." Brain = harness. Hands = sandbox. The session log lives outside both.

"The sandbox becomes cattle."

Sandbox market players

• Daytona, E2B, primary providers of disposable and persistent sandboxes
• Stripe Minions (Steve Kaliski), long-running agent swarms, own sandbox orchestration
• Browserbase (Kyle Jeong), long-running agent infrastructure
• iii, microVM sandbox (iii-sandbox) in the worker ecosystem

§9. The market and battle lines

"The ones who own the swarm management layer and the trajectory data will define this market."

The agent harness market is defined by three battle lines:

1. Labs vs Customer Infrastructure

Where does the control layer live? If at labs (Anthropic, OpenAI), they control the trajectory, model, observability, and upgrade path. If at the enterprise customer, the customer controls data, security, and compliance. This is a fundamental tension: enterprises cannot give labs access to production, but labs need data for improvement.

2. Swarm Control Layer

Who manages the agent swarm? OpenClaw shows that swarm management is a system inside the runtime. But who will manage cross-runtime swarms? Agents distributed across different harness instances, different organizations, different clouds? This is still an open problem.

3. Trajectory Ownership

Trajectory is the most valuable artifact. It makes work reproducible, auditable, and improvable. Control over trajectory = leverage in the future AI market. Current state: Claude Code and Cursor can restart from their own trajectories, but not from others'. There is no standard trajectory format.

"Control of the swarm and control of the trajectory state are the battle lines."

§10. Cross-sectional synthesis: what we know and what's next

"The next generation of tough technical problems in artificial intelligence are AI engineering systems problems."

8 convergent patterns

Identified gaps: what's next?

1. Swarm orchestration beyond delegation. Hermes gap: no durable child-run control. OpenClaw, the only one with full swarm management.
2. Standardized inter-harness communication. No cross-vendor protocol for agent-to-agent messaging.
3. Trajectory portability. No standard format for export/import of trajectories between harnesses.
4. Federated swarm management. Cross-runtime agent coordination between organizations/clouds.
5. Long-term memory beyond the session. Letta MemFS, the most ambitious approach, but the problem is unsolved.
6. Swarm-level cost optimization. Budgeting is individual (iii llm-budget), but not swarm-level.
7. Trajectory data security. No one has proposed a specific security model for trajectory (encryption at rest, access control, audit trails).
8. Sandbox standardization. Daytona, E2B, Stripe Minions, iii-sandbox, no common interface.
9. Observability and debugging for swarms. Understanding why agent #7 in a tree of 40 got stuck, an unsolved problem.
10. Governance. Hooks and permissions handle safety, but governance (who can spawn swarms, audit trail for decisions) is absent.

Data Compendium: all numbers

All authors and companies

Authors: Aparna Dhinakaran (Arize, articles 1, 2, 3, 4, 6), Mike Piccolo (iii, article 5).
Harnesses: Pi (pi-mono / earendil-works), OpenClaw, Claude Code (Anthropic), Letta (Letta Code), Hermes (Nous Research), iii (iii.dev).
Sandboxes: Daytona, E2B, Stripe Minions (Steve Kaliski), Browserbase (Kyle Jeong).
Tools: GrowthBook (feature flags Claude Code), Arize (observability, Alyx).
Contrast: LangChain, LangGraph, CrewAI, AutoGen, OpenAI Agents SDK, OPA, Cedar.
Products: Cursor, Windsurf, Codex.