Persistence
Start with state and persistence
Read the overview of thread-level checkpoints and cross-thread stores, then sketch what your workflow must retain.
Start with: Persistence
RedLectern topic
Agent memory and orchestration
State across steps · persistent memory · coordination · multi-agent arrangements.
For: Application builders
After this page you can: Design state handling and decide whether coordination is necessary.
Page reviewed
Part of: Artificial Intelligence › AI agents
About Agent memory and orchestration
An agent’s current state is the information available as it works: messages, tool results, instructions, and other context. Decide what must survive a step, a conversation, or a process restart before choosing how to store it. In LangGraph’s documentation, checkpointers keep graph state for a thread, while stores hold application-defined data across threads. Those are different jobs: a saved conversation can support continuity, while a separate store can hold information intended for reuse across sessions.
Orchestration is the coordination of state, tools, and workflow steps. It may be a fixed sequence, a router, a handoff between agents, or a lead agent delegating work. Multiple agents are useful when distinct work can proceed in parallel or needs separate context; a single agent with suitable tools may be enough for other tasks. Start by mapping the state and dependencies in one workflow. Add coordination only where the map shows a real need, and make each handoff’s inputs and outputs explicit.
Start here
Multi-agent
Compare coordination patterns
Use the pattern guide to compare subagents, handoffs, routers, and custom workflows.
Start with: Multi-agent
Learn the foundations
1.Choose what to retain and coordinateAgent memory is information an application retains so it can be reused across steps or sessions.
Agent memory is information an application retains so it can be reused across steps or sessions. Before storing anything, decide its scope: does it belong only to the current step, the ongoing thread, or future conversations? LangGraph describes checkpointers as thread-scoped state and stores as application-defined data that can persist across threads. This distinction helps builders choose a persistence boundary instead of treating all history as one undifferentiated memory.
Orchestration coordinates workflow steps, state, and tools. A single agent can follow a workflow, while multi-agent designs add distinct roles and coordination paths. A practical first design is to list each step’s inputs, outputs, and state changes; then identify where a checkpoint or shared store is needed. Add agents only when a specific coordination pattern addresses a need such as parallel work, context separation, or routing.
- Memory
Shows short-term thread memory and long-term memory across sessions.
Agent memory
Information retained for reuse across agent steps or sessions.
Orchestration
Coordinating models, tools, state, and workflow steps.
Multi-agent system
A system in which multiple agents interact or coordinate.
Try it
A support assistant must remember the current conversation and a user preference for a later conversation. Which information would you keep with the current thread, and which would you store for reuse?
Keep the current conversation with thread-scoped state so the assistant can continue that interaction. Store the user preference as application-defined information scoped to that user so it can be retrieved in a later thread.
2.Carry state across steps and sessionsState handling starts with deciding what the next step needs, and what should persist after the current run.
State handling starts with deciding what the next step needs, and what should persist after the current run. A checkpoint can preserve a thread’s graph state; a store can hold application-defined information across threads. Keeping those purposes distinct makes it easier to reason about resuming work, continuing a conversation, and reusing information in a later session. Choose storage according to the intended lifetime and scope of each item.
For a small exercise, sketch a workflow with two steps and mark what each step reads and writes. Then label each item as step-local, thread-level, or cross-thread. For example, a tool result needed by the immediate next step may stay in workflow state; the conversation history may need thread persistence; a saved preference may need cross-thread storage. Review what the application should retrieve before passing stored information into a later step.
- Persistence
Provides a concise comparison of thread-scoped checkpoints and cross-thread stores.
Try it
For a two-step order assistant, classify these items by lifetime: the latest tool result, the current conversation, and the user’s preferred delivery address for future orders.
The latest tool result can be step-local if only the next step needs it. Keep the current conversation as thread-level state. Store the preferred delivery address as cross-thread user data if the application is meant to reuse it in later conversations.
3.Decide whether coordination is necessaryMultiple agents introduce coordination choices: who assigns work, what context each agent receives, how results return, and where shared state lives.
Multiple agents introduce coordination choices: who assigns work, what context each agent receives, how results return, and where shared state lives. Common arrangements include a main agent calling subagents, a router directing requests to specialists, or handoffs that change which agent controls the interaction. These patterns solve different workflow needs; the presence of a complex task alone does not establish that several agents are needed.
Try drawing the workflow as steps and dependencies. If independent parts can run separately, a parallel worker arrangement may fit. If the next step depends on the previous result, a sequential workflow or handoff may be clearer. If one agent with selected tools can do the work, keep that design as the baseline. For any coordination path, define each role’s task and the result it must return, then check that the coordinating part can combine the results.
- How we built our multi-agent research system
Describes one orchestrator-worker arrangement and engineering considerations for parallel research agents.
Try it
A workflow must summarize three independent reports and combine the summaries. Would you begin with one agent or multiple agents? State one reason and one coordination detail to specify.
Multiple workers are a reasonable design to consider because the three reports can be handled independently. Specify that each worker returns a summary tied to its report, and that a coordinating step combines the three summaries.
Latest
No recent updates are available.
Books
Designing Data-Intensive Applications, 2nd Edition
Martin Kleppmann and Chris Riccomini · 2026
Use its discussion of data-system trade-offs to reason about reliable, persistent application state. It supplies the storage and reliability foundations for the topic’s cross-step questions.
An Introduction to MultiAgent Systems
Michael Wooldridge · 2009
A 2009 second edition, it predates current LLM frameworks; use it for durable concepts about agent design, cooperation, and interaction, not current framework instructions.
- Multiagent Systems: Algorithmic, Game-Theoretic, and Logical Foundations
Multiagent Systems: Algorithmic, Game-Theoretic, and Logical Foundations
Yoav Shoham and Kevin Leyton-Brown · 2008
Use this formal reference to examine distributed problem solving, coordination, and group protocols. Its 2008 treatment is conceptual, so pair it with current implementation references.