A2A Fans 
Introduction
AI agents face significant challenges in collaborating effectively if they are unable to locate one another or determine whether they can trust the information they encounter. The reliance on hard-coded endpoints and private documentation proves to be unsustainable as the number of agents increases. Each new partner necessitates a unique and often complex integration process, which can be both time-consuming and resource-intensive. Agent Cards provide a robust solution to the discovery problem that many AI agents encounter. Within the framework of the A2A Protocol, an Agent Card is defined as a public JSON document that serves as a digital business card for an agent.
This document conveys essential information to other agents, including the agent's identity, the capabilities it offers, the means by which it can be contacted, and the specific authentication methods it requires. Additionally, some Agent Cards are equipped with cryptographic signatures, allowing recipients to verify both the authenticity and integrity of the information presented. In this article, we will delve into the various components that make up Agent Cards, explore the mechanics of how discovery operates in this context, and examine the processes through which trust is established among agents. We will also discuss the areas where trust mechanisms may still fall short and highlight the practical patterns that are beginning to emerge in the year 2026.
Key Takeaways
An Agent Card is a machine-readable JSON description of an agent’s identity, skills, endpoint, and security requirements.
It is typically published at a well-known URL such as
/.well-known/agent-card.json.Discovery is the first step; trust requires additional signals such as signatures, authentication schemes, and operational history.
Signed Agent Cards use JSON Web Signatures over a canonical form of the card to prove origin and detect tampering.
Agent Cards enable opaque collaboration: agents work together without exposing internal memory, tools, or logic.
What Is an Agent Card?
An Agent Card serves as a standardized JSON metadata document that is published by an A2A-compliant agent, commonly referred to as the A2A server. This document is crucial, as it allows other agents, known as A2A clients, to fetch and review its contents in order to determine whether collaboration is feasible and to understand the necessary steps to initiate such collaboration.
You can think of the Agent Card as being analogous to an OpenAPI specification; however, it is specifically designed for autonomous agents rather than traditional APIs. This document effectively addresses four essential questions that are vital for agents looking to work together:
Who is this agent?
What skills does it offer?
Where do I send tasks?
How do I authenticate?
The card is deliberately public and lightweight so discovery can happen with a simple HTTP GET. Sensitive operational details often remain behind authentication or appear only in an extended card after the client has proven its identity.
What Information Does an Agent Card Contain?
Typical fields include:
Identity: name, description, version, and provider information.
Endpoint: the URL where the A2A service accepts tasks.
Skills: a list of capabilities the agent claims to support, often with input/output mode hints.
Supported interfaces and modalities: text, structured data, files, streaming, etc.
Security schemes: how clients should authenticate (OAuth 2.0, API keys, mTLS, etc.).
Signatures (optional but increasingly important): cryptographic proof that the card has not been altered and was issued by a known key holder.
Because the card is the first thing another agent sees, accuracy and honesty matter. Over-claiming skills leads to failed tasks and eroded trust.
How Discovery Works
The most prevalent method for discovering agents is through the well-established Uniform Resource Identifier (URI). An agent typically hosts its card at a specific and predictable path on its domain, which can be exemplified by the following URL:
https://example-agent.com/.well-known/agent-card.json, This URL format is widely recognized, although there is also an earlier variant, /.well-known/agent.json, which continues to be observed in various deployments. When a client agent seeks to discover an agent, it initiates a straightforward GET request to the specified URI. Upon receiving the response, the client agent parses the JSON data contained within the card and evaluates whether the skills and capabilities advertised by the agent align with the tasks it needs to delegate.
Importantly, this basic fetch operation does not necessitate any prior registration or the use of a proprietary Software Development Kit (SDK). In more complex and enriched environments, the process of discovery can also occur through various registries, online marketplaces, or organizational directories that serve to index a multitude of Agent Cards. The protocol itself plays a crucial role in standardizing the format of these cards; however, the underlying infrastructure designed to facilitate the discovery of the appropriate card at scale is still in the process of evolving and improving.
From Discovery to Trust
Fetching a card answers “what does this agent claim?” Trust requires more.
Unsigned cards are easy to publish and easy to spoof. Anyone can put a JSON file at a well-known path. For low-stakes or internal use, this may be acceptable. For production or cross-organization work, it is not enough.
Signed Agent Cards add a cryptographic layer. The publisher canonicalizes the card content and signs it with a JSON Web Signature (JWS). The client verifies the signature against a known public key (resolved via DID, well-known key endpoint, or trusted registry). A valid signature proves two things: the card came from the holder of that key, and the content has not been modified in transit.
Authentication schemes declared on the card further control access to the actual task endpoints. Best practice keeps static secrets out of the card itself and uses dynamic, short-lived credentials.
Even with signatures and authentication, trust is not complete. Capability claims can still be optimistic. Real operational trust grows from verified task history, vouching, monitoring, and reputation systems built on top of the protocol.
A Practical Collaboration Flow
- Client agent needs a specialized capability (for example, deep research or domain-specific analysis).
- It locates a candidate Agent Card (well-known URL or registry).
- It verifies the signature if present and checks that the claimed skills match the need.
- It authenticates according to the card’s security schemes.
- It creates a task with clear goals and context.
- The remote agent accepts, works (possibly requesting more input), and returns artifacts.
- The client incorporates the results and continues its own plan.
Throughout this process, the remote agent remains opaque. The client never sees its prompts, memory, or internal tools.
Practical Relevance and Platforms
In the realm of multi-agent systems, Agent Cards play a crucial role in transforming what were once static lists of partners into vibrant, dynamic, and discoverable networks. This innovative approach allows for the seamless addition or replacement of specialized agents without the need to rewrite every orchestrator, thereby enhancing flexibility and adaptability within the system. Furthermore, platforms that facilitate the integration of agents into real task workflows stand to gain significantly from the same foundational discovery primitives.
When agents take the initiative to publish clear and comprehensive descriptions of their capabilities and actively participate in tracked work, the resulting synergy between protocol-level cards and operational records, such as delivery history, acceptance rates, and settlement information, establishes a much stronger foundation for future collaboration. This combined approach offers a more robust basis for partnership than either layer could provide independently, ultimately fostering a more effective and efficient collaborative environment.
Benefits
Zero-config basic discovery via a well-known URL.
Framework and vendor independence: any compliant agent can advertise itself the same way.
Support for opaque collaboration that protects proprietary logic.
Extensible trust through signatures and declared authentication.
Foundation for registries, marketplaces, and dynamic agent teams.
Limitations and Risks
A card is only as trustworthy as its publisher and verification process. Unsigned cards are trivial to forge.
Skill claims are self-reported. Verification requires actual task execution and feedback loops.
Discovery at the internet scale still needs better naming, resolution, and ranking infrastructure beyond the basic well-known path.
Overly broad or vague cards reduce usefulness and increase failed hand-offs.
Security remains a shared responsibility: signatures help with authenticity, but authorization, input validation, and monitoring are still required.
Best Practices
Ensure that you publish skills that are both accurate and narrowly scoped to enhance their effectiveness. It is advisable to prefer the use of signed cards for any agents that are involved in production or are facing external users. It is crucial to keep any sensitive information or secrets out of the card; instead, you should declare the authentication schemes that will be used. Make sure to host the card at the recommended well-known location, and take the necessary steps to ensure that it remains available and properly versioned over time.
Conduct thorough testing of the entire process, starting from the card fetch, through the authentication phase, and all the way to task completion. It is beneficial to combine protocol-level discovery with operational signals, such as success rates, revision history, and human review where necessary. Additionally, it is important to monitor which agents are being discovered and subsequently called upon for tasks.
Future Outlook
Agent Cards are becoming the default discovery primitive for inter-agent systems. Expect wider use of signed cards, tighter integration with decentralized identity, richer registries that support capability search and ranking, and better tooling for validation and monitoring. As more agents publish reliable cards and accumulate verifiable work histories, discovery will shift from “can I find an agent?” to “can I find a trustworthy agent for this specific skill?”
Conclusion
Agent Cards give AI agents a standard way to introduce themselves. By publishing identity, skills, endpoints, and security requirements in a simple JSON document, agents become discoverable without custom integration. Cryptographic signatures and proper authentication turn basic discovery into a more trustworthy foundation for collaboration.
They do not solve every trust problem on their own. Real confidence still comes from verified execution, clear task design, and ongoing monitoring. Used well, however, Agent Cards remove a major barrier to multi-agent systems and make dynamic, cross-framework collaboration practical.
Frequently Asked Questions
- What is an Agent Card in simple terms?
It is a public JSON file that describes an AI agent’s identity, capabilities, how to reach it, and how to authenticate, like a digital business card for agents.
- Where is an Agent Card usually published?
At a well-known path such as /.well-known/agent-card.json on the agent’s domain so other agents can fetch it with a standard HTTP GET.
- Are Agent Cards the same as API documentation?
They serve a similar discovery purpose but are designed for autonomous agents rather than traditional request-response APIs. They emphasize skills, task endpoints, and authentication suitable for multi-turn collaboration.
- Do all Agent Cards need to be signed?
Not required for basic operation, but signed cards are strongly recommended for production and cross-organization use because they provide cryptographic proof of origin and integrity.
- How does an agent know it can trust a card?
By verifying a cryptographic signature when present, checking the declared authentication schemes, and, over time, relying on operational history and additional trust signals.
- Can I put secrets in an Agent Card?
No. Best practice keeps credentials out of the card and uses the declared security schemes to obtain dynamic credentials at runtime.
- What happens after discovery?
The client authenticates, creates a task, and collaborates through the A2A task lifecycle while the remote agent remains opaque.
- Is discovery only possible via well-known URLs?
That is the baseline method. Registries, organizational directories, and marketplaces can also index and surface Agent Cards for richer search and ranking.