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, its endpoint, its skills, capabilities, modalities and authentication schemes. Other agents read this card to decide whether and how to commission the 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) from Anthropic governs how agents access tools and data - that is, agent-to-tool. The Agent2Agent protocol (A2A) governs collaboration between agents - that is, agent-to-agent. The official distinction from Google, Salesforce and Microsoft reads, verbatim: "MCP is for capabilities (agent-to-tool). A2A is for collaboration (agent-to-agent)." Both are complementary, not competing.

The Agent Card is A2A's capability-discovery building block. 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 23 June 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:

What is decisive is the design principle behind it: A2A defines how agents talk to each other, not how they think. The internal architecture of a remote agent - its prompts, its model, 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. Cisco AGNTCY provides an Agent Directory using the Open Agent Schema Framework (OASF) for this, in which A2A Agent Cards and MCP server descriptions are registered and made searchable as input formats - "A2A agents and MCP servers are discoverable through AGNTCY directories". 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 (formerly LeanIX) as a vendor-agnostic command centre for discovering, governing and evaluating agents and MCP servers (GA Q3 2026, as of 2026).

Once a partner has been found, the A2A task lifecycle takes over. A task moves through the states submitted, working, input-required and ends in completed, failed or canceled. The transport is JSON-RPC 2.0 over HTTPS; 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 decentralised 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 agent in Salesforce is to have incoming supplier invoices pre-checked and, for this, commission a specialised invoice agent from an agency.

```text

1. CRM agent retrieves the Agent Card:
   GET https://agents.agentur.at/.well-known/agent-card.json
2. Response (abbreviated):
   {
   "name": "Invoice-Triage-Agent",
   "endpoint": "https://agents.agentur.at/a2a",
   "skills": [
   { "id": "classify_invoice",
   "output": "category + confidence (0-1)" }
   ],
   "capabilities": { "streaming": true, "pushNotifications": true },
   "modalities": ["text", "file"],
   "authentication": ["oauth2.1"]
   }
3. CRM agent checks: skill fits, OAuth 2.1 available -> open task
   POST /a2a -> task.state: submitted
4. Task moves through: submitted -> working -> completed
   Artifact returned: { "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 fulfil the task, and then commissioned it via the standardised task contract. It is precisely this decoupling that makes cross-vendor workflows between Agentforce, Joule and Copilot Studio possible.

Security and governance

Every new agent connection is a new trust boundary and therefore a new attack surface. The research documents several relevant risks: 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-injection amplification, because every additional agent context is a further bypass opportunity - the XPIA class scales linearly with the number of agents that process untrusted content.

Practical consequences for DACH deployments: scope-limited, short-lived tokens per task, 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 having to build a custom integration for each client. Anyone who skips Agent Cards ends up permanently behind a manual integration. The pragmatic recommendation from the research: card discipline from day one, enforce typed output contracts (for example via Pydantic or JSON Schema), and require a card for every productised 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 supports you in designing agents to be A2A-compliant, modelling Agent Cards cleanly and embedding them in a governance-ready discovery architecture.