MongoDB recently published a sharp piece of systems thinking about agent reliability. In "State & Persistence: The Problem of Agent Reliability"(opens in new tab), the authors make a distinction that's easy to state and, apparently, hard to build for: state is the execution context of a single agent run — intermediate results, tool outputs, the plan, the position in a multi-step task. Memory is the durable knowledge an agent carries across runs. Most teams store both under one label, with one lifecycle and one governance policy, and that conflation is where a lot of what gets reported as "agent unreliability" actually comes from.
The piece shows why the distinction matters: a worker dies on step five and the agent restarts from step one; a checkpoint expires on the same TTL as a long-lived preference; a restored agent re-issues a tool call that already had a side effect and a customer gets charged twice. It then works through checkpoint granularity, suspend/resume, five state-architecture patterns from in-memory to "database-as-state," and the versioning problem of pinning a model-code-prompt bundle to the run that started it. All of it is scoped, correctly, to what happens inside the agent harness — the process boundary around a single run.
That scope also opens a complementary question: what happens when the operational context outside the harness is itself fragmented across systems? A sentence near the end of the piece points toward that adjacent problem:
"...agent state still lacks the governance and cross-region durability that operational data takes for granted."
Operational data's governance and durability provide a useful benchmark for agent-state infrastructure. But in many enterprises, that operational foundation is not yet available as one coherent thing an agent can simply read. Individual databases may be well governed, while no single, current, consolidated view of operational reality exists across them. Order state lives in one system, billing in another, entitlements in a third, and none of them were designed to answer a cross-system question in real time. Operational data remains fragmented across systems of record for reasons that are mostly legitimate: workload isolation, security boundaries, ownership, and source-oriented schemas that were never meant to be queried by anything outside their own application.
A state problem that sits outside the harness
This is the second reliability surface, and it's a different failure mode than anything a checkpoint can fix. An agent harness can do everything the MongoDB piece recommends — externalize state at the tool-call boundary, separate state from memory, pin the model-code-prompt bundle, pass the kill test — and still produce a wrong outcome, because what it read when it called a tool was stale, incomplete, or inconsistent with what a different system already knew.
The MongoDB post's own ACRFence example is instructive here for a different reason than the one it's used for. An agent restored to the checkpoint before a $500 transfer re-attempts it with a fresh identifier; the bank sees no match, processes a second transaction, and the customer is charged twice. The post attributes this to semantic rollback — a restored, non-deterministic agent re-synthesizing a different request than the one it made before. That's a harness-state problem, and the fix lives in the harness: replay the recorded decision rather than re-invoke the model.
But consider a version of the same failure that has nothing to do with checkpoint restoration at all. An agent processing a refund reads order status from an order-management system, inventory availability from a warehouse system, and payment history from a billing system — three separate queries, three separate round trips, no shared transaction across them. Between the first read and the third, a return is recorded in the warehouse system and a chargeback is opened in billing. The agent's harness state is perfectly intact. Its checkpoint restores cleanly. It never crashes. It still authorizes a refund that shouldn't happen, because the world it read was never consistent to begin with — not because a checkpoint expired, but because nothing was maintaining a coherent, current, identity-resolved view across the systems the agent had to touch.
This is illustrative, not a documented incident, but the shape of it is common enough to be worth naming as its own category: identity resolution across systems, event ordering, conflict handling when two systems disagree, partial visibility when one system lags another. None of these are solved by better checkpointing, because they don't originate inside the agent's execution — they originate in the distance between systems of record and whatever is trying to act on their combined truth. A stale or inconsistent read here doesn't produce an outdated report. It produces an incorrect transaction, executed with full confidence, by an agent that behaved exactly as designed.
Operational State as a distinct layer
We think about this problem under a different name than either "state" or "memory": Operational State — a continuously maintained, consolidated representation of what's actually true right now across an enterprise's systems of record, correct in ordering, identity, completeness, and provenance, and built to be acted on rather than merely reported on. The Operational State Layer is the architectural capability an enterprise establishes to keep that representation current between its systems of record and whatever consumes it — applications, workflows, automation, and increasingly, agents.
It's a different axis from the one the MongoDB article works on. Their state and memory both belong to a single run or a single agent's history — private, run-scoped, harness-owned. Operational State is the opposite shape: one consolidated source, built once, meant to be read by many consumers — the refund agent, a support dashboard, a fraud model, a human ops team — none of which should each have to independently solve identity resolution and cross-system consistency to get a correct answer. That's a reusability property, not a recovery property, and it's the reason we don't think of it as a fourth pattern alongside the five the MongoDB post describes. It isn't a way of storing a run's execution state. It's the thing the run reads from before it decides what to do.
tapstate is the unified operational data engine we build for this layer: it captures changes from supported sources — including log-based CDC where available — transforms them incrementally in flight by filtering, joining, enriching, and reshaping source-oriented schemas into consumer-oriented entities, and serves the result as continuously fresh, queryable operational state. Capture, transform, serve, as one deployable data path, instead of assembling CDC, an event backbone, a stream processor, and a serving store as four separate products for every use case that needs current cross-system state.
It's worth being precise about what this is not. CDC captures change; it doesn't by itself assemble meaning from that change — that's the transformation and state-maintenance work sitting on top of it. Kafka and similar backbones move events with high fidelity; they don't materialize current, queryable state on their own. Warehouses and lakehouses are excellent at analyzing what already happened; for operational decisions whose value decays quickly, the next batch cycle may be too late. tapstate isn't a replacement for any of these — it's positioned at the point where change becomes current, served state, and it coexists with analytical systems and event infrastructure that remain doing exactly what they're good at.
Where the two layers meet — and where they don't
The MongoDB piece's Pattern 5 — "database-as-state" — is the closest point of contact between the two arguments. It describes enterprise agents where state, memory, and operational data need to commit together transactionally, and it's honest that this is the rare, hard case: sustaining OLTP-style state writes, vector retrieval, and large-blob storage inside one database, with latency as the binding constraint.
That pattern is solving a real problem, but a different one than ours. It asks how an agent's run-scoped state, memory, and application writes can share one transaction boundary. The Operational State Layer solves a separate problem: it provides a governed, current read model across systems before the agent decides. The two can coexist; neither subsumes the other.
Whether a harness checkpoints in a message log, a step-checkpoint store, or a fully transactional Pattern 5 database, the operational context it queries — the order, the account, the entitlement — still needs to be maintained as current, consolidated, and identity-resolved before the harness reads it. Getting the harness's own recovery story right and getting the read side of that story right are separable problems, and we think both need direct engineering attention rather than one absorbing the other.
Open design questions
Some of the most important questions here are architectural rather than product-specific.
What should freshness mean as an explicit contract an agent can inspect before acting, rather than an internal property of the data infrastructure? How should provenance, identity confidence, and conflicts between systems be exposed to operational consumers? Which classes of cross-system inconsistency can be detected and remediated automatically, and which should always require human review? And when should an agent rely on a maintained operational view versus revalidate directly against a system of record before committing an action?
These questions will shape how operational state is made safe and useful for agents, but they do not change the underlying claim: agent reliability has at least two state problems that don't reduce to each other.
One is inside the harness, and the industry — including the work MongoDB is doing across its agent-platform series — is converging on real answers: externalize state at tool-call boundaries, separate it from memory, version the bundle, pass the kill test.
The other is outside the harness, in the distance between systems of record and whatever is trying to act on their combined truth. Solving the first one well still leaves the second one open. We think the second one deserves the same level of architectural seriousness — which is the problem the Operational State Layer is built to address.
