Over the past six months, I’ve seen the same patterns repeating across enterprise AI teams. A2A and ACP light up the room during architecture reviews – the protocols are elegant, the demos impressive. Three weeks after production begins, someone asks: “Wait, which agent authorized the $50,000 vendor payment at 2 in the morning?” Excitement turns to worry.
Here is the contradiction: agent2agent (A2A) and agent communication protocol (ACP) are so effective at eliminating integration frictions that they have removed the natural “brakes” that used to force governance negotiations. We have solved the plumbing problem brilliantly. In doing so, we have created a new class of consolidation loan – one where organizations borrow faster today at the expense of accountability tomorrow.
The technical protocols are solid. Organizational protocols are missing. We increasingly move from “Can these systems be connected?” Moving forward from. Step “Who authorized this agent to close a position at 3 in the morning?” phase. In practice, this creates a governance gap: our ability to engage agents is exceeding our ability to control what they commit to us.
To see why that change is happening so rapidly, it helps to look at how the underlying “agent stack” is evolving. We are seeing the emergence of a three-tier structure that quietly replaces traditional API-based connectivity:
| layer | protocol example | Objective | “Human” analog |
| tooling | MCP (Model Reference Protocol) | Connects agents to local data and specific tools | a worker’s toolbox |
| Context | ACP (Agent Communication Protocol) | Standardizes how goals, user history, and status move between agents | A worker’s memory and briefing |
| Coordination | A2A (Agent2Agent) | Handles searches, negotiations, and delegation across borders | a contract or handshake |
This stack makes multi-agent workflows a configuration issue rather than a custom engineering project. That’s why the risk surface is growing faster than most CISOs realize.
Think of it this way: A2A is to shake hands Between agents (who talks to whom, about what task). is acp briefing document They exchange (what context, history, and goals move forward in that interaction). MCP is tool box Each agent has access locally. Once you look at the stack this way, you also see the next problem: We’ve solved API sprawl and quietly replaced it with something harder to see — agent sprawl, and with it, a wider governance gap.
Most enterprises already struggle to control hundreds of SaaS applications. One analysis puts an average of more than 370 SaaS apps per organization. Agent protocols do not reduce this complexity; They move around it. In the API era, humans filed tickets to trigger system actions. In the A2A era, agents use “agent cards” to find each other and interact on top of those systems. ACP allows these agents to do business in rich context – meaning conversations that start in customer support can flow into fulfillment and partner logistics with zero human handoffs. What used to be API dispersion is turning into dozens of semi-autonomous processes working on behalf of your company in infrastructure that you don’t fully control. The friction of manual integration acted as a natural brake on risk; A2A has removed that break.
That administrative gap does not generally result in a single catastrophic failure. This appears as a series of small, confusing events where everything looks “green” in the dashboard but the business outcome is wrong. The protocol documentation focuses on encryption and handshakes but ignores the emerging failure modes of autonomous collaboration. These are not bugs in the protocol; They are signs that the surrounding architecture has not caught up to the level of autonomy enabled by the protocol.
policy flow: A refund policy encoded in a service agent may technically interoperate with a partner’s collections agent through A2A, but their business logic may be exactly the opposite. When something goes wrong, no one owns the end-to-end behavior.
context oversharing: A team can extend the ACP schema to include “user sentiment” for better personalization, unaware that this data is now transmitted to every downstream third-party agent in the chain. What started as local promotion has become distributed performance.
fatalism trap: Unlike REST APIs, agents are non-deterministic. The logic of an agent’s refund policy may change when its underlying model is updated from GPT-4 to GPT-4.5, even if the A2A agent card declares the same capabilities. The workflow “works” – until it doesn’t, and there is no version trace to debug. This creates what I call “ghost breaks”: failures that are not visible in conventional observation because the interface contract appears unchanged.
Overall, these are not edge cases. This happens when we give agents more autonomy without upgrading the rules of engagement between them. These failure modes have a common root cause: the technical ability to collaborate between agents has outstripped the organization’s ability to say where that collaboration is appropriate, and under what constraints.
That’s why we need something on top of the protocol: an explicit “agent treaty” layer. If protocol is language, then treaty is the constitution. Governance should move from “side documentation” to “policy as code”.
Want radar delivered straight to your inbox? Join us on Substack. Sign up here.
Traditional governance policy assumes failure to prevent violations. An antifragile approach treats them as signs of exploitation. When an agent makes a commitment that violates a business constraint, the system should catch that event, trace the causal chain, and feed it back into both the agent’s training and negotiation rules. With time, the governance layer becomes not only strict but also smart.
Define junction-level constraints: Do not authorize just any connection; Authorize a scope. Which ACP fields is the agent allowed to share? Which A2A operations are “read-only” vs. “legally binding”? Which category of decisions requires human encouragement?
version of the behavior, not just the schema: Treat agent cards as first class product surfaces. If the underlying model changes, the version must change, triggering a re-review of the treaty. This isn’t bureaucratic overhead – it’s the only way to maintain accountability in a system where autonomous agents make commitments on behalf of your organization.
Cross-Organizational Traceability: We need observable traces that show not only latency but intent: which agent made this commitment under which policy? And who is the master of man? This is especially important when workflows span organizational boundaries and partner ecosystems.
Designing that junction layer isn’t just a tooling problem. It changes who should be in the room and how they think about the system. The hardest hurdle isn’t the code; These are the people. We are entering a world where engineers must think about multi-agent game theory and policy interactions in addition to just SDK integration. Risk teams must audit “machine-to-machine commitments” that can never be represented in human language. Product managers must have an agent ecosystem where a change in one agent’s reward function or context schema changes behavior across the entire partner network. Compliance and audit functions require new tools and mental models to review autonomous workflows that are executed at machine speed. In many organizations, those skills exist in separate silos, and adoption of A2A/ACP is moving faster than the cross-functional structures needed to manage them.
This may all seem abstract until you look at where enterprises are in their adoption curve. Three converging trends are making this necessary: Protocol maturity means that the A2A, ACP, and MCP specifications have become stable enough that enterprises are moving beyond pilots to production deployments. Multi-agent orchestration is moving from single agents to agent ecosystems and workflows that span teams, departments, and organizations. And tacit autonomy is blurring the line between “tool assistance” and “autonomous decision making” – often without explicit organizational approval. We’re moving from integration (making things talk) to orchestration (making things act), but our monitoring tools still only measure interactions. The next 18 months will decide whether enterprises can get ahead of this or whether we see a wave of high-profile failures that force retrospective rulings.
The risk is not that A2A and ACP are unsafe; it’s just who they are very effective. For the teams running these protocols, stop focusing on the “happy path” of connectivity. Instead, choose a multi-agent workflow and present it as a key product:
map reference flow:Each ACP field must have a “Purpose Range” tag. Document which fields agents view, and what business or regulatory requirements justify that visibility. This is not an inventory exercise; This is a way to expose hidden data dependencies.
audit commitments: Identify every A2A interaction that represents a financial or legal commitment – especially those that do not go through human approval. Ask, “If this agent’s behavior changed overnight, who would notice? Who is accountable?”
code treaty: Prototype A “gatekeeper” agent that enforces business constraints on top of raw protocol traffic. It’s not about stopping agents; It’s about making the policy visible and enforceable at runtime. Start with the minimum: one policy, one workflow, one success metric.
resources for learning: Capture which agents collaborate, what policies they enforce, and what contexts they share. Think of it as telemetry, not just audit logs. Patterns feed back into quarterly governance reviews.
If this works, you now have a repeatable pattern for scaling agent deployments without sacrificing responsiveness. If it breaks, you’ve learned something important about your architecture. First It breaks in production. If you can get a workflow to behave this way – governed, observable, and learning as you go – you have a template for the rest of your agent ecosystem.
If the last decade was about treating APIs as products, the next decade will be about treating autonomous workflows as policies encoded in the traffic between agents. The protocols are ready. You don’t have an organization chart. The bridge between the two is the agent pact – start building it before your agents start signing deals without you. The good news: You don’t have to redesign your entire organization. You need to add a critical layer—agent negotiation—that makes the policy machine-enforceable, observable, and learnable. You need engineers who think about composition and game theory, not just connections. And you have to treat agent deployment as a product, not as infrastructure.
The sooner you start, the sooner the governance gap will close.
