A2A
A2A stands for Agent-to-Agent. It's the protocol that lets one agent call another as if it were a sub-agent — across different flows, projects, or even different platforms entirely. In Anter, A2A works in both directions: you can expose your flow as an A2A target, and you can configure sub-agents to delegate to external agents via A2A.
Your agent's A2A card
Every flow has an agent card — a machine-readable description of what it does, what it's capable of, and how to reach it. Remote agents use this card to discover and call your flow.
Click A2A in the graph toolbar to view your agent's current card. The card shows:
- Name and version — the agent's display name and current version number
- Description — what the agent does (taken from the root agent's description field)
- URL — the A2A endpoint remote agents call to reach this flow
- Capabilities — the protocol features this agent supports
- Skills — domain areas this agent covers, derived from the skills assigned to its sub-agents
A discovery banner at the top of the panel tells you the current visibility of your card:
| Banner | Meaning |
|---|---|
| Publicly discoverable | Any agent that knows the discovery URL can find and call this agent |
| Project-scoped discovery | Only callers with a valid project API key can discover this agent |
| Public discovery disabled | Public A2A publishing is turned off at the platform level |
No configuration is required to make your agent discoverable — it's automatic based on your platform settings.
Calling a remote agent from a sub-agent
A sub-agent can delegate work to an agent running outside your flow — in another project or on a different platform entirely. Configure this in the sub-agent editor by changing the Execution target to Remote A2A.
Three fields appear:
Remote base URL — the base address of the remote agent's platform (for example, https://runner.example.com). Anter appends the A2A path automatically and shows you the computed endpoint below the field.
Remote project ID — the project that contains the remote agent, if the remote platform uses project scoping.
Remote API key — a bearer token or API key to authenticate with the remote platform. Stored encrypted and never exposed to the model.
Once configured, this sub-agent acts as a gateway — when the orchestrator routes work to it, the call is forwarded to the remote agent and the result comes back to your flow as if it were a local response.
Linking to another agent in your project
To route work to a different flow within the same project, use Internal A2A instead of Remote A2A. Change the execution target to Internal A2A and select the linked agent from the dropdown. The dropdown lists all other agents in the current project.
Internal A2A runs in-process — the handoff is fast and doesn't require external credentials. The linked agent's full graph executes independently and the result is returned to the delegating sub-agent.
Gateway nodes have no system prompt
When a sub-agent is configured as an Internal A2A or Remote A2A gateway, its system prompt field is disabled. The instructions live in the agent it points to — not in the gateway node itself. The gateway's job is purely to route.
When to use A2A
A2A is the right choice when:
- A task belongs to a specialized agent in a different project (Internal A2A)
- You want to compose your flow with an AI service on a different platform (Remote A2A)
- You're building an agent that itself orchestrates other independent agents
For sub-agents that are simply specialists within the same flow, standard connections (transfer and delegation) are simpler and don't require A2A configuration.