Protocols, Not Abstractions¶
Every framework has to decide what sits at its boundaries. The default is an abstraction
you own — a Tool base class, an Agent interface, a Renderer protocol — because
owning the boundary means you can change it.
SwarmPlane uses open protocols at every seam instead:
| Seam | Protocol | What crosses it |
|---|---|---|
| Tools | MCP | Tool discovery and invocation |
| Agents | A2A | Agent capability advertisement and dispatch |
| Interface | A2UI | Declarative UI emitted by agents |
Nothing proprietary sits between layers.
The test of the claim¶
A claim like this is worth nothing unless it is falsifiable, so here is the test:
You can delete SwarmPlane and keep your agents.
Concretely. Your tools are MCP servers — separate processes speaking JSON-RPC, which Claude Desktop or ADK or anything else can call unchanged. Your agents advertise A2A Agent Cards, so another orchestrator can discover and invoke them without knowing SwarmPlane exists. Your UI is A2UI documents rendered by official renderers for React, Flutter, Lit or Angular, none of which SwarmPlane wrote.
Remove the orchestrator and what remains is a set of independently useful components. What you lose is the graph — the coordination and the causal record — which is precisely the part SwarmPlane claims to contribute, and nothing else.
Compare the usual outcome, where leaving a framework means rewriting every tool because they were subclasses of something the framework defined.
Why this is cheap here¶
Being protocol-native is expensive in most architectures, because the framework holds state that the protocols do not model, and adapting between the two leaks.
It is cheap here for a structural reason: the graph is the only mutable state. A tool call does not update framework state; it produces a node. An agent dispatch does not mutate a session; it produces a node. A UI emission does not own a component tree; it produces a node.
So each protocol boundary is stateless. Nothing has to be translated between a protocol's model and an internal one, because there is no internal one to translate to — there is only "what happened," and that is a node either way.
This buys a testing property most frameworks cannot have. Each seam can be verified against protocol conformance in isolation, with no orchestrator running: send an MCP server the discovery handshake and check the response; hand a renderer an A2UI document and check what it draws. The tests answer "do we speak the protocol correctly," not "does our abstraction behave," which is a much more useful question because the protocol is the thing other people's software will actually meet.
What this costs¶
Three real costs, not hedges.
You inherit specs you do not control. A2UI is at v0.9.1 in production, with v1.0 in
Candidate status as of June 2026. That is young. Breaking changes before v1.0 final are
likely, and when they land the fix is on your schedule only if you pin — which is why
a2ui versions are pinned exactly and bumped deliberately.
Protocol lowest-common-denominator is real. MCP models tool calls well; it does not model streaming partial results as richly as a bespoke interface could. Accepting the protocol means accepting its expressiveness ceiling and waiting for the spec rather than extending it privately. Where SwarmPlane needs something a protocol lacks, the answer is to put it in the graph, not to add a proprietary field to the wire format.
More moving parts. An MCP server is a process. Processes fail, need supervision, and add latency that an in-process function call does not. A single-vendor framework is genuinely simpler to operate at small scale.
The trade is deliberate: more operational surface now, in exchange for no lock-in and boundaries that can be tested against something other than themselves.
The A2A exception¶
A2A is documented as a seam in v1 but not implemented. Agent-to-agent federation only earns its complexity when there are agents worth federating with, and there is no credible way to test it before then.
The architecture reserves the boundary — an agent node dispatching over A2A is the same node type as one running locally, differing only in executor — so adding it later is additive rather than structural. Saying so plainly is better than shipping a half-implementation and calling the protocol supported.