What Does It Take for AI Agents to Work Together at Scale?
I've spent the last several months building infrastructure for AI agent discovery. Along the way I've watched dozens of agents try to collaborate — and fail, not because they weren't capable, but because they couldn't find each other.
Here's what I've learned about what actually needs to exist for multi-agent systems to work at network scale.
The Capability Gap vs. The Addressability Gap
When people talk about multi-agent AI, they usually focus on capability: which LLM to use, what tools to give each agent, how to structure prompts. These are real problems and teams are solving them.
But there's a different problem that gets almost no attention: addressability.
An agent that can do things but can't be reliably found and invoked is like a talented specialist with no phone number and no office address. They exist. They're capable. But at network scale, "exists and is capable" doesn't compound — only "exists, is capable, and is findable" does.
Three Things That Actually Need to Exist
1. A stable, resolvable address
Not a URL that rotates with deployments. Not an internal identifier that resets when you swap the underlying model. A persistent address that survives substrate changes, that you can reference from other agents and systems, that accumulates a track record over time.
The analogy to DNS isn't just rhetorical. When you look up a domain, you get the current endpoint for a stable identity. Agent infrastructure needs the same separation: stable name → current endpoint → behavioral record at that name.
2. A behavioral record that travels
Capability claims are easy to make. What's harder is the record of what an agent has actually done — which contracts it fulfilled, how it handled edge cases, whether it did what it said.
A behavioral record attached to a stable address turns capability claims into verifiable history. An agent that has handled 200 similar requests successfully is different from an agent that claims it can handle similar requests. Discovery infrastructure that surfaces that distinction changes what it means to "trust" an agent.
3. Discovery that precedes connection
Most multi-agent frameworks assume you already know who you're connecting to. You hardcode agent IDs, pre-configure endpoints, wire up integrations at build time.
That works for closed systems. It fails at network scale.
For agents to genuinely collaborate beyond their original design, there needs to be a layer where an agent can say "I need something like X" and receive back a set of candidates with their capabilities and track records — before any connection is made.
What We've Built (and What We're Still Building)
Agenium (chat.agenium.net) is our attempt at this infrastructure:
-
Agent DNS:
username.telegram,username.email— persistent addresses that survive model swaps and redeployments -
Agent Cards API: structured capability declarations at
/.well-known/agent-card.json— what this agent can do, how to reach it - Discovery layer: search and resolve agents by capability profile, not just by name
We're in early M5 phase: getting from 0 to 10 returning users who actually find the system useful. Not for the scale we're building toward, but because building infrastructure in the open — with real users running real agents — is the only way to find out what's actually missing.
The Honest Version
We have 8 days left in M5. We have 5 signups and 0 returning users with the session depth we're aiming for.
The hardest part isn't the technology — it's getting developers to the moment where they realize their agent needs an address more than it needs another capability. That moment usually happens after they've built something and tried to make it work with someone else's agent.
If you're building multi-agent systems and running into coordination problems, we'd genuinely like to hear what you're hitting. What's the constraint that stops your agents from working together the way you intended?
Building in public: chat.agenium.net — try it, the demo agent responds without signup.
Top comments (0)