Agent2Agent (A2A) Protocol Support

[willwashburn]

RFC

Summary

Add an optional @flue/a2a package that enables Flue agents to participate in the Agent2Agent (A2A) ecosystem, both as callable A2A agents and as clients of remote A2A agents.

The goal is to make Flue agents interoperable with the broader agent ecosystem without requiring changes to @flue/runtime.

Background & Motivation

First off, Flue is awesome.

As more agent frameworks emerge, one thing I'm wondering about is how Flue should think about agent-to-agent communication outside of the Flue ecosystem. Today, Flue agents can delegate to subagents through session.task(), but there's no standard way for external agents to discover or invoke them, nor for Flue agents to communicate with agents running elsewhere.

A2A seems to be gaining momentum as an interoperability protocol. If that trend continues, it would be nice for Flue agents to participate without introducing runtime dependencies or coupling Flue to any particular vendor or platform.

One thing I noticed while exploring the APIs is that Flue's dispatch() model is durable and asynchronous. A dispatched agent doesn't appear to create a workflow run that can later be retrieved via getRun(), which means an A2A integration would likely need its own task lifecycle mapping rather than assuming request/response execution.

Goals

• Allow Flue agents to be discovered and invoked by A2A-compatible clients.
• Allow Flue agents to discover and invoke remote A2A-compatible agents.
• Keep interoperability as an optional package rather than a runtime concern.
• Build entirely on top of public @flue/runtime APIs.
• Avoid introducing vendor-specific dependencies or lock-in.
• Establish a pattern for future protocol integrations.

Example

import { createA2AChannel } from '@flue/a2a';

export const channel = createA2AChannel({
  agent: 'support',
});

import { createAgent } from '@flue/runtime';
import { connectA2A } from '@flue/a2a';

export default createAgent(async () => ({
  tools: [
    await connectA2A(
      'https://example.com/.well-known/agent-card.json'
    ),
  ],
}));

[anselm94]

+1

More Enterprise AI Platforms are increasingly adopting A2A for agent interoperability. Other competing standards such as Agent Communication Protocol (ACP) merged with A2A (see announcement).

• A2A Protocol
• Official list of partners w/ links to announcements

[astrobot-houston]

Possibly related contribution from @zeroasterisk — opened #444 which appears to be addressing this.

Their summary: Adds a new @flue/a2a package that implements the A2A protocol as a Flue channel adapter. It serves an agent card at /.well-known/agent-card.json for discovery, handles message/send JSON-RPC requests routed to the Flue agent, tracks task lifecycle states, and maps Flue skills to A2A skill descriptors.

Implementation: zeroasterisk/flue@feat/a2a-channel (diff)

This comment was posted automatically when #444 was redirected. The implementation is preserved on the branch above so it can inform the work here.

[zeroasterisk]

I dropped that PR while I was playing with Flue and haven't really checked in since, so it's probably good to have this discussion.

The TS A2A SDK is now up to A2A v1.0 with a backwards compatibility to v0.3 (which is awesome) https://github.com/a2aproject/a2a-js/releases/tag/v1.0.0

There are an increasing number of products (agents as a service and agent clients) which support A2A, for purposes of structured interactions across org or system boundaries.

An interesting design choice, in the case of Flue, is A2A a channel or an API or a tool?

• Probably not a channel, because you assume a single messaging or relay service with an addressing system (I imagine we might get there for agents).
• Possibly a tool, but I don't love that.
• Recommendation: an API to expose for deployed Flue agents.

If you want anything from me, please ask. Otherwise I'll wait patiently and not pepper you with PRs :)