Designing an Audio Content Platform on Google's A2A (Agent2Agent) Protocol

This post (originally published in Chinese on zhichai.net) lays out a full architecture for an audio content platform — covering both live streaming and on-demand audio — that uses Google's open Agent2Agent (A2A) protocol as its core communication framework.

Key points

• Why A2A: A2A is an open standard that lets AI agents built on different frameworks and vendors communicate, discover each other's capabilities, negotiate interactions, and collaborate on tasks — without exposing internal state, memory, or tools ("black-box" cooperation). For an audio platform with many specialized agents, this replaces brittle point-to-point integrations with a unified collaboration paradigm.

Core A2A concepts used in the design

• AgentCard: A JSON "business card" published at /.well-known/agent.json describing an agent's identity, skills, endpoints, and authentication requirements — enabling standardized, automatic discovery. E.g., a transcoder agent advertises skills like "mp3-transcode" and "aac-transcode".
• Task: The basic unit of collaboration, with a unique ID and lifecycle states (SUBMITTED, WORKING, INPUT_REQUIRED, COMPLETED, FAILED), making long-running audio processing trackable and controllable.
• Message & Part: Messages carry a sender role plus typed Parts — TextPart (text), FilePart (files by URI or inline bytes, e.g., audio clips), and DataPart (structured JSON) — so a single message can mix instructions, files, and metadata.
• Artifact: Immutable task outputs composed of Parts; tasks may produce multiple Artifacts, and large outputs support streaming delivery with append: true / lastChunk: true (useful for delivering transcoded audio incrementally).
• Streaming & Push Notifications: SSE-based streaming (capabilities.streaming: true, SendStreamingMessage) pushes TaskStatusUpdateEvent and TaskArtifactUpdateEvent for real-time progress; webhook-based push notifications cover long tasks and disconnected clients, with clients then pulling results via GetTask.

Architecture: four agent groups

1. Live monitoring & orchestration ("audio command center"): An orchestrator agent creates live-stream transcoding tasks, subscribes to streaming updates to track progress, manages multiple synchronized streams (e.g., multi-bitrate outputs for sports events), and handles exceptions via INPUT_REQUIRED states (e.g., source interruption).

2. On-demand processing & distribution: A coordinator agent chains transcoding, watermark embedding, metadata extraction (ID3 tags), and quality-check sub-tasks, then delivers final Artifacts to CDN/object storage. Sub-steps are pluggable — skip watermarking, or add a noise-reduction agent without touching existing components.

3. User-facing AI assistant: Parses natural-language requests ("recommend relaxing jazz", "play last night's replay"), invokes recommendation and retrieval agents with user-profile DataParts, supports multi-turn dialogue via INPUT_REQUIRED, and translates results back into conversational replies.

4. Content moderation & copyright protection: A moderation agent checks live segments periodically (e.g., every minute) and screens on-demand uploads; a copyright agent matches audio fingerprints against rights databases. Both support asynchronous analysis via push notifications, letting callers continue other work until results arrive.

Interface mapping

• AgentCard discovery: HTTP fetch of the published card; new agents become callable without code changes.
• SendMessage / SendStreamingMessage: Starts tasks; streaming variant used for live transcoding (progress and partial audio pushed in real time), non-streaming for batch on-demand jobs.
• GetTask / ListTasks: Final result retrieval, recovery after stream disconnection, and operator dashboards for monitoring WORKING tasks.
• CancelTask: Emergency interruption (e.g., policy violation mid-stream), user-cancelled processing, and timeout handling.
• Push notification config (CreateTaskPushNotificationConfig): Webhook URLs + auth for long transcodes, deferred recommendations, and coverage during brief disconnections.

Conclusion

The result is a loosely coupled agent ecosystem with strong extensibility (new capabilities = new agents + AgentCards), flexible workflow composition, both real-time and asynchronous support, and security isolation between agents. The author notes challenges — agent registry management, cross-agent transactional consistency, and increased observability/ops complexity — suggesting centralized agent directories and unified logging/tracing as mitigations.