How DeerFlow Keeps Long Work Coherent: Checkpoints, Compaction, Memory, and Goals

For DeerFlow, long-running work raises a precise continuity problem: which parts of an objective must remain exact, which can be compressed, which should become cross-session knowledge, and which should continue to drive the next turn? This chapter separates checkpoints, summaries, durable context, memory, and goals, then applies them to a recurring workflow. The distinction matters because DeerFlow can preserve a great deal of information without claiming that every preserved fragment is complete, current, trusted, or correct.

Five kinds of continuity

A checkpoint is the durable state of an ongoing graph execution. It belongs to a thread and can include the message history plus structured channels such as the sandbox identity, artifacts, goals, delegation records, loaded skill references, and summary text. A checkpoint answers, “What state does this conversation and its current workflow have?” It is the foundation for resuming, reading history, branching, or rolling back conversation state.

A summary is a lossy representation of older conversation material. When the context approaches a configured threshold, DeerFlow can retain a recent message window and generate summary_text for the older portion. The summary model can fall back to the run’s own model if a separately configured summary provider fails; if generation still fails, the automatic path leaves the existing compaction state unchanged. This is a useful failure behavior: an unavailable summarizer should not silently replace a detailed history with an empty or misleading summary.

Durable context is selected runtime information that DeerFlow preserves separately so it can be reintroduced after messages have been compacted. Delegation entries and loaded skill references are captured before summarization removes the tool calls or file reads that revealed them. On a later model request, the middleware injects a static authority contract and a separate hidden data message containing the summary, delegation ledger, skill references, and—when enabled—task notes. The data message is explicitly treated as untrusted historical observation, not as a new system instruction.

Memory is cross-session knowledge associated with a user or agent. It is not a replay of the current thread. A stored preference may help a later conversation, but it does not prove what happened during a particular run. Conversely, a tool result or temporary project constraint belongs to the current workflow unless it passes the rules for becoming durable user knowledge.

A goal is an active completion condition for a thread. It does not store the whole task or replace the checkpoint. After a visible run, DeerFlow can use a non-thinking evaluator to decide whether the goal is satisfied, blocked by missing evidence or user input, failed, waiting on an external condition, or simply not met yet. Only a bounded, no-progress-checked continuation may be added when the latest assistant turn is durably checkpointed and the thread has not changed during evaluation. The goal is therefore a controlled request to keep working, not an instruction to run forever.

These mechanisms have different owners and triggers:

• Checkpoints are written as graph state changes and are used for exact thread continuity.
• Summaries are generated when context thresholds or an explicit compaction request require compression.
• Durable context is captured from selected runtime events before compression and projected into the next model request.
• Memory is updated and recalled across sessions according to a backend’s scope and retrieval contract.
• Goals are evaluated after visible runs and can produce bounded hidden continuations.

Using the right mechanism is a design decision.