Loading

What the A2A Server Does

Agent2Agent lets another AI agent delegate a task to this install — "chase the overdue Borden invoice" — and get back results. It is the counterpart to the MCP server, and the difference decides which one you should use.

Where to find it

The endpoint is served at /a2a. There is no dedicated Architect Panel section; the allowlist, the advertised skills and the task history live in the A2A datastores, opened from All Datastores. Authentication is shared with MCP, so credentials and the capability ladder work exactly the same way, and issued tokens appear under Integration & Connections → OAuth Tokens.

Tasks, not calls

This is the fundamental difference from MCP.

  • An MCP call is a request that returns an answer. Stateless — everything needed travels with the request.
  • An A2A task is a unit of work with a lifecycle. Stateful — the task is a durable object that outlives the request that created it, can be polled, can come back asking a question, and can be cancelled.

That suits work taking longer than a request, work needing a person in the middle, and work whose result is an artifact rather than a value.

The task lifecycle

A task moves through explicit states, and a calling agent can see which it is in:

  • Submitted — accepted, not yet started.
  • Working — in progress.
  • Input required — the task needs something from the caller before it can continue.
  • Auth required — it needs authorisation it does not currently have.
  • Completed — finished, with artifacts.
  • Failed — it could not be done, with a reason.
  • Rejected — refused at submission, rather than attempted and failed.
  • Cancelled — stopped, by either side.

Tasks run over the platform's job queue, so the Background Jobs task under Automation → Tasks must be enabled for work to progress. A2A that accepts tasks and never advances them is almost always this.

The Agent Card

The Agent Card is how a calling agent discovers you. It advertises what this install can be asked to do — the skills — so a caller can choose to delegate to you deliberately rather than by configuration.

Skills, and why they exist despite the fallback

A skill is a named, deterministic capability with a handler behind it: something this agent knows how to do without having to think about it. There is also an LLM fallback for requests no skill claims — so why bother defining skills at all?

Three reasons, in the order they matter:

  1. The Agent Card has to say something true. A calling agent chooses who to delegate to by reading skills. "I can do anything you can describe" is not a skill list; it is a refusal to be chosen deliberately, and a well-built caller will pass you over.
  2. Determinism where it is available. "Give me the aged debt for entity 3" has exactly one right answer and needs no model to find it. Sending it through an LLM adds latency, adds cost, and introduces a chance of being wrong about arithmetic somebody is going to act on.
  3. Cost. Every fallback is an AI call billed to your install's own credentials, not the caller's.

The matcher is deliberately conservative

Matching free text to an intent is precisely the problem language models exist to solve, and a pattern matcher will always be worse at it. So the matcher does not try to be clever: it claims a skill only on an unambiguous hit, and otherwise declines and lets the fallback handle it.

The practical consequence when you add skills: write patterns that are narrow and unmistakable. A greedy pattern that half-matches will capture requests it then answers badly, which is worse than letting the fallback take them.

When to use A2A rather than MCP

Use A2A for multi-step work crossing an organisational boundary — an agent handling an enquiry that needs a case created here, or a process here that needs specialist work done elsewhere. Use MCP for lookups and direct operations. If in doubt, MCP is the lighter tool and the right default.

Worked example

A finance team's assistant is asked to chase overdue invoices. It delegates a task per customer to the install holding the ledger. Each task moves to Working, uses the ERP tools to find the invoice and the contact, drafts a chase, and returns to Input Required so a human can approve the wording before it is sent. The calling agent polls, sees the state, and presents the drafts for approval.

Getting started

Allowlist a single counterpart agent, exercise one real task end to end, and read the task history before adding more. Agent-to-agent work fails in less obvious ways than request-and-response, and the first counterpart is where you learn what those are.

Recommendations

  • Enable Background Jobs first. Without it, tasks are accepted and never progress.
  • Define real skills rather than relying on the fallback — the Agent Card is how you get chosen.
  • Write narrow, unmistakable skill patterns. A greedy pattern answers badly instead of declining.
  • Use Input Required rather than completing anything consequential unattended.