Agent Harness Coding Paradigm#

On the evening of August 13, 2026, DeepSeek delivered a “lightning double strike”: while releasing the official version of the DeepSeek-V4-Pro-0813 model, it quietly open-sourced the DeepSeek Harness Developer Preview v0.1. Within 48 hours of going live, it surpassed 93,000 GitHub Stars, and on its first day alone, it set a new record for AI open-source projects with approximately 37,500 Stars. At the same time, OpenAI also announced the open-sourcing of Codex’s Agent Harness. The two AI giants almost simultaneously focused their attention on the same concept—Harness (Agent Runtime). This is no coincidence, but a signal of a profound paradigm shift in the field of AI programming.

I. What is Harness? Why Has It Suddenly Become Important?#

Harness literally translates to “harness”—the set of reins and tack fitted onto a horse. The metaphor is apt: the model is a powerful horse, but you need a set of reins and a carriage to make it pull a load and get work done. DeepSeek’s official website provides a straightforward equation:

Agent = Model + Harness

The model is responsible for thinking and reasoning, while the Harness handles all the engineering work outside the model:

• Execution capabilities: reading and writing files, executing commands, calling external services
• Context management: compressing, filtering, and injecting the massive amount of intermediate information accumulated during long tasks
• Permission control: which directories can be touched, which commands require approval
• State persistence and error recovery: resuming and retrying after task interruption
• Loop and stop conditions: when to continue and when to wrap up
• Observability: recording the input and output of every step for troubleshooting

You can think of Harness as the operating system shell for AI—it determines what the model can see, which tools it can invoke, how context is organized, how to retry upon errors, and when to judge that a task is complete.

Why Has Harness Suddenly Become So Important?#

As model evaluation shifts from “single-turn Q&A” toward “real-world engineering tasks,” the Harness itself has become an important variable affecting evaluation results. A well-designed Harness can enable a mid-level model to perform excellently on complex tasks, while a poorly designed one can cause a top-tier model to fail frequently. This is precisely why DeepSeek chose to open-source Harness simultaneously with the official release of V4 Pro—model capabilities and the runtime framework must co-evolve.

From a macro perspective, the AI engineering paradigm is undergoing its third leap:

DeepSeek Harness is one of the representative works of the third leap.

Martin Fowler—one of the most respected voices in software engineering—published an article in 2026 coining the term “Harness Engineering,” marking Harness’s elevation from engineering practice to a formal engineering paradigm.

II. Two Harness Approaches#

Currently, two fundamentally different Harness approaches exist in the market.

Approach One: “Product-First”#

Represented by Claude Code and OpenAI Codex. Essentially, they have turned Harness into a closed-source finished product—tools, Skills, session management, and sandboxes are all encapsulated in a single shell. What you get is a fully furnished apartment; you cannot knock down walls or change the layout.

Claude Code aims to “make the best Agent product within the current paradigm,” targeting maximum effectiveness, simplicity, and pushing the boundary of model capabilities.

Approach Two: “Framework-First”#

Represented by DeepSeek Harness (dsh). What it does is equivalent to open-sourcing the construction drawings and all prefabricated components of that fully furnished apartment, telling you “knock down any wall you like, swap any part you want.”

DeepSeek Harness is open-sourced under the MIT license, and its core philosophy can be summed up in five words: Everything is a Plugin. This is not marketing speak—model adapters, tool registries, session logs, and the Agent Loop itself can all be replaced. The official team put it in very hardcore terms:

“There is no privileged kernel that requires patching.”

Comparison with Mainstream Competitors#

To put it figuratively, Claude Code is a fully furnished apartment, ready to move in; DeepSeek Harness is a bare workshop with all the tools provided, but you have to assemble the furniture yourself.

III. A New Coding Paradigm: From “Writing Code” to “Orchestrating Agents”#

The emergence of Harness is fundamentally changing the way software is developed.

3.1 From “Writing Scripts” to “Orchestrating Agents”#

In the past, when we wrote code, we told the computer what to do line by line. Now, with Agent Harness, the developer shifts from being a “person who writes code” to a “person who orchestrates Agents.” You no longer need to implement every detail; instead, you enable Agents to autonomously complete complex coding tasks through configuration and composing plugins.

DeepSeek Harness comes with four runtime modes pre-installed, each representing a different plugin combination scheme:

PTC (Programmatic Tool Calling) Mode#

PTC mode is one of the most technically innovative features among the four. Traditional tool calling is “one turn, one call”: the model decides to invoke a tool, waits for the result, then decides the next step. PTC mode allows the model to first generate a segment of TypeScript code, which then orchestrates multi-turn tool calls. For example, the model can write a piece of code: first query the file list, check the content of each file, and decide whether to modify based on matching results—the entire process is completed within a single model request, reducing the latency and context consumption of multi-turn conversations.

The four modes are essentially four Profiles (configuration combinations). A Profile is a named combination stored in the Harness home directory; it lists the Bundles to be stacked, any external plugins held, and retains the user’s own configuration files. A Bundle is a distribution format for Cordis configuration lines and the code they mount—whatever it inserts can be overridden by an upper-layer patch. You can view the actual configuration tree the machine boots with via the following command:

dsh --profile web --dump-config

Any line printed by this command can be replaced by your own patch—no need to fork the source code, just change the configuration.

3.2 Model-Agnostic: Freely Choose the Optimal “Brain”#

DeepSeek Harness is designed to be completely unbound from its own models. It has official built-in DeepSeek model access, while also supporting providers such as Anthropic and OpenAI, as well as any OpenAI-compatible custom endpoint. Model configuration changes take effect on the next request without requiring a service restart.

For custom providers (corporate gateways, self-hosted servers, etc.), you only need to select “Add Custom Provider” and fill in the Provider ID, Base URL, API protocol, credentials, and at least one model. You can freely choose the most suitable model based on task type and cost budget:

• Let Claude write complex logic
• Let DeepSeek handle low-cost batch processing
• Let GPT-4 perform final code review

What is even more astonishing is that Harness can even treat Claude Code and Codex as sub-Agents to invoke. By parsing the corresponding binaries in PATH, Harness can delegate tasks to these top-tier coding Agents for execution.

A competitor’s product has become one’s own component.

Relationship with MCP#

The two operate at different layers. MCP is an open standard connecting AI applications with external data, tools, and workflows; Harness is the higher-level runtime logic. An MCP Server can become a plugin within Harness.

3.3 Session as Event Stream: Reproducible, Debuggable, Evolvable#

Another core design of DeepSeek Harness is the append-only session log—one of the most distinctive features of the entire framework.

Everything the model sees enters the same append-only log, including:

• System prompts
• Reasoning / thinking content
• Tool calls and their results
• Sub-Agent scheduling
• Every context injection

Developers can inspect this information by source in the Trajectory view. Session recovery, forking, retrieval, and playback are all built upon this same event stream.

A key runtime invariant in the architecture documentation states:

Model-visible means logged. Anything that reaches a model request must be reconstructible from the log; the runtime asserts this.

This design first solves observability. When an Agent task fails, the problem could lie in model judgment, tool returns, context injection, scheduling strategy, or system prompts. If these contents are scattered across different components, it is difficult for developers to reconstruct what the model actually saw at that moment. A unified event stream provides a common script for debugging, evaluation, and playback.

It also provides a more natural data structure for session forking: a new branch can reuse events prior to the fork point, then append new context and actions, without overwriting the original history. For a system that emphasizes plugin replaceability, this is particularly important—because developers need to compare the performance of different Loops, tools, or scheduling plugins on the same task trajectory.

3.4 Security Sandbox: Letting Agents Safely “Get Their Hands Dirty”#

The fact that Agents can read and write files and execute commands brings tremendous convenience, but also tremendous security risks. DeepSeek Harness has built a multi-layered sandbox mechanism:

Tool calls in DeepSeek Harness are split into an extensible pipeline, which is the core of the entire framework’s security design:

Hook pre-interception → Approval manual review → Permission permission check → Sandbox sandbox isolation → Execute actual execution → Rewrite result rewriting → Record logging + UI

Before a request is executed, it passes through Hook, approval, permission checks, sandbox, and timeout controls; after execution, results can be rewritten, logged, and rendered in the UI. Developers can insert plugins at various stages without modifying the tools or the Agent Loop.

A core concept in the architecture is called a Seam—a swappable capability comprising three roles:

1. Service Definition: Declares the interface
2. Service Provider: Implements the interface
3. Consumer: Uses the interface, typically a model-facing tool

Seams are the reason why “replacing a single provider can change the entire product.” The filesystem and subprocess providers share an execution world, so when they are pointed to a remote sandbox, Bash, PTY, and LSP move along with them, without requiring provider forks.

IV. Cordis Microkernel: The Technical Foundation of “Everything is a Plugin”#

The underlying plugin framework of DeepSeek Harness is called Cordis—a microkernel responsible only for plugin loading, unloading, and dependency management. Cordis itself “does almost nothing”; it only provides three things:

1. Plugin loading (mount): Mounting plugins into a shared context
2. Plugin unloading (unmount): Automatically revoking all side effects registered by a plugin upon unloading
3. Dependency management: Plugins can declare dependencies, and the framework ensures dependencies start before consumers

You can imagine the entire Harness as a tree composed of plugins:

Cordis Root Context
├── Loader
│   ├── Plugin: LLM Adapter (DeepSeek API / OpenAI API / Claude API)
│   ├── Plugin: Tool Registry (Shell Tool / File Editor / Sandbox)
│   └── Plugin: Agent Loop
└── No privileged core — all capabilities are plugins

Cordis’s philosophy comes from the paper A Programming Paradigm for Spatiotemporal Composability, co-authored by Peking University and DeepSeek, emphasizing “spatiotemporal composability”:

• Temporal composability: After a plugin is unloaded, the services, events, and side effects it registered can be revoked accordingly
• Spatial composability: Plugins can declare dependencies and re-establish collaborative relationships when other components change

Three Forms of Plugins#

Cordis accepts function plugins, object plugins, and class plugins (Service subclasses). Each plugin describes what it contributes through an apply(ctx) function. cordis.yml is responsible for “composing” these plugins into an application.

A Service is the bridge for collaboration between plugins—a named capability provided by one plugin and consumed by others via ctx. In Harness, ctx.tools, ctx.llm, and ctx.agents are all services. Consumers only specify capabilities such as 'tools' without importing their providers, so the configuration can choose the provider without modifying the consumer.

inject lists the services required by this plugin. Cordis keeps the plugin in a PENDING state until every listed service exists. Loading order is determined by service dependencies, not by position in the file.

Core Design: Dynamic Dependency Tracking#

Dependency tracking is dynamic. If a required service disappears during application runtime—for example, the provider is unloaded or hot-swapped—each dependent plugin is unloaded accordingly and reloaded after the service is restored. This is why services can be replaced in the configuration: unload dsh-bash-local, mount another shell provider, and all plugins injecting 'shell' will restart and use the new implementation.

Lifecycle and Effect#

Registrations established through the Cordis API are effects that are automatically revoked when the owning plugin is unloaded. Each loaded plugin instance owns a fiber and transitions between the following states:

PENDING → LOADING → ACTIVE → UNLOADING → DISPOSED
                            ↘ FAILED

fiber.dispose() waits for all cleanup work of that plugin (including asynchronous disposers) to complete before ending, and recursively unloads all child plugins it mounted. This design ensures the “temporal composability” of the plugin system—unloading is clean, reversible, and recursive.

V. Deeper Ambitions: Self-Evolution of Agents#

DeepSeek Harness’s true ambition goes far beyond being a better coding tool.

It has designed Harness to be an object that can be modified and hot-reloaded by the Agent itself. This is not to serve present coding needs, but to serve the next generation of self-evolution and continuous learning frameworks in the future.

Creator Mode is the most noteworthy design among the four modes. Traditional Harness runtime methods are usually predetermined by product developers, and users can only choose from existing configurations. Creator Mode attempts to let the Agent directly understand the runtime it inhabits, then trial-install plugins and combine capabilities as needed for the task. In other words, the Harness configuration itself is beginning to become an object that the Agent can manipulate.

We can imagine such a scenario: an Agent, while executing a complex task lasting several days, simultaneously replaces the components supporting its own operation, like a perpetually sailing Ship of Theseus. When it finds a tool inefficient, it can write a better plugin and hot-swap it in; when it finds the current reasoning strategy unsuited to the current task, it can adjust the Agent Loop logic itself.

This is the essential difference between DeepSeek and Anthropic:

Creator Mode is not yet a complete self-evolution system, but it is already preparing for that day. DeepSeek has handed the composability of the runtime to models, configuration files, and framework developers simultaneously.

VI. Multi-Agent Orchestration: Spawn, Fork, Workflow, and Ralph#

DeepSeek Harness already has a complete multi-Agent system built in. A parent Agent can launch child Agents in multiple ways:

The Fork design keeps DeepSeek’s prefix cache reuse rate at a high level.

If placed among the five common orchestration patterns, DeepSeek Harness is closest to the hierarchical Supervisor-Worker model: the parent Agent is responsible for decomposing, assigning, and aggregating tasks, while child Agents are responsible for execution. More precisely, it is a hybrid system primarily using hierarchical orchestration, while also supporting parallel, pipeline, and Ralph loop patterns.

What is truly special is that it has turned these orchestration methods into plugins that can be replaced via configuration, and can even connect Claude Code, Codex, or external Agents supporting ACP to the same sub-Agent interface.

VII. Implications of the Paradigm Shift#

The new coding paradigm under Agent Harness brings profound implications:

First, competition in AI programming is shifting from a “model race” to a “Harness race”#

As model capabilities gradually converge, what truly determines whether an Agent can enter production environments is no longer just model capability, but how the Harness manages context, state, tools, permissions, recovery, and acceptance.

Second, the role of developers is being redefined#

You no longer need to meticulously write every line of code; instead, you need to understand how to design, compose, and orchestrate Agent capabilities. This is a higher level of abstraction, and also a higher level of value creation.

Third, open source is reshaping the landscape of AI programming#

DeepSeek chose to open-source under the MIT license, while OpenAI chose to open-source Codex’s Harness under Apache-2.0. The two giants have almost simultaneously opened up their most core Agent infrastructure—this foretells that the future of AI programming does not belong to any single company’s walled garden, but to an open, composable, and continuously evolving ecosystem.

DeepSeek Harness is still in developer preview, but it has completed 12,293 commits in 64 days, accompanied by 683 design notes. This iteration speed itself is the best proof that “the new paradigm is accelerating.”

VIII. Challenges and Limitations: Calm Reflections on the v0.1 Stage#

DeepSeek clearly states in the GitHub repository’s README:

DeepSeek Harness is currently in developer preview and is iterating rapidly. THERE WILL BE COMPATIBILITY-BREAKING CHANGES.

This means developers entering the ecosystem now need to bear relatively high migration costs. Core plugins and foundational interfaces will still change rapidly; experimenting, learning, and doing secondary development are perfectly fine; pursuing stability and deploying to production is recommended to wait until the version converges.

The “everything can be swapped” approach also brings obvious challenges:

More importantly, “everything can be swapped” does not automatically lead to better task success rates. What ultimately determines the value of this architecture is still:

• Whether the official team can provide high-quality default plugins
• Whether stable composition paradigms can be formed
• Whether credible evaluation results can be provided
• Whether third-party developers are willing to continue building plugins around it

An industry expert told InfoQ that, looking at Harness’s complete chain, the general directions of tool calling, memory management, and task planning are largely settled, while there remains ample room for innovation in various local segments: memory management requires compression and conflict resolution, task planning needs to reuse existing paths, and after Plan generation, an additional layer of approximate “compilation” checking needs to be added. The value of DeepSeek’s “everything is a plugin” also lies in reserving space for the replacement, composition, and continuous experimentation of these local capabilities.

The model is the brain; Harness is the limbs and nervous system. And when we can not only freely assemble this nervous system, but also let the brain transform it itself—perhaps we are closer to true, self-evolving AI Agents than imagined.

For developers who love to tinker, now is the best time to get hands-on experience and participate in ecosystem building. Want a capability? Assemble it yourself—that is precisely the promise of “everything is a plugin.”

“Closed source provides users with the present; open source lets users master the future themselves.”