Ch08 State — Agent’s Execution Context

Agents need to remember many things when processing complex tasks.

What step have we reached? What were the previous results? Which subtasks are completed, which are still in progress? Which tools have been called, what were the returned results?

This information is the Agent’s state.

An Agent without state management is like a project manager without a notebook—forgets what they’re doing halfway through, or repeats work already completed.

8.1 A Real Problem

You ask the Agent to help you write a 10-page report. The Agent wrote 5 pages, called a search tool once, and got some data.

At this point, your browser crashes.

After reopening, an Agent without state management will start from the beginning—the previous 5 pages were written in vain, and the search needs to be redone.

An Agent with state management will continue from page 5—it remembers what was written, what was searched, and where to pick up.

This is the value of state management.

8.2 Stateful vs Stateless Agents

Stateless Agents

Each call is independent. The results of the previous call cannot be seen by the next.

Stateless Agents are suitable for simple question-answering. The user asks a question, the Agent answers, and it’s done.

But if you want to do a multi-turn dialogue—“Help me revise the third section of the previous analysis report”—a stateless Agent doesn’t know what the “previous analysis report” is.

Stateful Agents

The Agent can remember the results of previous calls. The output of the previous step is the input for the next.

Stateful Agents are suitable for multi-step tasks, multi-turn dialogues, and long-term projects.

State Storage

States can be stored in different places:

• In memory: Fastest, but lost when the process restarts. Suitable for temporary state.
• In database: Persistent, not lost on restart. Suitable for long-term state.
• In files: Simple and direct, suitable for structured data.

Implementation: In LangGraph, state is defined via the State class and persisted via Checkpoint. State includes message lists, tool call results, intermediate variables, and execution progress.

Complete state management: Includes task creation, step updates, pause/resume/failure handling, progress querying, etc. State can be stored in memory, Redis, or files.

8.3 Persistent Execution: How to Recover After Interruption

Core Idea

The core idea of persistent execution is: save the current state after each step is completed.

When starting next time, restore from the last saved state and continue execution from the breakpoint.

This is the same principle as a game’s auto-save. If the power goes out halfway through a game, you load the save and continue, without needing to restart from the first level.

Checkpoint Mechanism

LangGraph uses checkpoints (Checkpoint) to implement persistence. After each super-step ends, the current state is automatically saved.

State includes: message list, tool call results, intermediate variables, execution progress.

When restoring, load the state from the most recent checkpoint and continue execution.

Implementation: Create a checkpoint store with MemorySaver, enable checkpoints when compiling the graph, and specify a session ID when executing. After interruption, simply call again with the same thread_id to restore.

Complete persistent execution example: Build a StateGraph containing outline generation, section writing, and report integration, enabling checkpoint persistence. After interruption, simply call again with the same thread_id to restore from the checkpoint.

Human-in-the-Loop Coordination

Persistent execution also supports human-in-the-loop.

When the Agent executes to a step requiring human confirmation, it pauses and saves the state. After human review, execution resumes.

This makes long-running tasks feasible—the Agent can execute for days or even weeks, with the ability to pause, resume, and modify in between.

8.4 State Machine Thinking: Designing Agent Flows with State Diagrams

What is a State Machine

A state machine is a way of thinking: viewing the Agent’s execution flow as a series of states and transitions between states.

The Agent starts from the “initial state”. After executing an operation, it transitions to the “executing state”. If execution succeeds, it transitions to the “completed state”. If execution fails, it transitions to the “error state”.

Designing with State Diagrams

When designing an Agent flow, first draw a state diagram:

• List all possible states: initial, searching, analyzing, writing, reviewing, completed, failed.
• Define transition conditions between states: search completed → enter analysis. analysis failed → return to search. review passed → enter completion.
• Annotate the behavior of each state: In the “searching” state, the Agent calls the search tool. In the “analyzing” state, the Agent calls the analysis tool.

After drawing the state diagram, the Agent’s complete behavior becomes clear at a glance. This is much clearer than writing code directly.

Benefits of State Machines

• Predictable: You know the Agent’s possible behavior in any state.
• Debuggable: When problems occur, you know what state the Agent was in and which transition had the problem.
• Testable: Each state and transition can be tested separately.
• Extensible: Adding new features only requires adding new states and transitions, without modifying existing logic.

Chapter Summary

State is the Agent’s execution context. Key points:

1. Stateful vs Stateless: Complex tasks require stateful Agents.
2. Persistent execution: Save state at each step, recoverable after interruption. Like a game’s auto-save.
3. LangGraph Checkpoint: Built-in persistence mechanism, one thread_id gets it done.
4. State machine thinking: Design Agent flows with state diagrams, clear, predictable, debuggable.

The next chapter covers the last subsystem of the Harness: Safety. The Agent’s boundaries and guardrails.