A2A on AMP - CrewAI

A2A server agents on AMP are in early release. APIs may change in future versions.

Overview

CrewAI AMP extends the open-source A2A protocol implementation with production infrastructure for deploying distributed agents at scale. AMP supports A2A protocol versions 0.2 and 0.3. When you deploy a crew or agent with A2A server configuration to AMP, the platform automatically provisions distributed state management, authentication, multi-transport endpoints, and lifecycle management.

For A2A protocol fundamentals, client/server configuration, and authentication schemes, see the A2A Agent Delegation documentation. This page covers what AMP adds on top of the open-source implementation.

Usage

Add A2AServerConfig to any agent in your crew and deploy to AMP. The platform detects agents with server configuration and automatically registers A2A endpoints, generates agent cards, and provisions the infrastructure described below.

from crewai import Agent, Crew, Task
from crewai.a2a import A2AServerConfig
from crewai.a2a.auth import EnterpriseTokenAuth

agent = Agent(
    role="Data Analyst",
    goal="Analyze datasets and provide insights",
    backstory="Expert data scientist with statistical analysis skills",
    llm="gpt-4o",
    a2a=A2AServerConfig(
        auth=EnterpriseTokenAuth()
    )
)

task = Task(
    description="Analyze the provided dataset",
    expected_output="Statistical summary with key insights",
    agent=agent
)

crew = Crew(agents=[agent], tasks=[task])

After deploying to AMP, the platform registers two levels of A2A endpoints:

Crew-level: an aggregate agent card at /.well-known/agent-card.json where each agent with A2AServerConfig is listed as a skill, with a JSON-RPC endpoint at /a2a
Per-agent: isolated agent cards and JSON-RPC endpoints mounted at /a2a/agents/{role}/, each with its own tenancy

Clients can interact with the crew as a whole or target a specific agent directly. To route a request to a specific agent through the crew-level endpoint, include "target_agent" in the message metadata with the agent’s slugified role name (e.g., "data-analyst" for an agent with role "Data Analyst"). If no target_agent is provided, the request is handled by the first agent in the crew. See A2A Agent Delegation for the full list of A2AServerConfig options.

Per the A2A protocol, agent cards are publicly accessible to enable discovery. This includes both the crew-level card at /.well-known/agent-card.json and per-agent cards at /a2a/agents/{role}/.well-known/agent-card.json. Do not include sensitive information in agent names, descriptions, or skill definitions.

File Inputs and Structured Output

A2A on AMP supports passing files and requesting structured output in both directions. Clients can send files as FileParts and request structured responses by embedding a JSON schema in the message. Server agents receive files as input_files on the task, and return structured data as DataParts when a schema is provided. See File Inputs and Structured Output for details.

What AMP Adds

Distributed State

Persistent task, context, and result storage

Enterprise Authentication

OIDC, OAuth2, mTLS, and Enterprise token validation beyond simple bearer tokens

gRPC Transport

Full gRPC server with TLS and authentication

Context Lifecycle

Automatic idle detection, expiration, and cleanup of long-running conversations

Signed Webhooks

HMAC-SHA256 signed push notifications with replay protection

Multi-Transport

REST, JSON-RPC, and gRPC endpoints served simultaneously from a single deployment

Distributed State Management

In the open-source implementation, task and context state lives in memory on a single process. AMP replaces this with persistent, distributed stores.

Storage Layers

Store	Purpose
Task Store	Persists A2A task state and metadata
Context Store	Tracks conversation context, creation time, last activity, and associated tasks
Result Store	Caches task results for retrieval
Push Config Store	Manages webhook subscriptions per task

Multiple A2A deployments are automatically isolated from each other, preventing data collisions when sharing infrastructure.

Enterprise Authentication

AMP supports six authentication schemes for incoming A2A requests, configurable per deployment. Authentication works across both HTTP and gRPC transports.

Scheme	Description	Use Case
SimpleTokenAuth	Static bearer token from `AUTH_TOKEN` env var	Development, simple deployments
EnterpriseTokenAuth	Token verification via CrewAI PlusAPI with integration token claims	AMP-to-AMP agent communication
OIDCAuth	OpenID Connect JWT validation with JWKS endpoint caching	Enterprise SSO integration
OAuth2ServerAuth	OAuth2 with configurable scopes	Fine-grained access control
APIKeyServerAuth	API key validation via header or query parameter	Third-party integrations
MTLSServerAuth	Mutual TLS certificate-based authentication	Zero-trust environments

The configured auth scheme automatically populates the agent card’s securitySchemes and security fields. Clients discover authentication requirements by fetching the agent card before making requests.

Extended Agent Cards

AMP supports role-based skill visibility through extended agent cards. Unauthenticated users see the standard agent card with public skills. Authenticated users receive an extended card with additional capabilities. This enables patterns like:

Public agents that expose basic skills to anyone, with advanced skills available to authenticated clients
Internal agents that advertise different capabilities based on the caller’s identity

gRPC Transport

If enabled, AMP provides full gRPC support alongside the default JSON-RPC transport.

TLS termination with configurable certificate and key paths
gRPC reflection for debugging with tools like grpcurl
Authentication using the same schemes available for HTTP
Extension validation ensuring clients support required protocol extensions
Version negotiation across A2A protocol versions 0.2 and 0.3

For deployments exposing multiple agents, AMP automatically allocates per-agent gRPC ports and coordinates TLS, startup, and shutdown across all servers.

Context Lifecycle Management

AMP tracks the lifecycle of A2A conversation contexts and automatically manages cleanup.

Lifecycle States

State	Condition	Action
Active	Context has recent activity	None
Idle	No activity for a configured period	Marked idle, event emitted
Expired	Context exceeds its maximum lifetime	Marked expired, associated tasks cleaned up, event emitted

A background cleanup task runs hourly to scan for idle and expired contexts. All state transitions emit CrewAI events that integrate with the platform’s observability features.

Signed Push Notifications

When an A2A agent sends push notifications to a client webhook, AMP signs each request with HMAC-SHA256 to ensure integrity and prevent tampering.

Signature Headers

Header	Purpose
`X-A2A-Signature`	HMAC-SHA256 signature in `sha256={hex_digest}` format
`X-A2A-Signature-Timestamp`	Unix timestamp bound to the signature
`X-A2A-Notification-Token`	Optional notification auth token

Security Properties

Integrity: payload cannot be modified without invalidating the signature
Replay protection: signatures are timestamp-bound with a configurable tolerance window
Retry with backoff: failed deliveries retry with exponential backoff

Distributed Event Streaming

In the open-source implementation, SSE streaming works within a single process. AMP propagates SSE events across instances so that clients receive updates even when the instance holding the streaming connection differs from the instance executing the task.

Multi-Transport Endpoints

AMP serves REST and JSON-RPC by default. gRPC is available as an additional transport if enabled.

Transport	Path Convention	Description
REST	`/v1/message:send`, `/v1/message:stream`, `/v1/tasks`	Google API conventions
JSON-RPC	Standard A2A JSON-RPC endpoint	Default A2A protocol transport
gRPC	Per-agent port allocation	Optional, high-performance binary protocol

All active transports share the same authentication, version negotiation, and extension validation. Agent cards are generated from agent and crew metadata — roles, goals, and tools become skills and descriptions — and automatically include interfaces for each active transport. They can also be manually configured via A2AServerConfig.

Version and Extension Negotiation

AMP validates A2A protocol versions and extensions at the transport layer.

Version Negotiation

Clients send the A2A-Version header with their preferred version
AMP validates against supported versions (0.2, 0.3) and falls back to 0.3 if unspecified
The negotiated version is returned in the response headers

Extension Validation

Clients declare supported extensions via the X-A2A-Extensions header
AMP validates that clients support all extensions the agent requires
Requests from clients missing required extensions receive an UnsupportedExtensionError

Next Steps

A2A Agent Delegation — A2A protocol fundamentals and configuration
A2UI — Interactive UI rendering over A2A
Deploy to AMP — General deployment guide
Webhook Streaming — Event streaming for deployed automations

​Overview

​Usage

​File Inputs and Structured Output

​What AMP Adds

Distributed State

Enterprise Authentication

gRPC Transport

Context Lifecycle

Signed Webhooks

Multi-Transport

​Distributed State Management

​Storage Layers

​Enterprise Authentication

​Extended Agent Cards

​gRPC Transport

​Context Lifecycle Management

​Lifecycle States

​Signed Push Notifications

​Signature Headers

​Security Properties

​Distributed Event Streaming

​Multi-Transport Endpoints

​Version and Extension Negotiation

​Version Negotiation

​Extension Validation

​Next Steps

Overview

Usage

File Inputs and Structured Output

What AMP Adds

Distributed State Management

Storage Layers

Enterprise Authentication

Extended Agent Cards

gRPC Transport

Context Lifecycle Management

Lifecycle States

Signed Push Notifications

Signature Headers

Security Properties

Distributed Event Streaming

Multi-Transport Endpoints

Version and Extension Negotiation

Version Negotiation

Extension Validation

Next Steps