Skip to main content
Transport-specific guide for integrating AdCP using the Agent-to-Agent Protocol. For task handling, status management, and workflow patterns, see Core Concepts.

A2A Client Setup

1. Initialize A2A Client

2. Verify Agent Card

3. Send Your First Task

Message Structure (A2A-Specific)

Multi-Part Messages

A2A’s key advantage is multi-part messages combining text, data, and files:

Skill Invocation Methods

Natural Language (Flexible)

Explicit Skill (Deterministic)

Status Handling: See Core Concepts for complete status handling patterns.

A2A Response Format

New in AdCP 1.6.0: All responses include unified status field.

Canonical Response Structure

AdCP responses over A2A MUST include at least one DataPart (kind: ‘data’) containing the task response. A TextPart (kind: ‘text’) for human-readable messages is recommended but optional.
For complete canonical format specification, see A2A Response Format.

A2A-Specific Fields

  • taskId: A2A task identifier for streaming updates
  • contextId: Automatically managed by A2A protocol
  • artifacts: Multi-part deliverables with text and data parts
  • status: Same values as MCP for consistency (A2A TaskState enum)

Processing Artifacts

AdCP responses use the last DataPart as authoritative when multiple data parts exist (e.g., from streaming operations):
For complete response structure requirements, error handling, and implementation patterns, see A2A Response Format.

Push Notifications (A2A-Specific)

A2A defines push notifications natively via PushNotificationConfig. When you configure a webhook URL, the server will POST task updates directly to your endpoint instead of requiring you to poll.

Best Practice: URL-Based Routing

Recommended: Encode routing information (task_type, operation_id) in the webhook URL, not the payload. Why this approach?
  • Industry standard pattern - Widely adopted for webhook routing across major APIs
  • Separation of concerns - URLs handle routing, payloads contain data
  • Protocol-agnostic - Same pattern works for MCP, A2A, REST, future protocols
  • Cleaner handlers - Route with URL framework, not payload parsing
URL Pattern Options:
Example Configuration:
For webhook payload formats, protocol comparison, and detailed handling examples, see Task Management - Push Notification Integration.

SSE Streaming (A2A-Specific)

A2A’s key advantage is real-time updates via Server-Sent Events:

Task Monitoring

Real-Time Updates Example

A2A Webhook Payload Examples

Example 1: Task payload for completed operation When a task finishes, the server sends the full Task object with task result in .artifacts:
CRITICAL: For completed or failed status, the AdCP task result MUST be in .artifacts[0].parts[], NOT in status.message.parts[]. Example 2: TaskStatusUpdateEvent for progress updates During execution, interim status updates can include optional data in status.message.parts[]:
All status payloads use AdCP schemas: Both final statuses (completed/failed) and interim statuses (working, input-required, submitted) have corresponding AdCP schemas referenced in async-response-data.json. Note that interim status schemas are evolving and may change in future versions, so implementors may choose to handle them more loosely.

A2A Webhook Payload Types

Per the A2A specification, the server sends different payload types based on the situation: For AdCP, most webhooks will be:
  • Task for final results (completed, failed)
  • TaskStatusUpdateEvent for progress updates (working, input-required)

Webhook Trigger Rules

Webhooks are sent when all of these conditions are met:
  1. Task type supports async (e.g., create_media_buy, sync_creatives, get_products)
  2. pushNotificationConfig is provided in the request
  3. Task runs asynchronously — initial response is working or submitted
If the initial response is already terminal (completed, failed, rejected), no webhook is sent—you already have the result. Status changes that trigger webhooks:
  • working → Progress update (task actively processing)
  • input-required → Human input needed
  • completed → Final result available
  • failed → Error details
  • canceled → Cancellation confirmed

Data Schema Validation

The status.message.parts[].data field in A2A webhooks uses status-specific schemas: Schema reference: async-response-data.json

Webhook Handler Example

Context Management (A2A-Specific)

Key Advantage: A2A handles context automatically - no manual context_id management needed.

Automatic Context

Explicit Context (Optional)

vs. MCP: Unlike MCP’s manual context_id management, A2A handles session continuity at the protocol level.

Multi-Modal Messages (A2A-Specific)

A2A’s unique capability - combine text, data, and files in one message:

Creative Upload with Context

Campaign Brief + Assets

Available Skills

All AdCP tasks are available as A2A skills. Use explicit invocation for deterministic execution: Task Management: For comprehensive guidance on tracking async operations across all domains, polling patterns, and webhook integration, see Task Management.

Skill Structure

Available Skills

  • Media Buy: get_products, list_creative_formats, create_media_buy, update_media_buy, sync_creatives, get_media_buy_delivery, list_authorized_properties, provide_performance_feedback
  • Signals: get_signals, activate_signal
Task Parameters: See Media Buy and Signals documentation for complete parameter specifications.

Agent Cards

A2A agents advertise capabilities via Agent Cards at .well-known/agent.json:

Discovering Agent Cards

Sample Agent Card Structure

AdCP Extension

Recommended: Include the extensions.adcp field in your agent card to declare AdCP support programmatically.
Extension Structure: See the AdCP extension schema for complete specification. Benefits:
  • Clients can discover AdCP capabilities without making test calls
  • Declare which protocol domains you implement (media_buy, creative, signals)
  • Enable compatibility checks based on version

Integration Example

A2A-Specific Considerations

Error Handling

Creative Upload Error Handling

For uploading creative assets and handling validation errors, use the sync_creatives task. See sync_creatives Task Reference for complete testable examples. The @adcp/client library handles A2A artifact extraction automatically, so you don’t need to manually parse the response structure.

Best Practices

  1. Use hybrid messages for best results (text + data + optional files)
  2. Check status field before processing artifacts
  3. Leverage SSE streaming for real-time updates on long operations
  4. Reference Core Concepts for status handling patterns
  5. Use agent cards to discover available skills and examples

Next Steps

For status handling, async operations, and clarification patterns, see Core Concepts - this guide focuses on A2A transport specifics only.