When the internet was young, getting two applications to talk to each other required custom integration for every pairing. Then HTTP happened. Then REST. Then OpenAPI. Suddenly, building on top of other services became routine rather than a multi-month engineering project.

I think we’re at that same inflection point for AI agents. And the Agent2Agent (A2A) protocol — now under the Linux Foundation with support from AWS, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow — is the candidate to become that foundational layer.

The Problem A2A Solves

Right now, most AI agent systems are islands. You have your Salesforce Agentforce doing CRM workflows. Your ServiceNow agent handling IT tickets. Your internal .NET agent managing deployments. Your Azure AI agent monitoring infrastructure.

They can’t talk to each other. Not because it’s technically impossible — because there’s no agreed standard for how. Every integration is a bespoke contract: what format do you speak? How do I discover your capabilities? How do we handle authentication? Who’s responsible for errors?

A2A addresses all of this. Think of it as defining the Content-Type: application/json equivalent for agent-to-agent communication.

What the Protocol Actually Defines

At its core, A2A specifies four things:

1. Agent Cards A lightweight JSON contract (contributed by Salesforce) that describes what an agent can do:

{
  "agentId": "deployment-agent-v2",
  "name": "CI/CD Deployment Agent",
  "version": "2.1.0",
  "capabilities": [
    {
      "name": "deploy_service",
      "description": "Deploy a microservice to staging or production",
      "inputSchema": { ... },
      "outputSchema": { ... }
    },
    {
      "name": "rollback_deployment",
      "description": "Rollback a deployment to a previous version",
      "inputSchema": { ... }
    }
  ],
  "trustScore": 0.94,
  "complianceTags": ["pci-dss", "soc2"]
]
}

This isn’t just documentation. It’s a machine-readable contract that other agents can query to understand what they can delegate.

2. Peer Communication Model Unlike MCP (Model Context Protocol) which treats tools as subordinate to a model, A2A treats agents as peers. Your deployment agent and your monitoring agent communicate as equals — either can initiate, either can respond.

3. gRPC Transport (v0.3) Version 0.3 added gRPC support alongside the original HTTP/JSON. For high-frequency agent coordination (think: 50 agents exchanging state updates every second), gRPC’s binary framing and multiplexing are critical for performance.

4. Signed Security Cards Agents can cryptographically sign their capability cards, enabling verification chains. This matters enormously for enterprise compliance — you need to prove which agent made which decision in your audit logs.

Complementary to MCP, Not a Replacement

A lot of people in the community are confused about the relationship between A2A and MCP (Model Context Protocol). They’re complementary:

MCP: Model ←→ Tools/Resources
     (model calls a tool, tool returns result)

A2A: Agent ←→ Agent
     (agent delegates to agent, collaborates as peers)

In a real architecture, you might have:

Orchestrator Agent (A2A coordinator)
├── Research Agent (uses MCP tools: web search, DB query)
├── Analysis Agent (uses MCP tools: Python exec, file system)
├── Drafting Agent (uses MCP tools: document template, image gen)
└── Deployment Agent (uses MCP tools: git, CI/CD APIs)

The orchestrator coordinates the other agents via A2A. Each agent uses MCP to call its specific tools. Both protocols are in play.

Agent Payments Protocol: The Natural Extension

Google also announced AP2 — Agent Payments Protocol — which extends A2A with standardized payment flows. Partners include Adyen, American Express, Mastercard, PayPal, Salesforce, Worldpay, and 60+ others.

Why does this matter? Because agentic workflows increasingly involve spending money. An agent booking travel, purchasing cloud resources, or procuring a vendor report needs a secure, auditable payment mechanism. AP2 makes this a first-class protocol concern rather than an afterthought.

For fintech developers: this is the moment to think about how your payment infrastructure exposes itself to agentic consumers.

Enterprise Adoption: What 2026 Actually Looks Like

Industry data is projecting that by end of 2026, 40% of enterprise applications will include task-specific AI agents. That’s a lot of agents. Without interoperability standards, enterprise IT will be managing a sprawl of disconnected agent islands.

The organizational structure I’m seeing work well:

Agent Registry Service — A centralized catalog of all agents in your organization, their Agent Cards, trust scores, and usage policies. Think: your internal npm registry, but for agents.

Agent Gateway — A policy enforcement layer that validates A2A requests, enforces rate limits, handles authentication, and provides audit logging. Analogous to an API gateway, but for agent traffic.

Trust Scoring — Agents accumulate trust scores based on reliability, accuracy, and compliance adherence. Low-trust agents get sandboxed; high-trust agents get expanded permissions. This creates incentives for quality.

Here’s a simplified .NET implementation of an A2A-compatible agent endpoint:

[ApiController]
[Route(".well-known/agent")]
public class AgentCardController : ControllerBase
{
    [HttpGet]
    public IActionResult GetAgentCard()
    {
        return Ok(new AgentCard
        {
            AgentId = "deployment-agent",
            Name = "Deployment Orchestrator",
            Version = "1.0.0",
            Capabilities = new[]
            {
                new Capability
                {
                    Name = "deploy",
                    Description = "Deploy services to target environments",
                    InputSchema = DeploymentInput.JsonSchema
                }
            },
            TrustScore = 0.92,
            ComplianceTags = new[] { "internal", "soc2" }
        });
    }
}

[ApiController]
[Route("a2a")]
public class AgentTaskController : ControllerBase
{
    [HttpPost("tasks")]
    public async Task<IActionResult> ReceiveTask([FromBody] A2ATask task)
    {
        // Validate caller's Agent Card
        var callerCard = await _agentRegistry.GetCard(task.CallerId);
        if (callerCard.TrustScore < 0.7) return Forbid();

        // Execute the delegated task
        var result = await _taskExecutor.Execute(task);

        return Ok(new A2ATaskResult
        {
            TaskId = task.TaskId,
            Status = "completed",
            Output = result
        });
    }
}

The Vendor Lock-In Question

Linux Foundation governance is the key differentiator here. When Google owned A2A, enterprises were rightly cautious about deep adoption — what happens when Google pivots? With LF governance (joined by AWS, Microsoft, Salesforce, SAP, ServiceNow), A2A has committed to being:

  • Vendor neutral
  • Open specification
  • Community governed
  • Extensible without fragmentation

Compare this to proprietary agent protocols that some vendors were pushing in early 2025. The ones without open governance have already started to diverge.

My Prediction

In 18 months, “A2A-compatible” will be a checkbox on enterprise software vendor RFPs the same way “REST API” is today. Vendors that don’t support it will be at a disadvantage.

More immediately: the teams that invest now in building proper Agent Cards, establishing internal trust scoring frameworks, and designing A2A-compatible APIs will have a six-month head start when their enterprise customers start demanding agent interoperability.

The internet of AI agents is being built right now. The protocol layer is settling. Build for it.

A2A protocol specification and SDKs are available at github.com/a2aproject/A2A. The Python and Java SDKs are production-ready; .NET SDK is in preview.

Export for reading

Comments