One-Line Summary: Federation lets agents on different machines (and sometimes different organizations) collaborate on tasks while preserving each side's privacy, trust assumptions, and resource budgets — exemplified by ruflo's federation mode, which combines mTLS for transport, ed25519 for identity, gossip for membership, and Raft/BFT for shared decisions.
Prerequisites: Consensus in multi-agent systems, mTLS and ed25519 for agent trust, gossip protocols for agents
What Is Federation?
Multi-agent systems within a single trust boundary (one machine, one team, one company) can coordinate cheaply. Federation extends multi-agent collaboration across trust boundaries: agents on different machines, owned by different organizations, possibly running different software, must collaborate without each side blindly trusting the other.
The motivating use cases:
- Two companies' code review agents collaborate on a shared pull request.
- A cluster of agents on personal laptops contributes to a research effort.
- Edge devices' agents stream observations to a central planning agent.
- Multi-tenant SaaS where each tenant's agent participates in shared workflows.
Each of these needs the same machinery: identity, transport security, membership, consensus, audit.
How It Works
A federated agent action passes through a stack of guarantees:
- Identity: Each peer has an identity (ed25519 keypair). Public keys are gossiped.
- Transport: Connections are mTLS — both sides authenticate; traffic is encrypted.
- Authorization: The peer is authorized for the action. Behavioral trust scoring may gate.
- Sanitization: Outbound traffic is scrubbed of PII / secrets (
pii-gating-and-aidefence). - Consensus (when needed): Raft or BFT for decisions that affect shared state.
- Audit: Every cross-boundary action is logged with peer identity, timestamp, content.
Ruflo's federation pipeline implements all of this; each step is one of the concepts in this module. Other harnesses approach federation more ad hoc — typically through MCP servers exposed over HTTPS.
Why It Matters
Single-trust-boundary multi-agent is largely a solved problem. Cross-trust-boundary multi-agent is where the next decade of agent infrastructure work happens — distributed agent ecosystems, agent-to-agent commerce, machine-readable APIs replaced by agent-readable agents.
The conceptual jump from "multi-agent" to "federated multi-agent" is roughly the same as the jump from monolith to microservices in the early 2010s: the problems get harder (security, observability, latency, partial failure) but new categories of value become available.
Key Technical Details
- Identity must be machine-readable: A peer's identity is its public key, not its name. Names are nicknames; keys are facts.
- Mutual auth, not server auth: Both sides authenticate each other in mTLS. One-way TLS (web server style) is insufficient for federation.
- Federation is opt-in per peer: A peer can choose to expose only some of its capabilities to federation. Default-deny.
- Latency budget grows: Cross-machine RTTs (10–100ms) compound across protocol stages. Federated decisions take seconds, not milliseconds.
- Consensus protocol selection depends on adversary model: Federated peers within one company can use Raft; across organizations, use BFT.
- PII gating must precede transmission, not follow: Once data leaves your machine, it's out. Scrub before send.
- Reputation drift: Behavioral trust changes over time; the federation layer has to refresh trust scores.
How Harnesses & Frameworks Implement This
| Harness / Framework | Federation support |
|---|---|
| Claude Code | None native; MCP-over-HTTPS approximates partial federation |
| Claude Agent SDK | DIY |
| ruflo | First-class — ruflo-federation plugin; the full stack above |
| LangGraph | DIY — typically via MCP-over-HTTPS |
| AutoGen | DIY |
| CrewAI | DIY |
| OpenAI Agents SDK | DIY |
| Codex CLI / Cursor | ✗ |
Connections to Other Concepts
mtls-and-ed25519-for-agent-trust.md— Transport and identity.behavioral-trust-scoring.md— Reputation layer.pii-gating-and-aidefence.md— Pre-transmit sanitization.gossip-protocols-for-agents.md— Membership.raft-for-agents.md,byzantine-fault-tolerant-agents.md— Decision consensus.
Further Reading
- ruvnet, ruflo-federation documentation.
- ruflo issue #1669 — Federation design RFC.