The most interesting part of DeepSeek Harness is not that it gives a model more buttons. It is that DeepSeek treats the machinery around the model as software you can inspect and change.
An agent is a system, not a model with a fancy name
When people say 'this model is a great agent', they often compress several components into one label. The model proposes the next action. A harness provides tools, stores the working state, decides when to call the model again, recovers from errors, and mediates access to files or a browser. The observed capability belongs to that whole arrangement.
DeepSeek puts the distinction in plain language: model plus harness. Cordis is the plugin system at the center of that design. Plugins can provide models, tools, skills, sessions, sandboxes, storage, loops, scheduling and interface components. Services and events let them communicate. That framing is compelling because it makes the agent's behaviour a composition you can investigate instead of a mysterious property you must accept as a bundle.
This does not magically make agents reliable. It makes the boundaries visible enough that developers can ask the right engineering questions. Which plugin owns a permission? Can a task be replayed? What data did a search tool inject? What happens when the model or a plugin fails? Those questions belong in the design, not in an incident report after something goes wrong.
Why a plugin kernel is a real design choice
A traditional coding agent can ship as one tightly integrated application. That makes the first experience coherent, but changes to its model provider, execution loop or storage can require changing the core. Cordis takes a different route. A kernel coordinates plugin lifecycle, dependencies, services and events. The agent's abilities live in replaceable pieces mounted into a runtime.
That is a useful separation of concerns. A developer can swap a model provider without rewriting terminal access. A team can constrain which tools are available in a particular environment. Someone building an evaluation harness can select a minimal loop rather than inheriting every convenience feature from a production assistant. This is why 'everything is a plugin' is more than a tidy slogan: it gives the composition a unit of extension and ownership.
There is a cost. Plugin interfaces become an ecosystem API, and an ecosystem creates compatibility work. A version mismatch can be harder to debug than one integrated codebase. Authors must decide which permissions are inherited, which services are trusted, how configuration composes, and whether a plugin can silently alter the agent's behaviour. The test of modularity is not how many plugins exist. It is whether the contracts remain legible as the system grows.
The session log may matter more than another tool
DeepSeek describes an append-only session log that records what entered the context: system prompts, model responses, tool calls and results, subagent scheduling and context injection. Its Trajectory view can resume, fork, search and replay from that event stream. For debugging an agent, that is an important idea. A transcript that only shows the visible chat omits much of what shaped the outcome.
Imagine an agent editing a configuration file after searching the repository. The useful debugging question is not simply 'what did it say?' It is what files did it read, what did the search return, what tool output appeared, what instruction was injected later, and which edit followed. If a run can be replayed from the same inputs, a developer can compare a fix instead of guessing at the source of the difference.
Traceability has a boundary: a record is evidence about a run, not a guarantee that every future run is deterministic or safe. Model versions, external services, clocks, network results and plugin state can change. And logs may contain sensitive prompts, paths or outputs. Append-only storage improves inspection while raising real questions about redaction, retention, access controls and user consent.
Minimal mode and Code mode change what you evaluate
The developer preview documents several modes: Standard, Code, Minimal and Creator. Standard exposes the full coding-agent toolset. Code Mode presents tools through an SDK so the model can orchestrate multi-step work in a TypeScript program. Minimal keeps the surface deliberately small with a shell tool and a file editor. Creator mode is for inspecting and composing the runtime.
Minimal mode is a particularly good idea for evaluation. A benchmark can accidentally measure a powerful harness rather than the model behaviour a researcher wants to compare. Remove extra tools, fix the budget and expose only what the test needs, then you can test a narrower claim. Standard mode is closer to how someone might actually use an agent. They answer different questions, and both are worth evaluating.
Code mode is also an interesting direction: rather than ask the model to make a sequence of isolated tool calls, let it write a small program that composes tools into a plan. This can reduce unnecessary round trips for structured tasks. It also means code execution is part of the trust boundary. The sandbox and permissions matter as much as the convenience of fewer calls.
What should you test before adopting it?
The project remains in developer preview, so judge it as infrastructure under active development. The published project description states that session content is kept locally by default and is not uploaded without consent. But if you configure an external model, a web tool, an MCP service or another plugin, those providers may receive data you send to them. 'Local-first' describes a default boundary, not every path a request could take.
For a real evaluation, try a small set of representative repository tasks in Standard and Minimal modes. Keep the model, task, repository, allowed tools and time budget the same. Compare first-pass completion, tool calls, external service use, retries, patch quality and human review. Record where the trajectory made a surprising choice. A beautiful UI cannot substitute for a clean test.
The idea I like is composability with inspectable runs. The question still open is operational: are the plugin contracts, permission boundaries and state handling good enough for other people to build safely? A preview can show a useful architecture. It takes harder use to show whether that architecture holds up.
FOLLOW THE EVIDENCE
Sources & further reading
Process note: AI tools assisted with research and drafting. Sources are linked so you can inspect the evidence. Unless an essay says otherwise, it does not claim hands-on testing or independent reproduction.
