13 Mar 2026 AI Engineering 5 min read

Dual-State Architectures for Agents

Chat transcripts are logs of utterances, not databases. This article describes a dual-state architecture for AI agents: one authoritative schema-validated process state per instance, with every user-facing view computed as a projection of a specific revision. We cover the pattern's roots in event sourcing and CQRS, its audit and concurrency benefits, and its honest limits.

The problem with conversational state

An agent that executes a business process — an order intake, a compliance review, a deployment — accumulates state: values collected, decisions taken, steps completed. Many early agent systems of 2023 to 2025 kept this state in exactly one place: the conversation transcript. The current state of the process was whatever the model could reconstruct from the message list on the next turn.

That design works in demos and fails in production. Corrections pile up as additional messages. Two readers — or two model invocations — can extract different current values from the same log. We build agent systems for regulated German industries, and the same architectural answer keeps emerging: keep one authoritative process state and compute every user-facing view from it. This article describes that pattern in general terms.

Two peers — each with its own state and private graph. 1/4

Chat history is not a database

A chat transcript is an append-only log of utterances. It has no schema, no constraints, no transactional updates and no defined notion of a current value. If a user changes a delivery quantity three times, the transcript contains four quantities; which one is valid is a matter of interpretation. Context windows make this worse: context is a finite resource with a limited attention budget, as Anthropic's context-engineering guidance from September 2025 puts it, and summarization of old turns is lossy by construction.

The transcript still matters. It records intent, tone and ambiguity — information a typed state object deliberately discards. The mistake is not keeping the transcript. The mistake is querying it as if it were a database. A log of what was said is input to state changes, not the state itself.

Property	Chat transcript	Authoritative state with projections
Current value	Implicit in message order	Explicit field in latest revision
Correction	Another message appended	Validated update creating a new revision
Validation	None	Schema and invariants enforced in code
Query	Re-read log or ask the model	Direct typed read
History	Interleaved with dialogue	Ordered diffable revisions
Reproducing a view	Not defined	project(state, revision)

One authoritative process state

The pattern has two halves. First: a single authoritative state object per process instance — typed, versioned, stored outside the model, in a database rather than in the prompt. The model proposes changes; deterministic code validates them against schema and invariants and applies them. Every accepted change produces a new immutable revision. The transcript is kept, but as evidence of intent, not as the record.

None of this is new machinery. Event sourcing has described state as a derivation from an ordered change log since Martin Fowler's 2005 write-up. Pat Helland's "Immutability Changes Everything" (ACM Queue, January 2016) makes the general case for append-only truth. Anthropic's "Building Effective Agents" (December 2024) argued for simple inspectable loops — an explicit state object is the most inspectable loop variable there is. And the storage half has reached frameworks: LangGraph 1.0 (October 2025) ships durable execution and checkpointing as core features.

Views as projections per revision

The second half: user views are projections. A chat reply, a form, a dashboard tile and a generated PDF are all pure functions from one state revision to one rendering: view = project(state, revision). This is CQRS applied to agents — Greg Young separated the write model from arbitrary read models in 2010. A projection contains no logic that changes state; it only renders it.

Computing projections per revision buys reproducibility and concurrency control. Every screen a user saw can be regenerated exactly, because it names the revision it was computed from. When the user edits a projected form, the edit carries that revision number; if the authoritative state has moved on, the system detects the conflict instead of silently overwriting — plain optimistic concurrency.

Revisions enable audit and replay

Ordered revisions are also the audit and control surface. Each revision records its cause: a model proposal, a user edit, an external event. Any two revisions can be diffed. Rollback is a new revision that restores earlier values — history is never rewritten. And human-in-the-loop approval gets a precise object: a person approves revision 23, not "the conversation so far". In regulated processes this precision is not optional.

Revisions also localize debugging. When an agent misbehaves, the question "which revision first contained the bad value and what caused it" has a mechanical answer. Without revisions the same question becomes transcript archaeology: rereading hundreds of turns and guessing which model invocation went wrong. In our experience the diff between two adjacent revisions is the fastest bug report an agent system can produce.

What the pattern does not solve

The pattern has clear non-goals. It does not make model output correct: a schema-valid wrong quantity is still wrong. It does not replace context engineering: the relevant slice of state must still be serialized into the prompt on every turn, and choosing that slice is real work. The pattern moves the authority, not the token budget.

It also has costs. Schemas for long-lived processes need migrations. A projection bug shows users wrong data even when the state is correct. Two representations — transcript and state store — demand synchronization discipline. For one-shot tasks without corrections, approvals or audits, a plain chat loop is simpler and sufficient. The pattern earns its complexity only when a process outlives a single session.

Outlook from March 2026

As of March 2026, the storage half is commoditized: durable agent state and checkpointing are standard framework features. The projection half is not — per-revision views are still mostly hand-built, and few teams treat the state schema as a first-class artifact next to the prompt.

We expect that to change. Typed process state with revisioned projections should become the default architecture for any agent process that spans sessions or reviewers, and we expect dedicated agent state stores to emerge as a product category within the next two years. The direction is unglamorous and, in our view, correct: agents are converging on four decades of database discipline, and the transcript is being demoted to what it always was — one input stream among several.