For much of the artificial intelligence race, the dominant question was almost always the same:

which model is better?

More parameters, better benchmarks, a larger context window, lower cost per token.

But when AI stops answering questions and starts working, the model is only one part of the system.

An agent needs to understand its environment, access files, execute tools, maintain state, recover from errors, enforce permissions, preserve a history, and decide what to do after every result.

That software layer is the agent harness.

And DeepSeek has just put it in the spotlight.

The company released DeepSeek Harness (dsh), an open MIT-licensed harness whose architectural thesis fits into one sentence:

Everything is a plugin.

Not only tools.

Models, skills, sessions, sandboxes, storage, agent loops, scheduling, and even the user interface can also be composed as plugins.

That makes the announcement much more interesting than “DeepSeek launched another coding agent.”

The real bet is different:

separate the agent’s brain from the infrastructure that turns it into an operational worker.

Agent = Model + Harness

DeepSeek’s official page states it directly:

Agent = Model + Harness

The model provides reasoning and generation.

The harness provides the operating environment.

A simplified version looks like this:

User
   ↓
Harness
   ├── context
   ├── tools
   ├── filesystem
   ├── sandbox
   ├── sessions
   ├── memory / storage
   ├── permissions
   ├── scheduling
   ├── subagents
   └── agent loop
          ↓
        Model

This change in perspective matters.

If two products use exactly the same model but one manages context, tools, state, and error recovery better, they will not necessarily produce the same agent.

Real performance emerges from the complete system.

It is the same direction we have previously analyzed at Capital de Tokens with Codex as a platform and agent harness: competitive value is starting to shift away from the isolated model and toward the infrastructure surrounding it.

DeepSeek is entering that battle from a different position: it opens the harness and designs its capabilities around a plugin system.

What the practical demo showed

A recent video about DeepSeek Harness provides a useful view of this architecture from the user’s perspective.

The demonstration installs the harness locally, opens its dashboard in the browser, selects a working folder, and grants permissions over that workspace.

It then connects a model through an API and starts using the agent on real files.

Examples in the demo include tasks such as:

  • inspecting a folder and classifying its documents;
  • detecting duplicate files;
  • creating new folders and reorganizing content;
  • building a functional application from a prompt;
  • analyzing a company’s website and producing automation opportunities;
  • creating a new plugin by describing it in natural language;
  • generating a custom code-audit agent.

The individual demos are not the interesting part. Many agentic tools can perform similar tasks.

What matters is how DeepSeek tries to represent those capabilities inside the runtime.

Instead of hard-coding a large monolithic application with every possible feature, the harness treats capabilities as interchangeable components.

“Everything is a plugin” means much more than installing extensions

When we hear the word plugin, it is easy to think of a browser extension or an optional add-on.

DeepSeek uses the concept much more deeply.

According to its official documentation, plugins can represent:

  • models;
  • tools;
  • skills;
  • sessions;
  • sandboxes;
  • storage;
  • agent loops;
  • scheduling;
  • the user interface.

That means plugins do not live only at the product’s edges.

The product itself is composed of plugins.

We can picture it like this:

DeepSeek Harness
│
├── plugin: model
├── plugin: filesystem
├── plugin: shell
├── plugin: sandbox
├── plugin: session
├── plugin: storage
├── plugin: agent loop
├── plugin: scheduler
└── plugin: UI

An agent “mode” can therefore be just a different composition of those pieces.

DeepSeek already uses this approach to provide several runtime modes.

Standard mode

It includes a broad set of programming capabilities: file editing, shell, search, planning, goals, subagents, and workflows.

Code mode

It exposes tools to the model through an SDK so the model can combine multiple operations inside a TypeScript program.

Instead of manually chaining dozens of tool calls, the model can program a small execution sequence.

Minimal mode

It reduces the environment to basic tools —mainly a persistent shell and editing— to provide a much smaller harness that is useful, among other things, for evaluating models without so many surrounding layers.

Creator mode

It is designed specifically for building new agent compositions: inspecting the runtime, experimenting with plugins, and generating custom presets.

This last mode reflects a particularly powerful idea:

the agent can help modify the environment in which it operates.

Cordis: the piece that makes composition possible

This is where the most interesting part of the architecture appears.

DeepSeek Harness is built on Cordis, a meta-framework designed to handle systems that change dynamically while they are running.

On August 26, the paper “A Programming Paradigm for Spatiotemporal Composability”, authored by Yifan Shi, Wei Zhang, and Tianyi Cui, was published on arXiv.

The work attempts to formalize two problems that appear when a system is composed of components that can dynamically enter and leave.

1. Temporal composability

Suppose we install a plugin.

That plugin can:

  • register tools;
  • modify configuration;
  • add listeners;
  • open resources;
  • register services;
  • alter runtime context.

Now we want to remove it.

Deleting a reference is not enough.

We need to correctly reverse every effect it introduced.

The paper calls this temporal composability and proposes the concept of revertible effects: transformations introduced by a component retain the information needed to undo them when the component disappears.

Conceptually:

plugin enters
   ↓
registers effects
   ↓
runtime preserves how to reverse them
   ↓
plugin leaves
   ↓
effects are reverted

For an extensible agent system, this is highly relevant.

A sandbox, tool, or model provider should be replaceable without leaving the runtime in a partially broken state.

2. Spatial composability

The second problem is dependencies.

Suppose a plugin needs another service in order to function.

Plugin B
   ↓ depends on
Plugin A

If A disappears, B should not keep operating as if nothing happened.

Cordis introduces reactive coeffects, a mechanism for declaring dependencies and reacting when those dependencies appear, disappear, or change.

In practical terms, components can activate or deactivate according to the runtime’s actual topology.

That makes it possible to build software where composition is not fixed only at startup.

It can change live.

A harness that can reconfigure itself while running

The combination of those two concepts is what the paper calls spatiotemporal composability.

Without the mathematical formalism:

a component should be able to enter, leave, or be replaced without leaving orphaned effects and without silently breaking the components that depended on it.

That is especially attractive for long-running agents.

Imagine an agent that remains active for hours or days.

During its lifetime we might want to:

  • change the model;
  • mount a new tool;
  • remove an unsafe integration;
  • change the sandbox;
  • activate a skill only for a particular task;
  • replace the storage system;
  • add a subagent;
  • modify the UI;
  • load a temporary workflow.

A traditional architecture can solve all of those problems, of course.

The difference is that DeepSeek is trying to make dynamic composition a central property of the framework.

An independent Helmcode explanation of the Cordis paper highlights precisely this connection between theory and implementation: the paper’s reversible effects and reactive dependencies have concrete counterparts in the plugin lifecycle Cordis executes.

Every execution also tries to be reconstructable

DeepSeek Harness’s second major thesis is less flashy, but probably just as important:

every run is traceable.

The documentation says that what the model observes is recorded in an append-only session log, including elements such as system prompts, tool calls, results, subagent scheduling, and context injections.

Operations such as these can be built on that same stream:

  • resume;
  • search;
  • fork a run;
  • replay it;
  • inspect its trajectory.

This brings the harness closer to an idea that will become increasingly important in autonomous systems: the agent’s execution must become an inspectable object.

When an agent modifies code, files, or infrastructure, knowing the final answer is not enough.

We need to understand:

what it saw
→ what it decided
→ which tool it called
→ what the tool returned
→ how its context changed
→ what it did next

In other words, observability stops being an optional extra and becomes part of agent design.

The ecosystem is already beginning to appear

A plugin strategy only works if an ecosystem forms around it.

DeepSeek recommends the dsh-plugin GitHub topic for discovering extensions, and community directories have already appeared to catalog and verify real plugins.

One example is Awesome DeepSeek Harness Plugins, an independent index that also provides a sensible warning: a repository calling itself a plugin does not mean it is safe, maintained, or compatible.

This could become one of the project’s strengths, but also one of its main risks.

An agent with filesystem, shell, network, and credential access runs components with capabilities far more sensitive than a conventional visual extension.

Plugin supply-chain security will therefore be critical.

The agentic equivalent of “install this extension” can literally mean:

install code
that will have access
to the environment where your agent works

That requires signatures, provenance, permission policies, isolation, and clear trust mechanisms.

It is not a stable platform yet

This is where enthusiasm needs to be tempered.

DeepSeek explicitly describes the project as a developer preview and warns that breaking changes will occur.

The repository is evolving quickly, and the main APIs should not yet be treated as a frozen production foundation.

That changes the right way to evaluate it.

Today, DeepSeek Harness is especially interesting for:

  • studying agent architecture;
  • experimenting with custom harnesses;
  • building plugins;
  • comparing models under different runtimes;
  • researching reconfigurable agent systems;
  • creating local prototypes;
  • observing how an open ecosystem evolves around the agent runtime.

It is not necessarily a reason to assume that any integration written this week will remain compatible without changes several months from now.

DeepSeek vs. Codex: two ways to turn the harness into a platform

An inevitable comparison appears here.

OpenAI is opening pieces of Codex as a platform through mechanisms such as codex exec, the SDK, and app-server.

DeepSeek is proposing an open harness whose internal architecture can itself be recomposed through plugins.

They are not exactly the same strategy.

A simplified view would be:

Codex
model + integrated harness
        ↓
APIs / SDK / app-server
        ↓
your product

versus:

DeepSeek Harness
        ↓
model = plugin
tools = plugins
sandbox = plugin
loop = plugin
storage = plugin
UI = plugin
        ↓
your composition

The strategic difference matters.

Codex is trying to become an integrable agentic engine.

DeepSeek Harness is also trying to become a configurable substrate for building different agentic engines.

That does not automatically make one better than the other.

It means they are attacking slightly different layers of the same problem.

Model price stops being the whole story

The video that motivated this research repeatedly emphasizes the low cost of using DeepSeek models.

That economic advantage matters, but we should separate two ideas.

One thing is model cost.

Another is total agent cost.

A real system also consumes:

  • sandbox compute;
  • storage;
  • search;
  • external APIs;
  • infrastructure;
  • observability;
  • human validation;
  • error recovery;
  • tool and plugin maintenance.

So the more interesting question will not only be:

how much does this model cost per million tokens?

It will be:

how much does it cost to correctly complete a task using this model + this harness?

That shift in unit —from token to completed task— will probably be one of the major changes in agent economics.

The agent war may become the harness war

For years we compared models as if they were complete products.

But agents are forcing the industry to separate several layers:

Model
↓
Harness
↓
Tools / Skills
↓
Sandbox
↓
Memory / state
↓
Observability
↓
Product

Each layer can become an independent competitive space.

DeepSeek Harness is interesting precisely because it makes that separation explicit and pushes modularity to the extreme.

If the approach works, a team could keep its product and change entire parts of its agentic stack without rebuilding the whole system.

It could use one model today and another tomorrow.

A local sandbox for development and an isolated one in production.

A minimal loop for benchmarks and a complex one for autonomous tasks.

A custom UI without changing the core.

The phrase “everything is a plugin” sounds simple.

But taken to its logical conclusion, it proposes something ambitious:

the agent should not be a fixed application, but a dynamic composition of capabilities.

And if that idea gains traction, the next major AI battle may not be decided only by who has the smartest model.

It may also be decided by who builds the best system for turning intelligence into work.

Sources