Distributed, durable execution for Swarm and Graph multi-agent patterns?

[sirianni]

I've read through the docs and various GH issues and PRs

• feat(a2a): configurable request handler #601
• [FEATURE] Support durable task store and event queue #532

It seems that the pluggable (durable) task store and event queue are only usable with A2A and not for programmatically defined flows (Swarm, Graph, Workflow). It's also not clear how "shared state" should be accessible to distributed workers.

Can someone share any insights as to the longer-term vision here?

[advijaykar]

Right now the durable task store and event queue are only wired up for A2A, which is why you don’t see the same guarantees when using Swarm, Graph, or programmatic workflows. Those patterns still run entirely in process, so they don’t get the benefits of distributed execution, replay, recovery, or shared state coordination the way A2A does. That isn’t because the team intends A2A to be the only durable path long-term; it’s just the first part of the system that was fully decoupled from the local runtime and given an external event backbone.

The longer-term plan the team has talked about is that all patterns—Swarm, Graph, Workflow, and anything built on top of them—will eventually sit on the same underlying execution substrate. That means the pluggable task store, event queue, and state persistence layer won’t be tied to A2A forever. The idea is to move toward a unified runtime where an agent or subgraph can execute on any worker, resume after interruption, and share state safely across machines, regardless of whether the developer wrote the logic as a workflow or as a multi-agent swarm.

Shared state is expected to come from that same durable backend rather than any kind of shared in-memory model. In other words, the workers won’t directly share mutable objects; they’ll coordinate through the durable store and event queue so execution can remain consistent even when spread across different nodes.

So the short answer is that A2A is the first piece that runs on the new distributed foundation. Swarm and Graph don’t benefit from it yet, but they’re not dead ends—just earlier API layers that haven’t been moved onto the same substrate. The vision is that all of them converge so you can run multi-agent patterns durably and distributed without having to choose A2A specifically for that capability.

[advijaykar]

If you’re trying to decide what to build on today, the practical guidance is that A2A is the only pattern that already runs on the durable infrastructure, so anything that truly needs fault-tolerance, resumability, or distributed fan-out should be wrapped in an A2A entry point for now. Many people design their coordinator logic or outer workflow in A2A, and then call into Swarm or Graph structures inside that boundary. Those inner structures still run in-process, but the edges of the system are durable, and it gives you a workable hybrid until the rest of the patterns migrate to the shared runtime.
From conversations and issues, the long-term direction is clearly to make the underlying runtime the primary abstraction and let Swarm, Graph, and Workflow be different ways of expressing behavior on top of it. Once that happens, the distinction between “durable A2A” and “non-durable workflows” basically goes away. The project just isn’t there yet, and A2A is leading because it was the easiest entry point to build on without breaking existing APIs.
So if you need distributed, reliable execution today, you anchor your system in A2A. If you’re simply exploring multi-agent orchestration or building prototypes, Swarm and Graph are perfectly fine. Over time those differences should shrink as more of the system moves onto the same event-driven substrate.