Connect Agents with A2A
The Agent-to-Agent (A2A) protocol is an open standard that defines how agents discover, communicate with, and call each other across platforms. Each A2A-compliant agent exposes a machine-readable agent card at a well-known URL, describing its capabilities and how to authenticate with it. Callers fetch the card at runtime, so they reach any A2A agent without prior knowledge of its implementation, and agents can update their capabilities without breaking existing callers.
In Redpanda ADP, A2A enables two integration paths: external applications and agents calling ADP agents over HTTP, and Redpanda Connect pipelines invoking agents for each event in a stream.
After reading this page, you will be able to:
-
Describe the A2A protocol and its role in agent communication
-
Explain how agent cards enable discovery
-
Identify how authentication secures agent communication
What is the A2A protocol?
The Agent-to-Agent (A2A) protocol is an open standard that defines how agents discover, communicate with, and invoke each other.
Agents that implement A2A expose their capabilities through a standardized agent card. This allows other systems to interact with them without prior knowledge of their implementation.
The protocol provides:
-
Standardized discovery: Agent cards describe capabilities in a machine-readable format.
-
Platform independence: Any system can call any A2A-compliant agent.
-
Version negotiation: Protocol versions ensure compatibility between agents.
-
Communication mode flexibility: Supports synchronous request/response and streaming.
For the complete specification, see a2a.ag/spec.
Agent cards
Every A2A-compliant agent exposes an agent card at a well-known URL.
The agent card is a JSON document that describes what the agent can do and how to interact with it. For the complete agent card specification, see Agent Card documentation.
Agent card location
ADP agents expose their agent cards at the /.well-known/agent-card.json subpath of the agent URL. You can find the agent URL on the Agents page.
For example, if your agent URL is https://my-agent.ai-agents.abc123.cloud.redpanda.com, your agent card URL is https://my-agent.ai-agents.abc123.cloud.redpanda.com/.well-known/agent-card.json.
The .well-known path follows internet standards for service discovery, making agents discoverable without configuration.
The agent card is served without authentication. The A2A protocol requires the discovery card to be publicly reachable, because a caller fetches it to learn how to authenticate with the agent. Invoking the agent still requires authentication. For details, see the Authentication section.
To configure the agent card, see Configure A2A discovery metadata.
Where A2A is used in ADP
ADP uses the A2A protocol in two contexts:
External integration
External applications and agents hosted outside ADP use A2A to call ADP agents. This includes backend services, CLI tools, custom UIs, and agents hosted on other platforms.
For integration pattern guidance, see Choose an Integration Pattern.
Internal pipeline-to-agent integration
Redpanda Connect pipelines use the a2a_message processor to invoke agents for each event in a stream. This enables real-time interaction between streaming data and AI agents, enabling use cases like:
-
Real-time fraud detection on every transaction.
-
Streaming data enrichment with AI-generated fields.
-
Event-driven agent invocation for automated processing.
The a2a_message processor uses the A2A protocol internally to discover and call agents. For pipeline patterns, see Integrate with Redpanda Pipelines.
How agents discover each other
A2A enables dynamic discovery without hardcoded configuration:
-
The caller fetches the agent card from the well-known URL.
-
The caller checks the protocol version and supported communication modes.
-
The caller uses the input schema from the agent card to format the request properly.
-
The caller sends the request to the agent’s endpoint.
This discovery model allows:
-
New agents to become available immediately after deployment
-
Existing agents to update their capabilities while callers adapt dynamically
-
Callers to understand exactly what agents do through self-describing agent cards
Authentication
A2A-compliant agents require authentication to prevent unauthorized access.
The agent card is the exception. ADP serves the card at the /.well-known/agent-card.json subpath without authentication, so that callers can discover how to authenticate before they hold a token. Every other request to the agent, including agent invocation, requires a valid access token.
ADP agents use OAuth2 client credentials flow. When you create an agent, the system provisions a service account with a client ID and secret.
External callers use these credentials to obtain access tokens:
-
Agent creation automatically provisions a service account with credentials.
-
Applications exchange the client ID and secret for a time-limited access token through OAuth2.
-
Applications include the access token in the Authorization header when calling the agent endpoint.
-
When tokens expire, applications exchange credentials again for a new token.
This flow ensures:
-
Credentials stay secure: Applications never send them directly to agents, only access tokens.
-
Exposure is limited: Tokens expire, reducing the window for compromised credentials.
-
Integration is standard: Applications can use existing OAuth2 libraries.
External integration
External applications must authenticate using the service account credentials. Each agent has its own service account.
For step-by-step authentication instructions, see Authentication.
Protocol versions
The A2A protocol uses semantic versioning (major.minor.patch). Agents declare their supported version in the agent card.