Agent Systems · 21-c03
26 June 2026 · State and durability
A production agent's reliability often depends on state design before model quality. If the system cannot tell where it stopped, which tool result it trusted, and which side effect already happened, intelligence becomes luck.
- Core split
- state != durability
- Key term
- checkpoint
- Operation
- replay + redrive
- Risk
- repeated side effects
Key terms in this post
- conversation state
- task state
- tool state
- checkpoint
- durable execution
- rollback
- idempotency
- compensation
The previous posts covered agents through goals, tools, loops, and architecture. This one moves into the less glamorous layer: agent state.
Saving chat history is not durable execution. Conversation state helps the model continue; durable execution defines how a multi-step job survives crashes and resumes without repeating unsafe side effects.
State layers
State is the meaningful information a system carries into the next decision. In agents, it is not one box: conversation state, task state, tool-result state, and side-effect state have different durability needs.
This distinction matters because not all state can be rolled back in the same way. A summary can be corrected; a double charge is a different problem.
conversation state
User intent, message history, summary, and active context.
task state
Plan, node, step, dependency, and intermediate output.
tool-result state
Tool input, output, error, retry count, and evidence.
side-effect state
Writes that have happened in the external world.
Conversation state
Conversation state keeps the model inside the same conversation. Message history, summaries, system instructions, response IDs, and sessions belong here.
It does not by itself prove which tool calls ran, which files changed, or which step can be safely retried.
Conversation memory is necessary for UX, but it is only one input to durable execution.
The user's intent and previous answers remain available.
Long history increases token and context pressure.
Tool side effects and progress need separate records.
Task state
Task state describes where the agent is in the work: plan item, node, dependency, interrupt, or terminal state.
Graph systems separate checkpointers for thread-scoped state from stores for durable cross-thread information.
request
The request becomes a task spec.
plan
Steps and dependencies are produced.
step
The active node and output update.
interrupt
Failure, approval, or wait state is recorded.
resume
The same thread continues from a safe point.
Tool state
Tool state is the evidence ledger for external contact: inputs, outputs, errors, latency, retries, and operation IDs.
Idempotency means the same operation key does not create the same external effect twice.
Retries are useful, but without recorded tool state they can amplify side effects.
operation id
Stable key for the same work.
input hash
Comparable representation of the tool request.
result payload
Saved observation for later reasoning.
side effect marker
Whether a write happened outside the agent.
retry policy
Which errors may be retried and how often.
Checkpoint
Checkpoint is not a raw memory dump; it is a logical snapshot of the workflow's state.
Its value is that it can be inspected, resumed, forked, or migrated.
Thread IDs, checkpoint IDs, parent IDs, schema versions, and tool evidence become the debugging spine.
thread_id
Conversation or job line.
checkpoint_id
Unique snapshot identifier.
parent_id
Previous point for fork and audit.
state_snapshot
Serializable task state.
tool_evidence
Trusted tool results so far.
schema_version
How old state should be read.
Durable execution
Durable execution lets a long-running job live beyond a single process.
Event sourcing records the events that created state rather than only the current state.
LLM calls, HTTP requests, time, randomness, shell commands, and browser clicks should sit behind recorded tool/activity boundaries.
command
The orchestrator requests work.
event
The runtime persists the outcome.
replay
Code rebuilds state from history.
resume
New decisions start from the safe point.
Rollback and redrive
Rollback is not always a database-style undo. External side effects often need compensation.
Redrive means continuing from a failed or safe step rather than rerunning everything.
The system must know what is preserved, what is rerun, and what must never be repeated.
read failure
retry
Repeat a bounded read.
wrong state
fork
Open a new branch from a checkpoint.
write happened
compensation
Record a corrective external action.
schema changed
migration
Move old checkpoints into the new schema.
Production notes
Good state design makes an agent more accountable. You debug through checkpoints, event history, tool evidence, and side-effect records.
Conversation state gives UX continuity; task state manages work; tool state preserves evidence; durable execution lets the whole system outlive a process.
Conversation
How is history summarized and trimmed?
Task
Are active steps and terminal states structured?
Tool
Are inputs, outputs, and errors recorded?
Idempotency
Do write tools accept stable operation IDs?
Checkpoint
Can state be inspected, resumed, forked, and migrated?
Replay
Are nondeterministic actions behind tool/activity boundaries?
Compensation
Do irreversible effects have corrective flows?