What is a harness, really?
The model proposes the next step; the harness turns it into controlled, recoverable action
model + context + tools + state + control + surfacesWhy can the same model feel like a different system inside another agent product?
Think of the model as a brilliant new pilot. The harness is not one cockpit button; it is the aircraft, instruments, checklists, air traffic control, flight recorder, and maintenance regime. The pilot chooses; the system makes the choice executable and accountable.
Mechanism
DeepSeek Harness assigns the complexity around model calls to plugin-owned capabilities: sessions preserve facts, prompt assembly builds requests, tools execute actions, policy and sandboxes constrain them, and client surfaces present results.
The design goal is not to make the model intrinsically smarter. It is to keep models replaceable, runs replayable, capabilities composable, and failures convergent.
Receive intent
Web, CLI, ACP, or SDK delivers the same agent input.
What extensions must preserve
- Every model-visible fact must be reconstructable from the log
- External action must cross a harness-owned capability boundary
- Replaceable capabilities must not leak concrete providers into the agent loop
The tempting wrong turns
- ×Equating tool calling with a production agent
- ×Stuffing every state into the messages array
- ×Using prompt wording as a substitute for real permissions and sandboxing
Do not trust the conclusion—verify it
These anchors are pinned to official deepseek-harness@47f9438; account for later breaking changes when reading current upstream.
Pause for ten seconds before revealing
Where is the responsibility boundary between model and harness?
Next we examine why DeepSeek Harness organizes these responsibilities as plugins instead of growing the central loop.