What is the A2A protocol?

Agent-to-Agent (A2A) protocol is an open standard for secure, efficient, and interoperable communication between autonomous software agents. With the rise of AI agents across industries, a consistent method for agents to discover, exchange information, and collaborate is crucial.

A2A provides a structured framework for interaction. Each agent publishes a digital profile outlining its capabilities, communication preferences, and security credentials. During contact initiation, agents exchange profiles, authenticate each other, and negotiate collaboration parameters, ensuring seamless cooperation across architectures and organisational boundaries.

The protocol uses web technologies like HTTP and JSON, simplifying integration for technical teams. Security is prioritised, with identity verification and encrypted data exchange included. By standardising communication, A2A enables scalable, flexible, and secure multi-agent systems adaptable to various use cases.

Who we are and what we are building

We are hellolang and have created Aigon, an AI-powered solution that helps development teams modernise legacy .NET systems. Our platform analyses codebases to identify technical debt and quality issues across the .NET ecosystem.

Aigon uses specialised AI agents to provide insights into code health, detect problematic patterns, and identify unused code. Beyond analysis, we are expanding to offer real-time documentation, AI-assisted test creation, and autonomous maintenance of legacy systems.

As our capabilities grow, so does communication complexity between our AI agents. Exploring standardised protocols like A2A is critical to our product's future.

We love open standards and strongly believe in their value to drive technological innovation

We see that open standards often serve as a catalyst for innovation. They enable interoperability, reduce vendor lock-in, and create ecosystems where technologies can evolve collaboratively rather than in isolation.

How Aigon operates today

Currently, our system uses a custom-built protocol implemented over SignalR that handles a range of essential functions:

Session management and state synchronisation
Message streaming with support for incremental updates via fragments
Interactive user input mechanisms (including specialised question flows)
Structured question/answer flows with multiple choice support
File proposal and approval workflows
Status reporting using a rich state model

This approach has served us well. However, as we scale and integrate with more services, we face increasing maintenance overhead, greater integration complexity with external systems, and challenges in documenting our bespoke approach for partners. Each new integration requires custom client implementations, creating technical debt that slows our capacity to innovate.

Reasons A2A protocol is promising

The A2A protocol is designed to enable communication between different AI agents. Based on JSON-RPC 2.0 over HTTP(S), it addresses many of the same challenges we have solved internally, but with the potential benefits of broader industry support:

Standardised Task Lifecycle: A2A defines clear states (submitted → working → input-required → completed/cancelled/failed) that provide a foundation for conversation flows. While not a perfect match for our more specialised states (like WaitingForFeedback or OutputtingUserText), they cover the core progression of a task and could be enhanced with custom metadata to support our specific needs.
Rich Content Support: The protocol's structured support for different content types via Part objects (text, files, structured data) unifies content handling. The DataPart type specifically could support our structured form needs, though we'd likely need to establish conventions for representing multiple-choice questions and specialised input forms.
Streaming Capabilities: A2A uses Server-Sent Events (SSE) via tasks/sendSubscribe for streaming, which differs from our fragment-based approach. This provides a standards-based alternative to our custom fragmentation logic, though we had to evaluate any performance differences in high-throughput scenarios compared to our SignalR implementation.
Interactive Flows: While A2A's input-required state offers a foundation for handling mid-conversation prompts, we need to extend it with metadata to preserve the rich semantics of our current AskQuestion and RequestUserInput patterns. This would ensure we maintain the distinction between free-form input and structured question flows.
File Handling: Our current ProposeFileUpdates workflow is more specialised than A2A's generic FilePart approach. A2A treats files as content artefacts with optional metadata, whereas our system has specific semantics around proposing, reviewing, and confirming changes. We could preserve this by using A2A's DataPart to carry the structured before/after content with approval metadata.
Communication Models: A2A supports both request/response and streaming modes and offers push notifications. This pattern could replace or complement our SignalR-based real-time updates for certain scenarios.

A practical example: multi-turn conversation

To illustrate both the benefits and implementation considerations, here is how a complex interaction might map between systems:

Our Current Protocol

sequenceDiagram autonumber participant C as Client participant S as Server C->>S: AppendUserMessage(query) S-->>C: AppendAssistantFragment(stream partial response) S-->>C: AskQuestion(request clarification) C->>S: RespondToQuestion(user selection) S-->>C: AppendAssistantFragment(continue response) S-->>C: ProposeFileUpdates(before & after) C->>S: FileUpdateResponse(confirm changes) S-->>C: UpdateStatus(state="Finished")

With A2A Protocol

sequenceDiagram autonumber participant C as Client participant S as Server C->>S: tasks/sendSubscribe(Message(query)) S-->>C: TaskStatusUpdateEvent(state="working") S-->>C: TaskArtifactUpdateEvent(stream partial response) S-->>C: TaskStatusUpdateEvent(state="input-required") C->>S: tasks/send(DataPart(selection)) S-->>C: TaskStatusUpdateEvent(state="working") S-->>C: TaskArtifactUpdateEvent(stream continuation) S-->>C: TaskArtifactUpdateEvent(file updates + metadata) C->>S: tasks/send(DataPart(approvals)) S-->>C: TaskStatusUpdateEvent(state="completed", metadata="Finished")

This comparison highlights that while A2A provides a solid foundation, we still need to establish conventions within its extensibility mechanisms (particularly metadata and DataPart structures) to preserve the semantics of our specialised interactions. The benefit would be using a standardised base protocol while maintaining our differentiated capabilities.

Re-imagining our frontend as a user agent

Perhaps most intriguing is the opportunity to reposition our frontend as a true "user agent" that communicates with our systems using this standardised protocol. This shift would:

Enhance Interoperability: Allow easier integration with third-party AI services that also implement A2A, creating a plug-and-play ecosystem around our platform. For instance, we could easily incorporate specialised coding agents or domain-specific assistants without creating custom bridges.
Future-Proof Development: Align with emerging industry standards, positioning us to benefit from tools, libraries, and services built around the A2A ecosystem as they emerge from the broader community.
Enable New Capabilities: We could more readily implement multi-agent collaboration patterns by adopting an ecosystem approach. For example, our code generation assistant could seamlessly delegate specialised tasks (like database schema design or security review) to purpose-built agents without requiring users to switch contexts.

The path forward

We're still in the exploratory phase, evaluating how well A2A aligns with our specific requirements. Our next steps include:

Building prototypes to evaluate key A2A protocol features, particularly focusing on:

Streaming performance compared to our current SignalR implementation

Latency implications of the HTTP/SSE model versus persistent connections

Developing extensions within A2A's metadata model to support our specialised interaction patterns

Creating a mapping specification that defines:

How our current protocol states translates to A2A states with appropriate metadata

Conventions for representing questions, file operations, and other structured interactions using A2A's content model

Error handling and recovery strategies aligned with A2A's error codes

Developing a transition plan that:

Allows for parallel operation of both protocols during migration

Provides adapter layers to minimise client-side changes

Identifies which aspects of our current protocol might need to be preserved as extensions

Summary

To conclude, embracing the A2A protocol marks a major advancement for hellolang and the Aigon platform. Transitioning to an open, industry-standard method for agent communication allows us to simplify integration, enhance interoperability, and ensure our architecture remains relevant as the AI landscape develops.

A2A provides a solution to decrease technical debt within our communication layer while paving the way for a more interconnected and effective product range. To support our specialized workflows, we will need to make some adjustments. However, standardisation will lead to better collaboration with outside partners and align us with new best practices. This makes A2A a strong base for our next phase of innovation.

We look forward to continuing our exploration and sharing our advancements as we prototype, expand, and gradually transition to this new protocol.

Exploring A2A