DM Explains · No. 049 · Agents
Agent state federation: giving AI agents a journal they can trust
Multi-agent workflows don't fail because agents forget too much — they fail because nobody kept a shared, durable record of what each agent started, finished, or left half-done.
· 15 min read
Read me first
Agent state federation genuinely does stop multi-agent workflows from silently losing work, but only when every step is journaled durably first; it is a record-keeping discipline borrowed from databases, not a smarter agent.
Illustrative: inventory, compliance and notify agents across two orgs ship an order — 1 each action becomes an Agent Transaction with snapshot, intent, effect, commit → 2 all three read/write one Shared State layer → 3 PD-KV Cache holds working memory over RDMA via UEC/UALink → 4 after a restart, replay reads the journal and redoes only the in-flight action → 5 assignments and cancellations ride the Agent Coordination Channel's own QoS class → 6 the two orgs address each other as a session, not a one-shot RPC → 7 federated sync after restart returned 10 of 100 downtime requests → shipment dispatched
A multi-agent workflow has been running for six hours across three services — one agent booking logistics, another verifying compliance, a third notifying a partner organisation — when the process restarts after a network blip. Nobody on either side of the handoff can immediately say which steps actually completed, which are stuck half-done, or whether an action got silently duplicated. The fix people reach for first — a bigger context window — does nothing for this problem, because the issue was never how much one agent could remember in one prompt. It was that nobody kept a shared, durable record of what happened across agents, machines and organisations.
Everyday picture. Amma keeps one shared kitchen notebook on the counter where everyone writes exactly what they started cooking, what they used, and whether it finished. When the power cuts mid-recipe, Papa checks the notebook to see which steps were done, half-done, or untouched before deciding what to redo, while Arjun asks why they couldn't just remember it all.
Where the picture breaks. A kitchen notebook is written by one trusted family in one house; agent state federation must also work across organisations that don't fully trust each other, over networks with real latency, which no notebook captures.
Why it exists now
Agents used to mean a single prompt and a single response. Now they plan, call tools, spawn sub-agents, and run for hours or days, often crossing into systems owned by other companies. A crash or network partition in that world can silently lose context, duplicate an action, or leave a task half-done with no trace of what happened — and nobody notices until a shipment goes out twice or not at all.
Through 2026, infrastructure and standards groups started publishing concrete specifications to close this gap rather than leaving it to individual engineering teams to improvise. The Open Compute Project's "AI Fabric for Agentic AI" whitepaper, versioned 2026-v1.0 and dated October 2026, proposes fabric-level primitives — a Persistent Distributed KV Cache, Agent State Journaling, and an Agent Coordination Channel — explicitly because, in its words, "agentic workloads introduce distinct requirements that the current framework does not fully address" (AI Fabric for Agentic AI Whitepaper 2026-v1.0 — Open Compute Project, 2026). In parallel, the Agent Session Protocol whitepaper argues that agents today "have compute, tools, and one-shot RPC; they do not have a network" (White Paper — Agent Session Protocol — Agent Session Protocol), and proposes persistent, consent-based sessions as the missing layer. Academic groups are formalising parallel pieces of the same picture: the Federation of Agents work on a semantics-aware communication fabric for large-scale agentic systems (Federation of Agents — arXiv, 2025), and a controlled study measuring what happens when shared agent state actually gets carried over existing federated messaging infrastructure (Persistent Agent Interaction over Federated Messaging — ResearchGate, 2026).
What changed is not the model. It is the recognition that multi-agent, multi-hour, multi-organisation workflows need the same durability guarantees that distributed databases have had for decades — and that nobody had yet written those guarantees down for agents specifically.
How it works
Agent Transaction
No step counts as real until it's written down
What it is. Every atomic action an agent takes gets wrapped into an Agent Transaction (AT) before it's trusted as having happened.
Why it exists. Agents forget, crash, or get restarted; a durable record outside the agent's own memory is the only thing that survives all three.
Where it breaks. If the commit marker itself is lost or delayed, an agent can't yet tell whether an action truly finished or just looked like it did.
How that's handled. The commit marker is written only after the underlying fabric confirms the effect record has durably persisted — so an unconfirmed action is treated as not-yet-done rather than assumed complete.
In technical terms
In technical terms: an Agent Transaction (AT) bundles a pre-state snapshot, an intent record, an effect record, and a commit marker written only once the fabric confirms durable persistence, mirroring a write-ahead log.
Shared State layer
One notebook, not six fading memories
What it is. A single live record that every agent in a system reads from and writes to, rather than each agent keeping its own private, fallible version of events.
Why it exists. Without one authoritative state, concurrent agents working on the same task after a partial failure end up with conflicting or stale views of what's already done.
Where it breaks. It becomes a single point every agent depends on; if the shared layer degrades, every agent sharing it degrades together.
How that's handled. Retries, rollback and replay are built into the layer itself, so a degraded write can be redone rather than silently accepted.
In technical terms
In technical terms: a durable shared-state layer supports retries, rollback and replay so concurrent agents don't produce conflicting views of the same task after a partial failure.
PD-KV Cache
Working memory that can move house
What it is. A shared, movable version of a model's key-value cache — the stored intermediate computation that avoids recomputing earlier parts of a conversation — that can migrate between machines.
Why it exists. Long-context, multi-turn agent sessions need working memory that outlives a single inference call and a single machine, without being recomputed from scratch after every hop.
Where it breaks. It solves memory continuity for one agent's inference state; it does nothing for coordination between multiple agents, which is a separate problem entirely.
How that's handled. It's kept as a vendor-neutral abstraction layered on top of existing disaggregated-cache architectures, so it can plug into the coordination mechanisms described below rather than replace them.
In technical terms
In technical terms: the Persistent Distributed KV Cache (PD-KVC) is a vendor-neutral abstraction for migrating a model's key-value cache across fabric tiers via RDMA-class transports like UEC 1.0 and UALink, building on Mooncake and NVIDIA Dynamo.
Replay recovery
Redo only what wasn't finished
What it is. After a crash, a recovery process reads the journal from the last committed Agent Transaction and classifies every action as completed, in-flight, or not yet started.
Why it exists. Coarse application checkpointing forces a restart from the last whole-system snapshot; replay recovery instead lets the system redo only the fraction of work that actually failed.
Where it breaks. This only works if every relevant action was actually journaled — an email already sent outside the journal can't be un-done by replay logic no matter how fine-grained the classification is.
How that's handled. In-flight actions are routed to compensation or re-execution depending on their recorded effect, rather than being retried blindly.
In technical terms
In technical terms: recovery reads the journal back from the last committed Agent Transaction, classifying work as completed, in-flight (needing compensation or re-execution), or not yet started — finer-grained than application checkpointing.
Coordination Channel
Small urgent messages need their own lane
What it is. A proposed dedicated, low-latency network lane carrying task assignments, result reports and cancellation signals between agents, kept separate from bulk data traffic.
Why it exists. Coordination messages are small and latency-sensitive in a different way than large data-parallel transfers, so routing them through the same lane as bulk traffic risks delaying exactly the signals that matter most for recovery.
Where it breaks. It's a fabric-level proposal, not yet a deployed standard — real data-centre networks don't universally carry this today.
How that's handled. The proposal journals these coordination messages as Agent Transactions too, so coordination state, not just tool-call state, can be reconstructed after a crash.
In technical terms
In technical terms: the proposed Agent Coordination Channel (ACC) is a separate low-latency quality-of-service (QoS) traffic class carrying task assignments, result reports and cancellations, journaled alongside tool calls so coordination state is reconstructable after a crash (AI Fabric for Agentic AI Whitepaper 2026-v1.0 — Open Compute Project, 2026).
Cross-org sessions
Agents need a network, not just a phone call
What it is. A persistent, consent-based session between agents in different runtimes or organisations, with durable identity, rather than a single one-shot call.
Why it exists. An agent in one runtime can't natively address an agent in another today — existing primitives give agents compute, tools and one-shot remote procedure calls, but nothing that behaves like a network connection between them.
Where it breaks. Existing protocols like the Model Context Protocol (MCP) and Agent-to-Agent (A2A) still don't provide this, so cross-organisation federation remains mostly unstandardised.
How that's handled. The Agent Session Protocol proposes persistent, consent-based sessions as the missing base unit, instead of layering more one-shot calls on top of each other.
In technical terms
In technical terms: the Agent Session Protocol argues agents today have compute, tools and one-shot RPC but no network, since an agent in one runtime can't natively address one in another; it proposes persistent, consent-based sessions instead (White Paper — Agent Session Protocol — Agent Session Protocol).
Substrate limits
History is retained; readiness is not
Illustrative: fabric restarts after a node failure → 1 reads the AT journal → 2 finds last commit marker for the compliance-check effect → 3 classifies: inventory check done, notify-partner in-flight, dispatch not started → 4 redoes only notify-partner → 5 resumes coordination with the receiving organisation's agent → 6 verifies and recommits → shipment approved, no step silently repeated or lost
What it is. The real-world behaviour of carrying shared agent state over an existing federated messaging substrate, such as Matrix/Synapse, across two organisational domains.
Why it exists. Rather than theorise, a controlled study built a two-domain testbed and measured what actually happens when agent state has to cross a federation boundary and survive a restart.
Where it breaks. Retained history is not the same as an agent having everything it needs the instant it restarts — engineering the gap between the two is still unsolved.
How that's handled. Applications built on this substrate have to budget for pagination and added latency explicitly, rather than assuming the first sync after a restart is complete.
In technical terms
In technical terms: in a two-domain Matrix/Synapse testbed, all 100 downtime requests eventually processed, but the first post-restart sync returned only 10 of 100 (pagination needed), round-trip time rose from 104.0 ms to 185.1 ms, and throughput fell to 76.5–78.4% of local (Persistent Agent Interaction over Federated Messaging — ResearchGate, 2026).
Compared with what came before
| Before: application checkpointing | Now: agent state federation | |
|---|---|---|
| Unit of recovery | Whole-process or whole-workflow snapshot | Individual Agent Transaction |
| Who holds state | Each agent's own memory or local store | A shared, durable journal every agent reads and writes |
| Recovery granularity | Coarse — restart from last snapshot | Fine — completed, in-flight or not-started per action |
| Cross-organisation support | Largely absent | Explicit goal, via sessions and federated messaging |
| What you give up | Simplicity, lower overhead | Latency and engineering cost of durable commits |
The old way is cheaper and simpler, and it was fine when an "agent" meant one model call with no state to lose. Once a workflow spans multiple agents, multiple hours and multiple organisations, that simplicity becomes the risk, not the saving — a lost snapshot there means lost work here.
Where it breaks
Not yet a deployed standard
Several of the pieces described above — the Agent Coordination Channel, the Persistent Distributed KV Cache abstraction, the Agent Session Protocol — are whitepaper proposals, not a universally deployed fabric. Real data-centre networks and agent runtimes mostly don't carry these primitives today.
Agent state federation genuinely does prevent silent loss of in-flight work, but only when every relevant action is actually captured as an Agent Transaction. An action taken outside the journal — a partner notified by a side channel, an email sent directly rather than through the journaled tool call — cannot be recovered or compensated for, no matter how good the replay logic is.
It also carries a measurable performance cost once state crosses organisational boundaries. The federated messaging study found round-trip latency rising from 104.0 ms locally to 185.1 ms across domains, and throughput dropping to 76.5–78.4% of the local value (Persistent Agent Interaction over Federated Messaging — ResearchGate, 2026). That is the price of durability and cross-domain trust, and it is paid on every exchange, not just during recovery.
Finally, the shared state layer is a single dependency by design. If it degrades, every agent reading and writing to it degrades with it — federation concentrates risk in one place even as it removes risk from individual agents' private memory.
Numbers to carry
| Figure | What it measures |
|---|---|
| 4 components | Parts of an Agent Transaction: pre-state snapshot, intent record, effect record, commit marker |
| 2026-v1.0 (October 2026) | Version and date of the OCP "AI Fabric for Agentic AI" whitepaper |
| 10 of 100 requests | Downtime requests available in the first post-restart sync in a Matrix/Synapse federated testbed |
| 104.0 ms → 185.1 ms | p50 round-trip time, local path vs federated path, same testbed |
| 76.5–78.4% | Federated-path throughput as a share of local-path throughput, same testbed |
Myths worth killing
| Commonly repeated | What is actually true |
|---|---|
| "Bigger context windows solve multi-agent state loss." | A larger context window helps one agent hold more text in one call; it does nothing for multiple agents sharing a durable, recoverable record across time and failures. |
| "A shared database is the same as agent state journaling." | A generic database stores current values; an Agent Transaction additionally records intent, effect and commit markers in causal order so in-flight actions can be correctly classified during recovery. |
| "MCP and A2A already solve cross-agent coordination." | They define how agents call tools or exchange single messages; the Agent Session Protocol argues this is one-shot RPC, not a persistent network connection between agents. |
| "If the messaging layer retains history, recovery is automatic." | The federated messaging study found the first post-restart sync returned only 10 of the 100 pending requests — pagination was needed to retrieve the rest. |
Worked example
The shipment-approval workflow, walked end to end:
- Inventory agent checks stock and writes an Agent Transaction recording its intent to reserve units and the effect once the reservation is confirmed.
- Compliance agent verifies documents and writes its own Agent Transaction, journaled alongside the inventory agent's in the shared state layer so both are visible to the third agent.
- Notification agent prepares to message the receiving partner organisation over a session-based connection, rather than a one-shot call, so the partner's side can trust the message came from an identified, consented source.
- A network blip restarts the process mid-flight. The recovery process reads the journal from the last committed Agent Transaction.
- It finds: inventory reservation completed, compliance check in-flight (document verification started but no commit marker written), notification not yet started.
- Only the compliance check is re-executed from where its last confirmed step left off; the inventory reservation is not redone, avoiding a duplicate hold on stock.
- Illustrative only: if each agent's step averages 90 seconds and only the compliance step needs replay, the restart adds roughly 90 seconds of extra work rather than redoing the full six-hour sequence — the arithmetic here is illustrative, not measured, but it shows the shape of what fine-grained replay buys over restarting everything from scratch.
Should you use it?
Reach for agent state federation when a workflow involves multiple agents or sub-agents coordinating over minutes, hours or days, when the task must survive restarts or cross-organisation handoffs without losing track of completed work, or when auditability requires a permanent, replayable record of every decision. Skip it for simple single-turn chatbot interactions with no need to resume after failure, for latency-critical paths where the overhead of durable commit markers isn't justified, or where state is cheap to recompute from scratch anyway.
The cheapest first experiment is not infrastructure at all: pick one existing multi-agent workflow and add a durable, append-only log of intent and effect for each step it already takes, without touching the agents themselves. See how often the log would have told you something a restart silently hid.
Say it in the room
"Use it when agents must survive restarts or organisational handoffs and leave an audit trail; skip it when the task is one prompt, one answer, nothing to resume."
Lines to carry
- "The hard problem isn't more memory, it's a journal."
- "A record that isn't durable is just a rumour."
- "Retained history is not the same as readiness."
- "Recovery should redo only what wasn't finished."
- "Agents need a network, not a phone call."
FAQ
Isn't this just a bigger context window by another name?
No. A context window governs how much text one model call can hold at once. Agent state federation is about multiple agents, processes and sometimes organisations sharing one durable, recoverable record over hours or days — a different axis entirely.
Do MCP or A2A already give agents this?
They give agents a way to call tools or exchange a single message with another agent. Neither provides the persistent identity or durable, multi-party session that the Agent Session Protocol argues is missing.
What happens if an agent takes an action outside the journal?
It can't be recovered or compensated for by replay logic, because the recovery process only knows about actions it has a transaction record for. This is the sharpest limit on the whole approach.
Is any of this a finished, deployed standard yet?
Mostly not. The Open Compute Project's fabric proposal, the Agent Coordination Channel and the Agent Session Protocol are whitepapers and early specifications as of their respective 2026 publications, not infrastructure that ships by default in data centres today.
What's the actual cost of federating state across organisations?
Measured in one controlled study, round-trip latency roughly doubled, from 104.0 ms locally to 185.1 ms federated, and throughput dropped to 76.5–78.4% of local. That is a real, paid cost for durability and cross-domain trust, not a free upgrade.
Glossary
- Agent — a software system that uses an AI model to plan, reason, call tools and take actions, often across multiple steps or turns.
- Agent State Journaling (ASJ) — a proposed method of recording every step an agent takes as a durable, ordered log entry so it can be replayed or recovered after a failure.
- Agent Transaction (AT) — the basic unit of an agent's journaled progress, made of a pre-state snapshot, an intent record, an effect record and a commit marker.
- KV cache (key-value cache) — the stored intermediate computation that lets a language model avoid recomputing earlier parts of a conversation or long input.
- Persistent Distributed KV Cache (PD-KVC) — a proposed shared, movable version of the KV cache that can be migrated between machines over a fast network.
- RDMA (Remote Direct Memory Access) — a networking technique that lets computers read and write each other's memory directly without the usual slower operating-system path.
- Agent Coordination Channel (ACC) — a proposed dedicated, low-latency network lane for small coordination messages between agents, separate from bulk data traffic.
- Write-ahead log — a database technique where every change is recorded in an append-only log before being applied, so the log can be used to recover state after a crash.
- Durable execution — a programming model where a program's progress is automatically saved so it can resume exactly where it left off after a failure.
- Federated system — a network of independently operated nodes that cooperate while keeping local control, rather than one node controlling everything.
- Agent Session Protocol (ASP) — a proposed open protocol giving AI agents persistent identity, durable multi-party conversations and consent-based reachability across runtimes.
- MCP (Model Context Protocol) / A2A (Agent-to-Agent) — existing protocols letting agents call tools or exchange single messages, without built-in persistent sessions or identity across organisations.
- Checkpointing — saving a snapshot of a system's state at a point in time so execution can resume or recover from that point.
- QoS (Quality of Service) traffic class — a category of network traffic given particular priority or latency guarantees.
- Versioned Capability Vector (VCV) — a machine-readable profile describing what an agent can do, so other agents can discover and select capable collaborators.
Sources
- AI Fabric for Agentic AI Whitepaper 2026-v1.0 — Open Compute Project, 2026
- White Paper — Agent Session Protocol — Agent Session Protocol
- Federation of Agents: A Semantics-Aware Communication Fabric for Large-Scale Agentic AI — arXiv, 2025
- Persistent Agent Interaction over Federated Messaging: Recovery and Application-Path Performance — ResearchGate, 2026