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 Agentic Data Plane, A2A enables two integration paths: external applications and agents calling Agentic Data Plane 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.
Current A2A versions make the interface and protocol version explicit during discovery and standardize how callers receive messages, task status, and artifacts. Callers can integrate with an agent without knowing which framework or runtime implements it.
For the complete specification, see A2A protocol specification.
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 A2A Agent Card specification.
Agent card location
Agentic Data Plane 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.clusters.rdpa.co, your agent card URL is https://my-agent.ai-agents.abc123.clusters.rdpa.co/.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 Agentic Data Plane
Agentic Data Plane uses the A2A protocol in two contexts:
External integration
External applications and agents hosted outside Agentic Data Plane use A2A to call Agentic Data Plane 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 supported interfaces, protocol versions, capabilities, and skills.
-
The caller formats message parts for the content types declared by the selected interface and skill.
-
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
Agentic Data Plane agents require authentication to prevent unauthorized access.
The agent card is the exception. Agentic Data Plane 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.
Callers authenticate as themselves, never as the agent they’re calling. Each caller needs its own service account and permission to invoke the agent. See Service account authorization and A2A runtime permissions.
Callers use OAuth2 client credentials to obtain access tokens:
-
The caller exchanges its client ID and secret for a time-limited access token through OAuth2.
-
The caller includes the access token in the Authorization header when calling the agent endpoint.
-
When the token expires, the caller exchanges 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 and agents authenticate with their own service account credentials, not the target agent’s. Grant the caller permission to invoke the agent with an access policy or a custom role. See Manage Access Policies.
Protocol versions
The A2A specification uses semantic release versions, but protocol compatibility uses major.minor. Each supported interface in the agent card declares the protocolVersion it exposes. Clients select a compatible interface and send that version on requests; patch versions do not affect protocol compatibility.