In A2A, what is an Agent Card and what does it let a calling agent do?

## Two planes, one system By 2026 the integration layer settled into two tiers, and interviewers expect you to name the split. The **tool plane** is how one agent reaches deterministic capabilities — files, databases, SaaS APIs — and a standard protocol exists for it. The **agent plane** is how one agent reaches *another agent*: an autonomous peer with its own model, its own context, its own opinions, and a job that may run for minutes. A2A is the protocol built for that second plane; ACP is a REST-native alternative for peers that expose plain HTTP and no streaming channel. The distinction matters because the two planes have different needs. A tool has a signature and returns a value. An agent has *capabilities* you must discover, a task lifecycle you must track, and a level of autonomy that means the answer may come back as a question. ## What the Agent Card carries The Agent Card is A2A's answer to "who are you and what can you do". A published card describes: - **Identity** — the agent's name, description and provider. - **Skills** — named capabilities with descriptions, and typically example inputs and the input/output content types they accept. This is written for a *model* to read as much as a developer: the description is what a calling agent reasons over when deciding whom to route to. - **Endpoint** — where to send work. - **Authentication** — which schemes the agent requires, so the caller knows what credential to present. - **Capabilities** — optional protocol features the agent supports, such as streaming status updates or push notifications to a webhook. - **Version information**, so a caller can reason about compatibility. The card is fetched over ordinary HTTP from a well-known location on the agent's host, which is what makes discovery work without a central registry — though registries and catalogs are commonly layered on top in enterprise deployments. ## Discovery in practice Consider a corporate procurement agent that must source a component it has never bought before. It has three candidate supplier agents, run by three different companies, built on three different frameworks. It fetches each Agent Card, reads the declared skills, and finds that two expose a `request_quote` skill while the third only exposes order tracking. It also reads each card's authentication requirement and confirms it holds a credential for two of them. It then opens a task with each of the two qualified peers and compares the results. Nothing in that flow required the procurement agent to know how a supplier agent is implemented. That is the entire point: A2A is an **opaque** protocol by design — peers exchange tasks and messages, not internal state, tools or memory. Neither side learns the other's prompts, model, or tool inventory, which is what makes it usable across organizational boundaries where those things are trade secrets. ## Why not just describe it as a tool? You can wrap a remote agent as a single function and call it. That works, and inside one codebase it is often the right call. It stops working well when: - The peer's capability set **changes without your redeploying** — a card is fetched at runtime, a hardcoded function signature is not. - The work is **long-running** — a function call has no vocabulary for "still working, 40% done, here is a partial artifact". - The peer may need to **ask you something** mid-task, rather than returning a value. - You must **choose among peers** you did not integrate individually. ## Trust, staleness and the limits An Agent Card is a self-description. It is a claim by the publisher, exactly like a service's own API documentation, and it carries the same risks: - **It can lie or overstate.** A skill description is prompt text your agent will read and act on, which makes a hostile card an injection surface. Treat fetched card content as untrusted input, not as instructions. - **It can be stale.** Cards are cached; a capability may have been withdrawn since you read it. Handle a call that fails because the skill no longer exists. - **It does not authorize you.** Discovery tells you an endpoint exists and what credential type it wants. Whether you may act, and on whose behalf, is an identity question settled by your credential and the peer's policy — the modern pattern being per-agent identity with delegated, on-behalf-of authorization so an agent's effective permission is the intersection of the user's rights and the agent's own allowed capabilities. - **It does not describe quality.** No card field tells you whether the supplier agent's quotes are accurate. That is an evaluation problem, not a discovery one. ## The honest framing Adoption of the agent plane is real but far from universal, and it is concentrated where it pays: crossing organizational or vendor boundaries. "A standard for tools, A2A for agents" is the stated default for cross-boundary enterprise deployments as of mid-2026. Inside a single codebase, discovery is a solved problem — you already know what your agents can do — and adopting a discovery protocol there buys ceremony rather than capability.