The AI industry has spent much of the past few years asking which model is best. DeepSeek Harness suggests that this may increasingly be the wrong unit of analysis.
Released in developer preview, the open-source project has already attracted more than 147,000 GitHub stars. Its headline design principle is unusually simple: everything is a plugin. The model is a plugin. Tools are plugins. Skills, sessions, storage, sandboxes, scheduling, the agent loop and even the user interface are plugins. DeepSeek says developers can replace or recombine these capabilities through configuration without modifying the core Harness source.
The attention around the repository is notable. Claims that it crossed 100,000 GitHub stars in less than 48 hours have circulated widely, although GitHub itself does not provide an authoritative historical record from which to verify claims that this makes it the fastest-growing repository in the platform's history. The safer observation is that adoption interest has been exceptionally rapid.
But GitHub stars are not the breakthrough.
The interesting idea is that DeepSeek has made the agent harness itself a composable technology layer.
That matters because the centre of gravity in AI systems is beginning to move. Model capability remains important, but an increasingly large part of what makes an agent useful, reliable and differentiated sits in the software surrounding the model.
The model is becoming one component of the agent
A language model on its own does surprisingly little.
It receives context and generates output. To become an agent capable of completing work over time, it needs an operating environment around it.
That environment may decide:
- Which tools the model can use
- How context is assembled
- What state persists between interactions
- How files and external systems are accessed
- When another agent is invoked
- How errors are handled
- How permissions are enforced
- When the system should continue, stop or ask for help
- What evidence is retained about what happened
This surrounding layer is increasingly described as the agent harness.
DeepSeek expresses the relationship bluntly on its Harness website: “Agent = Model + Harness”. It describes the model as the intelligence within the agent while the harness lets that model understand an environment, use tools and continue operating in real-world settings.
The distinction is becoming more than architectural terminology.
Recent research increasingly shows that the same model can behave differently when placed inside different harnesses. One 2026 study comparing coding-agent scaffolds found that harness choice could create up to a 40-fold difference in tokens consumed per solved task, even where changes in task success were considerably smaller. Other research has demonstrated substantial variation in completion, efficiency and failure behaviour across different model–harness pairings.
The implication is important.
An agent is not simply a model with access to tools. It is the behaviour produced by the model and the system wrapped around it.
That makes the harness a first-class part of AI engineering.
“Everything is a plugin” changes where architecture can evolve
Plugin architectures are hardly new.
Browsers, development environments, content-management systems and enterprise applications have used extension models for decades. What is more interesting about DeepSeek Harness is the extent to which it applies the concept.
Its underlying Cordis framework treats agent capabilities as components that can be mounted, removed and recombined. DeepSeek's architecture documentation says there is no privileged core that developers must patch to extend the system: the model adapter, tool registry, session log and agent loop are themselves replaceable plugins.
That creates a substantially larger design surface than a conventional agent framework where the outer loop is fixed and developers mainly choose the model and tools.
In DeepSeek Harness, the system can potentially vary across several dimensions:
- Model: Which intelligence provider handles a particular task
- Tools: What the agent is permitted to read, query, modify or execute
- Skills: Reusable behaviour or domain-specific operating instructions
- Memory and sessions: What the system retains and how previous state influences future execution
- Sandbox: Where actions can safely execute
- Agent loop: How the system plans, acts, observes results and decides what happens next
- Scheduling and orchestration: How work is distributed across time, processes or other agents
- Interface: How people or other systems interact with the resulting agent
None of these necessarily needs to be permanently coupled to the others.
The model becomes one dependency inside a wider composition.
Composability may matter more as agents become less predictable
Making everything replaceable introduces complexity. DeepSeek's answer is Cordis, the underlying meta-framework used by Harness.
Cordis is built around what its authors call spatiotemporal composability. In simplified terms, it is designed to address two problems created by highly dynamic plugin systems.
The first is what happens when a component disappears. A plugin may have registered services, altered state or introduced dependencies. Cordis tracks effects so those changes can be reversed when the component is removed.
The second is how components depend on one another. Rather than assuming a fixed system constructed once at startup, components can declare dependencies and respond as the surrounding context changes. The Cordis paper describes these concepts as temporal and spatial composability respectively. The paper remains under active development, so its formal claims should be treated accordingly.
This might sound like an implementation detail. It points towards a larger problem.
Agentic software is likely to be far more dynamically assembled than conventional applications.
One workflow might need a capable reasoning model, browser access, SQL tools and persistent memory. Another might require a cheaper model, a restricted filesystem and no network access. A third could load a specialist verification capability for one stage of a task and remove it afterwards.
If those environments become increasingly contextual, the architecture needs to support composition without turning every combination into a new application.
The plugin becomes more than an extension mechanism.
It becomes an architectural boundary around capability.
Model choice may become a runtime decision
One of the most consequential implications of this approach is that the model itself no longer has to define the application.
Much of today's AI software still implicitly follows a model-centric architecture:
Choose model → build application around model → integrate tools → optimise behaviour
A composable harness allows a different order:
Define task environment → compose capabilities → select model appropriate to the task
That is a more significant change than being able to switch from one provider to another.
It makes model selection potentially contextual.
A difficult planning stage might justify an expensive frontier model. A deterministic extraction task might use a smaller, cheaper model. Another workflow may require a model with particular multimodal capability or a deployment running inside a controlled environment.
The application does not necessarily need to move with the model.
Research into agent evaluation reinforces why the combination matters. Studies increasingly argue that model-only comparisons can hide meaningful differences introduced by prompting, tool configuration, memory, control loops and execution environments. The useful unit of evaluation may therefore increasingly be the model–harness configuration, rather than the model in isolation.
That could alter how AI systems are benchmarked, purchased and engineered.
The question becomes less:
Which model is best?
and more:
Which combination of model, tools, context, controls and execution logic performs best for this task?
Open source changes the competitive surface
DeepSeek Harness is released under the MIT licence and its current repository includes the source for the wider harness rather than simply an adapter for DeepSeek's models. DeepSeek also documents other agent environments that can use its model APIs, reinforcing that the company is not positioning the model and harness as inseparable products.
That creates an interesting strategic dynamic.
A closed agent product can differentiate through the experience created around its model: memory, tools, coding workflow, orchestration, context management and interface. Those capabilities can create substantial switching costs even if competing models become interchangeable underneath.
An open, highly modular harness challenges that coupling.
If developers can retain their tools, workflows, sessions and orchestration while replacing the model, competition moves upwards from the model layer.
And if they can replace the agent loop as well, it moves upwards again.
The valuable component may ultimately be whatever part of the system remains hardest to substitute.
That might be:
- Proprietary context
- Domain-specific skills
- Trusted execution environments
- Workflow integrations
- Evaluation systems
- Security controls
- Accumulated memory
- Specialised orchestration
- User experience
The model remains essential. It simply stops owning the entire stack.
Plugins create governance problems as well as freedom
There is, however, an obvious counterargument.
An architecture in which everything can be replaced is also an architecture in which everything can change.
That creates a large governance surface.
A model plugin can alter model behaviour. A tool plugin can expand what the agent can access. A memory plugin can change what information persists. An agent-loop plugin can change when actions occur. A sandbox plugin can alter execution boundaries.
Composability therefore increases the importance of provenance, dependency management, testing and policy enforcement.
DeepSeek has made traceability another major design characteristic of Harness. It says the system records what the model receives in an append-only session log, including system prompts, reasoning, tool calls and results, subagent scheduling and injected context. Its Trajectory interface then uses that event stream for inspection, replay, search, resume and forking.
That relationship between modularity and traceability is important.
If components can change independently, organisations need to know which composition produced which behaviour.
A useful production record may eventually need to identify not simply the model version, but:
Model + prompt + tools + skills + memory + policies + loop + plugin versions + execution environment
Agent observability consequently becomes configuration observability.
Without it, composability can become unpredictability.
The harness could become the new application layer
There is a bigger possibility behind all of this.
Today's AI application stack is often presented as a collection of layers: model, retrieval, tools, orchestration, application and interface.
But increasingly capable harnesses begin to absorb many of those distinctions.
DeepSeek Harness already encompasses models, tool registries, skills, sessions, storage, sandboxes, loops, scheduling and UI. Its standard configuration provides a coding agent with planning, goals, subagents and workflows, while alternative modes change how those capabilities are exposed and orchestrated.
At some point the word harness may begin to undersell what the layer is becoming.
It starts to look more like an agent runtime.
This runtime does not supply intelligence alone. It determines how intelligence enters a software environment and what happens afterwards.
That echoes a wider development across agent research. Recent work increasingly treats harnesses as systems responsible for planning, memory, tool use, execution, verification, state and recovery rather than as thin wrappers around inference.
If that continues, AI architecture may start to separate into three broad layers:
- Intelligence: Models provide reasoning, generation and judgement
- Runtime: Harnesses provide context, tools, state, loops, permissions, execution and observability
- Environment: Applications, data, APIs, users and external systems provide the world in which the agent acts
The important architectural boundary may therefore be moving away from the individual model and towards the runtime that mediates between intelligence and action.
The most valuable AI engineering may happen outside the model
None of this means models stop mattering.
Better reasoning, greater context windows, stronger multimodal capability and lower inference costs will continue to affect what agents can accomplish. Research also shows cases where changing the model inside the same harness produces substantial performance differences.
The mistake would be to replace model obsession with harness obsession.
What is changing is the relationship between them.
As foundation models become more capable and multiple providers can satisfy the same task, the differentiating work increasingly shifts towards how intelligence is assembled into a functioning system.
Which context reaches the model?
Which tools can it access?
How does it know whether an action succeeded?
What happens after failure?
What persists?
What gets verified?
Who can change the runtime?
How can the resulting behaviour be reconstructed?
Those are harness questions.
DeepSeek's contribution is to make virtually all of them configurable components rather than fixed assumptions.
Everything is a plugin
DeepSeek Harness is still explicitly a developer preview. Its maintainers warn that compatibility-breaking changes should be expected, which makes it far too early to treat the current implementation as a settled blueprint for production agent architecture.
Its significance lies elsewhere.
“Everything is a plugin” turns the agent from a largely fixed piece of software surrounding a chosen model into a composition of replaceable capabilities.
That creates flexibility, but also something more important: it makes the architecture itself available for experimentation.
Developers can experiment not only with which model thinks, but with how the agent remembers, acts, verifies, persists, orchestrates and recovers.
That is why the extraordinary interest around the project should not be read simply as another DeepSeek moment.
The larger shift is from competing over models to competing over the systems that make models useful.
The next phase of agent development may be defined less by who has the smartest model in isolation and more by who builds the best environment around interchangeable intelligence.
If everything is a plugin, the model is no longer the product. The composition is.
Sources
- DeepSeek Harness – GitHub repository
- DeepSeek Harness – official developer preview website
- DeepSeek Harness – developer documentation
- Cordis – A Programming Paradigm for Spatiotemporal Composability
- The Scaffold Effect in Coding Agents: Harness Choice as a Hidden Variable in Coding-Agent Evaluation
- Harness-Bench: Measuring Harness Effects across Models in Realistic Agent Workflows
- Claw-SWE-Bench: A Benchmark for Evaluating OpenClaw-style Agent Harnesses on Coding
