← Library

What Is A2A?

Soon, the AI agent you use will need to hand work to an agent it has never met, built by a company it has never heard of, running on infrastructure nobody at your company controls. A2A is the emerging answer for how that exchange actually happens: how the two agents find each other, learn what the other can do, and coordinate a piece of work without either one seeing the other's internals.

Picture a near future where your AI assistant needs to book a trip and negotiate directly with an airline's own booking agent. Or a procurement agent that asks a supplier's agent for availability and a quote, and keeps the request open while the supplier's agent asks back for a missing specification. In both cases, the agent doing part of the work isn't one you built, and it isn't one the company you're using built either. It's a third party, with its own owner, its own rules, and no existing relationship to lean on.

Until recently, there was no standard way to make that happen. Every such connection was a custom integration: someone had to read the other side's documentation, write an adapter, and maintain it by hand, and the moment either side changed anything, the adapter broke. That's a fine way to connect two systems you both control. It falls apart the moment "the other system" could be any of thousands of independently built agents you'll never personally look at the code for.

What A2A actually is

Agent2Agent, or A2A, is a protocol built to solve exactly that problem: a common way for one agent to discover another's capabilities, learn how to authenticate to it, and coordinate a piece of work without needing access to its internal implementation. It's worth being precise about the sibling standard you may already have heard of: MCP standardizes how a single agent uses tools, APIs, and data sources. A2A standardizes how independently operated agents collaborate as peers. An A2A agent can, and often does, use MCP tools internally to get the task done; the two solve different halves of the same problem.

Two pieces make A2A work, and both are worth seeing in something closer to their real shape than a summary can give you.

The first is an Agent Card: a public document, conventionally reachable at a well-known web address, that tells a stranger what an agent is, what it can do, and how to authenticate to it. A simplified one looks roughly like this:

Agent Card (illustrative, A2A 1.0 shape)

{
  "name": "Support Analyst",
  "description": "Triages production issues and Sentry incidents.",
  "version": "1.0.0",
  "supportedInterfaces": [
    { "url": "https://thinqos.com/a2a/support-analyst", "protocolBinding": "JSONRPC" }
  ],
  "capabilities": { "streaming": true },
  "securitySchemes": {
    "thinqos": { "openIdConnectSecurityScheme": { "openIdConnectUrl": "https://auth.thinqos.com/.well-known/openid-configuration" } }
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain", "application/json"],
  "skills": [
    { "id": "triage-issue", "name": "Production incident triage", "description": "Investigates and summarizes a production incident.", "tags": ["support", "incident-triage"] }
  ]
}

That's a capability and connection manifest, not a complete API schema. It tells a caller where the agent can be reached, which protocol version and content types it supports, what skills it advertises, and what authentication it requires before a request is even sent. It does not, by itself, give the caller a full typed contract for every skill.

The second piece is a task. One agent hands another a task by sending a message, and both sides track its progress through a shared set of states. A request to start one, in the shape the protocol's JSON-RPC binding uses, looks like this:

Request: hand off a task

POST /a2a/support-analyst HTTP/1.1
A2A-Version: 1.0
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": "1",
  "method": "SendMessage",
  "params": {
    "message": {
      "role": "ROLE_USER",
      "parts": [{ "text": "Triage THINQOS-BACKEND-3D. It is a recurring idle-in-transaction cluster." }],
      "messageId": "msg-1"
    }
  }
}

The response contains either a direct message, when the agent can just answer, or a task, when the work is stateful or long-running. A task carries an id, a status, a history, and any artifacts it has produced so far. That status is the part worth paying attention to: submitted, working, and eventually completed, failed, rejected, or canceled, plus two states that pause a task rather than end it. input-required means the agent needs more information before it can continue. auth-required means it needs an authorization or credential it doesn't yet have. Neither is a failure. Both preserve the task exactly where it stopped, so it can resume the moment the missing piece arrives.

Because A2A is asynchronous by design, that resumption doesn't depend on holding one connection open. Continuity is carried by the task's id and its conversational context, and the next update can arrive through a streaming connection, a later poll, a push notification, or simply another message in a later request. A2A supports a genuine back-and-forth under the same task and context, even when the transport underneath is disconnected the whole time.

One thing worth being precise about, because it's easy to read into the protocol more than it promises: A2A standardizes the exchange. It does not, by itself, decide whether an unfamiliar agent should be trusted, what it's allowed to see, whose authority it's acting under, or whether its results are reliable. An Agent Card can advertise an authentication scheme, and the protocol expects every request to be authenticated, but identity and authorization are handled by ordinary web-security mechanisms outside A2A's own semantics. Those remain the platform's job, not the protocol's.

Where it came from, and where it's going

Google opened A2A up in 2025, with input from more than fifty industry partners, and transferred it to the Linux Foundation the same year for neutral, vendor-independent governance. It reached version 1.0 in 2026 and now counts more than 150 supporting organizations, including AWS, Microsoft, Salesforce, and SAP, with production deployments already running. It's no longer a research proposal or one vendor's integration format. It has neutral governance, broad platform support, and early production use behind it. Whether it becomes the enduring interoperability layer for agents, the way HTTP did for web pages, isn't settled yet. But it now has a credible path to becoming exactly that.

What that means practically, for anyone using AI products over the next few years, is that "which agent is actually doing this work" starts to matter less than "can I trust it and can it get the job done," because the connection itself stops being the hard part. The interesting agents won't all be built by one company. A2A is the reason that can work anyway, and it's also exactly why the trust question above doesn't go away. It just moves to the platform.

How thinqOS applies it

What exists in thinqOS today is native agent collaboration: agents share rooms with each other and with you directly, and they delegate work to each other in the background through a durable work contract, an objective and a definition of done broken into obligations, each with its own status, tracked by a coordinating agent to completion. That machinery already runs our own agent-to-agent delegation. None of it is A2A, and none of it needs to be, because none of it crosses the boundary A2A exists for. It's agents that already share an identity graph, a connection, and an audit trail.

What A2A adds is the boundary: the piece that lets work cross between thinqOS and an agent it doesn't already know, in both directions.

Both directions matter, and it's worth being explicit that it's both. A thinqOS agent can be reached by an outside agent: it publishes an Agent Card, accepts tasks, and answers them. And a thinqOS agent can reach out, discovering an external agent from its card and handing it a piece of work mid-conversation, the same way it would ask a colleague. Support that only went one way would mean our agents could be hired but could never hire, which isn't interoperability so much as a storefront.

Reachability is opt-in, per agent. An agent is not on the public A2A surface until someone deliberately puts it there, and the default for every agent ever created is off. That's a deliberate choice rather than caution for its own sake: most agents on the platform are somebody's private assistant, and by default a thinqOS agent's turns are billed to its owner. An always-on surface would mean a stranger could both reach an agent that was never meant to be public and spend its owner's money doing it. An agent that hasn't opted in doesn't return "forbidden" either, because that would confirm it exists. It returns the same "no such agent" a made-up address would.

The translation underneath is simpler than the internal delegation machinery, for an instructive reason. Work contracts model a coordinator handing pieces of a job to several other agents, and they run inside an agent's own turn. One outside caller asking one agent one question isn't that shape. It's a single unit of work, requested from outside, run in the background, collected when it's done, which is something thinqOS already does. An A2A task is that unit of work, and the state mapping falls out of it.

A2A task state, and what it means underneath

A2A task state	thinqOS
submitted	The work is queued. Nothing runs until the caller has been authenticated and checked against the agent's own access rules.
working	The agent is running the task.
completed	Finished. The agent's answer comes back as the task's artifact.
rejected	Declined before it ran, because a policy check refused it. Deliberately distinct from having tried and failed.
failed	Ran and did not finish, including timing out.
canceled	Canceled by the caller.

One state in A2A's vocabulary is missing from that table, and the omission is the honest part. input-required, the state that lets an agent pause a task to ask a clarifying question and then resume it, has no counterpart in thinqOS today. A task here either finishes or it doesn't; there's no state that stops halfway and waits for the caller to say more. So the multi-turn exchange the protocol allows is something this boundary doesn't support yet. Single request, single answer, works. Genuine back-and-forth needs a resumable task, and that's real work we haven't done rather than a detail we forgot.

An external caller only ever talks to this adapter. It never reaches thinqOS's internal tools directly, so nothing an outside party sends can forge who's acting or skip a permission check that would otherwise apply. Tasks are scoped to the caller who created them: a second caller holding another's task id is told the task doesn't exist, rather than being handed someone else's work. And what thinqOS commits to is deliberately testable: publish the A2A interfaces and versions the adapter supports, starting with 1.0, and negotiate that explicitly with every caller rather than assuming every peer runs the same release.

Why it matters

Strip away the wire format and the state machine, and A2A comes down to one idea: the agent that ends up doing your work doesn't have to be one company's product anymore. It can be the best specialist for the job, wherever that specialist happens to live, because the connection between it and everything else follows a standard both sides already understand. That's a genuine shift. It's the difference between an ecosystem of agents that can only ever talk to their own kind and one where capability, not vendor, decides who does the work.

But A2A only ever settles the exchange, not the trust behind it, which gives you a real question to ask of any AI platform, not just thinqOS: how does it treat an agent it's meeting for the first time as a new principal? How is it authenticated, which identity is it acting for, what can it actually see, and how are its results attributed and reviewed? A2A provides the common language for that conversation to happen at all. The platform on the other end still has to enforce everything that makes it safe.

That's the whole shape of it: a common language for agents that don't know each other yet, and a boundary, drawn by the platform rather than the protocol, that decides who gets to cross it. thinqOS is building that boundary deliberately, at the exact place its own agents stop already knowing each other, and saying plainly which parts of the protocol it does and does not yet speak.

Part of the thinqOS science series.