The First Checkpoint: A Working Model of Capability, State, and Side Effects
DeerFlow 2.0 is easiest to misunderstand when its capabilities are considered one at a time. The Gateway, lead agent, skills, tools, sandbox, thread state, and evidence only make sense as parts of one controlled execution system. This checkpoint connects those parts and gives the reader a practical test for any design choice: is it changing what the agent can do, what the thread remembers, what the environment changes, or what the runtime can prove?
One objective passes through four different dimensions
Start with a single objective: “Investigate this question and give me a report I can use.” In DeerFlow, that sentence does not become a model response in one step. It becomes a run owned by a thread. The Gateway admits the run and establishes the execution context. The lead agent interprets the objective. Middleware prepares the request, applies policy, and maintains structured state. Tools and skills supply the actions and workflow knowledge. The sandbox gives those actions a place to operate. Events, artifacts, and delivery records connect the work back to the user.
That chain is causal. If the request is not admitted, no agent exists for the run. If the model has no suitable capability, it cannot gather or transform the needed information. If the capability is visible but not authorized, the call should not cross the execution boundary. If the tool runs without a thread-scoped environment, its files and side effects may have no clear owner. If the result is streamed but not recorded, a reconnect or restart can leave the user with an incomplete picture. Each layer answers a different question, and a failure at one layer should not be diagnosed as a failure at another.
The most useful way to organize the system is around four dimensions:
- Capability: What can the lead agent invoke? Built-in tools, configured providers, skills, MCP servers, and extensions answer different versions of this question. A skill may provide instructions and constrain tools; an MCP server may expose an external action; an extension may alter the host runtime itself.
- State: What does the run or thread retain? ThreadState includes messages but also sandbox identity, artifacts, goals, delegation entries, loaded-skill references, summaries, and background-task projections. Checkpoints and structured reducers determine how that state survives updates and replay.
- Side effect: What changes outside the model’s text? A sandbox can read or write files, execute commands, contact an external service, or create an artifact. The provider determines whether those operations are host-local, container-isolated, or remote and synchronized.
- Evidence: What can the runtime show about what happened? Stream events show progress, receipts record tool execution, workspace snapshots identify changed outputs, and delivery checks connect produced files to the user-visible result. None of these automatically proves that the report’s reasoning is correct.