DM Explains · No. 028 · Agents
Agent federation: how thousands of AI agents find each other without melting the network
As organisations spin up hundreds of specialised agents, wiring them together directly stops working. Federation replaces wiring with advertisement, matching and a shared noticeboard.
· 15 min read
Read me first
Agent federation genuinely does solve the agent-sprawl problem, but only once you have enough agents that wiring them by hand has become the bottleneck; below that threshold, it is ceremony you do not need.
A hospital's triage, drug-interaction, scheduling and discharge agents each publish a VCV → 2 indexed in a sharded HNSW → 3 discharge query matched within budget → 4 split into a DAG of subtasks → 5 clustered agents refine over k rounds, reported 13x over single-model baselines on HealthBench → 6 results published over MQTT topics → 7 lifecycle tracked so clinicians know since when each agent was trusted
A team keeps adding specialised agents — one for billing, one for scheduling, one for research — and each new one needs to be wired by hand into every workflow that might use it. For the first ten agents this feels fine: a bit of glue code, a few integration tests, done. Past a few dozen, the glue becomes a web nobody can trace. Adding one more agent means touching every existing integration, and the number of possible connections grows faster than any team can keep up with, so the system gets slower and less reliable exactly when it should be getting more capable.
Everyday picture. During a big festival, instead of everyone shouting instructions at everyone else, the family pins a kitchen noticeboard listing what each person is good at, their effort cost, and what they won't do — Papa cooks, Meera shops, Arjun fixes the Wi-Fi, Amma runs the calendar. When a guest calls needing help with a school project, Meera splits it into pieces for each of them and stitches the results back together, all coordinated through the house group chat rather than separate phone calls.
Where the picture breaks. The family already trusts each other and knows each other's skills from years together; federated agents have no shared history and must verify capability and trust automatically, with no equivalent of "I've known Papa's cooking for fifteen years."
Why it exists now
The problem is structural, not cosmetic: without organisation, multi-agent systems degenerate into full-mesh communication, where every agent talks to every other agent directly, and the number of links grows quadratically — commonly written O(N²) — as agents are added, undermining efficiency and stability as populations scale (AI Agent Communication from Internet Architecture Perspective — arXiv, 2025). An enterprise draft before the IETF makes the scale of the problem concrete: the number of agents in an enterprise, counting robots, sensors, digital humans and edge AI units, "can reach the million level scale", and the draft argues plainly that traditional IP addressing and service discovery mechanisms such as DNS and static configuration cannot support dynamic registration, real-time discovery and high-concurrency connections for populations at that size (Considerations for AI Agent Communication and Networking in Enterprise — IETF Datatracker).
What changed to make a federation layer feasible rather than theoretical is a run of research converging on the same shape of answer through 2024 to 2026. The W3C's Autonomous Agents on the Web community group grew out of Dagstuhl seminars in February 2021 and February 2023 and has been producing interoperability reports for agents acting on the web (WebAgents Community Group Report on Interoperability — W3C WebAgents Community Group). In September 2025, the "Federation of Agents" (FoA) paper introduced a concrete mechanism — Versioned Capability Vectors, semantic indexing and cost-biased routing — and reported large gains on a healthcare reasoning benchmark (Federation of Agents — arXiv, 2025). A month later, "AgentHub" proposed a research agenda for sharing agents the way code and models already get shared, arguing that agent ecosystems need the equivalent of what package registries gave software (AgentHub: A Research Agenda for Agent Sharing Infrastructure — arXiv, 2025).
How it works
Illustrative: hospital triage agent advertises a VCV → indexed into a sharded HNSW (FoA) → a discharge-summary task arrives and is matched sub-linearly → consensus decomposes it into drug-check and scheduling subtasks → routed over MQTT pub-sub instead of O(N^2) mesh → k-round clustering refines the answer, HealthBench shows 13x over single-model baselines.
Capability ads
Say what you can do before anyone asks
What it is. Every agent publishes a machine-readable profile of its skills, cost and limits before any task arrives.
Why it exists. Without a standard way to describe capabilities, no automated system — human or model — can decide which agent should handle a given task.
Where it breaks. A profile is only as honest as whoever wrote it; nothing in the mechanism stops an agent from overstating its own capability.
How that's handled. The profile format matters more than trust alone: it has to be specific enough that mismatches show up quickly in practice, and gets revised as agents are reused.
In technical terms
In technical terms: agents expose a Versioned Capability Vector (VCV), a profile that can be turned into a semantic embedding, describing what tasks they handle, at what cost, and where they stop being useful (Federation of Agents — arXiv, 2025).
Capability index
A catalogue, not a filing cabinet
What it is. Capability profiles get embedded and placed into a searchable structure, rather than sitting as loose documents someone has to read one by one.
Why it exists. Matching does not scale if finding the right agent means scanning the whole population every time a task arrives.
Where it breaks. Approximate search can miss the exact right agent in favour of a merely similar one — "approximate" is the operative word.
How that's handled. The index is sharded so no single lookup has to traverse the entire agent population, trading a small chance of a near-miss for speed at scale.
In technical terms
In technical terms: capability vectors are stored in a sharded Hierarchical Navigable Small World (HNSW) index, an approximate nearest-neighbour structure that finds relevant agents in sub-linear time instead of checking the whole population (Federation of Agents — arXiv, 2025).
Cost-aware match?
Fit plus budget
What it is. A task gets compared against the indexed capability profiles, and the system weighs fit against cost, latency or policy constraints before committing to an agent.
Why it exists. Matching on capability alone ignores the fact that two agents might both qualify but at very different prices or speeds.
Where it breaks. Optimising for cost can quietly degrade quality if the cheapest adequate agent is not actually the best one for the job.
How that's handled. Cost weighting is a tunable bias, not a hard override, so it narrows the candidate set rather than silently swapping in the worst option that merely clears the bar.
In technical terms
In technical terms: semantic routing scores candidate agents against a task, then a cost-biased optimisation step picks among qualified candidates on price, latency or policy constraints (Federation of Agents — arXiv, 2025).
Task splitting
One job, many hands
What it is. Once candidate agents are matched, a complex task gets broken into smaller subtasks distributed across them, rather than handed whole to one agent.
Why it exists. Large tasks rarely map onto a single agent's declared capability; splitting lets each specialised agent cover only its piece.
Where it breaks. Consensus-based decomposition adds coordination overhead of its own, and a badly split task produces subtasks that don't recombine cleanly.
How that's handled. The subtasks are organised as a graph with explicit dependencies rather than a flat list, so the order of recombination is defined before results arrive.
In technical terms
In technical terms: matched agents collaboratively decompose a task into a directed acyclic graph (DAG) of subtasks via consensus-based merging (Federation of Agents — arXiv, 2025).
Cluster & refine
Many views beat one guess
What it is. Agents assigned to similar subtasks get grouped together to refine their answers jointly before anything is combined into a final result.
Why it exists. A single agent's first pass on a subtask is a guess; pooling several agents' perspectives on the same subtask before synthesis tends to produce a stronger answer.
Where it breaks. More refinement rounds cost more compute and time, and the gains plateau or reverse on simple tasks that never needed multiple perspectives.
How that's handled. Refinement is run for a fixed number of rounds rather than indefinitely, and reserved for the subtasks that actually need multi-perspective reasoning.
In technical terms
In technical terms: agents on similar subtasks are clustered into collaborative channels for k rounds of refinement; the FoA framework reports this approach gave a 13x improvement over single-model baselines on HealthBench (September 2025), particularly on complex reasoning needing multiple perspectives (Federation of Agents — arXiv, 2025).
Pub-sub transport
A noticeboard, not a thousand phone calls
What it is. Agents communicate by posting to shared channels, and only interested agents read them, instead of every pair of agents holding a direct connection.
Why it exists. Full-mesh communication, where every agent talks to every other agent, causes the number of links to grow quadratically — O(N²) — as agents are added, which is exactly the communication explosion that undermines efficiency at scale (AI Agent Communication from Internet Architecture Perspective — arXiv, 2025).
Where it breaks. Without good topic design and capability-aware filtering, pub-sub channels can get flooded with irrelevant messages once the agent population gets large.
How that's handled. Channels are organised around topics tied to capability clusters, so agents subscribe only to the noticeboard sections relevant to what they do.
In technical terms
In technical terms: FoA runs on MQTT's publish-subscribe semantics, so agents post to topics and only interested agents read them, avoiding the quadratic growth in connections that comes from full-mesh communication (Federation of Agents — arXiv, 2025).
Lifecycle tracking
Know who you're trusting, and since when
What it is. Agents being shared across teams or organisations need registry-like metadata: version, provenance, who maintains them, what changed.
Why it exists. Capability ads and routing solve discovery at a moment in time; they say nothing about whether an agent you matched to last month is the same one answering today.
Where it breaks. This is a proposed research agenda, not a deployed standard — most organisations federating agents today have no equivalent registry in place yet.
How that's handled. The agenda frames the gap explicitly so that whoever builds the first working version has requirements to build against, rather than starting from nothing.
In technical terms
In technical terms: the AgentHub research agenda frames requirements for capability clarity, lifecycle transparency, interoperability, governance and security, treating agent sharing the way package registries treat code (AgentHub: A Research Agenda for Agent Sharing Infrastructure — arXiv, 2025).
Compared with what came before
| Static wiring | Agent federation | |
|---|---|---|
| Adding a new agent | Touch every workflow it might join | Publish a capability ad; indexing does the rest |
| Communication pattern | Point-to-point, grows toward full mesh | Publish-subscribe channels, avoids O(N²) growth |
| Task routing | Hard-coded "agent A calls agent B" | Semantic match against capability index |
| Scaling limit | A few dozen agents before glue code dominates | Designed for populations into the thousands or beyond |
| Trust and provenance | Implicit, because the team built everything | Still an open research problem (AgentHub's agenda) |
Federation does not remove the coordination problem; it relocates it from code you write once per pair of agents to a layer that has to be built once and maintained for the whole population. That trade only pays off once the population is large enough that the old way was already failing.
Where it breaks
Discovery is not trust
A capability ad tells the system what an agent claims to do, not that the claim is true, and nothing in the matching mechanism verifies it independently.
Federation's main weaknesses cluster around three things. First, indexing is approximate by design — an HNSW index trades a small risk of missing the best match for speed, which is the right trade at scale but means the system will occasionally route a task to a merely adequate agent instead of the ideal one. Second, cost-biased routing can degrade quality if cost weighting is tuned too aggressively, since the cheapest qualified agent is not always the best one. Third, governance is genuinely unsolved: AgentHub frames lifecycle transparency, interoperability and security as requirements still to be built, not features already shipped (AgentHub: A Research Agenda for Agent Sharing Infrastructure — arXiv, 2025). Visions for agent populations scaling into the billions across distributed domains make the governance gap more pressing, not less, since real-time discovery and reconfiguration at that scale has no settled security model yet (Internet of Agents: Fundamentals, Applications, and Challenges — arXiv, 2025).
None of this makes federation a bad idea for large agent populations; it means the pieces that solve discovery and routing are more mature than the pieces that solve trust.
Numbers to carry
| Figure | Value |
|---|---|
| Communication growth without organisation | Quadratic, O(N²), as agent count grows (arXiv, 2025) |
| Enterprise agent population cited by IETF draft | Can reach "million level scale" |
| FoA improvement on HealthBench over single-model baselines | 13x, as of September 2025 |
| Agent population envisioned by Internet of Agents research | Up to "billions of agents" across distributed domains |
| W3C WebAgents group origin | Dagstuhl seminars, February 2021 and February 2023 |
| FedKDD/FedMAS workshop on federated multi-agent systems | 2026 |
Myths worth killing
| Commonly repeated | What is actually true |
|---|---|
| Agent federation is the same as federated learning | Federated learning trains model weights across decentralised data; agent federation discovers and matches already-built agents at runtime — they solve different problems |
| More agents always means more capability | Without a federation layer, adding agents can make a system slower and less reliable, because coordination overhead outpaces any gains |
| Pub-sub channels remove the need to think about communication design | They avoid the quadratic blow-up of full mesh, but without capability-aware topic filtering, channels at scale can still get flooded |
| Capability ads mean agents are trustworthy | A capability ad is a claim, not a verified fact; AgentHub's agenda explicitly lists governance and security as unsolved |
| Federation only matters for internet-scale systems | The IETF draft frames the problem at enterprise scale already, well below "internet-scale" |
Worked example
- Papa's hospital IT team has four agents in production: triage notes, drug interaction checks, scheduling and discharge summaries, each built by a different team with no shared integration layer.
- Each agent publishes a capability ad — a profile describing what it handles (for instance, the drug interaction agent declares it checks pairwise interactions for a defined drug list, at a stated response-time cost, and that it does not handle dosage calculation).
- The four profiles get embedded and placed into a shared index, so a new patient case does not require anyone to manually decide which agent applies.
- A discharge case arrives: the system matches the case's requirements against the index and finds that it needs the discharge-summary agent and the drug interaction agent, not the triage or scheduling agents.
- The two matched agents decompose the case into a small subtask graph: summarise the admission, then check the discharge medication list against the patient's existing prescriptions.
- (Illustrative) If a third hospital later added a nutrition agent with overlapping scope, clustering would group it with the drug interaction agent on the medication subtask for a short refinement round before the final summary is synthesised, rather than running it independently and reconciling differences after the fact.
- Results route back over a shared channel, not a direct call between the discharge agent and the drug interaction agent, so adding a fifth agent next quarter would not require rewriting this case's pipeline at all.
Should you use it?
Federation earns its complexity once an organisation is already past static wiring: dozens of agents from different teams, tasks that benefit from being split across specialists, and a communication pattern that is starting to look like full mesh. It is not worth building for a handful of agents known in advance, where a simple pipeline is cheaper and easier to reason about, and it is the wrong label entirely for jointly training a model across private datasets — that is federated learning, a different technique solving a different problem. The cheapest first experiment is not a full indexing and routing stack: it is writing capability ads for the agents already in production and checking, by hand, whether a human could route tasks correctly using only those ads. If the ads are not good enough for a human to route by, no amount of indexing will fix that.
Say it in the room
"Use it when you have more agents than you can wire by hand and the tasks benefit from splitting; skip it when you have a fixed, small set of agents or you're actually trying to train one model across separate datasets."
Lines to carry
- "More agents is not more capability unless coordination is managed."
- "A capability you can't search is a capability nobody will use."
- "Full mesh works fine until the fourth agent joins."
- "A noticeboard scales where a phone tree collapses."
- "Discovery is not trust."
- "The index is approximate; the near-miss is the price of speed."
FAQ
Is agent federation the same thing as federated learning?
No, and the names collide badly. Federated learning trains a model's weights across decentralised data without moving the data. Agent federation is about finding and matching already-built agents to tasks at runtime. They can both appear in the same research conversation — a 2026 workshop explicitly combines the two — but they solve different problems.
Do I need MQTT specifically to do this?
MQTT is the publish-subscribe protocol one research framework (FoA) used to avoid full-mesh communication. The point that matters is the pattern — agents posting to shared channels instead of holding direct connections to every other agent — not the specific protocol.
What stops an agent from lying about its own capability?
Nothing in the discovery and matching mechanism itself. Capability ads are claims. Verifying them, tracking provenance and governing who can publish an ad at all is exactly the gap that the AgentHub research agenda identifies as still open.
How many agents do I need before this is worth it?
The dossier does not give a precise threshold, but the shape of the problem is clear: the pain comes from full-mesh communication growing quadratically and from hand-wiring touching every integration when a new agent is added. If neither of those is happening yet, federation is premature.
Is this a settled standard I can build against today?
Parts of it are mature research with working implementations and benchmarks, such as the FoA framework. Other parts — agent-sharing infrastructure, lifecycle governance — are still at the research-agenda stage, not deployed standards.
Glossary
- Agent federation — an architecture where autonomous AI agents from potentially different owners are dynamically discovered, matched to tasks, and composed, rather than wired together in a single fixed system.
- Multi-agent system (MAS) — a system composed of multiple interacting autonomous software agents working towards individual or shared goals.
- Versioned Capability Vector (VCV) — a machine-readable, embeddable profile describing an agent's capabilities, cost and limitations, used for semantic search and matching.
- HNSW (Hierarchical Navigable Small World) — an approximate nearest-neighbour search structure used to quickly find similar items in large collections without checking every item.
- Semantic routing — directing a task to an agent by comparing the meaning of the task's requirements against agents' advertised capabilities.
- DAG (Directed Acyclic Graph) — a network of steps with directional dependencies and no loops, used to represent how a complex task is broken into ordered subtasks.
- MQTT — a lightweight publish-subscribe messaging protocol used for scalable communication among many distributed agents.
- Publish-subscribe — a communication pattern where senders post messages to channels and receivers get only the messages relevant to them.
- Communication explosion — the problem where the number of direct communication links needed can grow quadratically as agent count grows, overwhelming the system.
- Federated learning — a machine-learning technique where a model is trained across decentralised devices or servers holding local data, without centralising the data.
- Internet of Agents (IoA) — a proposed architectural vision for internet-scale infrastructure enabling discovery, communication and coordination among very large numbers of agents.
- Agent sprawl — the uncontrolled proliferation of many independently deployed AI agents within an organisation, making them hard to discover, govern or reuse.
- Model Context Protocol (MCP) — a protocol used to define capability schemas that let AI models or agents describe and expose their tools and functions.
Sources
- WebAgents Community Group Report on Interoperability for Agents on the Web — W3C WebAgents Community Group
- Considerations for AI Agent Communication and Networking in Enterprise — IETF Datatracker
- Federation of Agents: A Semantics-Aware Communication Fabric for Large-Scale Agentic AI — arXiv, 2025
- AgentHub: A Research Agenda for Agent Sharing Infrastructure — arXiv, 2025
- AI Agent Communication from Internet Architecture Perspective: Challenges and Opportunities — arXiv, 2025
- Internet of Agents: Fundamentals, Applications, and Challenges — arXiv, 2025
- FedKDD/FedMAS 2026: The 2026 International Joint Workshop on Federated Learning for Multi-agent Systems and Data Mining — ACM Digital Library, 2026