There's a small JSON file sitting at /.well-known/agent.json that most teams fill out once and never revisit. That file is the Agent Card - the discovery mechanism at the center of Google's Agent2Agent (A2A) protocol - and how carefully you maintain it will determine whether your multi-agent system coordinates cleanly or silently misdirects work.
A2A is an open specification that defines how autonomous AI agents from different vendors and frameworks can discover each other, delegate tasks, and coordinate work. The protocol runs over HTTP, Server-Sent Events, and JSON-RPC 2.0 for transport, with Agent Cards handling capability advertisement. None of that transport machinery is especially novel. What's new is the contract it assumes you're keeping.
What the card actually contains
The Agent Card is a JSON file accessible via URL. It contains basic information about an agent: its name, description, version, service endpoint URL, supported modalities or data types, and authentication requirements. It also advertises the agent's capabilities and supported communication modes.
The analogy that keeps appearing in the documentation is a business card or a LinkedIn profile. That framing undersells the stakes. A business card going stale means someone can't reach you. An Agent Card going stale means a coordinating agent routes a task to a sub-agent that can no longer handle it - and, depending on how your error handling is built, may do so silently.
Agent Cards enable dynamic discovery: a planning agent can query an Agent Card registry to find a capable sub-agent without hardcoded knowledge of available agents. That's the upside. The downside is the same thing said in reverse: the planning agent has nothing to go on except what the card claims.
The input-required state changes the shape of errors
One thing the A2A task lifecycle gets right that naive agent-to-agent wiring usually doesn't: it has a named state for "I need more information before I can continue."
Unlike MCP tools, which have schema-defined inputs and outputs, A2A agents are black boxes - you describe what you need in natural language and they decide how to accomplish it. The input-required state enables agents to ask clarifying questions mid-task, unlike simple request-response patterns.
A task created via message/send does not always proceed directly to completion: the remote agent may reject the request (for example, unsupported operation or insufficient permissions), or suspend execution by transitioning into an input-required state when additional data is needed - such as a change ticket ID, confirmation, or extra logs - before it can continue.
This matters because the failure mode in most bespoke multi-agent glue code is a timeout or a hallucinated response, not a structured pause. The task lifecycle - submitted → working → input-required → completed - gives you something to instrument. But only if your Agent Card accurately describes what the agent actually needs, so the coordinator knows what to send in the first place.
The Agent Card is where your coordination assumptions live. If it's wrong, the protocol can't save you.
The opaqueness is a feature, until it isn't
From the client agent's perspective, the remote agent operates as an "opaque" system - the client interacts without needing to know its internal workings, memory, or tools. That opacity is deliberate. Modern agents are often opaque - you may not know what model, tooling, or internal logic they use - making direct integration risky and expensive. A2A standardizes the "agent communication contract" so organizations can safely combine specialist agents across teams and vendors.
The catch is that opacity puts all the legible information into the card itself. If the card claims an agent handles contract review but the underlying model was swapped for a cheaper one that skips legal citation, the coordinating agent has no way to detect the regression. The card said it could; it said it did. Done.
This is why the security analysis from Palo Alto Networks flags Agent Card poisoning as a real threat class: issues stemming from poor version control, delayed updates, weak authentication, and exposure of sensitive metadata. Malicious content embedded in agent cards can potentially compromise downstream agents if input validation is insufficient.
The non-malicious version of this problem - an honest but stale card - is probably more common and harder to detect.
What changed when IBM's ACP merged in
In late 2025, IBM's Agent Communication Protocol merged with A2A under the Linux Foundation. The merger preserved ACP's RESTful simplicity while incorporating A2A's enterprise-grade features like Agent Cards and task lifecycle management. The practical upshot: if you're evaluating protocols today, you're really choosing between MCP for tools and context, and the unified A2A for agent collaboration.
April 2026 also brought v1.0 stable, signed Agent Cards, the new Agent Payments Protocol (AP2), and GA support inside Microsoft Copilot Studio, Azure AI Foundry, and Amazon Bedrock AgentCore. Signed Agent Cards are the detail worth noting here - a cryptographic signature on the card means a coordinating agent can verify that the capabilities being advertised were attested by a known issuer, not injected or forged. That closes the poisoning vector, assuming your signing infrastructure is sound.
The practical discipline
The teams that will get the most out of A2A aren't the ones with the most sophisticated orchestrators. They're the ones that treat the Agent Card as a versioned artifact with an owner:
- Version it alongside the agent code it describes. A card that claims
v2.1capabilities while the endpoint runsv1.8logic is a coordination bug waiting to surface. - Test it. Write a fixture that parses the card and asserts the endpoint actually accepts the modalities and auth schemes it advertises. Run it in CI.
- Own it. Someone on the team is responsible for the agent's behavior; that person is also responsible for the card. Treat a stale card as a bug, not a configuration detail.
A teammate like Beagle, working inside Slack or Teams, runs into this class of problem often: it needs to understand what a downstream agent or integration can actually do, not just what someone once wrote that it could do. The card is the handshake. Make it honest.
The A2A specification and the a2aproject GitHub repository are the right primary sources if you're implementing. The spec is readable; the task lifecycle section in particular is worth an hour of your time before you write any coordination logic.