Agentic Data Plane

Connect Agents with A2A

The Agent2Agent (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, external applications and agents use A2A to call Agentic Data Plane agents over HTTP.

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 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.

The A2A standard defines how callers receive messages, task status, and artifacts, so callers can integrate with an agent without knowing which framework or runtime implements it. Agentic Data Plane agents implement A2A version 0.3. In A2A 0.3, an agent card declares one protocol version for the whole agent.

A2A lifecycle. An application or external agent fetches an Agentic Data Plane agent card, reads its capabilities, obtains an access token, sends a message, and receives a direct response or streamed task status and artifacts.
Figure 1. A2A separates discovery from authenticated message and task exchange

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. The agent URL is the Endpoint value on the agent’s Settings tab.

For example, if your agent URL is https://aigw.<cluster-id>.clusters.rdpa.co/a2a/v1/my-agent, your agent card URL is https://aigw.<cluster-id>.clusters.rdpa.co/a2a/v1/my-agent/.well-known/agent-card.json.

The .well-known path follows internet standards for service discovery, making agents discoverable without configuration.

Agentic Data Plane serves the agent card without authentication, 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.

Where A2A is used in Agentic Data Plane

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.

How agents discover each other

A2A enables dynamic discovery without hardcoded configuration:

  1. The caller fetches the agent card from the well-known URL.

  2. The caller checks the protocol version, capabilities, and skills.

  3. The caller formats message parts for the content types the agent and skill declare.

  4. 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.

Service-account callers use OAuth2 client credentials to obtain access tokens:

  1. The caller exchanges its client ID and secret for a time-limited access token through OAuth2.

  2. The caller includes the access token in the Authorization header when calling the agent endpoint.

  3. 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 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. Patch versions do not affect protocol compatibility. Agentic Data Plane agents implement A2A 0.3. In A2A 0.3, an agent card declares one protocolVersion for the whole agent.

Next steps