a2a-agents

A2A — Working with Other AI Agents

Ariadne speaks the Agent2Agent (A2A) protocol, an open standard (governed by the Linux Foundation) for letting AI agents from different vendors work together. If someone in your organisation runs an agent built on LangGraph, CrewAI, Microsoft's agent framework, or anything else that supports A2A, it can work with your Ariadne agent — and your Ariadne agent can hand work to it.

Like MCP Servers, the relationship goes both ways:

A2A or MCP?

Both connect Ariadne to things outside it, and it is easy to reach for the wrong one:

The short version: MCP adds tools your agent uses; A2A adds colleagues your agent works with. A tool answers in seconds. An A2A peer might take an hour, ask you a question halfway through, and send its answer when it's ready.

Part 1: Letting Other Agents Work With Yours

Your agent's public card

Every A2A agent publishes an agent card — a small public description saying who it is and what it can do. Other agents read it before they connect. Yours is at:

https://<your-ariadne-host>/api/.well-known/agent-card.json

It publishes your agent's name, its description, and its skills — taken live from Settings → Knowledge → Skills, so as your agent learns, the card stays current. Nothing else is exposed: no notes, no conversations, no knowledge.

Which agents appear: only agents that are visible and have their audience set to Everyone (Settings → Agents). An agent set to Only me or scoped to an organisation never appears on the public card. If you don't want any agent discoverable this way, make sure none is set to Everyone — the card then returns "no public agents".

A note for whoever runs your server: external agents look for the card at your domain root (/.well-known/agent-card.json), while Ariadne serves it under /api/. A small reverse-proxy rule mapping one to the other makes standard discovery work.

What an external agent can do

Once connected and authorised, a peer can:

• Send your agent a task and get the reply.
• Track it — every request becomes a task with a status it can poll.
• Watch it live — stream the agent's progress as it works.
• Be notified when it finishes — the peer registers a callback URL and Ariadne posts to it, so long jobs don't need a held-open connection.
• Cancel it — which genuinely stops the work, not just the current reply.

Each peer works in its own conversation. It can continue a conversation it started earlier, but it can never reach into your own chats — a peer can only see and continue work it began itself.

Permissions

An external agent connects with an access token you approve, carrying only the permissions you grant:

A token issued for A2A cannot be used against Ariadne's MCP endpoint, or the other way round, and revoking it takes effect immediately.

What it costs you

Work an external agent asks for runs on your Ariadne, using your models and counting against your usage — it is charged to whoever the access token was issued to. Treat granting A2A access the same way you would treat giving someone your API token: only for peers you trust, and worth watching in Settings → Usage after you first connect one.

Things to know before you turn it on

• Text only, for now. Peers send and receive text. Files and structured attachments are not yet accepted over A2A.
• Peer messages are treated as untrusted. Incoming text is labelled as coming from an external agent so your agent knows it is reading someone else's words, not yours.
• Your agent's normal tools are available when it works on a peer's request. Narrowing that down for external callers is planned but not done, so only connect peers you would be comfortable asking your agent for anything.
• There is no A2A page in the web UI yet. Enabling it, and issuing access to a peer, is done in server configuration by whoever runs your Ariadne instance.

Turning it on

Ask your administrator to:

1. Add an a2a entry to the OAuth:Services configuration so access tokens can be issued for it.
2. Set A2A:DefaultAgent to the agent that should answer external requests — normally the same agent shown on your card.
3. Apply the V063_A2ATasks database migration.
4. Optionally set A2A:EgressAllowlist (see below).

Part 2: Handing Work to an External Agent

Your agent can delegate to any A2A agent using the delegate_to_a2a_agent tool. You don't call it directly — just ask in chat:

"Ask the research agent at https://peer.example.com/a2a to summarise this quarter's competitor filings."

The tool returns straight away with a reference, and your conversation carries on. When the remote agent finishes, its answer appears in the conversation by itself. This matters for real delegation: remote agents can take far longer than a normal tool call, and waiting in-line would simply time out.

Your agent reads the peer's agent card first, so it knows what it's talking to before sending anything, and it can continue an earlier session with that peer rather than starting fresh each time.

Credentials for a peer

If the remote agent needs a token, store it against your agent rather than pasting it into chat. Credentials are saved per agent under the name a2a:<endpoint-url>, as either a bearer token or OAuth client-credentials details. Once stored, your agent picks it up automatically whenever it delegates to that endpoint.

Restricting where your agent may connect

Because the endpoint address can come from something your agent read — a web page, a document, another agent's reply — outbound A2A is gated by an allowlist, A2A:EgressAllowlist. Entries can be an exact host (peer.example.com), a wildcard (*.example.com), or a full URL prefix.

If the list is empty, every address is permitted. That is fine for local development and a poor idea on an internet-facing deployment — set it before you enable outbound delegation in production. When a request is blocked, your agent is told which setting to ask an administrator to change.

Compatibility

Ariadne has been built to the published v1.0 specification and tested against itself; it has not yet been exercised against a third-party A2A implementation, so treat the first connection with a new peer as a trial.

Troubleshooting

Related

• MCP Servers — connecting tools rather than agents
• Agents — agent visibility, audience, and tool collections
• Account & Organisation — tokens and usage
• Knowledge — the skills that appear on your agent card