13 Mar 2026 AI Engineering5 min read

Dual-State Architectures for Agents

Chat transcripts record utterances; they are not databases. This article describes a dual-state architecture for AI agents: each process instance has one authoritative, schema-validated state, and every user-facing view is projected from a specific revision. We trace the pattern to event sourcing and CQRS, then state its audit and concurrency benefits as clearly as its 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.

The design looks sufficient in demos and comes apart in production. Corrections accumulate as additional messages, and two readers — or two model invocations — can derive different current values from the same log. When building agent systems for regulated German industries, we repeatedly reach the same architectural answer: maintain one authoritative process state and compute every user-facing view from it. The following sections describe that pattern independently of any particular framework.

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 has value. It records intent, tone, and ambiguity — information a typed state object deliberately discards. The problem is therefore not retaining the transcript, but querying it as though it were a database. A record of what was said supplies input to state changes; it is 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. The first is a single authoritative state object per process instance: typed, versioned, and stored outside the model in a database rather than in the prompt. The model proposes changes; deterministic code checks them against schema and invariants before applying them. Every accepted change produces a new immutable revision. The transcript remains available 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 make debugging local. When an agent misbehaves, the system can answer mechanically which revision first contained the bad value and what caused it. Without revisions, the same investigation becomes transcript archaeology: rereading hundreds of turns and guessing which model invocation failed. In our experience, the diff between two adjacent revisions is the most precise 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 agent processes that span sessions or reviewers; we also expect dedicated agent state stores to emerge as a product category within the next two years. The direction is unglamorous but, in our view, correct: agents are adopting four decades of database discipline, while the transcript returns to its actual role — one input stream among several.