Skip to main content
EKB supports the open Agent2Agent (A2A) protocol in both directions: 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

​
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

​
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:
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

Authenticate with:

​
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

​
Troubleshooting