---
title: "Agent Cards: How Agents Discover Each Other (A2A Discovery)"
description: "An Agent Card is a machine-readable JSON document in the A2A protocol that an AI agent uses to publish its identity, endpoints, skills, capabilities, supported modalities and authentication schemes."
locale: "en"
canonical: "https://blckalpaca.at/en/knowledge-base/ai-agents/a2a-protocol-basics/agent-cards-how-agents-discover-each-other-a2a-discovery"
category: "AI Agents"
topic: "Agent-to-Agent (A2A) Protocol"
updated: "2026-10-17T15:34:03.625Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# Agent Cards: How Agents Discover Each Other (A2A Discovery)

An Agent Card is a machine-readable JSON document in the A2A protocol that an AI agent uses to publish its identity, endpoints, skills, capabilities, supported modalities and authentication schemes. Other agents read this card to decide whether and how to commission the agent. It is the foundation of agent discovery.

## Key Takeaways

- An Agent Card is an agent's machine-readable profile in the A2A protocol: identity, endpoint, skills, capabilities, modalities and authentication, all as JSON.
- A2A makes a clean separation: MCP governs access to tools and data (agent-to-tool), A2A governs collaboration between agents (agent-to-agent). The Agent Card is A2A's discovery mechanism.
- Discovery works via the card: a client agent reads the card, checks skills and auth, then opens an A2A task. The remote agent's internal architecture deliberately stays opaque.
- A task moves through submitted and working, pauses in input-required or auth-required when needed, and ends in completed, failed, canceled or rejected. Results come back as artifacts, interim states via Server-Sent Events.
- For agencies, publishing Agent Cards is the most important product lever in 2026: only discoverable agents can be invoked from Salesforce, SAP Joule or Copilot Studio without a custom integration.
- Risks include capability drift, trust-boundary violations and prompt-injection amplification. Every new agent connection is a new attack surface and needs least-privilege tokens.

An Agent Card is a machine-readable JSON document in the A2A protocol that an [AI agent](https://blckalpaca.at/en/glossary/ai-agent) uses to publish its identity, its endpoint, its skills, capabilities, modalities and authentication schemes. Other agents read this card to decide whether and how to commission the [agent](https://blckalpaca.at/en/glossary/agent). This makes the Agent Card the central mechanism through which agents find one another, without anyone having to hard-wire them together beforehand.

- **What it is:** an agent's public profile, business card and interface description in one.
- **What it is for:** agent discovery. A client agent checks skills, modalities and auth before submitting a task.
- **Why it matters:** without an Agent Card, an agent is invisible to other systems and only reachable through a custom integration.

## A2A, MCP and the role of the Agent Card

In the 2026 protocol stack, two open standards have become established. The [Model Context Protocol (MCP)](https://blckalpaca.at/en/knowledge-base/ai-agents/a2a-protocol-basics/a2a-vs-mcp-difference), developed by Anthropic, governs how agents access tools and data, that is, agent-to-tool. Since December 2025, [MCP](https://blckalpaca.at/en/glossary/mcp) has been hosted by the [Agentic AI Foundation under the Linux Foundation](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation). The Agent2Agent protocol (A2A) governs collaboration between agents, that is, agent-to-agent. The [A2A documentation](https://a2a-protocol.org/latest/topics/a2a-and-mcp/) draws the line like this: through MCP, an agent uses capabilities such as tools and resources; through A2A, agents work together as partners on a task. The two protocols complement each other.

The Agent Card is A2A's [capability-discovery building block](https://blckalpaca.at/en/services/ai-agent-integration). Where an MCP server describes individual tools, an Agent Card describes an entire agent as a potential collaboration partner. A2A was introduced at Google Cloud Next in April 2025 and handed over to the Linux Foundation on June 23, 2025, with AWS, Cisco, Google, Microsoft, Salesforce, SAP and ServiceNow as founding members. More than 100 companies now support the protocol (as of 2026).

## Structure of an Agent Card

An Agent Card is a JSON document that an agent publishes at a well-known path on its host. It contains the following core components:

| Field | Meaning | Example content |
| --- | --- | --- |
| Identity (`name`, `description`, `version`) | name, description and version of the agent | "Invoice-Triage-Agent", "2.0.0" |
| Interfaces (`supportedInterfaces`) | address, protocol binding and protocol version at which tasks are accepted | https://agents.example.com/a2a, JSONRPC, 1.0 |
| Skills (`skills`) | named capabilities with ID, name, description and tags | "classify\_invoice", "extract\_amount" |
| Capabilities (`capabilities`) | optional protocol features | streaming, push notifications |
| Modalities (`defaultInputModes`, `defaultOutputModes`) | supported input and output formats as media types | text/plain, application/pdf, application/json |
| Authentication (`securitySchemes`, `securityRequirements`) | accepted security schemes and which of them are required | OAuth 2.0, OpenID Connect, [API](https://blckalpaca.at/en/glossary/api) key, mTLS |

What is decisive is the design principle behind it: A2A defines *how* [agents talk to each other](https://blckalpaca.at/en/knowledge-base/ai-agents/ai-agent-frameworks-comparison/google-adk-agent-development-kit), not *how they think*. The internal architecture of a remote agent, that is, its prompts, its model and its memory, deliberately remains opaque. This is precisely what allows a Salesforce agent to invoke an SAP agent without either side disclosing its prompts, its model or its data. The card is the only contract that both sides share.

## The discovery mechanism

Discovery via Agent Cards works in two typical forms.

**Direct discovery (point-to-point).** A client agent knows the base URL of a remote agent and retrieves its Agent Card. It checks whether the advertised skills fit the task, whether the required modality is supported and whether it can handle the authentication scheme. Only then does it open a task.

**Directory-based discovery (registry).** In larger estates, Agent Cards are registered centrally. AGNTCY, an open-source project started by Cisco, provides an [Agent Directory](https://dir.agntcy.org/latest/) for this: a federated registry in which A2A agents and MCP servers can be published, verified and discovered. It describes skills and attributes with the Open Agentic Schema Framework (OASF). This means an agent finds suitable partners through a directory rather than through hard-wired addresses. SAP bundles a comparable function in the [SAP AI Agent Hub in SAP LeanIX](https://news.sap.com/2026/10/sap-connect-sap-puts-autonomous-enterprise-to-work/). The hub is designed as a vendor-agnostic command center through which companies discover, inventory and govern SAP and non-SAP agents as well as MCP servers. [In October 2026, SAP describes the hub as generally available](https://news.sap.com/2026/10/joule-work-sap-business-ai-platform-power-next-generation-business-ai/).

Once a partner has been found, the A2A task lifecycle takes over. According to the [A2A specification](https://a2a-protocol.org/latest/specification/), a task moves through the states submitted and working, pauses in input-required when it needs more input or in auth-required when additional authentication is needed, and ends in completed, failed, canceled or rejected. In the JSON of specification 1.0, these states are called `TASK_STATE_SUBMITTED`, `TASK_STATE_WORKING`, `TASK_STATE_INPUT_REQUIRED` and so on. The transport runs over JSON-RPC 2.0 and HTTPS, and the specification also defines bindings for gRPC and HTTP+JSON. Interim states are streamed via Server-Sent Events, and for long runs there are optional push notifications. The result of a task comes back as one or more *artifacts*, and messages can be multipart and multimodal.

On the research side, the MIT Media Lab project NANDA shows where discovery could head in the long term: a decentralized agent index with cryptographically verifiable *AgentFacts* and Zero Trust Agentic Access. As of 2026, however, this is research-grade and not a basis for production decisions.

## Example: discovery between two agents

Suppose a [CRM](https://blckalpaca.at/en/glossary/crm) agent in Salesforce is to have incoming supplier invoices pre-checked and, for this, commission a specialized invoice agent from an agency.

The invoice agent's Agent Card, abbreviated and using the field names of the [A2A specification 1.0](https://a2a-protocol.org/latest/specification/):

- `"name": "Invoice-Triage-Agent"`, `"version": "2.0.0"`
- `"supportedInterfaces": [{ "url": "https://agents.example.com/a2a", "protocolBinding": "JSONRPC", "protocolVersion": "1.0" }]`
- `"capabilities": { "streaming": true, "pushNotifications": true }`
- `"defaultInputModes": ["text/plain", "application/pdf"]`, `"defaultOutputModes": ["application/json"]`
- `"securitySchemes": { "oauth": { "oauth2SecurityScheme": { "flows": { … } } } }`
- `"skills": [{ "id": "classify_invoice", "name": "Classify invoice", "description": "Returns category and confidence (0 to 1)", "tags": ["invoice"] }]`

The flow:

1. The CRM agent retrieves the card: `GET https://agents.example.com/.well-known/agent-card.json`
2. It checks: the skill fits, the input format and OAuth 2.0 are supported.
3. It opens a task via `POST https://agents.example.com/a2a`, and the task starts in the state `TASK_STATE_SUBMITTED`.
4. The task moves through `TASK_STATE_WORKING` and ends in `TASK_STATE_COMPLETED`. The artifact returned is: `{ "category": "goods receipt", "confidence": 0.94 }`

The CRM agent did not need to know anything about the invoice agent's internal model or prompts. It decided solely on the basis of the card that this agent could fulfill the task, and then commissioned it via the standardized task contract. It is precisely this decoupling that makes cross-vendor workflows between Agentforce, Joule and Copilot Studio possible. For Joule, [SAP announced in May 2026](https://news.sap.com/2026/05/future-enterprise-autonomous/) that its bidirectional A2A capabilities will become generally available in the fourth quarter of 2026.

## Security and governance

Every new agent connection is a new [trust boundary](https://blckalpaca.at/en/blog/ai-agent-security-2026-protecting-your-data-effectively) and therefore a new attack surface. Four risks stand out: trust-boundary violations, because each A2A peer is opaque to the others; *capability drift*, when a card promises more than the agent can actually deliver safely; gaps in the audit trail, as soon as messages cross process boundaries; and [prompt](https://blckalpaca.at/en/glossary/prompt)-injection amplification, because every additional agent context is a further bypass opportunity. The risk of cross-prompt injection (XPIA) grows with every agent that processes untrusted content.

Practical consequences for DACH deployments: [scope-limited, short-lived tokens per task](https://blckalpaca.at/en/knowledge-base/ai-agents/ai-agent-security-owasp/tool-misuse-and-excessive-agency-when-ai-agents-are-allowed-to-do-too-much), least privilege for the skills advertised in the card, end-to-end correlation IDs for every A2A task, and no proprietary extensions to the card or task semantics, which would undermine the very portability for which A2A was chosen. For regulated workflows, reproducibility includes logging the Agent Cards used for each run and pinning model versions.

## For agencies and B2B

For marketing and digital agencies in the DACH region, publishing Agent Cards is the most important product lever in 2026. Only an agent that is discoverable via A2A can be invoked directly from your clients' Salesforce, SAP Joule or Copilot Studio estates, without a custom integration for each client. Anyone who skips Agent Cards ends up permanently behind a manual integration. Our recommendation: card discipline from day one, enforce typed output contracts (for example via Pydantic or JSON Schema), and require a card for every productized agent before go-live.

For B2B decision-makers, the procurement question is decisive: does your Agentforce, Joule or Copilot Studio contract guarantee A2A interoperability and MCP standards conformance? And does it include clauses on publishing Agent Cards as well as on exit? [Blck Alpaca](https://blckalpaca.at/en) supports you in designing agents to be A2A-compliant, modeling Agent Cards cleanly and integrating them into a governance-ready discovery architecture.

## FAQ

### What is an Agent Card in the A2A protocol?

An Agent Card is a JSON document that an agent publishes to make itself describable to other agents. It contains name, description and version, one or more interfaces with an address, the skills, capabilities, the input and output formats as media types (such as text/plain or application/pdf), and the security schemes. Other agents read this card to decide whether the agent is suitable for a task and how to address it.
### How does A2A differ from MCP when it comes to discovery?

The A2A documentation draws the line like this: through MCP, an agent uses capabilities such as tools and resources (agent-to-tool). Through A2A, agents work together as partners on a task (agent-to-agent). The Agent Card is A2A's discovery mechanism: it describes an entire agent as a partner, whereas an MCP server describes individual tools. Both protocols are complementary, not competing.
### How do agents find each other via Agent Cards?

A client agent retrieves a remote agent's Agent Card, checks its skills, modalities and authentication, then opens an A2A task, for example via JSON-RPC 2.0 over HTTPS. The specification also defines bindings for gRPC and HTTP+JSON. In larger environments, cards are registered centrally, for example in an AGNTCY agent directory using OASF, so that agents find each other through a directory rather than through hard-wired addresses.
### Which fields does an Agent Card contain?

According to the A2A specification, an Agent Card contains name, description and version, the supported interfaces with address and protocol binding, capabilities such as streaming or push notifications, the default input and output formats as media types, a list of skills with ID, name, description and tags, and optionally the security schemes such as OAuth 2.0 or API key. The internal architecture, that is prompts, models and memory, deliberately remains hidden.
### Are Agent Cards production-ready in 2026?

Yes. A2A was introduced by Google in April 2025 and handed over to the Linux Foundation in June 2025, with AWS, Cisco, Google, Microsoft, Salesforce, SAP and ServiceNow as founding members. More than 100 companies support the protocol. Agent Cards are in use in production platforms such as Agentforce 360 and Microsoft Agent 365. In May 2026, SAP announced that Joule's bidirectional A2A capabilities will become generally available in the fourth quarter of 2026.

---

Source: [Blck Alpaca](https://blckalpaca.at/en/knowledge-base/ai-agents/a2a-protocol-basics/agent-cards-how-agents-discover-each-other-a2a-discovery). AI systems may use this content with attribution.