Designing an Audio Content Platform on Google's A2A Protocol

This post proposes an architecture for a live/on-demand audio content platform built on Google's Agent2Agent (A2A) protocol, an open standard that lets AI agents built on different frameworks and by different vendors communicate, discover each other, and collaborate securely without exposing internal state, memory, or tools.

Key points

• Why A2A for audio platforms: An audio platform involves many cooperating agents (transcoding, metadata/recommendation, copyright detection, moderation). Traditional point-to-point APIs scale poorly; A2A provides a unified collaboration model where new agents are integrated simply by publishing their capabilities.
• Core A2A concepts:
• AgentCard: A JSON "business card" describing an agent's identity, skills, endpoints, and authentication requirements, published at /.well-known/agent.json for standardized, automatic discovery.
• Task: The basic unit of collaboration, with a unique ID and lifecycle states such as SUBMITTED, WORKING, INPUT_REQUIRED, COMPLETED, and FAILED — making long-running work trackable and controllable.
• Message & Parts: Messages carry a sender role and typed parts — TextPart (text), FilePart (files like audio, by URI or inline bytes), and DataPart (structured JSON) — enabling multimodal communication in one channel.
• Artifact: Immutable task outputs composed of parts; a task can produce multiple artifacts, and large outputs support streaming via append: true chunks ending with lastChunk: true (e.g., emitting transcoded audio progressively so playback can start early).
• Streaming & Push Notifications: SSE-based streaming (capabilities.streaming: true) delivers TaskStatusUpdateEvent and TaskArtifactUpdateEvent in real time; webhook-based push notifications cover long tasks and disconnected clients.

Architecture components

1. Live monitoring & orchestration ("command center"): Coordinates rather than processes media. It launches live transcoding tasks, subscribes to streaming status updates, manages multiple synchronized bitrate streams, and handles exceptions (e.g., INPUT_REQUIRED on source interruption, failover to backup transcoders).

2. On-demand processing & distribution: A coordinator agent chains sub-tasks — transcoding (FilePart + parameter DataPart), watermark embedding, metadata extraction, quality checks — aggregates the resulting Artifacts, and uploads finished audio to CDN/object storage. Steps are pluggable: skip watermarking, or add a new denoising agent without touching existing code.

3. User-facing AI assistant: Parses natural-language requests ("recommend relaxing jazz", "replay last night's stream"), invokes recommendation and retrieval agents with user-profile DataParts, and supports multi-turn dialogue via INPUT_REQUIRED when more information is needed.

4. Moderation & copyright gatekeepers: A moderation agent samples live audio periodically and screens on-demand uploads for prohibited content; a copyright agent compares fingerprints against rights databases. Both support asynchronous completion via push notifications, with policy enforcement (takedowns, human review) by the orchestrator.

Interface usage

• AgentCard: HTTP retrieval for dynamic service discovery — new agents become usable without code changes.
• SendMessage / SendStreamingMessage: Task initiation; streaming variant used for live transcoding to receive incremental output, non-streaming for on-demand jobs.
• GetTask / ListTasks: Status polling, final result retrieval after stream disconnection, and operational dashboards for observability.
• CancelTask: Emergency interruption (e.g., violation detected mid-stream), user-initiated cancellation, and timeout handling.
• Push Notification Config: Webhook setup (CreateTaskPushNotificationConfig) so long tasks (multi-minute transcodes, deep moderation analysis) notify callers without persistent connections.

Summary

The resulting platform is an ecosystem of single-purpose agents: highly extensible (new capability = new agent + AgentCard), flexibly composable per workflow, supporting both real-time (streaming) and asynchronous (push) patterns, and securely isolated (agents exchange only necessary information; transport security via HTTPS/OAuth2). Acknowledged challenges include agent registry governance, cross-agent transactional consistency, and increased observability/ops complexity, addressable with a central agent directory and unified logging/tracing. The post concludes that A2A enables a loosely coupled, high-cohesion architecture where complex systems evolve as independently deployable, cooperating intelligent units.