Coding agents have become increasingly capable and sophisticated over the past year. Today's coding agents are capable of extraordinary feats of engineering (and yes sometimes sloppy code) and have managed to convert the most sceptical software engineers into believers. The improvement in model capabilities across the board is undoubtedly a big part of this transformation but equally important is the engineering that has gone into building the layer that mediates the interaction between the user and the model: the agent harness.
The exact mechanics of how a harness works with a model is still a bit of a mystery to some. What feels like one continuous and cohesive system is actually two distinct sub-systems that have been designed to work well with each other using a well defined contract that binds them together. The agentic loop is a series of exchanges (bound by the contract) between the agent harness and the model.
The user initiates the activity with an instruction and the agent harness operates within the purview of a target environment that exposes capabilities and actions. The agent harness assembles each request sent to the model, decides which actions proposed by the model may take effect, records what happened, and determines whether another model call is needed. The agent harness turns a probabilistic model into a process that can use tools over several steps while preserving policy and state.
DeepSeek Harness is useful because its implementation is open source and we can review its architecture to understand the design of an agent harness. The project describes itself as an agent harness in which "everything is a plugin," built on a plugin framework called Cordis. It is also marked as a developer preview, so the details may move. The current repository gives us a concrete system to inspect.
One turn can contain several model calls
The diagram separates four actors: the developer supplies intent and delegated authority; the harness manages context, policy, memory, and loop control; the model provider runs inference and returns a proposal; the environment is where files, processes, browsers, APIs, and people produce real outcomes.
DeepSeek's architecture gives "step" and "turn" precise meanings. A step is one model request plus the tool calls it produces. A turn contains zero or more steps and closes when no work remains. A tool result can therefore become part of the next request within the same user turn.
The model strongly influences that path. Its text or tool-call proposal is the immediate reason to continue or finish. The harness still owns the mechanics: it applies execution policy, updates recorded state, runs stopping checkpoints, and assembles the next request. So the model can steer the flow but the actual control of the agentic loop really rests with the harness first and the user ultimately.
A framework to understand the agentic loop
Context, Authority, and Continuation are a useful way to read the loop. They are not three formal DeepSeek subsystems; they are questions we can map to its services and events.
Context: What can the model see?
Before inference, the harness has to construct a model request. In DeepSeek Harness, ctx.sessions owns the append-only session event log and model-visible history. ctx.systemPrompt assembles prompt sections and tool schemas. ctx.tools contributes the tools available in the current scope. ctx.llm is the adapter boundary to the selected model provider.
The harness produces the model's context. DeepSeek's design requires model-visible history to be logged or reconstructable from the session log. That makes the model-visible history traceable to durable events rather than hidden mutable state.
Authority: What may take effect?
A model proposal has no effect on its own. DeepSeek routes tool calls through the scoped registry and guarded execution pipeline exposed by ctx.tools. Approval rules and guards can intervene before an operation reaches the environment. The resulting observation, including an error, is recorded back into the session.
The model provider emits structured output. The harness interprets that output under the authority delegated by the developer, invokes an allowed tool, and captures the result. Keeping those roles separate makes inspection, approval, and failure handling possible.
Continuation: Is another step owed?
After a proposal and any tool results have been recorded, ctx.agentLoop drives the step and turn lifecycle. It can continue by assembling another request from the updated session, or finish by returning the final response. Tool obligations, queued input, current state, and live lifecycle events determine whether work remains. The default loop has no built-in turn budget. A plugin that needs a bound can cancel at an extension point such as agent/turn-stopping.
One instruction can lead to several inference calls. The harness cycles through model, tool, observation, and model again until the turn's work is complete or a boundary stops it. The model supplies the next proposal; the harness preserves the process around it.
Cordis provides the plugin system
In Cordis, ctx is a shared repository of services. The name is unrelated to the model's context window. A plugin can register a service at a stable key such as ctx.sessions, ctx.llm, ctx.tools, or ctx.agentLoop. Other plugins declare the services they require and receive a context that exposes them.
Cordis also supplies typed events and reversible effects. Direct capability calls live on service methods; interception and policy can live on events. Registrations have disposers so reload and teardown can unwind them predictably. In this design, "everything is a plugin" means the model adapter, tool registry, session log, and loop driver participate through the same composition and lifecycle rules. A profile can replace one through configuration without patching a privileged core.
It's a tradeoff, and that flexibility comes with a cost. Plugins have to use the same service contracts, follow the expected event order, and clean up properly when they are removed or reloaded. If one of those assumptions is wrong, failures can be harder to trace because the behavior is spread across several plugins. DeepSeek Harness is still a developer preview, so a plugin built against today's interfaces may also need to change as the project changes.
Reading other harnesses
DeepSeek shows one implementation of an agentic loop. Other harnesses use different constructs and tradeoffs.
To read another one, find where it assembles the model request, authorizes actions, records results, and decides whether to continue. Its names and boundaries reveal those design choices.