AI agents do not need more context — they need better state

When an AI agent loses the thread of a task, the default diagnosis is usually simple: it needed more context.

So the team adds more. The full conversation, more documentation, longer tool outputs, previous plans, old error logs, and every file that might be relevant are packed into the prompt. The agent can now see more of the past, but its work does not necessarily become more reliable.

Sometimes it becomes worse.

Important decisions compete with stale observations. A resolved error remains visible beside the current one. An early plan survives after the code has changed. The agent reads the entire history but cannot reliably distinguish a fact from an assumption, or the current state from the route used to reach it.

The problem is not always missing context. It is missing state.

Context is a record; state is a model

Context answers: what information has appeared during this run?

State answers different questions:

• What is true now?
• What has already been completed?
• Which assumptions remain unverified?
• What is blocking progress?
• Which action should happen next?

A transcript may contain the answers, but only as scattered evidence. The agent still has to reconstruct the current situation from a sequence of messages, tool calls, failures, corrections, and partial results.

That reconstruction becomes harder as the task grows.

Consider an agent changing an application across several files. It first assumes that authentication is handled in middleware, later discovers that one route bypasses it, changes the implementation, runs a test that fails for an unrelated fixture, fixes the fixture, and then receives a new requirement.

The transcript preserves every step. A useful state model preserves only what the next decision needs: the current requirement, the files changed, the authentication constraint, the remaining failing check, and the fact that the original middleware assumption was false.

History explains the journey. State controls the operation.

More tokens do not create a control loop

Large context windows solve a real problem. They let a model inspect more code, documentation, and interaction history without immediately discarding it. That is valuable.

But storage capacity is not task control.

A warehouse can hold every component needed to build a machine. It does not provide an assembly sequence, an inventory count, or a signal that one part has failed inspection. In the same way, a prompt can contain everything relevant while leaving the agent uncertain about priority and progress.

Reliable work requires a loop:

1. Observe the environment.
2. Compare it with the desired outcome.
3. Choose the next bounded action.
4. Execute it.
5. Verify the result.
6. Update the state.

Without the final step, the next iteration operates on an increasingly noisy record. The agent may repeat a completed action, revive an invalid plan, or treat an old failure as current. The model is not merely forgetting. The system has failed to maintain a clean representation of reality.

State should live outside the model

If task state exists only inside the agent’s reasoning, it disappears when the context is compressed, the session restarts, or another agent takes over.

Durable work needs durable state.

That does not require a complex memory platform. A small structured artifact is often enough. For a software task, it might contain:

• Objective: the observable outcome required.
• Constraints: boundaries the solution must respect.
• Current facts: verified properties of the system.
• Decisions: choices made and the evidence behind them.
• Progress: completed and remaining work.
• Open risks: unknowns that could invalidate the solution.
• Next action: one specific step, not a broad intention.

The format matters less than the discipline. A Markdown file, a database row, or a workflow object can all work if the state is explicit, current, and available to every component that needs it.

The agent should read this state before acting and update it only after evidence changes. That turns memory from an impression into an interface.

Separate facts, decisions, and plans

Many agent systems store information without recording what kind of information it is. This creates subtle failures.

“The API uses OAuth” may be a verified fact from the running system, an inference from documentation, or an early guess made before inspection. Those three statements should not have the same authority.

The same applies to decisions. A team may choose a temporary implementation because a dependency is unavailable. If the reason is not stored with the decision, a future agent may preserve the workaround as if it were an architectural principle.

Plans are even more fragile. They describe an intended future based on the facts known at one moment. When an observation changes, the plan must be invalidated or revised. Keeping it in the context without marking it obsolete makes old intentions compete with present evidence.

A useful state model therefore records provenance and status:

• Was this observed, inferred, or supplied by a user?
• When was it last verified?
• Which decision depends on it?
• Is it active, superseded, or unresolved?

This may look like administrative overhead. In practice, it reduces the more expensive overhead of rediscovery, contradiction, and confident repetition.

Summaries are lossy checkpoints

Long-running agents often use summaries to stay within a context budget. This is necessary, but a summary is not neutral compression.

It decides what survives.

If a summary preserves the narrative rather than the operational state, it may retain ten completed steps and omit the one unresolved constraint that matters. If it records conclusions without evidence, the next model cannot tell which ones are safe to trust. If it flattens disagreement into a single sentence, an important uncertainty can become a false fact.

Good checkpoints are written for resumption, not recollection.

After reading one, a fresh agent should be able to answer four questions without the original transcript:

1. What outcome is required?
2. What is verified to be true now?
3. What remains uncertain or incomplete?
4. What evidence should the next action produce?

If it cannot, the checkpoint saved tokens but lost control of the task.

Tool output is not state either

Agents can produce enormous amounts of evidence: search results, test logs, database rows, traces, screenshots, and API responses. Keeping all of it in the prompt feels safe because nothing has been discarded.

But raw evidence has a half-life.

A test result describes a particular revision. A file listing becomes stale after a rename. A production metric belongs to a time window. A successful API response may no longer matter after configuration changes.

The system should retain the evidence needed for audit, while promoting only current conclusions into active state. Each conclusion should point back to the evidence and carry enough scope to know when it expires.

This is the difference between a log and a ledger. A log records events. A ledger represents the current result of those events while preserving how it was derived.

Agent systems need both, but they should not confuse them.

Design for interruption

A useful test of an agent workflow is not whether it can complete the happy path in one uninterrupted session. It is whether the work can survive interruption.

Can the process resume after a context reset without repeating risky actions? Can another model take over without reading thousands of tokens of dialogue? Can a human inspect the current position without reverse-engineering the agent’s reasoning? Can the system detect that an external dependency changed while the agent was paused?

If the answer is no, the workflow depends on continuity rather than state. It may look autonomous during a demo, but it is fragile in production.

Interruption-safe systems use explicit checkpoints, idempotent actions, versioned artifacts, and verification before resumption. These are ordinary distributed systems principles applied to a new kind of worker.

The model can be probabilistic. The workflow around it does not have to be vague.

The operational advantage

Models will continue to gain larger context windows and better recall. That will make more information available, but it will not remove the need to decide what the system currently believes and why.

The durable advantage will belong to teams that can turn an agent’s observations into clean, inspectable, recoverable state. Their agents will repeat less work, recover faster, hand off more safely, and expose uncertainty before it becomes an incorrect action.

Do not measure an agent only by how much context it can consume. Measure whether it can leave the task in a state that the next decision can trust.

Context makes history available. State makes progress durable.

Systems > Emotions.