Context
Plumbing is a new coordination language (v0p1, March 2026) by William Waites (University of Southampton / Leith Document Company) that models multi-agent LLM systems as morphisms in a symmetric monoidal category. It was introduced via guest posts on John Baez's Azimuth blog and The n-Category Café. The language provides compile-time verification that agent graphs are well-formed before any compute is spent.
Plumbing and Vera operate at adjacent layers of the stack:
- Vera guarantees individual computations are correct (Z3 verification, contracts, type checking)
- Plumbing guarantees collections of agents are well-connected (typed channels, monoidal composition, functorial session type compilation)
Integration architecture
A Plumbing agent's tool_out/tool_in ports would invoke Vera-compiled WASM modules as verified tool calls:
- Agent sends a typed request to
tool_out
- Plumbing runtime dispatches to a WASM module compiled from Vera source
- Result returns on
tool_in
Vera's contracts guarantee the tool behaves correctly. Plumbing's type system guarantees the tool is wired correctly into the agent graph.
The natural integration point is the typed port interface — Plumbing's stream types (!A) can be made to match Vera's algebraic data types at the serialization boundary (likely JSON, since Plumbing already uses JSON for agent communication).
A second pathway: Plumbing's v0p1 release includes an MCP server. A Vera runtime exposed as an MCP tool server would allow any Plumbing-orchestrated agent to invoke verified Vera functions as tools, with MCP handling serialization and the two type systems providing complementary guarantees.
What Plumbing provides that Vera doesn't
- Parallel composition as a first-class operator (
⊗) — tensor product places agents side by side with formally defined semantics
- Barrier synchronization (
⋈) — waits for values from two streams before proceeding
- Session types compiled to wiring via a functor — concise protocol specs automatically expand to executable agent graphs
- Multi-port agent model — typed control, tool, telemetry, and operator-in-the-loop ports
- Runtime agent reconfiguration — e.g., modulating temperature as a debate converges
Theoretical grounding
The Orchard-Yoshida result (POPL 2016) establishes a bidirectional embedding between effect systems and session types. Vera's algebraic effects could encode the same coordination protocols that Plumbing's session types specify, but Plumbing's domain-specific calculus provides engineering ergonomics where coordination patterns that would require pages of effect handler definitions can be expressed in a few lines of categorical composition.
What this could mean for Vera
The most valuable addition Plumbing could inspire is not importing its coordination primitives (which belong at the orchestration layer) but rather a typed protocol specification mechanism — session types or equivalent — that Vera's effect system could implement. This would enable Vera programs to participate as verified, protocol-aware components in larger multi-agent architectures.
References
Context
Plumbing is a new coordination language (v0p1, March 2026) by William Waites (University of Southampton / Leith Document Company) that models multi-agent LLM systems as morphisms in a symmetric monoidal category. It was introduced via guest posts on John Baez's Azimuth blog and The n-Category Café. The language provides compile-time verification that agent graphs are well-formed before any compute is spent.
Plumbing and Vera operate at adjacent layers of the stack:
Integration architecture
A Plumbing agent's
tool_out/tool_inports would invoke Vera-compiled WASM modules as verified tool calls:tool_outtool_inVera's contracts guarantee the tool behaves correctly. Plumbing's type system guarantees the tool is wired correctly into the agent graph.
The natural integration point is the typed port interface — Plumbing's stream types (
!A) can be made to match Vera's algebraic data types at the serialization boundary (likely JSON, since Plumbing already uses JSON for agent communication).A second pathway: Plumbing's v0p1 release includes an MCP server. A Vera runtime exposed as an MCP tool server would allow any Plumbing-orchestrated agent to invoke verified Vera functions as tools, with MCP handling serialization and the two type systems providing complementary guarantees.
What Plumbing provides that Vera doesn't
⊗) — tensor product places agents side by side with formally defined semantics⋈) — waits for values from two streams before proceedingTheoretical grounding
The Orchard-Yoshida result (POPL 2016) establishes a bidirectional embedding between effect systems and session types. Vera's algebraic effects could encode the same coordination protocols that Plumbing's session types specify, but Plumbing's domain-specific calculus provides engineering ergonomics where coordination patterns that would require pages of effect handler definitions can be expressed in a few lines of categorical composition.
What this could mean for Vera
The most valuable addition Plumbing could inspire is not importing its coordination primitives (which belong at the orchestration layer) but rather a typed protocol specification mechanism — session types or equivalent — that Vera's effect system could implement. This would enable Vera programs to participate as verified, protocol-aware components in larger multi-agent architectures.
References