The Big Agent Harness Architecture Comparison
Many harnesses, different jobs.
A field map of where real agent systems place control, state, authority, recovery, and proof—compared on common responsibilities, not a leaderboard.
Start with a baseline
A harness in six responsibilities
A beginner conceptual decomposition that makes the minimum work around a model visible without claiming production completeness.
A model response is not completion. The loop is only the beginning; production systems must also locate authority, recovery, evidence, and acceptance.
- Admitnot establishedAdmission is a production question beyond the beginner loop.
- AssembleownedThe host assembles instructions
- BindownedThe host exposes tools and translates their schemas for the model.
- RunownedThe loop alternates model output and tool results until a stop condition.
- Recovernot establishedCrash recovery is not established by the conceptual decomposition.
- Verify and closenot establishedOutcome verification and human acceptance remain outside the baseline.
An 8-minute comparison lesson
Choose a comparison lens
Compare the same questions across systems, while preserving different product boundaries and explicit unknowns.
- Job
- What work is this system actually trying to own?
- Control
- Who decides what happens next?
- State
- What survives the current model call?
- Authority
- Who may cause which effects?
- Recovery
- Where can interrupted work re-enter?
- Verification
- What evidence can establish the result?
- Deliberate omission
- Which responsibility stays outside the system?
Shared axes, different boundaries
Read across, not down
The table asks the same questions of every system. A narrow memory layer can therefore be studied honestly beside a coding harness without pretending they are substitutes.
| System | Primary job | Control | Durable state | Authority | Recovery | Verification | Deliberate omission |
|---|---|---|---|---|---|---|---|
| Claude Code | Help a developer inspect, change, and reason about a codebase from the terminal. | The public source establishes an agentic product surface, not its complete internal control loop. | Durable session state and its internal owner are not established by the current public source. | Exact tool binding and permission enforcement are not established by the current public source. | Interruption and crash recovery semantics are not established by the current public source. | Git workflow support is documented, while project acceptance remains external. | It does not own the repository's definition of done or protected merge policy. |
| DeepSeek Harness and Cordis | Run one coding agent with inspectable context, capability, session, approval, persistence, and plugin lifecycle seams. | A concrete agent loop owns turns and steps while Cordis services and plugins supply most runtime responsibilities. | Normalized session events are durable facts from which requests, trajectories, persistence views, and interfaces can be reconstructed. | Host policy, approvals, guards, sandbox providers, and credentials bound execution within a declared single-operator developer-preview trust model. | Durable steps close on cancellation or request error, persistence repairs interrupted turns, and plugin lifecycles drain owned work before teardown. | Extensive repository checks verify implementation contracts; project outcome acceptance and production readiness remain external. | The runtime does not supply a whole-product acceptance authority, prove plugin cleanup semantics, or establish production multi-tenant security. |
| Gemini CLI | Bring model-guided coding and research work into a terminal workspace. | The CLI runtime coordinates model turns, built-in tools, and configured extensions. | Session and project context support continuity; the complete durability contract needs deeper inspection. | The CLI mediates local tools while extensions can widen the effective capability boundary. | Checkpoint and resume behavior must be separated from ordinary conversational continuity. | Tool results and checks inform the run; external project policy decides acceptance. | The CLI does not own application-specific completion policy or deployment acceptance. |
| OpenAI Codex | Carry out coding work inside a developer-controlled local workspace. | The public README establishes a local coding agent, not its complete internal control loop. | Session durability and its internal owner are not established by the current inspected path. | Sandbox, approval, and capability-binding semantics require a deeper source inspection. | Session recovery and external-effect reconciliation require a deeper source inspection. | Project checks, review, and acceptance remain outside the documented repository summary. | Codex does not replace project-specific review, CI, protected merge, or product acceptance. |
| OpenHands | Give software agents a workspace in which to inspect, change, and run code. | The agent runtime coordinates model decisions and actions inside the workspace. | Runtime events and workspace state divide conversational continuity from execution state. | The contained workspace bounds many actions, while integrations can extend effects beyond it. | Durable task and workspace behavior depends on the selected runtime and deployment path. | The agent can exercise code in its environment; external review still owns final acceptance. | A contained workspace does not prove that a software task meets its external acceptance criteria. |
| LangGraph | Make long-running agent control flow and state transitions explicit. | The graph runtime owns node scheduling and transitions declared by the application. | Checkpoints and thread-scoped state provide durable continuity across graph execution. | Application code defines nodes and tools; deployment policy controls their effective permissions. | Persisted checkpoints support resume and replay, subject to replay-safe node and effect design. | The graph can route to validators, but it does not invent the application's acceptance criteria. | Graph structure alone does not make external side effects idempotent or outcomes correct. |
| Letta | Keep an agent's state and memory available across interactions and applications. | The Letta server mediates agent execution, persistent state, memory, and tool-facing behavior. | Server-managed agent state and memory persist beyond a single model context window. | Agent tools and application permissions define effects outside the memory and runtime layer. | Persistent server state provides re-entry, while effect recovery remains capability-specific. | The runtime can preserve and inspect state; application outcomes still require external validation. | Persistent memory does not by itself establish truth, permission, or outcome completion. |
| Graphiti | Preserve changing knowledge with temporal structure for agent applications. | The calling application owns the run loop; Graphiti owns graph ingestion and retrieval operations. | Episodes, entities, relationships, and temporal facts form the durable graph state. | The application decides which sources may enter memory and how retrieved facts influence action. | Graph state persists independently; recovery of an interrupted agent run stays external. | Graph queries can surface provenance and time, but application outcomes require separate proof. | Graphiti does not own agent control flow, action permissions, or outcome closure. |
| Mem0 | Give an application a reusable memory layer across model sessions. | The calling application owns the agent loop; Mem0 owns memory operations behind its API. | Memory records persist separately from the application's transient conversation state. | The caller controls when memory is written, retrieved, and allowed to influence action. | Durable memory survives sessions, but recovery of agent work belongs to the calling runtime. | Retrieval quality can be evaluated; real-world action and completion are outside the service. | Mem0 does not own the model loop, execution environment, or application acceptance policy. |
Architecture gallery
See each system in its own shape
This is a working field map. Each profile uses the same visual grammar, but unsupported responsibilities remain external, delegated, or explicitly unestablished.
01
Frontier coding harness
Claude Code
Help a developer inspect, change, and reason about a codebase from the terminal.
Inspected 16440d0f6ee8 · FD · deep dive needed
- AdmitownedThe product accepts an interactive coding request from the developer.
- AssembleownedThe product builds model context from the conversation and codebase.
- Bindnot establishedComplete tool binding and permission enforcement are not established here.
- RunownedThe product executes coding tasks through its documented agentic surface.
- Recovernot establishedSession continuation and complete crash semantics are not established here.
- Verify and closeexternalRepository checks and human review remain final arbiters of completion.
- Control
- The public source establishes an agentic product surface, not its complete internal control loop.
- State
- Durable session state and its internal owner are not established by the current public source.
- Authority
- Exact tool binding and permission enforcement are not established by the current public source.
- Recovery
- Interruption and crash recovery semantics are not established by the current public source.
- Verification
- Git workflow support is documented, while project acceptance remains external.
02
Frontier coding harness
DeepSeek Harness and Cordis
Run one coding agent with inspectable context, capability, session, approval, persistence, and plugin lifecycle seams.
Inspected 47f943859bef · IP · refresh needed
- AdmitownedThe concrete loop admits session input into a turn and preserves even rejected zero-step attempts.
- AssembleownedPlugins assemble prompt sections
- BindownedCordis services compose tools
- RunownedA concrete turn and step loop streams the model and dispatches bounded
- RecoverownedSession facts
- Verify and closeexternalRepository checks cover runtime contracts while the developer or product owner accepts the outcome.
- Control
- A concrete agent loop owns turns and steps while Cordis services and plugins supply most runtime responsibilities.
- State
- Normalized session events are durable facts from which requests, trajectories, persistence views, and interfaces can be reconstructed.
- Authority
- Host policy, approvals, guards, sandbox providers, and credentials bound execution within a declared single-operator developer-preview trust model.
- Recovery
- Durable steps close on cancellation or request error, persistence repairs interrupted turns, and plugin lifecycles drain owned work before teardown.
- Verification
- Extensive repository checks verify implementation contracts; project outcome acceptance and production readiness remain external.
03
Frontier coding harness
Gemini CLI
Bring model-guided coding and research work into a terminal workspace.
Inspected 5411f113cafa · FD · deep dive needed
- AdmitownedThe CLI accepts a request inside its configured project environment.
- AssembleownedProject context and conversation are compiled for the model.
- BindownedBuilt-in and configured extension tools form the capability surface.
- RunownedThe CLI iterates model responses and tool results.
- Recovernot establishedSession continuity exists but complete interruption recovery needs deeper verification.
- Verify and closeexternalProject checks and human review remain outside universal CLI closure.
- Control
- The CLI runtime coordinates model turns, built-in tools, and configured extensions.
- State
- Session and project context support continuity; the complete durability contract needs deeper inspection.
- Authority
- The CLI mediates local tools while extensions can widen the effective capability boundary.
- Recovery
- Checkpoint and resume behavior must be separated from ordinary conversational continuity.
- Verification
- Tool results and checks inform the run; external project policy decides acceptance.
04
Frontier coding harness
OpenAI Codex
Carry out coding work inside a developer-controlled local workspace.
Inspected 343074d4207d · FD · deep dive needed
- AdmitownedThe product accepts a coding request on the developer's computer.
- Assemblenot establishedComplete context assembly is not established by the current inspected path.
- Bindnot establishedTool binding
- RunownedThe documented coding agent runs locally on the developer's computer.
- Recovernot establishedSession and effect recovery are not established by the current inspected path.
- Verify and closeexternalProject checks
- Control
- The public README establishes a local coding agent, not its complete internal control loop.
- State
- Session durability and its internal owner are not established by the current inspected path.
- Authority
- Sandbox, approval, and capability-binding semantics require a deeper source inspection.
- Recovery
- Session recovery and external-effect reconciliation require a deeper source inspection.
- Verification
- Project checks, review, and acceptance remain outside the documented repository summary.
05
Frontier coding harness
OpenHands
Give software agents a workspace in which to inspect, change, and run code.
Inspected 4bf8dd3aaf12 · FD · refresh needed
- AdmitownedThe platform receives a software task and creates an agent workspace.
- AssembleownedTask and runtime events become model-visible context.
- BindownedThe runtime exposes development tools through the contained workspace.
- RunownedAgent decisions and environment actions advance through the controller.
- Recovernot establishedDeployment and runtime configuration determine durable recovery guarantees.
- Verify and closeexternalTests may run inside the workspace while acceptance remains project-owned.
- Control
- The agent runtime coordinates model decisions and actions inside the workspace.
- State
- Runtime events and workspace state divide conversational continuity from execution state.
- Authority
- The contained workspace bounds many actions, while integrations can extend effects beyond it.
- Recovery
- Durable task and workspace behavior depends on the selected runtime and deployment path.
- Verification
- The agent can exercise code in its environment; external review still owns final acceptance.
06
Stateful agent runtime
LangGraph
Make long-running agent control flow and state transitions explicit.
Inspected f09cfe8ffc1e · FD · refresh needed
- AdmitdelegatedThe application decides which work enters a graph run.
- AssembleownedGraph state is projected into the input for each scheduled node.
- BinddelegatedApplication nodes bind models and tools to graph transitions.
- RunownedThe runtime schedules nodes and transitions through declared graph state.
- RecoverownedCheckpoints and interrupts provide a durable re-entry point.
- Verify and closedelegatedApplication-defined validators and policy decide whether the graph may finish.
- Control
- The graph runtime owns node scheduling and transitions declared by the application.
- State
- Checkpoints and thread-scoped state provide durable continuity across graph execution.
- Authority
- Application code defines nodes and tools; deployment policy controls their effective permissions.
- Recovery
- Persisted checkpoints support resume and replay, subject to replay-safe node and effect design.
- Verification
- The graph can route to validators, but it does not invent the application's acceptance criteria.
07
Stateful agent runtime
Letta
Keep an agent's state and memory available across interactions and applications.
Inspected 87fd37aab68c · FD · refresh needed
- AdmitownedThe server resolves a request to a persistent agent identity.
- AssembleownedWorking messages and selected memory form model context.
- BinddelegatedApplication configuration supplies the agent's external tools and permissions.
- RunownedThe runtime coordinates model turns with state and memory updates.
- RecoverownedPersistent agent state supports continuity across sessions and clients.
- Verify and closeexternalApplication policy must verify the real-world outcome of agent action.
- Control
- The Letta server mediates agent execution, persistent state, memory, and tool-facing behavior.
- State
- Server-managed agent state and memory persist beyond a single model context window.
- Authority
- Agent tools and application permissions define effects outside the memory and runtime layer.
- Recovery
- Persistent server state provides re-entry, while effect recovery remains capability-specific.
- Verification
- The runtime can preserve and inspect state; application outcomes still require external validation.
08
Memory framework
Graphiti
Preserve changing knowledge with temporal structure for agent applications.
Inspected 993e081a6d79 · FD · deep dive needed
- AdmitexternalThe application decides which events and work may enter the system.
- AssembledelegatedGraphiti retrieves structured facts while the caller builds model context.
- BindexternalThe application owns non-memory tools and action permissions.
- RunexternalThe calling harness owns the model and tool loop.
- RecoverdelegatedThe graph persists knowledge but not the caller's complete run state.
- Verify and closeexternalThe caller verifies actions and accepts completion.
- Control
- The calling application owns the run loop; Graphiti owns graph ingestion and retrieval operations.
- State
- Episodes, entities, relationships, and temporal facts form the durable graph state.
- Authority
- The application decides which sources may enter memory and how retrieved facts influence action.
- Recovery
- Graph state persists independently; recovery of an interrupted agent run stays external.
- Verification
- Graph queries can surface provenance and time, but application outcomes require separate proof.
09
Memory framework
Mem0
Give an application a reusable memory layer across model sessions.
Inspected 9b565da8e3f1 · FD · deep dive needed
- AdmitexternalThe calling application decides whether work may begin.
- AssembledelegatedMem0 returns memories while the caller assembles final model context.
- BindexternalThe application binds action tools and their permissions.
- RunexternalThe calling harness owns model execution and continuation.
- RecoverdelegatedMemory persists while task recovery remains outside the memory service.
- Verify and closeexternalThe application verifies actions and decides completion.
- Control
- The calling application owns the agent loop; Mem0 owns memory operations behind its API.
- State
- Memory records persist separately from the application's transient conversation state.
- Authority
- The caller controls when memory is written, retrieved, and allowed to influence action.
- Recovery
- Durable memory survives sessions, but recovery of agent work belongs to the calling runtime.
- Verification
- Retrieval quality can be evaluated; real-world action and completion are outside the service.
How this comparison was made
Boundaries before features
Agent systems are often compared as feature lists even when they own different parts of the work. Normalize each system across job, control, state, authority, recovery, verification, and deliberate omission before comparing it. A normalized diagram can still invent equivalence if an unsupported responsibility is silently marked as owned.
The first edition favors major, instructive systems with official public sources. Profiles marked “deep dive needed” are useful working maps, not final dossiers; their open questions are preserved inside each profile.