Stop Comparing Agent Frameworks — First Decide Whether You Need a Product, a Chassis, or a Workflow
DeepSeek Harness, Codex, Claude Code, LangGraph: How to Choose — First Determine Whether You Lack a Product, a Chassis, or a Workflow
"Which is stronger: DeepSeek Harness, Codex, Claude Code, or LangGraph?"
This question seems straightforward, but it conflates three different procurement targets: a ready-to-use Coding Agent product, a deeply recomposable Agent Runtime, and a state graph explicitly orchestrated by developers.
If the comparison axis is wrong, a more detailed feature list is more misleading. "All have tools, plugins, Subagents, and persistence" does not prove they solve the same problem, nor can it yield a ranking of performance, cost, or success rate.
This article does not provide a ranking. It answers a single architectural decision: When a team is preparing to build Agent capabilities, should it prioritize a mature product, a recomposable chassis, or an explicit workflow Runtime?
The final output is an adoption decision matrix used to determine which layer of complexity should be borne by the product, the Runtime, the workflow, or the team itself.
Step 1: Determine Which Layer of Capability You Are Buying
We can first place the four subjects back within their respective public boundaries.
| Subject | Primary Boundary | Main Composition Unit | State and Recovery Focus | Work Assumed by the Team |
|---|---|---|---|---|
| DeepSeek Harness | A recomposable Agent Runtime in Developer Preview | Cordis Plugin, Capability Seam, Profile/Bundle/Patch | Append-only Session Event, derived Surface, Goal/Job/Subagent | Composition, version freezing, regression, security, and productization |
| OpenAI Codex | An Agent product and embedding capability for software engineering work | CLI, non-interactive exec, App Server, MCP, configuration and approvals |
Product task/session, Turn, runtime environment, Sandbox and approvals | Configuring rules, permissions, and engineering acceptance |
| Claude Code | A terminal Coding Agent product and its extension ecosystem | Plugin, Skill, Agent, Hook, MCP Server | Product Session, independent Subagent Context, Hook lifecycle | Project rules, plugins, and permission governance |
| LangGraph | A low-level orchestration Runtime for building long-running, stateful Agents/Workflows | Graph, Node, Edge, Functional API | Checkpoint, Thread, Store, Interrupt, durable execution | Business state graph, node semantics, recovery, and deployment |
This table marks the complexity each subject assumes for the team by default. Real systems may still combine multiple subjects.
Codex and Claude Code have already packaged "how to get work done in a code repository" into a product experience. DeepSeek Harness exposes more underlying primitives as a unified plugin graph. LangGraph requires developers to explicitly write business steps, state, and recovery points as a graph or functional workflow.
Choose Codex: When You First Need a Product That Can Enter the Engineering Workflow
OpenAI's official documentation positions the Codex CLI as a tool for inspecting, editing, and running code in the terminal, and it can also enter repeatable scripts and CI via codex exec. The App Server provides a protocol boundary for embedding Codex into a product. Sandboxing, network control, and approvals are part of the product's security contract.
Codex organizes models, tool execution, repository operations, approvals, and multiple product entry points into a working system oriented toward software engineering.
Scenarios suitable for prioritizing Codex:
- The team needs to get an Agent into a real repository as quickly as possible, rather than designing a Runtime first.
- Clear entry points are needed, such as an interactive terminal, non-interactive automation, and embedded protocols.
- OS Sandboxing, network boundaries, and human approval must become part of the daily product workflow.
- The team prefers configuring rules and acceptance criteria over maintaining its own Agent Loop, Session, and plugin loader.
The cost is equally clear: the product will decide a portion of the core semantics for you. You can extend tools, MCP, rules, and working methods, but this does not mean every layer of the Runtime can be substituted downward with the same plugin mechanism.
Therefore, one cannot infer from DeepSeek Harness having "more replaceable layers" that it is better at completing coding tasks than Codex. Nor can one infer from Codex's more complete product loop that it is suitable for hosting arbitrary business Agent Runtimes. Without experiments that unify the model, task, environment, permissions, and budget, neither inference holds.
Choose Claude Code: When You Need a Team Extension Surface on Top of Stable Product Semantics
Claude Code officially defines a Plugin as a distributable extension directory that can combine Skills, Agents, Hooks, and MCP Servers. A Subagent runs in an independent Context Window and can have its tools and permissions restricted. Hooks execute deterministic commands at specific lifecycle points and also support Prompt/Agent Hooks that require judgment. The official Sandbox documentation treats Bash filesystem and network isolation as a dedicated security surface.
This forms a different extension focus from DeepSeek Harness:
- Claude Code first provides a Coding Agent product, then allows teams to add capabilities around the product lifecycle.
- DeepSeek Harness incorporates the Agent Loop, Session, LLM Adapter, Tool Registry, and Surface into the same Cordis plugin semantics.
Both are called "plugins," but the layer to which a plugin can replace, who owns the lifecycle, and which states are built-in product facts are different.
Scenarios suitable for prioritizing Claude Code:
- The team's main work surface is still a terminal Coding Agent.
- There is a desire to make project rules, specialized Agents, Hooks, and MCPs distributable team assets.
- An independent Subagent Context is needed to isolate search, logging, and implementation tasks.
- Greater value is placed on in-product extension rather than recombining the underlying Agent Runtime.
Extension governance determines whether this capability can safely enter the team workflow. Hooks can run commands automatically, Plugins carry Agents, Skills, and Servers, and Subagents involve independent tools and permissions. The team still needs to review the source, permissions, versions, and lifecycle, and must not misinterpret "official plugin support" as "any plugin is inherently trustworthy."
Choose LangGraph: When Business Processes Must Be Explicit, Pausable, and Recoverable
LangGraph officially defines itself as a low-level orchestration framework and Runtime for building long-running, stateful Agents, with a focus on durable execution, streaming, human-in-the-loop, and persistence. It allows mixing deterministic steps with LLM-driven steps within the same Graph.
Its state contract is more explicit than a general Agent Loop:
- The Checkpointer saves the Graph State of a Thread.
- The Store saves application data across Threads.
thread_idis the pointer for restoring the same Checkpoint.interrupt()can pause execution inside a Node, save the state, and wait for external input before resuming via the same Thread.- Upon resumption, the Node will re-execute from the beginning, so side effects before the interruption point must be considered for idempotency.
This type of semantics is very suitable for approval flows, cross-system business processes, reviewable state transitions, and deterministic recovery. However, it will not automatically decide what constitutes a good Coding Agent product for you, nor will it automatically provide a general Plugin Tree like DeepSeek Harness.
Scenarios suitable for prioritizing LangGraph:
- Business steps, approval points, and recovery boundaries must be explicitly visible.
- Deterministic nodes and open-ended Agent nodes need to be mixed.
- State must be persisted per Thread and support fault recovery or human interruption.
- The team is willing to define State Schema, Nodes, Edges, Checkpoints, and side-effect idempotency.
The cost is that you bear more orchestration responsibility. Writing a Graph does not mean the nodes are internally safe, the model is reliable, or tool side effects are rollback-able. A persistent Checkpoint also does not mean external system transactions are automatically consistent.
Choose DeepSeek Harness: When You Truly Need to Build a Multi-Product Agent Chassis
The previous seven articles have already frozen the main facts for the fixed DeepSeek Harness commit 47f9438:
- The Agent Loop, Session, Tool Registry, LLM Adapter, and product Surface are all within the Cordis plugin graph.
- A Plugin's Effects can be recycled in reverse order upon unloading, and dependency changes can trigger Consumer re-runs.
- Turn, Step, Tool, and failure events enter explicit Session Event semantics.
- The raw append-only Log is separated from the model-visible Surface; Compaction works by replacing the visible interval rather than rewriting history.
- A Tool enters the world of Approval, Guard, Provider, and side effects from its Schema; successful registration does not equal safety.
- Subagent, Job, and Goal manage child Agents, background producers, and long-term objectives of the same Session, respectively.
- Profile, Bundle, and Patch can deliver the same Runtime as Web, Headless, and SDK, but the final plugin tree and host contract must be frozen.
The distinctiveness of this design comes from the reversible plugin lifecycle and event semantics: changes that are typically scattered across core classes, configuration, SDK, and UI are placed within a single set of composition boundaries.
Scenarios suitable for prioritizing research into DeepSeek Harness:
- The team is building multiple Agent product surfaces, not just buying one Coding Agent.
- Models, tools, storage, the Agent Loop, the Surface, or the execution world need to be replaceable.
- There is a willingness to maintain internal Distributions, Profiles, Patches, regression matrices, and source-level diagnostics.
- The migration cost of a Developer Preview is acceptable, and versions are strictly frozen.
Scenarios not suitable for a direct heavy bet:
- Only a working coding assistant is needed.
- The team lacks the capability to maintain a plugin graph and version compatibility.
- High-privilege production tasks require proven cross-platform isolation, long-session recovery, and audit loops.
- Out-of-the-box complete Benchmarks, production SLOs, or cross-machine scheduling proofs are expected.
As of 2026-08-19, the official master is still at 99f6f02f, and npm/PyPI is currently at rc7. The dynamic version facts and the fixed rc5 source baseline must be separated; today's package version cannot be retroactively written as the behavior of the fixed commit.
The Four Are Not a Mutually Exclusive Choice
Real systems may combine these subjects, but combination creates new boundaries.
For example, LangGraph could manage the outer approval and business state, delegating an open-ended Agent node to DeepSeek Harness. Alternatively, Codex or Claude Code could serve as the engineering task product, calling an existing company LangGraph service.
Before combining, state and cancellation semantics must be aligned:
- Who owns the Task ID, Session ID, and Thread ID.
- When the outer layer cancels, whether the inner Turn, Job, or tool side effects stop.
- When the outer Checkpoint replays, whether commands already executed by the inner layer are idempotent.
- How the two sets of logs are correlated into a single Trace.
- Whether human approval belongs to product approval, Graph Interrupt, or tool Guard.
- Which layer is responsible for the final completion judgment and resource accounting.
If these questions have no answers, a dual Runtime will only turn a recoverable system into a dual state machine.
An Adoption Decision Matrix
| Your Primary Problem | Priority Candidate | Reason | Must Verify Before Proceeding |
|---|---|---|---|
| Get an Agent into a real code repository quickly | Codex or Claude Code | Product entry points, repository workflows, and permission experience are already formed | Target repo permissions, command boundaries, real task success rate, and human intervention |
| Build distributable terminal Agent extensions | Claude Code | Plugin/Skill/Agent/Hook/MCP are explicit team assets | Plugin source, Hook side effects, Subagent permissions, and version governance |
| Build multiple Agent products sharing underlying semantics | DeepSeek Harness | Agent Core and product Surface can both enter a unified plugin graph | Fixed version, valid configuration, migration regression, real model E2E, and security boundaries |
| Build explicit approval, recovery, and business state flows | LangGraph | Graph/Checkpoint/Thread/Interrupt directly express the workflow | State Schema, persistence backend, Node idempotency, and external transactions |
| Only need a simple, short-lived Agent | Start with a simpler solution | Building your own Runtime or Graph may add unproductive complexity | Whether a single-process script, off-the-shelf product, or small state machine is already sufficient |
| Need both a product Agent and a deterministic business flow | Combine, but define state ownership first | Two types of tools solve problems at different levels | ID mapping, cancellation propagation, Checkpoint/side effects, unified Trace |
The matrix only decides "what to validate first," not a substitute for a PoC. The final choice should still be measured under the same model, tasks, permissions, tools, budget, and environment.
Four Things That Should Not Be Compared
Without a unified experiment, the following conclusions should not be drawn:
- Whose task success rate is higher.
- Whose Token or total cost is lower.
- Whose latency is smaller.
- Who is more suitable for all teams to enter production.
Architectural openness, feature count, GitHub popularity, a single demo, and official product maturity cannot substitute for these four actual measurements.
A more reasonable evaluation should fix the model and Provider, task set, repository snapshot, tools, permissions, Sandbox, retries, human intervention, and scorer. Separately record success rate, time consumed, Tokens, tool calls, failure types, recovery count, and side-effect correctness.
Conclusion
The main difference between DeepSeek Harness, Codex, Claude Code, and LangGraph lies in who bears which layer of complexity for the team:
- Codex and Claude Code are first and foremost directly usable Coding Agent products.
- DeepSeek Harness is first and foremost a recomposable Agent product chassis.
- LangGraph is first and foremost an explicit state and workflow Runtime.
If the team lacks delivery efficiency, choose a product first. If it lacks underlying reuse for multiple products, research Harness. If it lacks explicit approval and recovery, choose Graph. If a simple script is already sufficient, do not forcibly introduce any complex Runtime for the sake of architectural completeness.
First determine whether the team lacks a delivery product, a multi-product chassis, or a recoverable workflow, then verify real tasks with a PoC under identical conditions. The complexity not assumed by the chosen system should be explicitly left on the team's own acceptance checklist.
References
- DeepSeek Harness fixed Commit
47f943859bef60e4160492346772ded9b24f765aand the reviewed source mapping from the previous seven articles in the series. - Dynamic snapshot of the official DeepSeek Harness repository and registry, checked on 2026-08-19.
- OpenAI Docs: Codex CLI, Non-interactive mode, App Server, Agent approvals & security.
- Claude Code official documentation: Plugins, Subagents, Hooks, Sandboxing.
- LangGraph official documentation: Overview, Persistence, Interrupts.