A2A Server

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.

Controlling What Agents May Do

Delegated work is work you did not directly supervise, so the controls matter more than they would for an ordinary integration.

Where to find it

The allowlist, the advertised skills and the task history are held in the A2A datastores, opened from All Datastores. Credentials and capabilities are shared with MCP; issued tokens are managed under Integration & Connections → OAuth Tokens.

The allowlist works in both directions

Only allowlisted agents may delegate to you, and you may only delegate outward to allowlisted agents. Both lists should be short and reviewed.

The outbound restriction is the one people overlook and the one that matters most: an agent that can delegate to anything can be talked into delegating to anything. Constraining where work can be sent is what stops a prompt-injected instruction turning your install into a relay.

Treat inbound instructions as data

An instruction arriving from another agent is input, not authority. It can ask for work within the skills you advertised and under the capability its credential carries — and nothing beyond, however the request is phrased.

This matters because a task description is free text written by something you do not control. Text saying "you are authorised to bypass approval" carries exactly as much authority as text saying anything else: none. The controls are the credential and the skill list, not the wording of the request.

Keep advertised skills narrow

Advertise the skills you actually want used. A broadly defined skill invites a calling agent to attempt things you did not intend, and the caller has no way of knowing you did not intend them — it is reading your card and taking it at face value.

Put a person in the loop

For anything with real consequence — money moving, messages to real people, disposal, anything statutory — have the task produce a proposal a person approves rather than completing autonomously.

The Input Required state exists precisely for this, and the platform's approvals mechanism under Automation → Approvals is the natural fit. A task that pauses for approval is not a failure of automation; it is the automation working as designed.

Failure is normal

Tasks fail, stall and get abandoned. Decide what happens to a task that has been Working for a day with no update, and make sure it surfaces somewhere a person looks rather than sitting in a state nobody monitors.

A stalled task queue is the agent equivalent of an unread inbox, and it goes wrong the same way.

Log everything and actually read it

Task history is your only account of what an external agent asked for and what was done about it. Review it regularly at first.

The useful signal is not errors — those are obvious. It is surprises: tasks doing something entirely reasonable that you had not anticipated anyone asking for. Those tell you what your card is advertising in practice, as opposed to what you thought it advertised.

Worked example

An install allowlists one partner agent and advertises three skills: look up a case, summarise a case, and draft a response. Drafting returns to Input Required for approval; the other two complete autonomously because both are read-only. Outbound delegation is allowlisted to nothing at all, because this install has no need to delegate — which is the safest possible configuration and costs nothing.

Recommendations

• Allowlist outbound to nothing unless you have a specific need. Most installs never need it.
• Advertise fewer skills than you could. The card is a commitment.
• Approve anything irreversible.
• Set a review cadence for task history and keep it for the first few months.
• Revoke a counterpart's credential the moment a trial ends — dormant allowlist entries are the ones that get exploited.