a2a-setup

A2A (Agent2Agent) Setup Guide

When NOT to use A2A

Several agents in the same project are not a reason to use A2A. If the user wants agents in one project to work together ("connect these two agents", "let the triage agent hand off to the billing agent"), use Cognigy's native Handover to AI Agent tool on the calling AI Agent node. It transfers the conversation to another AI Agent in the same or a different Flow and keeps the conversation context. A2A would instead publish an endpoint, add an Agent Card, auth and network latency, and run the target as a separate conversation.

This plugin cannot create a Handover to AI Agent tool yet. Tell the user to add it in the Cognigy UI (AI Agent node → Tools → Add Tool → Handover to AI Agent). Don't build an A2A setup as a workaround.

Use A2A only when at least one of these holds:

• The target agent is outside the project: an external or third-party A2A agent, another team's deployment, another project or tenant.
• The user wants to expose a Cognigy agent to outside callers over A2A.
• The user explicitly asks for A2A by name.

If it's unclear whether the user means in-project handover or A2A, ask.

Read this first

• manage_a2a_server publishes a callable endpoint. With authenticationType: "none" anyone who has the URL can call the agent. Confirm with the user before you create one, and tell them that.
• Gotcha (Cognigy targets only): a manage_a2a_server endpoint lives at /a2a/v1/<URLToken>, not the plain endpoint URL. Always copy agentBaseUrl straight from that tool's response — don't build it yourself. External/third-party agents don't have this quirk; just use whatever base URL they publish.
• Always check liveCheck on the manage_a2a_server response before telling the user the agent is ready — created: true alone doesn't mean it's callable yet. Every create/update fetches the Agent Card live and returns liveCheck.reachable. This works for API-key endpoints too: the key guards message requests, not the Agent Card.