Bidirectional Agent-to-Agent (A2A)

EKB supports the open Agent2Agent (A2A) protocol in both directions:

Direction	What it means	Where you set it up
Outbound	Your EKB agent calls an external A2A agent over HTTPS	Agent → Toolkits → Agent Communication → target type External (A2A)
Inbound	Systems outside EKB call your agent through authenticated A2A endpoints	Agent → External Access tab (agent card URL + access keys)

Tasks persist across the conversation and stay isolated to the project that owns the agent.

This is separate from calling another agent inside EKB (same toolkit, target type In EKB). For internal multi-agent patterns, see Agent Communication Toolkit.

Prerequisites

Direction	You need
Outbound	Permission to edit the agent; Agent Communication toolkit enabled; partner’s HTTPS A2A base URL (and bearer token if they require one)
Inbound	Permission to edit the agent; ability to issue External Access keys; partner able to call your API host over HTTPS with a bearer token

Outbound: call an external A2A agent

Use this when a partner or third-party system exposes an A2A-compatible agent you want your EKB agent to delegate to.

Configure

1. Open the agent → Toolkits → enable Agent Communication.
2. Add a helper-agent configuration (the UI may call this a helper or target agent card).
3. Under Where this agent lives, choose External (A2A) (not In EKB).
4. Enter the external agent’s base URL. HTTPS is required.
   • You can paste either the base URL or the full agent-card URL ending in /.well-known/agent-card.json — both are accepted.
5. Provide the partner’s API key / bearer token if required. Prefer storing it in the vault rather than pasting a literal into a shared config.
6. Click Verify Connection so EKB can fetch the agent card and confirm name, description, skills, and reachability before you save.
7. Save the agent configuration.

At runtime, your agent can hand work to that external agent the same way it would to an in-project helper — with context passed over A2A.

Outbound field checklist

Setting	Notes
Target type	Must be External (A2A)
URL	HTTPS only; http:// is rejected
Auth	Optional bearer / API key depending on the partner
Verify Connection	Use before save; failures usually mean DNS, TLS, SSRF block, or non-A2A URL

Requirements and limits

• External targets must use HTTPS.
• Discovery and calls go through EKB’s backend (with SSRF protections). A URL that verifies is one the backend can actually reach — a laptop-only hostname will not work in production.
• Treat partner tokens like any other secret: vault references preferred over pasted literals.

Inbound: let others call your EKB agent

Use this when another product, partner agent, or custom A2A client should invoke one of your EKB agents.

Agent Card URL

On the agent’s External Access tab you get an Agent Card URL shaped like:

https://<your-api-host>/a2a/agents/<agent_id>/.well-known/agent-card.json

Hand this to the other side. Their A2A client reads the card to discover what the agent can do and where to send requests.

Sharing the card URL alone does not grant access — callers still need a key you issue.

The card describes your agent’s name, description, skills (default chat skill), and JSON-RPC endpoint. Streaming is not advertised for these endpoints.

Access keys

1. Open the agent → External Access.
2. Optionally label the key (for example, Acme partner integration) so you can tell keys apart later.
3. Create a key and copy the token immediately — only a hash is stored; the secret is shown once.
4. Give the partner:
   • The Agent Card URL
   • The bearer token
5. Revoke keys you no longer need. If a secret is lost, revoke and issue a new key (you cannot retrieve the old plaintext).

Keys are scoped to that agent. A valid token for agent A cannot be used against agent B.

What external callers hit

Resource	Method / path	Purpose
Agent card	GET /a2a/agents/{agent_id}/.well-known/agent-card.json	Discovery (authenticated)
JSON-RPC	POST /a2a/agents/{agent_id}/rpc	message/send and related A2A methods

Authenticate with:

Authorization: Bearer <access-key>

Partner checklist (inbound)

1. Fetch the agent card with the bearer token.
2. Read the advertised JSON-RPC endpoint from the card.
3. Send A2A JSON-RPC requests with the same bearer token.
4. Expect tasks to remain tied to the owning project of the agent (see below).

Project isolation

Inbound A2A execution runs in the project that owns the agent. Template agents that exist in multiple projects are not shared across callers: each call is pinned to the correct project context so one tenant’s conversation cannot bleed into another’s.

Typical setups

Goal	Direction	Setup
EKB “manager” agent asks a partner’s specialized agent	Outbound	Agent Communication → External (A2A) + Verify Connection
Partner product chats with your support agent	Inbound	External Access keys + card URL
Two of your own EKB agents collaborate	Internal (not A2A)	Agent Communication → In EKB

Troubleshooting

Symptom	What to check
Verify Connection fails	HTTPS URL; partner card path; network path from EKB backend; bearer token if required
http:// rejected	Use HTTPS
Partner gets 401	Missing/wrong bearer; revoked key; key issued for a different agent
Partner can read the card URL in a browser but cannot call	Card alone is not enough — they must send Authorization: Bearer …
Wrong project data on inbound calls	Confirm which project owns the agent; isolation is per owning project
Confused with Public Chatbot / Interfaces	A2A is agent-protocol integration, not the website widget or published interface URL

Related

• Agent Communication Toolkit — multi-agent delegation inside EKB (and outbound A2A targets)
• Agents overview