Agents are a distributed systems problem
Updated August 2026
The hard part of multi-agent systems was never the intelligence. It is everything around the intelligence: how independent processes discover each other, agree on who owns a piece of work, prove they are who they claim to be, and share enough context to act coherently. We have spent two decades solving versions of these problems for services. We are now solving them again, badly, for agents.
The model is not the system
Every meaningful jump in model capability has been absorbed within months by the products built on top of it. The differentiator moved somewhere else. What separates a demo from a system that runs unattended for a quarter is not the reasoning — it is retries, idempotency, timeouts, partial failure, and the ability to explain after the fact why something happened.
I spent years building the Identity Graph at Netflix: a real-time distributed graph resolving who a user is across devices, accounts, and sessions, under load, with no room to be wrong. Almost none of the difficulty was in the algorithm. It was in consistency boundaries, replay, backpressure, and what happens when one node has a stale view of the world. Multi-agent systems have exactly this shape, and most of them are being built as if they do not.
Coordination without a coordinator
Most agent frameworks today solve coordination with an orchestrator: a privileged process that decomposes the task, assigns the steps, and collects the results. This works until the orchestrator is the bottleneck, the single point of failure, and the party that must be trusted by everyone. It is a centralized answer to a problem that is structurally decentralized.
The alternative is a protocol rather than a coordinator — a shared set of rules by which agents negotiate task ownership, hand off work mid-flight, and resolve goals that conflict. This is what I have been building toward with MACP. The interesting design constraint is that agents will not share an owner, a vendor, or a trust domain. Anything that assumes they do will not survive contact with the real world.
The precedent I keep returning to is not microservice orchestration but BGP and SMTP: protocols that let mutually distrusting parties interoperate without anyone being in charge. Those systems are ugly in the details and have outlived nearly everything built on top of them.
Identity before trust
"Can I trust this agent?" is unanswerable until "who is this agent?" has an answer that does not depend on the agent's own claim. Today the answer is usually an API key held by a human, which collapses the entire question into whoever provisioned the credential. That is adequate for one company's internal fleet and hopeless across organizational boundaries.
What is missing is verifiable identity plus scoped, revocable attestations of capability — the ability to say not just that an agent is who it says, but that it has been delegated a specific, bounded authority by a party you already trust, and that the delegation can be withdrawn. This is the problem AITP addresses.
The failure mode I expect to see repeatedly over the next few years is confused-deputy attacks against agents: an agent with broad legitimate authority persuaded by untrusted input to exercise it on someone else's behalf. Prompt injection is the current name for one instance of this. The general form is an authorization problem, and it will not be solved at the model layer.
Context is infrastructure
Agents spend an enormous fraction of their cost and latency re-deriving things they, or another agent, already knew. Context is currently treated as a per-invocation concern — assembled, used, discarded. It should be treated the way we treat state in a distributed system: something with an owner, a lifetime, a consistency model, and a defined story for propagation.
The moment more than one agent works on a shared objective, you inherit every problem stream processing has already faced. What is the ordering guarantee? What happens when two agents hold divergent views? Is context replayable, so a run can be audited or reproduced? Stateful stream-to-stream processing gave me strong opinions here, and ACDP is where I am putting them.
My expectation is that context distribution, not inference, becomes the dominant cost and the dominant correctness risk in serious multi-agent deployments.
What I think happens next
The coordination, identity, and context layers get standardized, and it happens in the open. Closed vertical stacks will be faster initially and will lose, for the same reason proprietary networking stacks lost: the value is in interoperating with parties you do not control.
Agent-to-agent interaction becomes mostly machine-to-machine commerce, and it inherits the requirements of commerce — attribution, non-repudiation, dispute resolution, audit. These are unglamorous and load-bearing.
The winning abstractions come from people who have operated distributed systems at scale rather than from the model labs, because the problems are operational. The labs are solving a different, also-hard problem.
I could be wrong in an obvious way: if one model provider ends up running the overwhelming majority of agents, coordination becomes an internal implementation detail and the protocol layer never needs to exist. I think the pull toward heterogeneity is stronger, but that is the bet, and it is worth naming.