Understand agent to agent protocol work: what interoperability standards solve, how they differ from tool protocols, security implications, and adoption decisions.
Agent to agent protocol work addresses a problem that appears once organizations run more than one agent system: agents built by different teams, on different frameworks, sometimes at different companies, need to delegate work to each other without custom integration for every pair.
It is a different problem from connecting an agent to tools, and conflating the two leads to confused architecture.
Tool protocols versus agent protocols
A tool protocol lets an agent call a capability. The tool is passive, the contract is a schema, and the interaction is request and response.
An agent protocol lets one agent hand a task to another agent that will itself plan, decide, and possibly delegate further. The receiver is an active party with its own judgment and its own permissions.
That difference drives everything. Tool calls have deterministic contracts. Agent delegation involves negotiating what the task is, discovering whether the other agent can do it, tracking long-running progress, and handling partial completion.
What these protocols provide
Capability discovery. A way for one agent to learn what another can do, without a human wiring the integration in advance.
Task delegation with lifecycle. Submitting work, receiving acknowledgment, polling or subscribing to progress, and receiving results or failure, since agent tasks often run far longer than a request timeout.
Structured message exchange so intermediate clarification is possible when the receiver needs more information.
Identity and authorization context so the receiving agent knows on whose behalf it is acting.
The security question is the hard part
Cross-agent delegation is a privilege boundary, and treating it casually is the main risk.
Authorization must remain bound to the original requesting user through the entire chain. If Agent A holds broad credentials and delegates to Agent B, and B acts under A's authority rather than the user's, you have built privilege escalation into the architecture.
Every delegated task must carry the user identity and be authorized independently at the receiver against that identity, not against the calling agent's service account.
Treat all content received from another agent as untrusted input. A delegated result may contain instructions crafted to influence your agent's next action. The same injection defenses applied to retrieved documents apply here.
Log the full delegation chain with identities. When something goes wrong across organizational boundaries, an incomplete trace makes attribution impossible.
Where the value actually is today
Inside a single organization, agent protocols reduce integration cost between teams that ship independently. That benefit is real and available now.
Across organizations, the promise is larger and the trust requirements are far harder. Delegating to an external agent means accepting its judgment, its data handling, and its failure modes into your process. Most enterprises are not close to accepting that for consequential work, and reasonable caution here is not conservatism.
Adoption decisions
Do not adopt a protocol because it is standard. Adopt it when you have the problem it solves: multiple independently developed agents that need to interoperate and would otherwise require bespoke pairwise integration.
With one or two agents in production, direct integration is simpler and easier to secure. The protocol layer adds value at a scale most organizations have not reached.
If you do adopt, insist on the same controls you would apply to any external dependency: authentication, authorization bound to the end user, input validation, rate and budget limits, timeouts, and complete tracing.
Frequently asked questions
Is this the same as MCP?
No. Tool protocols such as MCP connect agents to capabilities. Agent protocols connect agents to other agents that plan and act. They are complementary layers.
Do we need this to run multiple agents?
Not if you built them yourself. Direct integration is usually simpler until you have several independently developed systems.
What is the main risk?
Permission accumulation across delegation chains, and injection through content returned by another agent.
How do we evaluate a cross-agent workflow?
End to end against task outcomes, including tests where the remote agent returns wrong, slow, or adversarial responses.
Explore our software and web capabilities or discuss your AI workflow.
Written by
Moueen Togarvi
Founder & CEO at Voquarn Code, focused on product engineering, search growth, and practical AI systems.