Agent-to-Agent (A2A) Playbook

1. Scope of this playbook

This playbook is for architects evaluating whether and how to adopt A2A for cross-boundary agent coordination — between internal teams that don't share a platform, between your organization and vendors or partners, or between agents built on genuinely different frameworks. It assumes you're already familiar with MCP (see the Enterprise MCP Playbook) and with the coordination patterns covered in the Multi-Agent Architecture Playbook — A2A sits alongside both, not above or below them in the stack.

2. A2A maturity model

Self-assessment checklist

• Do any of your AI agents currently need to interact with agents built by a different team, a different vendor, or a different organization?
• If so, is that interaction happening through custom point-to-point integration, or a standard protocol?
• Can you verify the identity of an external agent your systems are interacting with, or is trust currently implicit?
• Is there a central log of every cross-boundary agent interaction, or is this scattered across whichever team built the integration?
• Does your organization have a defined policy for which external agents/organizations are allowed to interact with your agents at all?

3. Is A2A even the right protocol for you?

The clearest signal you need A2A: an agent you don't fully control (a vendor's agent, a partner's agent, or another team's agent on a completely different platform) needs to hand off work to or receive work from an agent you do control, and today that requires custom integration work per pairing. If all of your agent coordination happens within one team's platform and one framework, you don't need A2A yet — the coordination patterns in the Multi-Agent Architecture Playbook are the right tool, and adding A2A on top would be solving a boundary problem you don't have.

The distinction matters because A2A and internal multi-agent orchestration solve genuinely different problems. A2A's value is interoperability across a trust boundary with independently developed, independently trusted agents; it's not a better way to coordinate agents that already share a platform and a trust relationship.

4. Readiness checklist

• You've identified the specific cross-boundary agent interactions A2A would replace or enable — not adopting the protocol speculatively, but against a concrete use case.
• An identity and trust policy exists (or is being defined) for which external agents your systems will engage with, and under what conditions.
• Your logging and observability infrastructure can capture cross-boundary agent interactions with the same rigor as internal ones.
• Legal/compliance has weighed in if the cross-boundary interaction involves a different organization.
• There's a fallback plan if an external agent misbehaves or the interaction needs to be shut down.

5. Build vs. buy

6. Phased rollout playbook

Phase 0 — Scoping

Identify one concrete cross-boundary use case — ideally one with a willing partner team, vendor, or organization on the other end, since A2A adoption is inherently two-sided. Define what "success" means beyond "the protocol worked": task completion rate, latency, and — critically — what happens on failure.

Phase 1 — Pilot

Implement A2A for that one pairing with signed agent identity enabled from the start, not added later. Log every interaction centrally even during the pilot, since this is exactly the data you'll need to build the trust-policy rules in Phase 2.

Phase 2 — Production hardening

Formalize the trust policy: which external agents/organizations can interact with yours, under what scopes, with what rate limits. This is also when to bring legal/compliance in fully if the pilot didn't already require it.

Phase 3 — Scale-out

Extend to additional cross-boundary pairings using the trust-policy framework proven in Phase 2, rather than re-litigating trust decisions for every new partner from scratch.

7. Governance & risk checklist

• Every cross-boundary agent interaction has a named internal owner accountable for it, distinct from whoever owns the internal agent's day-to-day behavior.
• Trust policies are reviewed on a defined cadence, not set once and forgotten — a partner organization's risk profile can change.
• There's a documented process to revoke trust for a specific external agent or organization immediately if something goes wrong.
• Cross-boundary interactions that lead to consequential actions route through the same human-in-the-loop gates your internal agents use for equivalent actions.
• Contractual or SLA terms exist with external parties for agent-to-agent interactions where the relationship is commercial, not just internal team-to-team.

8. Security checklist

• Signed agent-card verification (A2A v1.2's cryptographic domain verification) is enforced, not optional — an unsigned or unverifiable agent card should not be trusted.
• Rate limits and cost ceilings apply per external agent/organization to prevent a misbehaving or compromised counterpart from causing a runaway cost or availability event.
• Data shared with external agents is scoped to the minimum necessary for the task — the same least-privilege discipline as MCP tool scoping applies here, across an organizational boundary where the stakes are higher.
• Incoming requests and data from external agents are treated as untrusted input, subject to the same validation and injection defenses as any other external data source.
• There's monitoring for anomalous patterns in cross-boundary agent traffic — a sudden spike or unusual task pattern from a trusted external agent can indicate the counterpart itself has been compromised.

9. Cost model & ROI

The ROI case strengthens with the number of external pairings: one custom integration is often cheaper to build directly than to stand up A2A for; five or more pairings usually favor the standard protocol, especially as new partners are added over time.

10. Organizational playbook

Ownership should split between a platform/integration team that owns the A2A infrastructure and trust-policy tooling, and business or partnership teams that own the specific external relationships and the business logic of what gets shared. This mirrors how most enterprises already handle external API partnerships and B2B integrations — A2A doesn't require a wholly new organizational model, but it does require the trust-policy function to explicitly cover autonomous agent behavior, not just data access.

11. Common failure patterns

• A2A-as-MCP confusion: teams adopting A2A to solve a tool-integration problem that MCP was the right fit for, or vice versa.
• Unsigned trust: enabling A2A interoperability without enforcing signed agent-card verification, effectively getting the interoperability benefits without the trust guarantees the protocol is designed to provide.
• Speculative adoption: standing up A2A infrastructure without a concrete cross-boundary use case, then struggling to justify the governance overhead against unclear value.
• Static trust policy: setting trust rules for external partners once and never revisiting them, even as those partners' own risk profiles or agent behaviors change.
• Boundary blindness: applying internal multi-agent trust assumptions to cross-boundary A2A interactions where the stakes and threat model are meaningfully different.

12. A2A adoption decision scorecard

A use case that scores low on "genuine trust-boundary crossing" is very likely better served by the Multi-Agent Architecture Playbook's internal coordination patterns — reserve A2A adoption for where it earns its governance overhead.