Agent-to-agent interop with A2A: Agent Cards, Tasks and production security

What A2A gives you

For two years the interesting problem in applied AI was getting a single agent to do useful work: give it good tools, a sensible prompt, some memory, and let it reason. That problem is far from solved, but the frontier has already moved. The systems being built now are not single agents — they are teams of them. A triage agent hands a refund case to a payments agent. A research agent delegates a data-extraction job to a specialist. A logistics agent asks a pricing agent for a quote. And here the old approach breaks down, because those agents were built by different teams, on different frameworks, sometimes by different companies entirely. There was no shared language for one agent to discover another, understand what it could do, and hand it a piece of work safely.

A2A — short for Agent2Agent — is the open protocol that fills that gap. It is a standard for interoperability between independent, opaque agents: opaque because you do not need to know how the remote agent is implemented, only what it advertises it can do. A2A reached v1.0 in 2026 and is hosted by the Linux Foundation, having been donated to the foundation in June 2025. Its backers are not a fringe collection — they include Google, Microsoft, Salesforce and ServiceNow, and there are production-ready SDKs across five languages. This is the article I wish I had when my own team first wired two agents together across a service boundary. It covers the three primitives you actually need to understand — Agent Cards, Tasks and JSON-RPC messaging — and then the part that most write-ups skip: how to run the thing in production without opening a hole in your estate.

If you are still choosing an agent framework underneath all this, our comparison of LangGraph vs CrewAI vs OpenAI Agents SDK is a useful companion — A2A sits above whatever you pick there, which is precisely the point.

The three primitives: Cards, Tasks and JSON-RPC

Almost everything in A2A reduces to three ideas working together. Learn these and the rest of the specification reads as detail rather than mystery.

The Agent Card is how agents are discovered. It is a JSON descriptor that a remote agent publishes to advertise four things: its identity, its capabilities and skills, its endpoint URL, and its authentication requirements. Before any work is exchanged, a calling agent fetches the card, reads what the remote agent offers and how to reach it, and decides whether to proceed. The card is a contract. Because it is rigid and declared up front, it enforces which capabilities exist and helps prevent the schema drift that quietly wrecks integrations where one side changes its shape and the other finds out in production.

The Task is how work is modelled. When one agent asks another to do something, that request does not vanish into a single request/response — it becomes a Task, a unit of work with a lifecycle and a state. The receiving agent moves the Task through defined states as it makes progress, which is what makes long-running, multi-step collaboration tractable. You can track a Task, reason about where it is, and — crucially for anything that takes more than a moment — follow it to completion rather than holding a connection open and hoping.

Underneath both sits JSON-RPC 2.0, the wire format over which messages are exchanged. This choice matters more than it looks. JSON-RPC payloads are rigid and structured; combined with the capabilities declared in the Agent Card, they leave little room for the free-form ambiguity that makes agent-to-agent calls fragile. The structure is a feature. It is what lets an agent written in Go accept a Task from an agent written in Python without either side having to trust the other's internal conventions.

Reading an Agent Card

The fastest way to make A2A concrete is to look at a card. Below is a trimmed Agent Card for a fictional invoice-reconciliation agent — the sort a Bengaluru fintech might expose so that its wider platform can delegate reconciliation work to it. Notice how it declares its skills, its endpoint, and — the part you must never treat as optional — how it expects to be authenticated.

{
  "name": "invoice-reconciler",
  "description": "Matches supplier invoices to purchase orders and flags exceptions.",
  "version": "1.4.0",
  "url": "https://agents.example.in/a2a/invoice-reconciler",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "defaultInputModes":  ["application/json", "text/plain"],
  "defaultOutputModes": ["application/json"],
  "securitySchemes": {
    "oauth2": {
      "type": "oauth2",
      "flows": {
        "clientCredentials": {
          "tokenUrl": "https://auth.example.in/oauth/token",
          "scopes": { "invoices:reconcile": "Run reconciliation tasks" }
        }
      }
    }
  },
  "security": [{ "oauth2": ["invoices:reconcile"] }],
  "skills": [
    {
      "id": "reconcile-batch",
      "name": "Reconcile invoice batch",
      "description": "Reconcile a batch of invoices against open purchase orders.",
      "tags": ["finance", "reconciliation"],
      "inputModes":  ["application/json"],
      "outputModes": ["application/json"]
    }
  ]
}

Everything a calling agent needs is here and nowhere else. It learns the endpoint (url), the concrete skill it can invoke (reconcile-batch), the content types the agent speaks, and — through securitySchemes and security — that it must present an OAuth 2.1 client-credentials token carrying the invoices:reconcile scope. A calling agent that cannot satisfy that requirement simply does not get to send work. The card has done its job before a single Task exists.

Sending a Task over JSON-RPC

Once a calling agent has read the card and obtained a token, sending work is a JSON-RPC call to the declared endpoint. The example below shows a client dispatching a Task, in the shape an A2A SDK produces for you. It is deliberately close to raw so you can see what actually crosses the wire.

// Client side — dispatch a Task to a remote A2A agent
const res = await fetch("https://agents.example.in/a2a/invoice-reconciler", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    // Short-lived, scoped token obtained via OAuth 2.1 client-credentials
    "Authorization": `Bearer ${accessToken}`
  },
  body: JSON.stringify({
    jsonrpc: "2.0",
    id: "req-8842",
    method: "message/send",
    params: {
      message: {
        role: "user",
        parts: [
          { kind: "text", text: "Reconcile the March supplier batch." },
          { kind: "data", data: { batchId: "MAR-2026-014" } }
        ]
      }
    }
  })
});

const { result } = await res.json();
// result.status.state moves through the Task lifecycle:
//   "submitted" -> "working" -> "completed" (or "failed" / "input-required")
console.log(result.id, result.status.state);

Three things are worth pausing on. The request is plain JSON-RPC 2.0 — a method, an id, and structured params — so any conformant agent on any stack can accept it. The response carries a Task with a status.state, which is your window into the lifecycle: you poll or subscribe to that state rather than assuming the work finished when the HTTP call returned. And the Authorization header is not decoration. Strip it out and, on a correctly configured agent, the Task never starts. The transport is doing real security work here, which brings us to the part you cannot skip.

Production security: transport first, then identity

An agent that accepts Tasks from other agents is, from a security point of view, a service that lets remote code trigger actions on your behalf. That framing should make you cautious, and A2A's own guidance is unambiguous about the baseline. Encrypted transport is not optional: use HTTPS for HTTP bindings and TLS for gRPC, with TLS 1.3 or later and strong cipher suites recommended. A plaintext A2A endpoint is a mistake in the same category as a plaintext login form — it exposes tokens, Task contents and results to anyone on the path.

But encryption on its own only protects the pipe; it says nothing about who is at the other end. That is the job of authentication, and the two must always be combined. Short-lived, scoped tokens are the direction of travel across the agent ecosystem, and OAuth 2.1 client-credentials flows are commonly used to issue them — the same model that MCP already mandates for remote servers. The pattern is worth stating plainly: a calling agent authenticates to a token endpoint, receives a short-lived token scoped to exactly the capability it needs, and presents that token on every Task it sends. The receiving agent validates the token and the scope before it does any work.

A concrete way to keep these honest across a dual-market estate: a Bengaluru fintech serving Indian customers and a London logistics firm serving UK ones will typically run their agents in separate regions — an AWS Mumbai or London region respectively — for latency and data-residency reasons. Keep the token issuer regional too, scope tokens narrowly, and never let a token minted for one capability be reused for another. The Agent Card tells every caller which scope a skill needs; your job is to enforce that the presented token actually carries it.

There is a further habit worth building in from the start: log every Task at the boundary. Because a Task has an identity and a lifecycle, you can record who called, which skill they invoked, which scope their token carried, and how the Task terminated. That audit trail is not busywork — it is what turns a multi-agent system from an opaque tangle into something you can debug and, when a regulator or a customer asks, actually account for. In a dual-market setup it also lets you keep the Indian and UK records where they belong, which matters as much for the London logistics firm under UK data rules as it does for the Bengaluru fintech under Indian ones.

A2A and MCP are complementary, not rivals

The question I am asked most is whether A2A replaces MCP, or the other way around. It does neither, and getting this straight saves a lot of wasted architecture debate. The two protocols solve different problems along different axes. MCP — the Model Context Protocol — is vertical: it connects a single agent to the tools and data it needs, so one agent can call a database, a search index or an internal API. A2A is horizontal: it connects agents to each other, so one agent can delegate a whole task to another. They are complementary standards, and a serious multi-agent system usually runs both at once — MCP so each agent can reach its own tools, A2A so those agents can collaborate.

It helps to picture a single flow. A London logistics firm's triage agent receives a delivery-exception query. Over MCP it reaches its own tracking database to pull the shipment record. Then, over A2A, it hands a Task to a specialist pricing agent — possibly run by a different team on a different framework — to compute a goodwill refund. That pricing agent, in turn, uses its own MCP tools to check pricing rules. Two protocols, each doing the job it was designed for, with no overlap and no competition.

AGNTCY is a further open interoperability effort in the same neighbourhood, and it is best understood the same way — as another complementary standard rather than a competitor to be chosen against. We covered its emergence separately in our piece on AGNTCY, the open agent-interoperability standard, and the broader jostling among vendors in the agent SDK wars between OpenAI, Google and Anthropic. The healthy way to read all of this is that the industry is converging on shared plumbing, not fragmenting into walled gardens.

The SDK ecosystem and where to start

You do not hand-roll JSON-RPC envelopes in practice. A2A ships production-ready SDKs in five languages — Python, JavaScript/TypeScript, Java, Go and .NET — and they are explicitly designed to interoperate across multi-agent frameworks, which is the whole reason the protocol exists. A Python agent built on one framework and a .NET agent built on another can exchange Tasks precisely because both speak the same wire protocol underneath their respective SDKs.

If you are starting out, resist the temptation to expose everything at once. Model a single, well-scoped skill as an Agent Card, put it behind HTTPS with OAuth 2.1, and have one client agent discover and call it. Get the Task lifecycle working end to end — submitted, working, completed — before you add streaming, push notifications or a second skill. The discipline that pays off most is on the boundary between agents: design the skills you expose the way you would design any external API, because to the agents calling you, that is exactly what they are. Our guide to designing tools for AI agents — schemas, errors and retries applies directly to the shape of the skills you put in your card.

The strategic reason to invest now is that the interoperability layer is settling. A protocol at v1.0 under the Linux Foundation, backed by Google, Microsoft, Salesforce and ServiceNow, with five language SDKs, is not a research curiosity — it is infrastructure. The teams that learn to expose and consume agents cleanly today are the ones that will slot into the multi-agent systems everyone else is only beginning to sketch. The full specification is worth reading once end to end — it is published openly at a2a-protocol.org, and the original context is set out in Google's A2A announcement and the governance handover to the Linux Foundation.

A word on sequencing for teams that already run agents in production today. You do not need to rewrite anything to adopt A2A. Because the protocol treats every agent as opaque, you can wrap an existing agent — whatever framework it was built on — behind an Agent Card and a JSON-RPC endpoint, and it becomes reachable by the rest of the mesh without its internals changing. That is the pragmatic on-ramp: expose your most-requested capability as a single skill, secure it properly, and let one partner agent call it. Only once that loop is proven do you widen the surface. Treating adoption as an additive layer rather than a migration is what keeps it low-risk, and it is why a small team in Bengaluru or London can join a much larger multi-agent system without betting the roadmap on it.

Putting it together

A2A is smaller than it first appears, and that is its strength. Three primitives carry the weight: an Agent Card advertises identity, skills, endpoint and auth; a Task models the work as something with a lifecycle you can track; and JSON-RPC 2.0 keeps the wire rigid enough that agents on different stacks can trust each other's messages. Wrap all of it in encrypted transport — HTTPS or TLS, 1.3 or later — and flow short-lived, scoped OAuth 2.1 tokens through it so identity is never in doubt. Remember that A2A and MCP are partners, not rivals: MCP for an agent's own tools, A2A for agents talking to each other. Whether you are a Bengaluru fintech exposing a reconciliation skill or a London logistics firm delegating pricing work, the same recipe holds. Start with one skill, one card, one authenticated caller, and grow the mesh from something you can actually secure. Do that, and your agents will be ready for the multi-agent world that is already arriving.