Beyond the Endpoint: How Agent Cards Enable Discovery, Interoperability, and Trust

Imagine an employee asks an AI assistant: Can I claim this hotel expense?

The assistant cannot answer the question itself, but somewhere in the enterprise there is an Expense Agent that can. The challenge is not simply finding its endpoint. The assistant needs to determine: Does this agent handle expense-policy validation? How do I interact with it? What authentication does it require?

In traditional software, APIs and integrations often define these relationships. In a multi-agent ecosystem, agents may need to discover and evaluate one another dynamically.

And that is where Agent Cards come in. They provide a machine-readable description of an agent — its identity, capabilities, skills, interaction mechanisms, security needs, and other agents’ capabilities — so that others can get the information they need to learn about, understand, and interact with it.

An endpoint tells an agent where to connect. An Agent Card helps it decide whether — and how — to connect.

Agents Need More Than an Endpoint

Traditional APIs are built on a contract: the client knows the endpoint, knows the interface, and can invoke a predefined operation. In an agentic ecosystem, that is only part of the problem.

An agent may encounter another agent dynamically and must decide:

• Who are you? – identity, ownership, and version
• What can you do? – capabilities and supported tasks
• How can I work with you? – protocols, inputs, outputs, and interaction modes
• Can I trust you? – authentication, authorization, and other trust signals
• Are you suitable for this task? – constraints and operational context

An endpoint answers, “Where do I send the request?” It does not answer, “Should I interact with this agent, and how?”

This is the gap that Agent Cards address: they provide a machine-readable description of an agent so that other agents can discover its capabilities and understand how to interact with it.

What Is an Agent Card?

An Agent Card is a machine-readable metadata document that describes an AI agent and the capabilities it exposes to other agents. In the Agent2Agent (A2A) protocol, it is a standardized way for an agent to advertise its identity, capabilities, skills, supported interaction modes, and security requirements.

Think of an Agent Card as the agent’s self-description. It allows other agents, orchestrators, or platforms to know the things that the agent can do without having to know what it is or setting up integrations manually.

A typical Agent Card captures:

• Identity – name, description, and basic information about the agent
• Capabilities – protocol-level features the agent supports
• Skills – specific tasks or functions the agent can perform
• Interaction modes – supported input and output formats
• Security – authentication schemes and security requirements
• Connection information – details required to communicate with the agent

For example, an enterprise Expense Agent might advertise skills such as validate expense, check policy compliance, and submit reimbursement. Another agent can inspect this metadata and determine whether the Expense Agent has the capability required for a particular task.

The Agent Card therefore acts as a standardized capability profile, providing the metadata needed for agents to discover, understand, and interact with one another programmatically.

Anatomy of an Agent Card

An Agent Card brings together an agent's metadata and its interaction with another agent. The structure depends on the A2A specification version, but the key parts can be grouped into a few areas:

• Identity – Describes the agent with information such as its name and description, helping other systems understand its purpose.
• Connection information – Specifies how the agent can be reached and the interfaces or protocols available for communication.
• Capabilities – Declares protocol-level features supported by the agent, such as streaming or other interaction capabilities.
• Skills – Defines the tasks the agent provides. A skill typically describes its purpose and may include supported input/output modes, examples, and tags.
• Security – Specifies the authentication mechanisms and security requirements that have to be followed when communicating with the agent.
• Metadata for discovery – Descriptions, tags, and skill information provide useful signals for registries, orchestrators, and other agents searching for an appropriate agent.

The skills section is particularly important. It moves discovery beyond simply finding an agent to understanding what that agent can do. For example, an Expense Agent could expose skills such as validate-expense and submit-reimbursement, allowing an orchestrator to select it based on the task being performed.

Together, these elements turn the Agent Card into a structured capability profile that can be interpreted programmatically across an A2A ecosystem.

Agent Skills: Describing What an Agent Can Actually Do

An Agent Card describes the agent, but skills describe the specific tasks the agent can perform. They provide a structured way for another agent or orchestrator to determine whether an agent is suitable for a particular request.

A skill typically communicates:

• ID and name – a unique identifier and human-readable name
• Description – what the skill is designed to accomplish
• Tags – keywords that help with discovery and classification
• Examples – sample requests that illustrate when the skill should be used
• Input/output modes – the types of content the skill can consume or produce

Consider an Expense Agent that provides two skills:

"skills": [
  {
    "id": "validate-expense",
    "name": "Validate Expense",
    "description": "Validates an expense against corporate policy",
    "tags": ["expense", "validation", "compliance"],
    "examples": [
      "Check whether this hotel expense complies with policy"
    ]
  },
  {
    "id": "submit-reimbursement",
    "name": "Submit Reimbursement",
    "description": "Submits an approved expense for reimbursement",
    "tags": ["expense", "reimbursement"]
  }
]

These descriptions allow another agent to reason about which capability is relevant to the user's intent. For example:

User: “Can I claim this ₹8,000 hotel expense?”

Orchestrator: identifies the intent as expense policy validation → discovers the Expense Agent → finds the validate-expense skill → delegates the task

Skills therefore provide the semantic layer for capability discovery. Instead of merely discovering that an Expense Agent exists, other agents can understand the individual tasks it offers and select the capability that best matches the work to be performed.

How Agent Cards Enable Discovery

In an agent ecosystem, discovery is not simply finding another agent, but rather finding the right agent for a particular task. Agent Cards do this by providing structured and machine-readable information about an agent and its skills.

A typical discovery flow looks like this:

User Intent → Discover Agents → Retrieve Agent Cards → Match Skills → Select Agent → Initiate A2A Interaction

Consider a user asking:

“Check whether my hotel expense complies with company policy.”

An orchestrating agent can use available Agent Cards to identify agents whose advertised skills match the request. An Expense Agent exposing a validate-expense skill with tags such as expense, validation, and compliance becomes a strong candidate.

Agent Cards support discovery at multiple levels:

• Agent-level discovery – identify agents relevant to a domain or purpose.
• Skill-level discovery – determine which agent provides the capability required for the task.
• Compatibility discovery – verify supported interaction modes and protocol capabilities.
• Security-aware discovery – understand authentication requirements before initiating communication.

Importantly, the Agent Card provides the metadata for discovery; the location of Agent Cards may be different if we have to track them. Cards may be obtained from well-known locations, registries, catalogs, configuration, or other discovery infrastructure.

This separation is powerful: discovery mechanisms can evolve independently, while the Agent Card provides a common description of what each discovered agent offers.

Agent Discovery Is More Than Service Discovery

Traditional service discovery is concerned with locating a service instance. Once a service name is assigned to it, Kubernetes DNS or service registries can guide a client to find services.

Agent discovery has a broader objective. An agent does not necessarily know in advance which other agent should do a task. It may need to find candidates and reason about which one is the best fit.

For example, given the request:

“Check whether this travel expense complies with company policy.”

An orchestrator might find several agents related to finance, travel, expenses, or compliance. Selecting the right one is more than just locating them. It involves knowing their advertised skills, descriptions, supported interaction modes, security requirements, and other capability metadata.

The distinction can be summarized as:

Service Discovery

Service Name → Location → Connect

Agent Discovery

Intent → Candidate Agents → Capability/Skill Matching → Compatibility Check → Agent Selection → Interact

This makes agent discovery much more semantic and task-oriented. The goal is not simply “Where is the service?” but in order to discover:

“Which available agent is capable of performing this task, and can I interact with it appropriately?”

Agent Cards provide the structured metadata needed to support this decision. The discovery infrastructure can locate candidate agents, while their Agent Cards allow an orchestrator to evaluate those candidates and select the most appropriate agent and skill.

Public vs. Authenticated Agent Cards

Not every agent should expose the same information to every caller. A2A supports the idea of making basic agent information available through a public Agent Card, while additional information can be made available to authenticated clients through an authenticated extended Agent Card.

Public Agent Card

The public Agent Card provides all the info as part of the initial discovery and interactions. It will advertise things like the agent's name, capabilities, skills, supported interfaces, and security requirements. For example, an enterprise Expense Agent might advertise:

Expense Agent

Skills: validate-expense, check-expense-policy

This provides a potential client with enough information to determine if the agent is relevant and how authentication should be established.

Authenticated Extended Agent Card

Some information may only be appropriate after the caller has authenticated. An authenticated extended Agent Card can expose additional capabilities or metadata intended for authorized clients. For example:

Public
validate-expense
   check-expense-policy

After authentication
submit-reimbursement
approve-expense
   access-finance-workflow

This is particularly useful in enterprise environments where an agent may reveal some capabilities depending on the caller's identity, permissions, or organizational context.

The principle here is progressive disclosure:

Discover → Understand Security Requirements → Authenticate → Retrieve Extended Agent Card → Access Authorized Capabilities

This allows organizations to balance discoverability with controlled exposure. Agents can advertise enough information to participate in an ecosystem without unnecessarily exposing sensitive or privileged capabilities to unauthenticated clients.

Security and Trust Begin at Discovery

Discovery answers “Which agent can do this task?” But for enterprise environments, capability alone is not enough. When dealing with a discovered agent, a system also needs to determine if it can be trusted and accessed safely.

Agent Cards support this process by exposing security-related metadata and capabilities. A client can understand the authentication mechanisms required by the agent and establish the appropriate credentials before starting an A2A interaction.

This makes security part of the discovery workflow rather than something only considered after an agent has been selected:

Discover → Evaluate Capability → Evaluate Security Requirements → Authenticate → Interact

An important distinction is that an Agent Card is not proof that an agent is trustworthy. Trust also depends on how the card was obtained, the identity of the agent or organization behind it, transport security, credential validation, authorization policies, and governance controls surrounding the interaction.

In enterprise environments, discovery should therefore combine two questions:

• Can this agent perform the task?
• Should this agent be allowed to perform the task?

Agent Cards provide important metadata for making that decision, while enterprise identity, authorization, policy, and governance mechanisms establish the broader trust boundary around agent-to-agent communication.

Securing Agent-to-Agent Communication

Agent discovery establishes which agent to interact with. The next problem is to make sure the interaction itself is secure.

Once an agent has been selected, requests, responses, credentials, context, and potentially sensitive enterprise data can flow between agents. Such A2A communication should therefore protect four fundamental properties: confidentiality, integrity, authentication, and authorization.

Common enterprise controls include:

• HTTPS/TLS encryption to protect data in transit.
• Service-to-service authentication to verify the identity of communicating agents.
• Token-based authorization to ensure an agent can invoke only permitted capabilities.
• Identity propagation when the originating user's or agent's identity must be preserved across interactions.
• Mutual TLS (mTLS) where both communicating parties need strong cryptographic authentication.
• Audit logging to maintain traceability of agent interactions.

These controls are particularly important because an agent may invoke another agent autonomously. A successful discovery should therefore not imply authorization. An agent might advertise a capability while the requesting agent is not permitted to use it.

Securing Asynchronous Interactions

Agent-to-agent interactions may also be long-running. Instead of keeping a connection open, an agent may complete a task asynchronously and inform the requesting agent by a callback or push notification.

In such cases, the notification endpoint should be validated, incoming notifications authenticated, messages protected from tampering, replay attacks prevented, and communication performed over secure channels.

A useful way to think about the flow is:

Discover → Authenticate → Authorize → Establish Secure Channel → Invoke → Validate Response → Audit

The Agent Card helps communicate the security requirements needed to establish this interaction, but it is not itself the security enforcement mechanism. Authentication, authorization, transport security, policy enforcement, and auditing must still be implemented by the surrounding agent platform and enterprise security architecture.

This distinction is important: the Agent Card describes how secure interaction should occur; the runtime infrastructure enforces it.

Agent Card Lifecycle and Governance

An Agent Card should not be treated as a create-once, static metadata file. As an agent develops, its capabilities, skills, endpoints, authentication requirements, and operational constraints may also change. The Agent Card must evolve with it.

This calls for an Agent Card lifecycle that governs how cards are created, validated, published, updated, and eventually retired.

A typical lifecycle can be represented as:

Define → Validate → Publish → Discover → Monitor → Update → Deprecate

Define and Validate

When an agent is created or modified, its Agent Card should accurately describe its identity, capabilities, skills, endpoints, and security requirements. Before publication, organizations should validate the card for:

• required metadata and schema correctness;
• valid and reachable endpoints;
• clear and unambiguous skill descriptions;
• correct authentication requirements;
• consistency between advertised capabilities and actual agent behavior.

This prevents agents from publishing incomplete or misleading discovery information.

Publish and Discover

Once validated, the Agent Card can be published through the appropriate discovery mechanism. Consumers can then use it to evaluate whether the agent is suitable for a particular task.

Publication should also consider visibility. As discussed earlier, not every skill or capability necessarily needs to be discoverable by every consumer. Public, internal, and privilege-specific views may require different governance policies.

Monitor and Update

Agent Cards should remain synchronized with the agents they describe. If a new skill, alternate endpoint, authentication mechanism, or ability is changed, the Agent Card should update accordingly.

This is particularly important because Agent Card metadata can influence runtime agent selection and routing. Outdated metadata could cause an orchestrator to select an inappropriate agent or attempt to invoke a capability that no longer exists.

Version and Deprecate

Significant changes should be versioned so consumers can identify compatibility changes. Skills or capabilities that are being removed should be explicitly deprecated before they disappear where practical, allowing dependent agents and orchestrators time to adapt.

When an agent itself is retired, its Agent Card should also be withdrawn or marked accordingly so that it is no longer selected during discovery.

When the agent itself is retired, its Agent Card should also be withdrawn or marked so that it is no longer selected during discovery.

Governance Across the Lifecycle

As multi-agent environments grow, Agent Cards become part of the organization's agent governance surface rather than just documentation.

Organizations should therefore establish ownership and controls around:

Who can publish an Agent Card? Who can modify it? Who approves newly advertised capabilities? How are changes tracked? Which consumers can discover which skills?

Governance should also provide traceability around agent interactions.  The key principle is simple:

The Agent Card lifecycle should follow the agent lifecycle.

When an agent changes, its discoverable contract must change with it. This makes discovery accurate, secure, and trustworthy as the agent ecosystem evolves.

Agent Card Design Best Practices

A well-designed Agent Card should make an agent easy to discover, correctly understood, securely accessed, and safely selected. Because its metadata may affect runtime discovery and routing, clarity and accuracy matter.

A few practices help keep Agent Cards effective:

• Make the purpose clear: Give a brief name and description that immediately describes what the agent is doing.
• Define skills precisely: Describe specific tasks and when they should be used. Avoid vague names such as Analyzer or Helper. Skills are an important signal for discovery and selection.
• Separate capabilities from skills: Capabilities describe general protocol-level functionality; skills describe the specific tasks the agent performs.
• Use meaningful metadata: Tags, descriptions, examples, and input/output modes should help consumers determine whether a skill matches their intent.
• Make security requirements explicit: Clearly advertise authentication and access requirements so consumers understand how to establish a secure interaction.
• Apply least-privilege discovery: Expose only the capabilities and skills appropriate for the consumer's identity and authorization level. 
• Keep the card synchronized: Update the Agent Card whenever skills, capabilities, endpoints, or security requirements change.
• Validate and version: Validate cards before publication and version significant changes so consumers can manage compatibility and deprecation. 

A good Agent Card should make five questions easy to answer:

Who are you? → What can you do? → When should I use you? → How do I access you? → Can I trust and safely invoke you?

Agent Cards in an Enterprise Multi-Agent Architecture

In an enterprise multi-agent environment, Agent Cards become part of the overall discovery and interaction architecture. Instead of having agents know in advance about each other, an orchestrator or agent router can use published Agent Cards to discover candidates, evaluate their skills and capabilities, apply security and policy requirements, and select the appropriate agent for the task.

Agent Card acts as the bridge between an agent's implementation and the enterprise mechanisms that make it discoverable, selectable, secure, and governable.

Conclusion

As AI agents become more autonomous and interconnected, knowing where an agent is no longer enough. Agents need a structured way to understand what other agents can do, how to interact with them, and under what security and governance conditions.

Agent Cards provide this metadata layer, enabling discovery, skill-based selection, secure interaction, and interoperability across multi-agent ecosystems. In combination with appropriate lifecycle management and governance, they can help transform the independently deployed agents into a discoverable, trustworthy, and manageable agent ecosystem.

The future of multi-agent systems is not just connected agents, but agents that can discover, understand, and trust one another.