A2A Compatibility

Overview

The Agent developed through our platform naturally supports Agent to Agent capabilities. The Publish-Subscribe mode can be used for message communication within the AgentOpera framework. At the same time, the Agent developed by AgentOpera framework can be seamlessly compatible with the Google A2A protocol and interoperate with Agents developed by other frameworks.

Concept and flow

One of the biggest challenges in enterprise AI adoption is getting agents built on different frameworks and vendors to work together. That’s why Google created an open Agent2Agent (A2A) protocol, a collaborative way to help agents across different ecosystems communicate with each other. Google is driving this open protocol initiative for the industry because this protocol will be critical to support multi-agent communication by giving your agents a common language – irrespective of the framework or vendor they are built on. With A2A, agents can show each other their capabilities and negotiate how they will interact with users (via text, forms, or bidirectional audio/video) – all while working securely together.

The Agent2Agent (A2A) protocol facilitates communication between independent AI agents. Here are the core concepts:

• Agent Card: A public metadata file (usually at /.well-known/agent.json) describing an agent's capabilities, skills, endpoint URL, and authentication requirements. Clients use this for discovery.

• A2A Server: An agent exposing an HTTP endpoint that implements the A2A protocol methods (defined in the json specification). It receives requests and manages task execution.

• A2A Client: An application or another agent that consumes A2A services. It sends requests (like tasks/send) to an A2A Server's URL.

• Task: The central unit of work. A client initiates a task by sending a message (tasks/send or tasks/sendSubscribe). Tasks have unique IDs and progress through states (submitted, working, input-required, completed, failed, canceled).

• Message: Represents communication turns between the client (role: "user") and the agent (role: "agent"). Messages contain Parts.

• Part: The fundamental content unit within a Message or Artifact. Can be TextPart, FilePart (with inline bytes or a URI), or DataPart (for structured JSON, e.g., forms).

• Artifact: Represents outputs generated by the agent during a task (e.g., generated files, final structured data). Artifacts also contain Parts.

• Streaming: For long-running tasks, servers supporting the streaming capability can use tasks/sendSubscribe. The client receives Server-Sent Events (SSE) containing TaskStatusUpdateEvent or TaskArtifactUpdateEvent messages, providing real-time progress.

• Push Notifications: Servers supporting pushNotifications can proactively send task updates to a client-provided webhook URL, configured via tasks/pushNotification/set.

Typical Flow:

1. Discovery: Client fetches the Agent Card from the server's well-known URL.

2. Initiation: Client sends a tasks/send or tasks/sendSubscribe request containing the initial user message and a unique Task ID.

3. Processing:

   • (Streaming): Server sends SSE events (status updates, artifacts) as the task progresses.

   • (Non-Streaming): Server processes the task synchronously and returns the final Task object in the response.

4. Interaction (Optional): If the task enters input-required, the client sends subsequent messages using the same Task ID via tasks/send or tasks/sendSubscribe.

5. Completion: The task eventually reaches a terminal state (completed, failed, canceled).

Integration

This following demonstrates a simple image generation agent built with AgentOpera and exposed through the A2A protocol.

This agent utilizes AgentOpera and the Google Gemini API to generate images based on text prompts. The A2A protocol enables standardised interaction with the agent, allowing clients to send requests and receive images as artifacts.