DEV Community: DA SEIN

DeepSeek Harness Deep Dive (4): Agent Loop — How One Prompt Turns Into Dozens of Actions

DA SEIN — Fri, 04 Sep 2026 15:40:38 +0000

The previous three articles answered three increasingly concrete questions:

Why does an LLM need a Harness at all?
Why does DeepSeek Harness make almost everything a Plugin?
How does Cordis keep those Plugins composable instead of letting them become another pile of tightly coupled modules?

At this point the Runtime is ready. Models, Tools, Sessions, events, and other capabilities have all been mounted.

So now comes the question that matters most in practice:

When the user sends one message, what actually happens next?

The easy answer is “the Agent Loop runs.” But that phrase hides most of the interesting engineering.

A toy Agent Loop is often written like this:

while (true) {
  const response = await llm(messages)
  const results = await executeTools(response.toolCalls)
  messages.push(...results)
}

That is useful for teaching the basic idea, but DeepSeek Harness has to solve a harder problem. A user may send another instruction while the current task is still running. Plugins may rewrite or reject the next model step. A model call may produce several Tool Calls. Some of those calls can run in parallel, others must form barriers. A task may need another model request after the Tools finish—or may need to stop without making any model request at all.

So instead of starting from while (true), it is more useful to start from the three boundaries the Runtime actually manages:

Inbox → Turn → Step

Once these three are clear, the rest of the Agent Loop becomes much easier to understand.

Turn and Step Are Not the Same Thing

This distinction is the first place where the real Harness differs from a simple chatbot loop.

DeepSeek Harness defines a Step as one model request together with the Tool executions requested by that model response.

A Turn, on the other hand, is the larger unit of work. It can contain zero, one, or multiple Steps.

A useful mental model is:

Turn
├── Step 1
│   ├── one model request
│   └── the tools requested by that response
│
├── Step 2
│   ├── another model request
│   └── another group of tool executions
│
└── ...

Figure 1: A Step is one model request plus the Tools it requested. A Turn is the larger boundary that may contain zero or many Steps.

Suppose the user says:

Fix the failing login test.

The first model request may decide to run:

pytest tests/test_login.py

That model request and the resulting test execution belong to Step 1.

The Tool result says authentication failed because of an unexpected redirect. The Agent now needs the model to think again. That new model request begins Step 2.

The second response may read a file, edit it, and run another test. If another model request is needed afterward, that becomes Step 3.

All of them may still belong to the same Turn.

This sounds like a small naming detail, but it changes how we understand an Agent. A Turn is not “one prompt, one answer.” It is closer to:

One continuous unit of work that may require several rounds of model reasoning and environmental feedback before the Runtime considers it complete.

There is an even stranger possibility: a Turn may contain zero Steps.

Why would the Harness open a Turn and then never call the model?

To understand that, we first need to look at the Inbox.

A User Message Does Not Go Straight to the LLM

When a message reaches an Agent, DeepSeek Harness does not immediately append it to a messages[] array and call the model.

It first enters the Agent's Inbox.

The Inbox has two logical destinations:

next-turn
next-step

These names describe when the message is eligible to enter model-facing work.

An ordinary:

agent.followup(message)

goes to next-turn and wakes the driver. It represents a normal new user request.

But DeepSeek Harness also exposes:

agent.steer(message)

and:

agent.inject(message)

Both target next-step, but they behave differently.

steer() is an active intervention. If the Agent is already running, the message is intended for the nearest later Step boundary. If the Agent is idle, steering can wake it and start a Turn.

inject() is quieter. It queues model-facing context for the next Step but does not wake an idle Agent by itself. That makes it useful for things such as file-change notices, extra instructions, or other context that should be seen the next time the Agent is already doing work.

The routing looks roughly like this:

Figure 2: followup() targets the next Turn; steer() and inject() target the next Step, but only steering wakes the driver.

This design matters because a running Agent is not a closed pipeline.

Imagine the Agent is already investigating a bug and you suddenly send:

Do not modify the database layer.

A simplistic implementation might have to cancel the whole run, rebuild the prompt, and start over.

DeepSeek Harness instead has a place for steering to wait until the next safe Step boundary.

That is a much more useful abstraction for long-running Agents: the user can intervene while work is in progress without pretending that every interaction starts from an idle chatbot.

The Turn Opens Before the Model Is Called

Once waking work is available, the driver enters its running state and opens a durable Turn:

turn/start

Notice the order: the Turn begins before the first Step.

The driver then claims the input for the proposed Step. At a Turn boundary, that means:

all pending next-step input
+
one queued next-turn message

The claimed messages are no longer merely waiting in the Inbox. They are now the candidate input for the next model-facing Step.

But the model still has not been called.

Before that happens, DeepSeek Harness runs:

agent/pre-step

This is one of the most important interception points in the whole Agent Loop.

A listener can decide:

reject

or:

enter(messages)

And enter(messages) does not have to return the exact batch that was claimed. Plugins can rewrite what enters the Step.

That gives Context-management, compaction, policy, or steering-related extensions a clean place to intervene before the model request is derived.

It also explains the zero-Step Turn.

The sequence can legally be:

turn/start
   ↓
claim input
   ↓
agent/pre-step
   ↓
reject
   ↓
turn/end

No step/start occurs. No LLM request occurs.

This is a subtle but important design choice: the durable history can record that the Runtime opened and closed a Turn even when policy or preprocessing prevented any model work from happening.

Only After Pre-Step Does a Step Really Begin

If agent/pre-step returns enter(messages), the driver finally opens:

step/start

The entered user-role messages are then appended to the Session as:

user/message

At this point, the Harness has enough information to construct the request.

But even here it does not simply reuse a mutable messages[] object.

The Runtime does two different things:

It assembles the current System Prompt and Tool schemas from registered capabilities.
It derives model history from the Session log.

Conceptually:

Session log
   ↓
derive model history

Plugin registrations
   ↓
assemble system prompt + tool schemas

both
   ↓
model request

The actual request then passes through:

agent/request
   ↓
llm/stream

The model streams back chunks. DeepSeek Harness records those raw chunks as:

assistant/chunk

and, after a successful provider call, records the assembled result as:

assistant/message

This may seem excessively detailed for a simple model call, but it serves a larger design rule that we will examine in the next article:

Model-visible means logged.

The Session is not merely a chat transcript. It is the durable source from which model-visible history can be reconstructed.

For now, the important point is simpler: the Agent Loop never treats the model request as an isolated black box. The request is constructed from Runtime state, streamed through an adapter seam, and written back into the Session as durable facts.

A Step Includes the Tools Requested by That Model Call

Suppose the model response contains:

read_file("src/auth.ts")
run_test("tests/login.test.ts")

The Step does not end as soon as the model stops generating.

Those Tool Calls belong to the Step that produced them.

At a high level, the loop does this:

assistant/message
   ↓
classify Tool Calls
   ↓
tool/call
   ↓
Tool execution pipeline
   ↓
tool/result
   ↓
step/end

DeepSeek Harness can classify calls by execution mode. Some Tool Calls are allowed to overlap; exclusive calls form ordering barriers. Results are then committed in model order.

We will leave the permission checks, pre/execute/post waterfalls, timeouts, Sandbox providers, and parallel scheduling details for the dedicated Tool Pipeline article. The important point here is only the boundary:

One Step owns one model request and the Tool executions requested by that response.

The Step closes only after those calls have settled and their results have been written.

Why Does the Loop Start Another Step?

Now we reach the actual loop.

After:

step/end

the Runtime asks whether more model work is owed.

There are several reasons why the answer may be yes.

A Tool result may require the model to interpret what happened. A Tool may defer additional model-facing context. The user may have sent steering while the previous Step was running. Other next-step input may now be waiting.

If more work exists, the Runtime does not open a new Turn immediately.

Instead, the current Turn continues:

Step 1
   ↓
Tool results
   ↓
claim next-step input
   ↓
agent/pre-step
   ↓
Step 2

This is why:

Turn ≠ Step

is not just terminology.

The Turn is the continuity boundary. Steps are individual rounds of model interaction inside it.

A Coding Agent may therefore spend one Turn doing something like:

Step 1: run failing test
Step 2: inspect relevant files
Step 3: edit implementation
Step 4: rerun test
Step 5: inspect another failure
Step 6: final verification

From the user's point of view, that may still feel like one request.

From the Harness's point of view, it is a sequence of separately logged and interceptable model Steps.

When Does a Turn Actually End?

The obvious answer would be:

When the model says it is done.

But the Harness cannot rely on that alone.

A model response may look final while a Tool has requested continuation. Steering may have arrived during execution. Another piece of next-step context may already be queued.

DeepSeek Harness therefore checks whether the Turn still owes more work.

When there is no Tool continuation and the next-step Inbox is empty, the loop reaches a final checkpoint:

agent/turn-stopping

This gives interested Plugins one last place to react before the Turn is committed as finished.

Then:

turn/end

is appended.

Only after the driver's work drains does the Agent return to:

idle

One subtle point: running does not mean “a Turn is currently open.” It describes the broader driver activity interval and may span consecutive queued Turns.

Again, DeepSeek separates several notions that a toy Agent often collapses into one variable:

Agent status
Turn lifetime
Step lifetime
Inbox state

That separation is what lets the Runtime support steering, cancellation, replay, queued work, and extensions without turning the main loop into one giant stateful function.

The Whole Path

We can now put the lifecycle together:

Figure 3: The Agent Loop is not simply LLM → Tool → LLM. Inbox routing, durable Turn/Step boundaries, pre-step interception, Session logging, and continuation checks all sit around that familiar cycle.

In a compressed form:

User / plugin input
        ↓
      Inbox
        ↓
   turn/start
        ↓
 claim proposed input
        ↓
  agent/pre-step
        ↓
    step/start
        ↓
append user/message
        ↓
assemble request
        ↓
 agent/request
        ↓
   llm/stream
        ↓
assistant/message
        ↓
 Tool Calls + results
        ↓
    step/end
        ↓
more work?
   ↙        ↘
 yes        no
 ↓           ↓
next Step   agent/turn-stopping
             ↓
          turn/end

This is the point where “Agent Loop” stops being a vague name for while (true).

It is better understood as:

A driver that continuously turns queued work into durable Turn and Step transitions, derives each model request from Runtime state, executes the actions the model asks for, and decides whether the current unit of work should continue or close.

That also explains why DeepSeek Harness keeps the Agent Loop itself replaceable behind a Service interface. The loop is enormously important, but it is still one Plugin in the larger composition rather than a privileged core that every extension must modify.

And one part of this lifecycle deserves its own article.

We repeatedly wrote events such as:

turn/start
user/message
assistant/message
tool/result
turn/end

Why log all of them instead of just maintaining the latest messages[] array?

Why does DeepSeek insist that model-visible information must be reconstructable from the log?

That is the next piece of the architecture:

Session is not chat history.

The next article will focus on the rule behind it: Model-visible means logged.

References

DeepSeek Harness (3): Everything Is a Plugin — Now What?

DA SEIN — Sun, 23 Aug 2026 13:52:16 +0000

The previous article ended with a simple question:

“Everything is a Plugin” sounds clean, but once dozens of Plugins exist at the same time, does the complexity really disappear?

Of course not.

A Tool Plugin may depend on a Sandbox. The Agent Loop depends on Tools and Sessions. A permission component may need to intervene before a Tool actually runs. More importantly, these Plugins are not always loaded once at startup and left alone forever. They may be replaced by configuration, mounted only for a specific Agent, or removed once a task is finished.

If a “plugin system” only means dynamically importing a collection of modules, then the coupling that used to live inside the Harness core will simply reappear somewhere else.

That is the problem Cordis is designed to solve.

DeepSeek’s own description of Cordis is actually fairly modest: the Cordis kernel mainly manages Plugin mounting, unmounting, and dependencies, while the actual Agent capabilities remain inside the Plugins themselves. In other words, Cordis is not another, larger “Agent core.” It is closer to a set of Runtime rules: it does not decide how Shell execution should work, but it does make sure that questions like “who provides Shell, who depends on Shell, when is it available, and what should disappear when the Plugin is removed?” remain manageable.

That is the best entry point for the concepts that follow.

First, Do Not Confuse Context with the Prompt

The first overloaded word is Context.

Earlier, when discussing LLMs, we also used “context” to mean the information the model can see in one request: user messages, history, Tool schemas, System Prompt, and so on.

But Cordis ctx is not that.

A useful first approximation is to think of it as the shared runtime workspace in which Plugins discover and register capabilities. If a Plugin wants to find a service, subscribe to an event, or register something that should later be cleaned up, it usually starts from ctx.

So it is better to keep these two meanings separate:

Model Context
= information sent into the LLM for one request

Cordis Context / ctx
= runtime environment where Plugins find and register capabilities

Why do we need such a Runtime Context at all?

Suppose one Plugin needs access to the Tool system. The most direct implementation would be:

import toolRegistry from "./tool-registry"

But that immediately couples the Plugin to one concrete implementation. If you later want to replace the Tool Registry, swap the Session Provider, or use different implementations under different configurations, every consumer may need to change.

Cordis inserts another layer: a Plugin does not directly look for another Plugin. It looks for the Service that Plugin provides.

A Service can be understood as a capability exposed under a stable name. In DeepSeek Harness, common examples include:

ctx.tools
ctx.sessions
ctx.llm
ctx.agents

The Provider Plugin registers the capability under a stable key. Consumer Plugins depend on that key rather than on the concrete implementation behind it.

Figure 1: A Provider Plugin registers a capability into the Cordis Context; a Consumer Plugin resolves it through a stable key.

This resembles Dependency Injection, but Cordis adds something important: a Plugin can explicitly declare what it depends on.

For example:

const plugin = {
  inject: ["tools", "sessions"],

  apply(ctx) {
    // ctx.tools and ctx.sessions are available here
  },
}

There is nothing mysterious about inject. It simply says:

This Plugin only makes sense when both tools and sessions exist.

The Plugin therefore does not need to guess whether Sessions should start first, or manually poll until Tools are ready. The Runtime can infer activation from declared dependencies. If those dependencies change later, it can react to that change as well.

This is much closer to what Cordis means by Spatial Composability.

In the previous article, we used “which Agent owns this capability?” as an intuition. That intuition is useful, but it is not the formal meaning. Spatial composability is more fundamentally about this:

A component can declare the external capabilities it depends on, and the Runtime can react as those dependencies appear, disappear, or change.

So “spatial” here is not simply a location in an Agent tree. It is about the component’s position inside a network of dependencies.

A Plugin Must Be Removable, Not Just Loadable

If dependency management answers “how Plugins work together,” the next problem is:

What happens when a Plugin leaves?

This is where many ordinary plugin systems become much less convincing.

Imagine a Plugin that does all of the following when it starts:

register a Tool
add a Prompt section
subscribe to an Event
start a Timer
open an external resource

If unloading the Plugin only means removing it from a list, the system is not actually clean.

The Tool schema may still exist. The Event listener may still fire. The Timer may still be running. The Prompt may still tell the model that a capability exists even though the Plugin that provided it is gone.

The Runtime has accumulated ghost state.

Cordis treats these runtime changes as Effects.

The term sounds abstract, but here it can be understood very literally:

An Effect is a change a Plugin makes to the Runtime, together with enough information to undo that change later.

A simplified example looks like this:

ctx.effect(() => {
  const dispose = registerCapability()

  return () => {
    dispose()
  }
})

When the Plugin registers something, it also returns a disposer: the logic required to remove that registration later.

So the lifecycle becomes reversible:

Mount Plugin
   ↓
register Tool / listener / timer / prompt
   ↓
Runtime uses the capability
   ↓
Unmount Plugin
   ↓
run the disposer
   ↓
restore the Runtime

Figure 2: Dynamic composition is not only about mounting Plugins; the Runtime must also be able to remove the Effects they leave behind.

This corresponds to Temporal Composability in the Cordis paper.

Its strict meaning is not simply “when in the Agent Loop should a Plugin run?” For example, “Memory injects information before the LLM request” or “Logger records results after Tool execution” describe lifecycle intervention points, but they are not the core definition.

The deeper requirement is:

When a component leaves the system, the side effects it previously introduced must be completely reversible.

A Plugin should not only be easy to add now. It should also be possible to remove later without leaving the Runtime in a half-mutated state.

Cordis uses a Fiber to track a running Plugin instance. The name may sound abstract, but for our purposes a Fiber can be understood as the lifecycle record associated with one mounted Plugin instance. It tracks whether dependencies are currently satisfied, which Effects were registered, and what must be cleaned up when the Plugin is removed.

So:

Plugin
= code and configuration

Fiber
= the running instance of that Plugin and its lifecycle record

Now “unload a Plugin” means more than deleting an object reference. The Runtime can follow the Fiber and undo what the Plugin added.

Agent Scope: Not Every Capability Should Be Global

Once dependencies and teardown are handled, DeepSeek Harness still faces a more concrete problem:

A single Runtime may contain multiple Agents, but not every registration should be visible to every Agent.

Some capabilities naturally belong to the global layer, such as model providers, persistence infrastructure, or shared services. Others may exist only for a particular Agent: a special Prompt section, a Tool variant, or a Listener that only makes sense for the current task.

If all registrations live in one global registry, Agent A’s local capabilities can leak into Agent B.

DeepSeek Harness therefore adds a local registration layer for each Agent. A useful mental model is:

Agent A sees
= Global Layer + Agent A Local Layer

Agent B sees
= Global Layer + Agent B Local Layer

Figure 3: Agent Scope does not duplicate the entire Runtime; it overlays agent-local registrations on top of shared infrastructure.

There is an important detail here that our earlier intuition can easily get wrong: the current implementation is not simply “child Agents automatically inherit every capability from their parents.”

It is not:

Parent Agent
   ↓ automatically inherit everything
Child Agent

It is closer to explicitly selecting the current Agent and resolving capabilities from Global + that Agent’s Local Layer.

This gives the system much tighter control over local registrations and avoids accidentally leaking one Agent’s local capabilities into another.

But Scope should not be confused with a security boundary.

It answers:

Which registrations should this Agent operation see?

It does not automatically answer:

Should this Plugin be trusted? Can it access the host filesystem?

Approval, permissions, and Sandboxes still need separate mechanisms. Scope is a composition boundary, not a security sandbox.

If We Have Services, Why Do We Still Need Events?

At this point, one final question remains.

If Plugins can already call each other through Services, why does DeepSeek Harness make such heavy use of Events?

Because not every form of collaboration should look like:

ctx.someService.doSomething()

Some components merely want to observe something that happened. Others want to intercept an operation before it becomes final. They should not force the Agent Loop to import every possible extension directly.

For example:

Tool is about to execute
   ↓
Permission Plugin wants to inspect it

Tool execution finishes
   ↓
Logger wants to record the result

Model request is about to be sent
   ↓
Another Plugin wants to modify or intercept it

If the Agent Loop contains an if branch for every extension, “Everything is a Plugin” quickly collapses back into “the core knows about every module.”

Events provide shared extension points.

The simplest Event is just a notification:

Something happened; interested Plugins may respond.

DeepSeek Harness also makes frequent use of Waterfall Events. A Waterfall can be understood as a chain of middleware with explicit control handoff. A Listener handles the current request and calls next() to delegate to the next Listener. If it owns the final decision, it can stop the chain instead.

This leads to a practical rule that is easy to remember:

Use a Service when you need to directly call a capability.
Use an Event when you need to observe, intercept, or inject policy into an existing flow.

That is how Permission, Telemetry, Sandbox adapters, and other extensions can attach themselves to an existing runtime path without moving back into the Agent Loop core.

Putting the Pieces Back Together

Now Cordis no longer looks like a pile of abstract nouns.

Its core flow can be summarized like this:

Plugin declares required capabilities
        ↓
inject

Dependencies become available
        ↓
Plugin activates

Plugin resolves stable Services through ctx
        ↓

Plugin registers capabilities or listeners
        ↓
those changes are tracked as reversible Effects

While the Plugin is running
        ↓
Services handle direct capability calls
Events handle observation, interception, and policy

If a registration belongs only to one Agent
        ↓
place it in that Agent's Local Scope

Plugin is replaced or removed
        ↓
Fiber triggers teardown
        ↓
Effects are disposed

At this point, “Everything is a Plugin” finally becomes more than an architectural slogan.

Cordis does not eliminate complexity. Tools still need implementations. Sessions still need persistence. The Agent Loop still needs to manage state transitions. What Cordis does is force that complexity into clearer boundaries:

A Plugin declares what it depends on, what it provides, what it registers, and how its runtime changes can be undone; the Runtime organizes those relationships.

That makes it possible to add a new capability beside the existing system instead of repeatedly modifying an ever-growing privileged core.

And that leads naturally to the next question:

Once all of these Plugins are mounted, how does a single user message actually travel through DeepSeek Harness?

From Session input, to Turn and Step, to the model request, Tool Call, and finally back into the next model context—that is the next layer to unpack: the Agent Loop.

References

# DeepSeek Harness Deep Dive (2): Everything Is a Plugin — But What Exactly Is a Plugin?

DA SEIN — Fri, 21 Aug 2026 13:47:51 +0000

As discussed earlier, a mature Harness needs to handle at least tool execution, Context management, Session persistence, and execution control. But once Agents begin taking on more complex tasks, that is no longer enough. Models need access to more tools, file systems and browsers, sandboxed code execution, long-term memory, and sometimes collaboration with other Agents. As a result, more and more capabilities begin to accumulate inside the Harness:

                 Agent Runtime

                      |

 ------------------------------------------------

 |          |          |          |             |

Model     Tools     Memory    Session     Sandbox

Adding capabilities is not the problem by itself. The real problem is that all of them eventually end up inside the Runtime.

The most straightforward approach is simply to add whatever is missing. Need Memory? Add a Memory module to the Harness. Need a Sandbox? Add another Sandbox layer. Need Subagents? Extend the Agent Loop with multi-Agent scheduling. This works reasonably well while the system is small, but as it grows, the modules begin to entangle with one another.

The Agent Loop needs to know when Memory should run. The Tool system needs to know how the Sandbox works. The permission layer has to intervene before a Tool is actually executed. The Session system, meanwhile, needs to record state changes produced by all of these components. Eventually, adding one new capability no longer means adding one isolated module—it means changing relationships across the existing Runtime.

The Harness can easily end up looking like this:

              Harness Runtime

 ------------------------------------------------

 LLM code
 Tool code
 Memory code
 Session code
 Sandbox code
 Permission code
 Agent Loop code
 Subagent code
 ...

The Harness was originally introduced to manage the complexity of an Agent, but it can quickly become the new center of complexity itself.

DeepSeek Harness takes a very direct approach to this problem:

Everything is a Plugin

The idea is to avoid hard-coding specific capabilities directly into the Runtime whenever possible. Instead, the Runtime becomes a platform responsible for loading, composing, and managing capabilities.

The architecture therefore shifts from “a Harness containing a collection of modules” toward something closer to this:

              Harness Runtime

                    |

              Plugin System

 ------------------------------------------------

 |          |          |          |             |

 Model    Tool     Memory    Session      Agent Loop

Plugin   Plugin    Plugin    Plugin       Plugin

The important point here is that a Plugin in DeepSeek Harness is not just a Tool. Model adapters, Session infrastructure, Agent Loops, and other runtime capabilities can all be brought under the same plugin model. In other words, an Agent is no longer defined primarily by a hard-coded Agent class. It is increasingly defined by the set of capabilities currently loaded into the Runtime.

That is a significant shift.

Traditionally, a Coding Agent might be implemented as something like:

Coding Agent
├── LLM
├── Shell
├── File System
├── Git
└── Memory

Those capabilities are usually tightly associated with the Agent itself.

Under a plugin-based design, the same Agent is better understood as:

Agent Runtime
     +
Model Plugin
     +
Shell Plugin
     +
File Plugin
     +
Session Plugin
     +
Memory Plugin

Change the combination, and you can construct a different Agent. The Runtime does not need separate implementations for a Research Agent, Coding Agent, or Data Agent. Instead, it needs a stable mechanism for composing capabilities.

But this immediately creates a second problem: Plugins inside an Agent system are more complicated than ordinary software plugins.

In conventional software, a plugin is often little more than an extra callable feature. A translation extension in a browser, for example, might simply expose:

translate(text)

You provide text, receive a translation, and the plugin has done its job.

Many capabilities inside an Agent system do not work like that.

Take Memory. If a Memory Plugin were nothing more than:

memory.search()

then it would effectively be just another Tool.

A real Memory system may need to load previous experience when a task begins, retrieve relevant information before model inference, record important outcomes after a Tool executes, and extract durable knowledge when the task finishes.

In other words, it participates in several stages of the Agent lifecycle:

Task begins
   ↓
Load history

Before model inference
   ↓
Inject relevant information

After tool execution
   ↓
Record results

Task ends
   ↓
Persist useful experience

So in DeepSeek Harness, it is more useful to think of a Plugin not as:

Plugin = Function

but as:

Plugin Capability + Lifecycle + State

A Plugin does not merely describe what it can do. It also needs to participate in questions such as when it should act, within which runtime environment it should act, and what state should remain after it acts.

This also explains why Tools, although extremely important, are only one kind of Plugin.

Formally, we can write:

Tool \subset Plugin

A Shell Tool itself may be as simple as:

shell("pytest")

Its job is to execute a command.

But before that command actually runs, the Harness may need to answer several questions. Does the current Agent have permission to execute it? Does the operation require user approval? Are the arguments valid? Should the command run on the host system or inside a Sandbox? What happens if it times out?

After execution, another set of questions appears. Is the output too long? Should it be truncated? Where should the full log be stored? Which parts of the result should enter the next Context?

The real execution path therefore looks more like this:

Model produces Tool Call

        ↓

Check capability and permissions

        ↓

Validate arguments

        ↓

Enter execution environment

        ↓

Execute Tool

        ↓

Process result

        ↓

Record state and update Context

        ↓

Continue to the next inference step

At this point, ordinary “modularity” is still not enough.

The components inside an Agent Runtime have two additional relationships that are especially important.

The first is:

Who does this capability belong to?

The second is:

When should this capability intervene?

Suppose a Main Agent creates both a Research Agent and a Coding Agent:

                 Main Agent

              /              \

      Research Agent      Coding Agent

The Coding Agent may need Shell, Git, and file-system access, while the Research Agent may need Browser, Paper Search, and Citation capabilities.

If every Plugin is global, both Agents would see every capability. That would be confusing and potentially dangerous. An Agent whose job is only to inspect code has no reason to possess database-write, deployment, or file-deletion privileges.

Capabilities therefore need a scope.

Some capabilities may be inherited by child Agents. Some should remain local to the current Agent. Others may need to be replaced or restricted in a child Agent. This is the kind of problem addressed by Spatial Composability:

What is the scope of a capability within the Agent structure?

The second problem comes from the way Agents operate over time.

An Agent does not execute a single function and stop. It repeatedly moves through a loop such as:

User input
   ↓
Model inference
   ↓
Produce action
   ↓
Execute tool
   ↓
Receive feedback
   ↓
Infer again

Different Plugins need to intervene at different points in that lifecycle.

A Permission Plugin may need to inspect an action before a Tool executes. A Memory Plugin may need to inject information before the LLM is called. A Logger may need to record results after a Tool returns. These components are not merely attached to the side of the Runtime; they are embedded into the temporal structure of the Agent itself.

That leads to the second concept:

Temporal Composability

In other words: At what point in the runtime lifecycle should a capability appear, what effect should it have, and how should that effect be removed when the capability disappears?

So the real problem behind “Everything is a Plugin” in DeepSeek Harness is not ordinary software modularity.

The deeper goal is:

Turn capabilities inside the Agent Runtime from fixed structure into dynamically composable components, while still controlling where those components apply across Agents and when they intervene throughout the runtime lifecycle.

This is also why DeepSeek does not stop at simply designing a Plugin API.

If Memory, Tools, and Sessions are all converted into Plugins but there is no mechanism for managing their dependencies, scopes, and lifecycles, those Plugins will eventually become tangled again. The complexity has merely been moved somewhere else.

So after “Everything is a Plugin,” the more important question becomes:

Who manages these Plugins, and how can they remain composable inside an Agent Runtime that is constantly changing?

That is where Cordis enters the picture.

DeepSeek Harness Deep Dive(1): Introduction to Agents and Harness

DA SEIN — Thu, 20 Aug 2026 14:04:12 +0000

Over the past few years, the development of artificial intelligence has
mainly revolved around Large Language Models (LLMs). As model scale and
the number of parameters continue to increase, their knowledge and
reasoning abilities have improved continuously. However, from a certain
perspective, what LLMs do is still an evolution from simple "fill in the
blank" into a more complex and longer "fill in the blank" process --- a
user's question is essentially a problem given to the model.

However, this purely conversational interaction is clearly far from
sufficient in real-world applications. For example, when you ask:

"Help me fix the login bug in this project."

A native LLM can list possible causes, suggest solutions, and even
provide code examples, but it cannot truly inspect project files, run
tests, modify code, obtain execution results, or iteratively adjust
itself based on feedback.

Therefore, in order to make LLMs more practically useful, concepts such
as workflows and agents were developed. Today, agents have become one of
the most widely discussed topics in AI.

As the beginning of this series analyzing DeepSeek Harness, let's first
briefly introduce what an Agent is.

From LLM to Agent

At the simplest level, an LLM can be represented as:

LL M : C o n t e x t \to O u tp u t

In other words:

Given a context:

C o n t e x t

the model produces:

O u tp u t

For example:

Input:

User:
Explain Transformer.

Model output:

Transformer is a neural network architecture based on the Attention mechanism...

This process is essentially:

I n p u t \to M o d e l R e a so nin g \to T e x t O u tp u t

This pattern works very well for tasks that are fundamentally
text-based, such as question answering, writing, translation,
summarization, and generating papers.

However, it lacks one critical capability:

I n t er a c t i o n w i t h t h e E n v i ro nm e n t

Why is interaction with the environment so important?

The simplest and most practical way to extend the capabilities of models
is not necessarily to build completely new environments, but rather to
allow models to interact with existing tools and systems.

Therefore, with Agents, models are no longer only answering questions.
They can:

Observe the environment (Observe)
Make plans (Think)
Execute actions (Act)
Receive feedback (Observe)

forming a loop:

O b ser v e \to T hink \to A c t \to O b ser v e \to ...

For example, a Coding Agent:

User:
Fix the failing test.

Agent:

Read project files

↓

Run pytest

↓

Analyze error logs

↓

Modify code

↓

Run tests again

↓

Confirm the fix

As we can see, through interaction with the environment, the Agent gains
much higher practical value.

From Agent to Harness

A simple Agent can be represented as:

Where:

LLM is responsible for understanding the task and generating the next decision.
Tools provide capabilities such as file operations, search, and API calls.
Environment is the external world where tools interact, such as file systems, code repositories, databases, and browsers.

However, this structure is still incomplete.

It is missing:

State persistence
Context management
Permission control
Execution loops

These components together form what is called Harness.

Harness can be understood as:

A complete Agent runtime environment deployed around the model.

In simple terms, if the LLM is the "brain", then Harness provides the
nervous system, sensory system, motor system, and memory system that
allow the brain to actually operate.

Without Harness:

response = llm(prompt)

The model outputs:

Run pytest

But then:

Who runs pytest?
Who records the result?
Who sends the result back to the model?
Who decides whether the task succeeded?

These responsibilities cannot be handled by the model itself.

Therefore, an external system is required:

Model proposes an action

↓

Harness receives the action

↓

Execute the tool

↓

Receive feedback

↓

Update context

↓

Call the model again

Creating this loop:

C o n t e x t_{t} \to LL M \to A c t i o n_{t} \to E n v i ro nm e n t \to O b ser v a t i o n_{t} \to C o n t e x t_{t + 1}

Therefore, we can define:

A g e n t = M o d e l + H a r n ess

A useful analogy is:

If the LLM is the brain, Harness is the nervous system, sensory system,
motor system, and memory system.

Without these systems, the brain cannot act independently.

Therefore, it is easy to understand why the same model can perform
completely differently under different Harness designs.

From Harness to DeepSeek Harness

As mentioned above, the LLM itself only performs:

C o n t e x t \to O u tp u t

What truly turns it into an Agent is the external runtime mechanism that
continuously executes actions, receives feedback, updates state, and
calls the model again.

Harness is responsible for supporting this entire loop.

The most direct responsibility is Tool Management.

The model may decide:

"Run pytest"
"Read this file"
"Call this API"

But the actual execution, result collection, error handling, and
returning results back to the model are all handled by Harness.

Without this layer, the model's actions remain only text.

However, once tools begin running, another problem immediately appears:

The model needs to know:

What happened before?
What actions have already been taken?
What are the tool results?
What is the original goal?

Therefore, Harness also needs to manage Context.

It organizes:

User requirements
Historical actions
Tool results
Current environment state

into the input used for the next model call.

As tasks become longer, Harness must decide:

Which information should be kept?
Which information should be compressed?
Which information can be discarded?

Furthermore, if a task needs to run for a long time, maintaining only
the current Context is not enough.

The Agent also needs to know:

What it has already done
Where it currently is
How to continue after interruption

This is Session Management.

It stores the execution state of the entire task.

Finally, the execution loop itself cannot run forever.

Harness needs to control:

When a tool can be executed
When user confirmation is required
Whether to retry after failure
Whether to continue
When to stop

This is Execution Control.

Therefore, a mature Harness can be roughly described as:

H a r n ess \approx T oo l M ana g e m e n t + C o n t e x t M ana g e m e n t + S ess i o n M ana g e m e n t + E x ec u t i o n C o n t ro l

Naturally, as Agent systems develop, the number of tools increases,
Context becomes longer, Sessions become more complex, and additional
capabilities such as permissions, logging, lifecycle management, and
more extensions are introduced.

Once Harness starts taking responsibility for these capabilities, it can
quickly become a complex system itself.

Therefore, a new question naturally emerges:

How can we allow Harness to continuously gain new capabilities without
putting everything into the Runtime core and eventually turning it
into an increasingly bloated and difficult-to-maintain system?

Or, more directly:

How do we manage the growing complexity of Harness itself?

In my view, one of the values of DeepSeek Harness lies exactly here.

Its design philosophy starts from:

Everything is a Plugin