Skip to main content
This document describes the end-to-end agent-to-agent (A2A) request lifecycle. The A2A flow has four principal stages:
  • Agent discovery
  • Authentication
  • sendMessage (request)
  • sendMessageStream (streaming updates)
Below is a concise reference table followed by detailed explanations and examples.
StagePurposeTypical endpoint / artifact
Agent discoveryLocate an agent and retrieve its capabilities and endpointsGET /.well-known/agent-card (or registry/direct configuration)
AuthenticationObtain a token (e.g., OpenID Connect) for the agent’s security schemaAuthorization server token endpoint → JWT
sendMessageSubmit a request to an agent (synchronous or async task creation)POST /sendMessage with JWT
sendMessageStreamReceive streaming task lifecycle events and artifactsPOST /sendMessageStream with JWT (server-sent events or similar)

​
Agent discovery

Discovery is the first step: the client finds an agent card that describes the agent’s capabilities, endpoints, and security schema. Discovery can happen in one of three ways:
  • Well-known URI: the client requests a predictable path on the agent or controller.
  • Curated registry: a central catalog contains agent cards.
  • Direct configuration: a client is given an agent card or endpoint manually.
Example (well-known URI): 
Client -> GET /.well-known/agent-card
Server -> Returns Agent Card (JSON describing capabilities, endpoints, security)
The returned agent card typically includes:
  • The agent’s name and description
  • Endpoints (e.g., sendMessage, sendMessageStream)
  • Supported authentication schemes (e.g., OpenID Connect)
  • Declared skills and tool metadata

​
Authentication

After parsing the agent card, the client inspects the security schema. If the agent uses OpenID Connect (or another OAuth2 flow), the client obtains an access token from the authorization server and presents that token to the agent. Typical flow:
  1. Discover token endpoint from the agent card or identity provider metadata.
  2. Authenticate (client credentials / authorization code / other grant).
  3. Receive a JWT access token.
  4. Use the JWT in Authorization: Bearer <token> when calling the agent.
Store and transmit JWTs securely. Always use TLS, implement short token lifetimes, validate audience/issuer claims, and follow least-privilege practices.

​
sendMessage (request)

With a valid JWT, the client calls the agent’s sendMessage endpoint to submit work. The agent processes the incoming message, creates a task, and returns a task response. The exact response depends on the agent implementation — it may return a synchronous result, a task identifier, or a simple acknowledgement indicating the task was queued. Simple sequence: 
Client -> POST /sendMessage (Authorization: Bearer <JWT>, body: message)
Agent  -> Returns TaskResponse (e.g., { taskId, status, result? })
Key considerations:
  • The message payload should match the agent’s expected schema (declared in the agent card).
  • Responses vary: some agents do full synchronous processing and return results inline; others return a task ID for later polling or streaming.

​
sendMessageStream (streaming updates)

When you need real-time updates (task submitted, progress, artifacts, completion), use sendMessageStream. The client opens a streaming connection (SSE, WebSocket, or chunked HTTP) and the agent pushes lifecycle events:
  • Task submission confirmation
  • Task status updates (e.g., “working”, “succeeded”, “failed”)
  • Artifact update events (e.g., logs, files, intermediate outputs)
  • Final completion event
Example stream sequence: 
Agent Discovery
Authentication
sendMessage API
sendMessageStream API

Client -> POST /sendMessageStream (with JWT)
Server -> Stream: Task (Submitted)
Server -> Stream: TaskStatusUpdateEvent
Server -> Stream: TaskArtifactUpdateEvent
Server -> Stream: TaskStatusUpdateEvent (Done)
Use streaming when you want low-latency progress updates or to receive artifacts as they are produced.

​
Real-world examples

​
Enterprise agent network

A2A enables agents across departments and organizations to discover and interoperate using the same protocol. Agents advertise their capabilities and endpoints so other agents can call them directly, enabling cross-company collaboration and standardized integrations.
A diagram titled "Enterprise Agent Networks" showing two companies (Company A and Company B), each with Department A and Department B boxes containing agent icons labeled Agent A and Agent B. The two company blocks are connected at the bottom by an "A2A Protocol" link.

​
Agent composition

Agent composition is the pattern where one agent treats another agent as a tool. Building systems from small, focused agents (each exposing specific skills) makes complex workflows easier to maintain and scale.
A slide titled "Agent Composition (Interpretation)" showing two identical cartoon agents on the left and right with horizontal arrows between them indicating bidirectional communication.

​
Distributed systems

Agents may be deployed in different regions or clouds. A2A supports distributed deployment, enabling agents to collaborate over the network and form a resilient, geo-distributed agent infrastructure.
A world map titled "Distribution Systems (Interpretation)" with two cartoon agent icons at left and right and location pins in North America and India connected by dotted lines. It illustrates networked distribution between the two agents.

​
Key takeaways: what A2A enables — and what it does not

What A2A provides:
  • Cross-company agent collaboration
  • Multi-agent coordination and composition
  • Secure, standardized communication at the protocol level
  • Reduced need for custom integrations when parties follow the same A2A conventions
What A2A is not:
  • An agent-building framework (it does not replace frameworks like LangChain)
  • A full messaging/control plane (MCP) on its own
  • Model-specific (A2A is independent of the underlying model)
  • Limited to trivial tools — it supports complex agent-to-agent coordination
A2A EnablesA2A Is Not
Cross-company agent collaborationAn agent-building framework
Multi-agent coordinationA replacement for an MCP
Standardized, secure protocolModel-dependent
Reduced integration burdenLimited to simple tools
A split slide titled "What A2A Enables" (left) lists cross-company agent collaboration, multi-agent coordination, secure standard communication, and no custom integrations. The right column, "What A2A Is Not," states it's not an agent-building framework, not an MCP replacement, not model-dependent, and not for simple tools.

​
How A2A fits with KAgent

When A2A is enabled in KAgent, KAgent exposes a discoverable endpoint so other agents can find and communicate with it. The well-known URI for a KAgent-managed agent typically follows this pattern: 
URL Format - kagent-controller:8083/api/a2a/namespace/agent-name
KAgent exposes each agent’s A2A endpoint under the controller’s API. Replace namespace and agent-name with the actual Kubernetes namespace and agent name.
KAgent supports agent-as-tools (composition) and multi-agent workflows. A caller agent can invoke a callee agent for a specific skill and treat the callee as a managed tool within a larger workflow.
A diagram titled "How Kagent Uses A2A" showing two cartoon agent robots labeled Agent A and Agent B linked by an "A2A Protocol" box. Above them are three labeled blocks: "Agent A2A Server," "Agent as tool," and "Multi-agent workflow."

​
Example: agent composition in KAgent

The example below shows a flight agent that exposes a book_flight skill and a travel-planner agent that calls the flight agent via A2A. 
# Agent A - Makes itself available via A2A
apiVersion: kagent.dev/v1alpha1
kind: Agent
metadata:
  name: flight-agent
spec:
  systemMessage: "I book flights"
  a2aConfig:
    skills:
      - name: "book_flight"
        description: "Books international flights"

---
# Agent B - Uses Agent A via A2A
apiVersion: kagent.dev/v1alpha1
kind: Agent
metadata:
  name: travel-planner
spec:
  systemMessage: "I plan trips"
  tools:
    - type: Agent
      agent:
        ref: flight-agent  # Uses Agent A via the A2A protocol
When the travel-planner receives a request requiring a flight booking, it invokes flight-agent’s book_flight skill over A2A and uses the returned result as part of the itinerary.

​
Summary

A2A is a protocol that standardizes agent-to-agent communication to support multi-agent orchestration, secure discovery and authentication, and streaming task lifecycles. It enables agents across organizations and environments to interoperate while remaining agnostic to underlying model frameworks. Further reading and references That’s it for this lesson. The course also covers KAgent architecture.

Watch Video