most agent harnesses maintain execution state. Belief Stack maintains belief state.

The question came up after our recent planning experiments:

It is a fair question.

Modern agent harnesses already maintain state.

LangGraph has state.

Workflow engines have state.

Task orchestrators have state.

Memory systems have state.

So what exactly is new here?

The answer is short:

Most of those systems maintain execution state.

Belief Stack maintains belief state.

That sounds subtle. It is not.

Execution state vs belief state

A typical agent state object looks something like:

• current task
• current step
• tools executed
• files modified
• pending actions

This is operational bookkeeping. It tells the system what it has done.

A belief state object answers a different question:

Examples:

• validation is still pending
• the migration completed successfully
• the deployment is blocked
• the user’s goal changed
• the last fix attempt failed

Those are not actions. They are claims about reality.

And claims have a lifecycle.

Beliefs have a lifecycle. Execution state usually doesn’t.

Most state systems overwrite. The current task replaces the previous task. The current step replaces the previous step. There is no record of a state being contradicted — only of it being changed.

Beliefs evolve differently.

A belief can be:

• born
• strengthened
• weakened
• contradicted
• retired

And the moment of contradiction is itself information.

Here is a concrete failure mode we documented earlier this year.

A coding assistant arrives at a deploy step. Its belief was user approval is still required. The user types something like “go ahead.” The same signal:

• retires the approval required belief
• triggers the deploy

By the time the assistant runs its safety check, approval required is gone — the very signal the deploy is responding to has already cancelled it. The agent reads its state, sees no pending approval requirement, and proceeds.

In an execution-state model, this is unremarkable. The approval state was active. The user approved. It is no longer active. Bookkeeping looks correct.

In a belief-state model, the lifecycle overlap is the bug. Two beliefs whose overlap window is structurally null — one retired by the same signal that creates the other — cannot meaningfully gate each other. The architecture surfaces the failure mode before it can fire.

That diagnostic is unavailable in a system that only tracks current state.

If this sounds familiar to an engineer, it should. Belief Stack is not a new idea in the abstract. It is an extension of a discipline already in use — state transitions, lifecycle guards, invariant checking — into an environment those tools were not originally built for.

A traditional state machine assumes approval = true. An agent receives “looks good,” “ship it,” “let’s do it,” “actually hold off.” Those are not the same input. The challenge is not maintaining state. The challenge is maintaining state over an ambiguous semantic substrate.

Planning needs maintained belief, not reconstructed belief.

The difference becomes operational the moment an agent has to plan.

Planning requires answering questions like:

• What is currently true?
• What is no longer true?
• What assumptions should constrain the next action?
• What should I stop relying on?

Today many agents answer those questions by repeatedly reconstructing state from raw history.

Prompt logs. Tool outputs. Memory stores. Retrieved documents. Prior plans.

Every step begins by re-deriving the same working model of reality from raw evidence.

We call this the reconstruct-world-model-every-step tax.

It is not free.

In a pre-registered experiment we asked an LLM to make a single next-action judgment about each of 75 historical moments in 164 Claude Code session logs (~20,190 evaluation turns).

Each judgment was anchored to a specific (session, turn) — e.g. “at turn 2987, is the assistant authorized to proceed?” — across five categories: approval_status, validation_check, completion_check, readiness_check, repeated_failure.

Three arms answered the same 75 judgments under three context shapes (same model, same temperature, same seed; only the shape of context differs). Each answer was scored against a deterministic oracle:

Arm B won on every dimension — speed, cost, and accuracy. The model with no raw evidence at all answered 8 points more questions correctly, at 31% of the latency and 14% of the input tokens, than the model holding the full log.

The model did not appear under-informed by the smaller context.

It appeared overburdened by reconstruction.

Beliefs come with warrants. Logs don’t.

A second piece of what makes belief state distinct: every claim carries a warrant.

A maintained belief is not just validation_pending: true. It is:

That is the L1 contract: nearest is not the same as valid. No belief is emitted outside its coverage. Every assignment carries an audit trail.

This is what makes belief state inspectable, contestable, and replayable.

A log doesn’t have warrants. A scratchpad doesn’t have warrants. A vector retrieval result is the warrant for itself — a tautology that makes calibration difficult. A maintained belief stack carries warrants as part of the object.

What this is not.

It is worth being precise about what belief state isn’t.

It is not a conversation log. Logs are records of what happened. Belief state is a projection of what is currently true.

It is not a scratchpad. Scratchpads record execution, not belief. In v0.3, the arm with overlay + scratchpad (94.7%) underperformed the arm with overlay alone (98.7%). One plausible explanation is that the scratchpad reintroduced execution chronology that competed with the maintained state representation — but distinguishing attention dilution from prompt-structure effects is a question for the next experiment. The observation is firm; the mechanism is open.

It is not a summary buffer. Narrative summaries can drift from underlying evidence and don’t carry warrants. You can ask a summary whether it believes something. You cannot ask it why.

It is not RAG. Retrieval is stateless at query time. It returns fragments that match. It does not maintain a current world model and does not know when something has stopped being true.

It is not a knowledge graph. Triples don’t have lifecycle. Facts don’t expire, get contradicted, or carry decay.

It is not memory. Memory frameworks store facts the agent has learned. Belief state tracks what the agent currently holds to be true about the present situation. Different timeframe, different epistemic role.

One substrate. Two consumers.

The maintained state, once it exists as a first-class object, becomes available to two consumers — one query surface for each.

The agent consumes the state through overlay() before planning — a compact, ranked projection sized to fit the planning context. That is the surface v0.3 measured: wired correctly, it improves accuracy, cuts latency, and reduces token cost by an order of magnitude.

The human surface is the other half of the story.

Each verb on the human side answers a question a log cannot:

• state() — what does the agent currently hold to be true?
• timeline() — when did this belief come into being, and how has it evolved?
• explain() — why is this belief warranted? What evidence supports it, and how strongly?
• audit() — what beliefs are past their applicability boundary, low-confidence, or contradicting one another?

A log can tell you the user typed “let me check before we deploy.” It cannot tell you that the agent registered this as a belief, attached it to a deployment guard, attached an expiry condition, and is still holding it three turns later.

Planning depends on what the agent is currently relying on. Logs are history. Beliefs are dependencies.

That distinction matters in three contexts.

Debugging. When an agent acts wrongly, the question is rarely what did it do — that is in the log. It is what was it relying on when it did it. Belief state answers that directly. Logs and scratchpads cannot.

Trust calibration. Before delegating a harder task, a human can read the current belief state and decide whether the agent’s understanding of the situation matches their own. If the agent believes migration is complete and the human knows it isn’t — that disagreement is visible before the next action fires, not after.

Handoff. When a different agent or human picks up the work, they don’t reconstruct from raw history. They read state. The substrate they query is the same one the previous agent was acting from. No re-derivation. No interpretive drift between handoffs.

One substrate. Two surfaces. Different shapes for different consumers, same source of truth.

We demonstrated this at fixture level with two CLI commands — tkos state for humans and tkos overlay for models — hitting one SQLite store. Same data, two query shapes.

The result is a state layer that is not optimized for bookkeeping.

It is optimized for planning — and for trust.

Humans and agents should inspect the same state.

Where it sits.

If the object is different, the next question is architectural: where does it sit?

Belief Stack sits between evidence and planning. Observability is a consequence of that position, not its purpose.

That is the architectural claim the v0.3 experiment earns us the right to make. A compact maintained belief overlay outperformed larger raw-context bundles on planning tasks while using a fraction of the tokens and latency. The model did not appear under-informed by the smaller context.

It appeared overburdened by reconstruction.

And once the maintained state exists, the human surface comes along for free — same substrate, different query shape. The thing the agent is relying on becomes the thing a human can inspect.

Two claims, paired:

That may be the missing layer between evidence and planning in agent architectures.