DeepSeek Harness · 2 of 6
One turn through source
The default driver is a harness-controlled phase machine. `AgentLoop` creates the runtime; `ReactLoopAgent` owns one session’s inbox, scope, phase, and projected request state.
§1
Separate the factory from the running agent
AgentLoop injects the agent registry, session store, LLM service, tools, and prompt assembler, then creates or resumes agents. The per-session ReactLoopAgent holds the session, inbox, current phase, scoped context, and runtime-context projection. Source · AgentLoop Source · ReactLoopAgent
The class name can mislead: ReactLoopAgent is not the LLM. It is the controller that repeatedly prepares requests for an LLM and commits the resulting events.
§2
The source trace
| Stage | Concrete owner | Durable/live boundary | Pinned source |
|---|---|---|---|
| Accept input | followup(), steer(), or inject() on the agent inbox. | Live inbox events; different queues and wake behavior. | agent.ts 113–140 |
| Open turn | Driver claims next-step input and one queued prompt. | turn/start is durable; claim/status signals are live. | lifecycle 19–38 |
| Admit step | agent/pre-step waterfall may reject or rewrite messages. | A rejected first claim can close a durable turn with no step. | agent.ts 225–242 |
| Build request | Prompt assembler plus runtime-context projection derive model history and tool schemas. | Model-visible data must be reconstructable from session events. | architecture 92–96 |
| Stream model | agent/request then llm/stream waterfalls. | assistant/chunk* and final assistant/message are durable. | lifecycle 39–52 |
| Execute tools | Driver classifies calls and uses bounded scheduling plus ordered result commitment. | tool/call and tool/result are durable around live tool waterfalls. | lifecycle 53–66 |
| Continue or stop | Owed tool work or next-step input starts another step; otherwise agent/turn-stopping runs. | step/end and turn/end are durable. | lifecycle 67–80 |
§3
Turn and step have exact meanings
In this architecture, a step is one model request plus the tools it calls. A turn contains zero or more steps: it opens before first input is claimed and closes when nothing remains owed. The zero-step case matters because a pre-step listener can reject the proposed first step while the durable log still records the attempted turn. Source · turn flow
This contract makes hooks legible. agent/pre-step can control what enters a request. agent/request can alter the request envelope. llm/stream can wrap provider streaming. agent/turn-stopping is the final serial checkpoint after natural work appears complete.
§4
Follow-up, steering, and injection are not aliases
The pinned agent exposes different inbox paths. Follow-up content is queued work that can wake the driver. Steering targets the next-step path. Injected context waits in the inbox until another admitted message causes a request. All pass through the pre-step waterfall when claimed. Source · inbox methods
The distinction gives live control without smuggling unlogged model context. An injection can be delayed, but once it becomes model-visible it must enter the durable event surface.
§5
Model-visible means logged
DeepSeek derives model history from the append-only session log and asserts that anything sent to the model is reconstructable from that log. Raw assistant chunks preserve stream/UI fidelity, while the completed assistant message records the provider call result even when visible content is empty. Source · model-visible invariant
A tool result may contain an artifact locator rather than every external byte, while the model-visible representation and its provenance remain reconstructable.
§6
Error recovery is another controlled transition
A provider failure closes the current step before agent/request-error listeners decide whether a retry action is justified. Compaction can respond to canonical context overflow, but retry occurs only when pruning or summarization actually advances the model surface; otherwise the original error remains authoritative. Source · request error path
The pattern avoids success-shaped recovery. A retry is a new controlled attempt based on a changed surface, not a silent loop around the same failed request.