In This Issue
Why an agent system has several kinds of state, not one memory
Where conversation, workflow, business, execution, and artifact state should live
Why persistence alone does not make an agent recoverable
How to test whether a failed run can be reconstructed safely
A practical state ownership exercise for one real workflow
The signal
Agent systems rarely have one state.
They have several kinds of state moving at different speeds and living in different components.
Conversation history may sit with a model provider. A workflow checkpoint may sit in an orchestration database. A customer record may remain in the system of record. A generated file may live in object storage. An approval may be recorded in an application table or a queue message.
The system can work while every piece remains available. The architecture is tested when a worker fails, a message arrives twice, or an external action completes without the local system recording the result.
At that point, asking whether the agent has memory is not enough.
The more useful questions are:
Which component owns each type of state?
Which copy is authoritative?
What must survive a failure?
What must be retrieved again?
Can the system determine the next safe action without guessing?
An agent that remembers the conversation can still lose the task. A workflow that resumes from a checkpoint can still act on an outdated customer record. A system that logs every tool call can still send the same message twice.
State becomes dependable when its ownership and recovery rules are explicit.
What it is
State is any information that can change what the system does next.
That includes the messages the model sees, the objective it is pursuing, the step a task has reached, the approvals still pending, the tool results already produced, the files created, the retries attempted, and the current facts retrieved from outside the agent.
These elements serve different purposes and should not automatically share one storage or lifecycle model.
State type | Examples | Natural owner |
|---|---|---|
Conversation state | Messages, summaries, active instructions | Conversation service or application store |
Task state | Objective, constraints, current step, pending approval | Application database or workflow engine |
Execution state | Tool calls, attempts, errors, completed transitions | Run ledger, event history, or orchestration system |
Business state | Customer status, inventory, permissions, policy | Authoritative business system |
Artifact state | Files, reports, code changes, messages sent | Repository, object store, or destination service |
System state | Agent definition, tools, policies, feature flags | Versioned configuration and deployment systems |
Conversation state helps the model maintain continuity. Task state tells the application what work remains. Execution state records what has already happened. Business state represents what is currently true outside the run.
Combining them into one large memory object may feel simpler at first. It makes authority harder to establish when records disagree.
Why it matters
A stateful agent can continue a conversation. A recoverable agent system can explain where it stopped and determine how to continue safely.
Those are different capabilities.
Suppose an agent is creating a customer refund. It verifies eligibility, requests approval, submits the refund, and prepares a confirmation message.
The worker fails immediately after calling the payment system.
When a replacement worker starts, the conversation history may show that the refund was planned. The workflow checkpoint may show that the payment step was in progress. The payment provider may show that the refund was completed.
Which state wins?
The payment provider owns the result of the payment operation. The workflow engine owns the progression of the task. The conversation is only a working representation of what the user and system discussed.
If the replacement worker treats the conversation or an old checkpoint as the source of truth, it may submit the refund again.
The same problem appears in less obvious workflows. An agent can send a duplicate email, open a second ticket, overwrite a newer file, repeat a code change, or continue under permission that has since been revoked.
Reliable recovery depends on knowing which component can answer each question.
How it works
Keep model context replaceable
The context window is a working view, not the durable record of the system.
It can contain selected messages, retrieved facts, task summaries, tool results, and current instructions. Its purpose is to give the model enough information to make the next decision.
If the context disappears, the application should be able to assemble it again from records that have defined owners.
Provider-managed conversation state can simplify continuity. It does not remove the need to decide what the application must retain independently, how long provider-held state persists, or which business facts must be retrieved again.
Checkpoint task progress
A checkpoint should capture enough task state to resume from a meaningful boundary.
That normally includes:
The current objective
Confirmed constraints
The last committed step
A pending approval or unresolved decision
References to durable outputs
Retry and timeout information
The version of the workflow that created the checkpoint
LangGraph checkpointers save graph state at execution steps. Temporal persists workflow event history and uses it to recover execution.
The mechanisms differ, but both address the same architectural requirement: a live worker should not be the only component that knows where the task stands.
Retrieve changing facts from their source
Some information should survive between steps. Other information should be retrieved again.
Prices, permissions, policies, repository contents, account status, and inventory can change after a checkpoint is written.
The system may need to preserve the identifier it used and the decision it made at the time. Before taking another action, it should retrieve the current fact from the component that owns it.
This prevents an old workflow snapshot from silently overriding newer business state.
Record side effects separately
An intention is not proof that an action completed.
A message in the conversation saying that an email will be sent does not prove that it was sent. A tool call recorded as started does not prove that the destination accepted it.
External actions need a reconcilable record. That may include an idempotency key, external operation ID, attempt number, request status, and confirmed result.
When a retry begins, the system should check the destination before repeating the action.
The reconstruction test
A simple failure exercise exposes weak state ownership.
Stop the worker immediately after a tool call. Start a replacement worker with only the run ID.
Can it determine:
What the user asked it to accomplish?
Which constraints were confirmed?
What step was last committed?
Which external action may have completed?
Whether an approval is still valid?
Which agent, prompt, tool, and policy versions were used?
What the next safe action is?
If answering these questions requires reading logs by hand, asking the model what it remembers, or guessing whether an external action completed, the system has stored data but does not have reliable recovery.
Full bit-for-bit replay is not always possible. Model outputs can vary. External systems change. Some tools are nondeterministic.
The useful goal is controlled reconstruction.
The system should preserve authoritative inputs, state transitions, versions, durable outputs, and external operation identifiers. That should be enough to resume the run, compensate for a completed action, or close the task without inventing missing history.
What to know before committing
One database can hold several types of state. That does not mean they should share one logical contract.
Conversation records, workflow checkpoints, approvals, tool attempts, and business facts may live in the same physical database while retaining different owners, retention rules, and update paths.
Version compatibility also matters.
A checkpoint created by one version of an agent may not be safe to resume under another. The workflow schema may have changed. A tool may accept different inputs. A policy may now block an action that was previously allowed.
Long-running work needs an explicit decision about whether old runs will be migrated, resumed under their original version, revalidated, or closed.
More stored state is not automatically safer. It expands privacy exposure, retention obligations, and the chance that stale information will be mistaken for current truth.
Keep the minimum state needed for continuity, recovery, and audit. Retrieve changing facts from their owner.
Worth reading
LangGraph’s documentation on persistence and checkpointers shows how graph state can be saved at execution steps and associated with a thread, enabling interruption, inspection, and recovery without depending on one live process.
Takeaways
Before adding another memory feature, create a state ownership map for one real agent workflow.
List every piece of information that can change the next action.
Label its scope: turn, conversation, task, run, user, project, or organization.
Name the component that owns the authoritative version.
Identify every cached, summarized, embedded, or derived copy.
Mark the boundaries from which work can safely resume.
Record external side effects with an operation identifier and confirmed result.
Define which facts must be retrieved again before the next action.
Record the workflow, model, prompt, tool, and policy versions associated with the run.
Stop the worker after a tool call and attempt recovery using only the run ID.
Anything that must be guessed is a missing state contract.
The core test is straightforward: after a failure, can the system reconstruct what happened and choose the next safe action from authoritative records?
Where does your current agent workflow keep the state needed to recover after a failed tool call?
If this helped you, leave a comment or your reaction. I’d like to hear where you landed.
INVENEW exists to help tech builders, operators, founders, and leaders turn AI from experiments into working systems.
In partnership with AtScale
Everyone in data and AI is selling "context." Almost no one means the same thing by it. Metadata catalogs call themselves context platforms. So do knowledge graphs, warehouse-native semantics, and workflow engines. Each solves a real problem. Most of them don't solve the same one.
Note: Third-party company and product names belong to their respective owners and are used for identification and illustrative reference only.