A2A in Agentforce · MindBlaze

Your Agentforce agent is good at its job and completely trapped. It can reason over your CRM, call custom Apex actions, and — once you register an MCP server — reach out to tools like Snowflake or Jira. But the moment its work depends on another agent — a supplier’s procurement agent, a partner’s logistics agent, a specialist agent your own company built on a different platform — the model breaks down. You can’t hand a task to an agent you don’t own and can’t see inside. Historically you’d rebuild that agent’s capability as yet another tool, or give up and keep a human in the middle.

The Agent2Agent protocol — A2A — is the standard built to close that gap, and it’s a genuinely different thing from the protocols Agentforce already speaks. This post is what A2A actually standardizes, how an Agentforce agent participates as a peer rather than a tool, the Agent Card and task lifecycle you need to understand before you wire anything up, and — because this is the load-bearing part — the trust boundary you open the instant your agent starts delegating to agents you don’t control.

What A2A is, and who’s behind it

A2A is an open protocol for communication between opaque agentic applications — agents built on different frameworks, run by different organizations, that need to collaborate without exposing their internal state, memory, or tools to each other. It was created by Google Cloud and announced in April 2025, then contributed to the Linux Foundation in mid-2025 for vendor-neutral governance. Its founding members read like a truce among rivals — AWS, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow — and by 2026 more than 150 organizations had lined up behind it.

The word that matters in the definition is opaque. A2A is explicitly designed so that a client agent can delegate a task to a remote agent and get back a result without the remote agent revealing how it did the work, what model it used, or what data it touched. That opacity is the feature — it’s what makes cross-company agent collaboration possible at all — and, as we’ll see, it’s also the entire security problem.

A2A vs. MCP: the distinction that keeps people confused

If you’ve internalized MCP, the temptation is to file A2A as “MCP for agents” and move on. Don’t — the protocols do different jobs, and the A2A spec itself is precise about it:

MCP standardizes how an agent connects to tools, APIs, data sources, and resources — it’s the “how-to” for an agent to use a capability. Think of it as reaching down to a tool.
A2A standardizes how independent, opaque agents communicate and collaborate as peers — it’s about how agents partner or delegate work to each other. Think of it as reaching across to another agent.

The two compose cleanly, and the spec spells out exactly how: an A2A client agent asks an A2A server agent to perform a complex task; that server agent, in turn, might use MCP internally to hit the tools and data it needs to fulfill it. One agent’s peer collaboration is another agent’s private tool use. You’ll often run both.

The one-line mental model that stays accurate: MCP connects an agent down to tools and data; A2A connects an agent across to peer agents; Atlas orchestrates agents within Agentforce. Three layers, three jobs — get them straight and the architecture stops being confusing.

That third layer matters because Agentforce already has an internal orchestration story. Multi-agent orchestration — an orchestrator delegating to specialist agents through the Atlas reasoning engine — is Salesforce routing work among agents it hosts. A2A is the layer for when the agent you need to delegate to lives on someone else’s platform entirely. Atlas is your team; A2A is how your team talks to the other company’s team.

The Agent Card: how agents discover each other

Everything in A2A starts with the Agent Card — a JSON document that advertises what an agent is, what it can do, and how to talk to it. It’s served from a standardized well-known location so any client can find it:

https://{server_domain}/.well-known/agent-card.json

(Early drafts used /.well-known/agent.json; the current, registered path is agent-card.json — worth getting right, because the old one still floats around in blog posts.)

A trimmed Agent Card looks like this — the shape is from the protocol spec:

{
  "protocolVersion": "0.3.0",
  "name": "GeoSpatial Route Planner Agent",
  "description": "Provides advanced route planning and traffic analysis services.",
  "url": "https://georoute-agent.example.com/a2a/v1",
  "preferredTransport": "JSONRPC",
  "provider": {
    "organization": "Example Geo Services Inc.",
    "url": "https://www.examplegeoservices.com"
  },
  "version": "1.2.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "securitySchemes": {
    "google": {
      "type": "openIdConnect",
      "openIdConnectUrl": "https://accounts.google.com/.well-known/openid-configuration"
    }
  },
  "security": [{ "google": ["openid", "profile", "email"] }],
  "defaultInputModes": ["application/json", "text/plain"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "route-optimizer-traffic",
      "name": "Traffic-Aware Route Optimizer",
      "description": "Calculates the optimal driving route between locations.",
      "tags": ["maps", "routing", "navigation", "traffic"]
    }
  ]
}

The pieces that decide whether an integration works: skills[] (what the agent can actually do, each with an id, description, and tags the client reasons over), capabilities (does it support streaming over SSE, pushNotifications via webhooks), securitySchemes and security (how you authenticate — more on that below), and the defaultInputModes / defaultOutputModes that declare which content types it speaks. A client reads the card, decides the remote agent can do what it needs, authenticates, and starts a task.

The task lifecycle: what actually goes over the wire

A2A’s baseline transport is JSON-RPC 2.0 over HTTPS (the 1.0 spec adds gRPC and REST bindings, but JSON-RPC is what most deployed agents emit today). The client sends a message; the server returns a Task — a first-class object with an id, a status, a history, and any artifacts the work produced.

A minimal request delegating a task looks like this:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "message/send",
  "params": {
    "message": {
      "role": "user",
      "parts": [{ "kind": "text", "text": "Plan a route from HQ to the airport avoiding tolls." }],
      "messageId": "9229e770-767c-417b-a0b0-f0741243c589"
    }
  }
}

And the response comes back as a task the client can track:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "id": "363422be-b0f9-4692-a24d-278670e7c7f1",
    "contextId": "c295ea44-7543-4f78-b524-7a38915ad6e4",
    "status": { "state": "completed" },
    "artifacts": [
      {
        "artifactId": "9b6934dd-37e3-4eb1-8766-962efaab63a1",
        "name": "route",
        "parts": [{ "kind": "text", "text": "Take I-280 S, 34 minutes, no tolls." }]
      }
    ],
    "kind": "task"
  }
}

The state machine is the part to design around. A task moves through submitted → working and lands in a terminal state — completed, failed, canceled, or rejected — but it can also pause in states you have to handle: input-required (the remote agent needs more from you) and auth-required (it needs step-up authentication mid-task). For long-running work — and cross-company delegation is often exactly that — the client either polls tasks/get or subscribes to a stream, rather than blocking on a synchronous reply. An agent that assumes every delegated task returns instantly will break the first time it delegates something real.

Where Agentforce fits — and where to be careful

Here’s the honest part. The A2A protocol facts above are stable and specified. Agentforce’s support for A2A is a fast-moving surface, and this is the section where you should trust release notes over any blog — including this one.

Salesforce positions Agentforce to both consume and expose agents over A2A: an Agentforce agent acting as a client can delegate to an external A2A agent (a procurement agent on Azure, a logistics agent on Google Cloud), and Agentforce capabilities can be exposed so external agents delegate in. Salesforce has folded A2A into the same Summer ‘26 wave that brought Atlas 3.0 and multi-agent orchestration to maturity. But treat the specifics as evolving: confirm the current GA-versus-pilot status, and exactly which A2A configurations are supported, against the official Agentforce release notes for your org before you build a production dependency on it. The interoperability story has been moving fast enough that any capability claim deserves a version check.

Two precision points that keep teams honest. First, you’ll see Salesforce framing around an Agent Card that carries a “Trust Score” or “compliance tags.” Those are Salesforce’s own trust concepts layered on top of A2A — they are not fields in the A2A Agent Card schema, so don’t design an integration expecting a third-party agent to emit them. Second, the claim that Salesforce originated the Agent Card is a marketing narrative; the Agent Card is defined in the open A2A spec. Build to the spec, and treat vendor-specific enrichments as vendor-specific.

The trust boundary you’re opening

Every security team asks the right question here: when my agent delegates to an agent I don’t own, what stops it going wrong? A2A gives you real primitives, and they map directly onto the least-privilege posture we argue for with any agent that touches untrusted surfaces.

Authentication is declared, not improvised. The Agent Card’s securitySchemes support API keys, HTTP Bearer, OAuth 2.0 (including client-credentials for service-to-service), OpenID Connect, and mutual TLS. Credentials travel in the HTTP Authorization header, out of band from the task payload — and the spec requires servers to scope task visibility to the authenticated client. For agent-to-agent service calls, prefer client-credentials or mTLS and scope the token to exactly the skills you’re invoking.
Signed Agent Cards let you verify who you’re talking to. A card can be signed (JWS), and clients should verify a signature before trusting it. Skip that and you’re trusting a JSON file served from a domain, which is a spoofing invitation.
Opaqueness cuts both ways. You’re delegating to an agent whose model, logic, and data handling you cannot inspect. Your audit trail and governance can only rely on what the Agent Card declares, what the task returns, and the authorization scope you granted. Treat every external agent as an untrusted principal with its own blast radius — the same fleet-governance discipline you’d apply internally, extended across an org boundary you don’t control. And because a remote agent’s response is untrusted content re-entering your agent’s reasoning, the prompt-injection surface now includes anything it can be manipulated to return.

Salesforce wraps its side of this in the Einstein Trust Layer, which is real protection for the Salesforce end of the boundary — but the Trust Layer stops at your edge. What the remote agent does with the task you hand it is governed by its operator, not by Salesforce.

The caveats worth knowing before you commit

A2A is young, and it shows in ways that matter for an enterprise dependency:

Version churn is real. The jump to 1.0 introduced breaking changes — RPC methods were renamed and a discriminator field was removed versus the 0.3.x line. Interop only works if both agents speak compatible versions, so pin and test the version your Agentforce agent and its counterparties actually use.
Discovery is not solved. A2A standardizes the Agent Card, not a trusted registry to find cards in. Naming, discovery, and resolution across organizations are open ecosystem gaps you’ll have to fill with your own configuration for now.
Delegation is a cost and latency multiplier. Every hop to an external agent adds a network round trip, its own reasoning time, and — if that agent bills per interaction — its own meter. A2A makes delegation easy; it doesn’t make it free.

What to actually do

A2A is the piece that turns “my agent is stuck inside Salesforce” into “my agent can hand work to any agent that speaks the standard.” That’s a real expansion of what an agent programme can reach — and, exactly like MCP, it’s an expansion of what an agent can reach too far. The same discipline applies: understand the three layers (MCP down to tools, A2A across to peers, Atlas within Agentforce), build to the open spec rather than one vendor’s enrichments of it, verify Agentforce’s current A2A support against your release notes before you depend on it, and treat every external agent as an untrusted principal — scoped token, verified card signature, minimal skills. Do that and you get genuine cross-vendor collaboration. Skip it and you’ve given an agent you can’t see a task it can’t be trusted with.

Understanding the basics

What’s the difference between A2A and MCP?

They solve different problems and compose together. MCP connects an agent to tools, APIs, and data — it’s how an agent uses a capability. A2A connects agents to each other as peers — it’s how one agent delegates work to another, potentially on a different platform run by a different company. A single A2A server agent might use MCP internally to reach the tools it needs while fulfilling a task delegated to it over A2A. Most real deployments use both.

Is Agentforce A2A support generally available?

Treat it as evolving. Salesforce has positioned A2A within the same Summer ‘26 wave as Atlas 3.0 and multi-agent orchestration, and frames Agentforce as able to both consume and expose agents over A2A. But the exact GA-versus-pilot status and which A2A configurations are supported have been moving, so confirm the current state against the official Agentforce release notes for your org before building a production dependency on it.

Is it safe to let my agent delegate to an external agent?

Only with the guardrails A2A gives you actually turned on. Authenticate with a scheme declared in the remote agent’s Agent Card (prefer OAuth client-credentials or mutual TLS for service-to-service), scope the credential to the minimum skills you need, and verify the card’s signature before trusting it. Remember that the remote agent is opaque — you can’t inspect its internals — so treat it as an untrusted principal, and treat anything it returns as untrusted content re-entering your agent’s reasoning. The Einstein Trust Layer protects the Salesforce side of the boundary, not the remote agent.

Trying to decide whether a capability belongs behind MCP, an internal Agentforce agent, or an external A2A delegation — and want the auth scope and trust boundary right before your agent talks to one you don’t own? Talk to us. Designing agents that collaborate without over-trusting is exactly the work we do.

A2A in Agentforce: letting your agent talk to agents you don't own