Agent Card

Definition

An Agent Card is a self-describing JSON manifest used in the Agent2Agent (A2A) protocol to tell clients and other agents what an agent is, what it can do, how to reach it, and how it should be accessed securely. In the A2A specification, the Agent Card includes core metadata such as the agent’s name, description, version, supported interfaces, capabilities, default input and output modes, skills, and optional security schemes and signatures. (a2a-protocol.org)

A2A documentation describes the Agent Card as the mechanism clients use to discover an agent and learn how to interact with it. The protocol also standardizes a common discovery location at /.well-known/agent-card.json, although Agent Cards can also be found through registries or direct configuration. (a2a-protocol.org)

How It Relates to Marketing

For marketing teams, an Agent Card matters because agentic workflows are only useful at scale if systems can discover the right specialist agent without custom integration work each time. A campaign orchestration agent, for example, may need to locate a pricing agent, a compliance agent, a localization agent, or a reporting agent. The Agent Card gives each of those agents a standard, machine-readable way to publish their capabilities and access requirements. (Google Developers Blog)

In practical terms, Agent Cards can support modular marketing operations. A brand governance agent could advertise review skills, a content operations agent could expose publishing skills, and an analytics agent could expose reporting skills. Because those capabilities are declared in a standard structure, organizations can swap or add agents with less custom engineering than a fully bespoke integration model would require. (Google Developers Blog)

How to Calculate Agent Card

There is no formula for calculating an Agent Card because it is a protocol object, not a metric. (a2a-protocol.org)

What can be measured instead is the operational quality of an Agent Card implementation, such as:

  • discovery success rate
  • percentage of agent skills accurately declared
  • time required to connect a new remote agent
  • authentication failures caused by incomplete or incorrect card data
  • cache hit rate for Agent Card retrieval
  • percentage of workflows that require manual integration work after discovery

These are implementation metrics rather than properties of the Agent Card itself.

How to Utilize Agent Card

The primary use of an Agent Card is discovery. A client fetches the card, reads the agent’s supported interfaces, identifies the available skills, checks supported media types, and determines whether features such as streaming, push notifications, or an extended authenticated Agent Card are available. (a2a-protocol.org)

A typical implementation uses the Agent Card to:

  • identify the agent by name, description, provider, and version
  • determine which interface to call through supportedInterfaces
  • inspect skills to understand what the agent is designed to do
  • evaluate capabilities such as streaming, push notifications, and extended Agent Card support
  • review securitySchemes and securityRequirements before making authenticated calls
  • verify signatures when provided to confirm integrity and authenticity (a2a-protocol.org)

In a marketing use case, a journey orchestration agent might fetch Agent Cards from several remote agents before deciding which one should handle offer selection, compliance review, creative adaptation, or audience analysis. That reduces hardcoded dependencies and makes the workflow more composable. (Google Developers Blog)

ConceptWhat it isPrimary purposeHow it differs from an Agent Card
Agent CardA self-describing manifest for an agentDiscovery, capability declaration, interface and security descriptionIt is the top-level object clients read to understand the agent. (a2a-protocol.org)
Agent SkillA declared capability within an agentDescribe a specific function the agent can performSkills are components inside the Agent Card, not a replacement for it. (a2a-protocol.org)
Agent InterfaceA declared endpoint, transport, and protocol versionTell clients how to connect to the agentInterfaces are one field within the Agent Card and focus on connectivity rather than full discovery metadata. (a2a-protocol.org)
Extended Agent CardA more detailed authenticated version of the cardProvide additional information after authenticationIt builds on the public Agent Card and is only available when the agent declares support for it. (a2a-protocol.org)

Best Practices

Publish a complete public Agent Card with clear descriptions and accurately scoped skills. Since clients use the card to decide whether and how to interact with an agent, vague descriptions or overstated skills make routing less reliable. (a2a-protocol.org)

Use supportedInterfaces carefully. The specification states that the list is ordered and that the first entry is preferred, so the ordering should reflect the interface you want clients to use by default. (a2a-protocol.org)

Treat security as part of discovery, not an afterthought. The specification allows Agent Cards to declare security schemes and requirements, while the discovery guidance warns against embedding static secrets and recommends access controls for sensitive Agent Cards or extended cards. (a2a-protocol.org)

Support caching correctly. The discovery guidance recommends standard HTTP caching headers, including Cache-Control and ETag, because Agent Cards change infrequently but still need eventual freshness when skills or authentication requirements change. (a2a-protocol.org)

Sign Agent Cards when trust and verification matter. The specification allows JSON Web Signatures so clients can verify authenticity and integrity before trusting the card’s contents. (a2a-protocol.org)

Agent Cards are likely to become more important as multi-agent systems become more common and as A2A adoption expands. The Linux Foundation announced in April 2026 that the A2A project had passed 150 supporting organizations and was seeing production use, which suggests growing demand for standard discovery and interoperability patterns. (Linux Foundation)

As enterprise use grows, Agent Cards will likely evolve from simple discovery manifests into more governance-oriented assets that help organizations manage trust, routing, security posture, and interoperability across many specialized agents. The specification already points in that direction through support for signatures, security declarations, extended authenticated cards, and multiple protocol bindings. (a2a-protocol.org)

Tags:

Was this helpful?