Checkpoint: A Working Mental Model of the Harness
DeepSeek Harness becomes easier to understand when three facts are read as one system: Cordis assembles the live plugin tree, the Agent loop turns admitted input into model and tool work, and the Session log records the model-visible result. This checkpoint connects those facts into a practical ownership model. The goal is not to repeat the lifecycle, but to make it possible to look at a new capability and ask where its state lives, which lifecycle owns it, and which extension point should change.
That model is useful because the same behavior can cross several boundaries before a person sees it. A request may begin in a profile patch, enter a scoped Agent, pass through a prepared LLM route, call a tool, meet a policy decision, and return as both a live update and a durable event. If those boundaries are blurred, a provider replacement can look like a loop change, a UI notification can be mistaken for history, or a scope can be mistaken for a security barrier.
Follow one request from composition to replay
Start with a user asking DeepSeek Harness to inspect a repository. The dsh launcher selects a profile, and the profile’s ordered bundles and patches construct a Cordis context. The context contains service providers for the model, tools, sessions, and any policy or transport the chosen surface needs. A dependent plugin does not become active merely because its row appears in a configuration file; its injected services must be available.
The browser or another host then creates an Agent. During the unpublished setup window, the creator can install the scoped prompt sections, tools, restrictions, or listeners that belong to this Agent. Only after that composition is ready does the Agent and its Session become publicly announced. The same process can hold several Agents whose registration sets differ, while global services continue to serve responsibilities that must span sessions.
The user’s prompt enters the Agent inbox. The loop opens a turn, claims the appropriate input, assembles the prompt and visible tool schemas, and asks the live pre-step pipeline whether the proposed step should enter. At this point the message has been offered to the lifecycle, but it has not automatically become model history. A hook may reject it, a context provider may rewrite it, or cancellation may win before commitment.
If the proposal is admitted, the loop opens a step and resolves the actual LLM call. The selected adapter checks the exact model’s capabilities and materializes any adapter-owned defaults. Only then does the loop commit the system prompt, accepted user messages, request header, and route context as needed. It derives the request from those durable facts and freezes it before the provider sees it.
The response then travels in two directions. Live assistant-stream frames can reach a UI as the provider emits chunks. Durable settlement reaches the Session log as an assistant message or an assistant attempt. If the response requests a tool, the loop records the call, sends it through the tool pipeline, records the single model-facing result, and may begin another step in the same turn. When no work remains, the loop records the turn’s ending reason and reports idle status.
The request has therefore passed through several owners without becoming several competing versions of itself. The profile owns composition. The Agent owns live control and setup. The loop owns turn and step transitions. The LLM adapter owns provider translation. The tool runtime and its policy listeners own external-call handling. The Session owns the durable facts from which the model history is derived.