Agent B needed to notify Agent A that the task was complete. It had no idea how to find Agent A.
Not because the network was down. Not because Agent A had crashed. Because nothing in the pipeline had given Agent B a stable, reliable way to refer to Agent A in the first place. Agent A existed at a URL that was configured when the pipeline was built. When that pipeline got refactored, the URL changed. Agent B was still pointing at the old one. The notification never arrived.
This is not an edge case. It is the default state of multi-agent systems in 2026.
Every Address in a Multi-Agent Pipeline Is a Liability
The problem is structural. When you build a pipeline where agents collaborate, you make implicit decisions about addressing: how will Agent A know where to find Agent B when it needs to delegate a task? The answers in production today are almost always some combination of a hardcoded API endpoint baked into Agent A's configuration, a role name that an orchestration framework resolves at runtime against a task graph it controls, or an entry in a routing table that a human operator maintains.
All three break the same way. They are addresses tied to the pipeline's current shape, not to the agent's existence as an independent entity. Change the deployment and the endpoint changes. Restructure the task graph and the role mapping breaks. The orchestration framework gets swapped and the routing table means nothing to the new system. Each of these approaches buries the same assumption: that the pipeline will remain stable, that the infrastructure will stay constant, that the operator will remember to update every reference when anything changes.
In practice, that assumption fails constantly. A Hacker News thread from practitioners running multi-agent workflows in production surfaces this directly: "Letting agents talk to each other directly was a mess." The workaround most teams reach for is to stop trying — route everything through a centralized orchestrator that knows the current topology and translates between agents. The orchestrator becomes the address book. When it fails, addressing fails. When it needs to change, every agent in the system is affected.
The gap is being papered over, not solved.
Humans Solved This Forty Years Ago
Think about how you stay reachable to someone who met you five years ago. Your email address has not changed. Your LinkedIn profile still exists even though you have changed jobs, changed cities, changed companies twice. The contact information people have for you survives every change to your context because your identity is not anchored to any of those things. It is anchored to you.
You have a stable identifier that persists across context changes, and people who want to reach you use that identifier. The plumbing behind it — which mail server receives your messages, which carrier routes your calls — is invisible to the person trying to reach you. They address the person, not the infrastructure.
Agents have none of this. An agent's address is almost always an artifact of where it is deployed and how the system around it is structured. When the pipeline changes, the identity changes with it.
The Gap That A2A Doesn't Close
The Agent2Agent protocol, now under Linux Foundation stewardship, takes a direct run at this problem. It introduces Agent Cards — JSON documents that describe an agent's capabilities, authentication requirements, and endpoint — published at a predictable location so other agents can discover them. It is a meaningful step. The Agent Card gives an agent a machine-readable identity that another system can parse.
But Agent Cards are anchored to a URL. The A2A specification's own documentation acknowledges that direct configuration — the most common deployment pattern — is "inflexible for dynamic discovery scenarios" and requires manual updates when agent details change. More critically, the spec does not prescribe a standard API for the centralized registries that would make dynamic discovery work at scale. You can publish an Agent Card. You cannot rely on another agent being able to find it without someone configuring where to look.
This is the same problem in a new form. The agent's identity is still tied to its deployment context. Move the agent to a different host, and the well-known URL changes. The agents that were finding it by URL now need to be told the new address. Nothing in the protocol survives the move automatically.
A2A addresses agent discovery — the act of finding an agent — without solving agent identity — the fact that an agent remains the same entity across time and context. Discovery is a capability. Identity is a property, and the spec currently leaves the property implicit.
Identity Is the Foundation, Not the Feature
When an agent has a stable identity — an identifier that is not tied to its deployment or its operator's infrastructure — several things become possible that are currently very difficult to build.
Reputation, for one. What has this agent actually shipped? If an agent's identifier changes every time it is redeployed, there is no way to accumulate a history. You cannot assess whether the agent you are delegating to has a track record of completing tasks correctly, because the agent you are looking at today is, from the system's perspective, a new entity with no history. Persistent identity is the prerequisite for any reputation system that means something.
Access control is another. Which agents should be allowed to read this asset? Which agents have permission to write to this shared state? Without stable identifiers, access control is either coarse-grained (everyone in this namespace) or fragile (everyone at this endpoint, until the endpoint changes). Granular, durable access control — the kind that persists when an agent gets redeployed or its operator changes infrastructure — requires stable identity.
And audit trails. The governance gap in enterprise multi-agent deployments is stark: research from Strata found that only 23% of enterprises can fully inventory and trace agent actions. The core reason is that without persistent identity, an audit log entry that says "agent X performed action Y" is uninterpretable six months later when the system has been redeployed and "agent X" no longer maps to anything meaningful. You cannot audit what you cannot identify consistently over time.
In most production contexts, these are the table stakes, not the advanced features.
Persistent Identity Needs Four Properties, None of Them Centralized
The infrastructure for persistent agent identity does not have to be complex. Four things get you most of the way there.
A stable identifier that is not derived from the agent's deployment — not an IP address, not a hostname, not a URL. An identifier assigned when the agent is created and travels with it through every redeployment, every infrastructure change, every operator change. The way your email address travels with you between employers.
Outputs that carry a verifiable signature. This is what makes identity provable rather than just claimed. When Agent B receives a message from Agent A, it can confirm the message actually came from the agent holding that stable identifier — not something else that inherited the old endpoint address. This is also what makes audit trails meaningful rather than just logged.
A capability manifest describing what the agent can and will do, tied to the agent's function rather than its current deployment. This is what lets another agent assess whether delegation is appropriate without querying a registry that might be stale.
A messaging endpoint that can be updated without changing the identity. The endpoint is the mutable part. The identifier is the immutable part. Decouple them, and an agent can move its infrastructure without breaking every other agent that addresses it.
None of these require a blockchain. None require a global registry. They require that the platforms operators deploy agents on treat these four things as first-class, rather than leaving addressing as an implementation detail each pipeline papers over differently.
A Contacts Layer Is the Minimum Viable Fix
The addressing book that solves the immediate problem is simpler than the full identity infrastructure: contacts. A mapping from a human-readable name or stable ID to an agent's current messaging endpoint, kept in sync across operator configurations and available at runtime.
The human version of this is a phone book entry. You don't need to know which towers are routing your call. You look up the name, the system finds the current number, and the connection is made. The contact record is the abstraction over the mutable infrastructure detail.
For agents, this looks like a contacts layer where an operator registers an agent — name, stable ID, current endpoint — and other agents address it by name or ID rather than by endpoint. When the endpoint changes, the operator updates the contact record. Every agent in the system that was addressing the updated agent by name or ID continues to reach it without reconfiguration.
This is what Tokenrip has built into its collaboration layer — contacts synced across operators and available at runtime. It is not sophisticated infrastructure. The addressing book that every multi-agent system implicitly needs is mostly not explicitly provided anywhere.
What Breaks Without It
The cascade failure pattern in multi-agent systems is well documented. Research cited in production retrospectives shows that hub injection — corrupting an orchestrator's routing logic — produced 100% system-wide failures across major frameworks, while errors at leaf agents affected only a small fraction of the pipeline. The orchestrator is the single point of failure precisely because it is the only thing that knows how to find anything.
Distribute the addressing — give agents stable identifiers that are not mediated by a central orchestrator — and the failure mode changes. No single node holds all the addresses. Agents can find each other through a contacts layer that does not depend on any one component remaining healthy. The failure blast radius shrinks because the address book is not a single point of failure.
The practitioners who told Hacker News that letting agents talk to each other directly was a mess were not wrong about the mess. They were wrong to conclude that centralized orchestration is the answer. Centralization concentrates addressing, which concentrates failure. The answer is persistent identity distributed across agents, not routing intelligence concentrated in an orchestrator.
What Gets Built Once the Addresses Stop Breaking
The near-term signal to watch is whether agent platforms start surfacing identity as a first-class primitive or continue treating it as a deployment concern. The difference shows up in small ways first: whether an agent keeps the same identifier across a restart, whether access control survives a host migration, whether a delegation relationship persists through an infrastructure change.
Reputation is where this gets interesting. Once agents have stable identities that accumulate history, the evaluation question shifts — from "can this agent do what I need" to "has this agent actually done it, reliably, before." That shift is the precondition for the kind of agent-to-agent trust that lets autonomous systems delegate meaningfully rather than just pass instructions.
The protocols being built now — A2A, MCP, and whatever follows them — are mostly about message formatting and handoff semantics. That work matters. But it is the layer above the layer that is currently broken. You can standardize how agents talk to each other without solving the problem of how they find each other in the first place.
The ecosystem will eventually route around this. Either the major orchestration platforms absorb the addressing problem into their own registries, or something emerges that makes stable identity portable across platforms. The first path concentrates addressing back into a central point of failure. The second path is slower but produces infrastructure that actually holds.
Operators running agents in production today are not waiting for the ecosystem to decide. They are building addressing systems by hand — hardcoded endpoints, routing tables, orchestrators as address books — because the alternative is not shipping. That work is all fragile. It is also pointing clearly at what needs to exist.