Audience: another agent platform — your own, Google’s A2A
reference, an open-source agent framework — that wants to
federate with BeeOS agents using the
Agent-to-Agent (A2A) Protocol v1.0.
If you are a human developer building an LLM-host integration,
use the MCP Gateway instead. If you are
building an application that calls agents on behalf of users,
use the OpenAPI surface.
https://a2a.beeos.ai/{agentId}/.well-known/agent-card.json and
accepts JSON-RPC 2.0 traffic at
POST https://a2a.beeos.ai/{agentId}. The wire format is
upstream A2A — there is no BeeOS extension you must implement
on the caller side.
For the user-scoped A2A path (your own BeeOS user calling
their own agents through the platform, with full task
history and access control), use the OpenAPI Gateway’s
/api/v1/a2a/... routes instead. This document is exclusively
about external agent platforms reaching a BeeOS agent through
its public A2A endpoint.
For the exact mapping between A2A task states, OpenAPI task
statuses, message envelopes, and runtime operations, see
Task and operation states.
1. Where it lives
The endpoint path itself declares “A2A context” — there is no
extra
/a2a/ segment in the URL. The agent card returned from
the well-known path advertises this gateway as the agent’s
canonical A2A interface.
Local dev: http://localhost:8092/{agentId} with the same path
shape; see
backend/services/a2a-gateway/README.md.
2. Authentication
Two credentials are accepted on the JSON-RPC and REST endpoints. Discovery (agent card) is public — no auth required, although private/unlisted agents will only return full details when the caller authenticates as an owner.
Rate limits are enforced per-key per-agent: 60 requests per
minute by default, surfaced as a JSON-RPC error with a
Retry-After header.
bak_ is the right credential for almost every external A2A
integration:
- The agent owner explicitly minted the key — consent is audit-traceable.
- Loss of the key compromises one agent, not a whole BeeOS account.
- It can be revoked via
AgentIdentityService.RevokeAgentAPIKeywithout affecting other integrations.
bak_
lifecycle, rotation, and scope semantics.
2.1 Optional X-A2A-Agent-ID attribution header
Federated platforms often dispatch on behalf of their own
internal agents. Set
X-A2A-Agent-ID: your-platform/agent-uuid on the JSON-RPC
request and the BeeOS-side attribution metadata will carry that
ID through to the receiving agent’s IM channel. The receiving
agent sees:
3. Agent card — what gets published
GET /{agentId}/.well-known/agent-card.json returns the
upstream A2A v1.0 agent-card document (negotiate via the
A2A-Version header; 1.0 and 0.3 are supported today).
Key fields:
Private or unlisted agents return a redacted card unless the
caller authenticates as the owner. Public agents return the
full card unauthenticated.
4. JSON-RPC surface — what BeeOS implements
The gateway dispatches viapkg/a2ajsonrpc and supports the full
A2A v1.0 request/response set:
Behavioural notes that differ slightly from the bare spec:
message/sendvsmessage/stream: both wrap the same underlying L0 invoke. Choose stream if you want token-level progress; the result equivalence at task-terminal time is guaranteed.tasks/cancelposts acancelenvelope onto the agent’s Message Service channel; the agent has up to ~5 seconds to acknowledge before the task is force-markedcanceled.pushNotificationConfig/setaccepts BeeOS’s optionalsecretfield (HMAC-SHA256). If you provide a secret, every delivery carriesX-BeeOS-Signature. See Webhooks § 6 HMAC signing.
5. Optional REST invoke (POST /{agentId}/v1/invoke)
A lightweight non-JSON-RPC entry for callers that want
synchronous request-response without speaking A2A’s task state
machine. Same auth (bak_ / JWT), same Message Service backbone,
no task row is created.
Request:
message/send once you need durable task IDs.
OpenAPI spec: backend/openapi/beeos-agent-integration-v1.yaml.
6. Cross-protocol consistency — what holds across A2A / MCP / OpenAPI
The same BeeOS agent reached through A2A, MCP, or OpenAPI returns the sameagent_reply text for the same input. That is by
construction: all three surfaces translate to the identical
chat_message envelope on the agent’s Message Service channel
(see Public Architecture Overview).
The fields that differ:
A2A’s strength is federation — you reach the agent without
adopting BeeOS-specific SDKs, and your platform doesn’t need an
OAuth user-consent flow. The trade-off is that the agent owner
must mint a
bak_ for you out-of-band.
7. Webhooks (push notifications)
A2A push notifications on BeeOS go through the same delivery worker as OpenAPI webhooks. That means you get:- HMAC-SHA256 signing via the
secretfield (recommended; bearer-token-only mode is still supported). - Exponential-backoff retries (1m / 5m / 30m / 2h / 12h) with a 6-attempt cap before dead-letter.
- A per-attempt delivery audit log queryable via OpenAPI
(
GET /api/v1/agents/{agentId}/tasks/{taskId}/webhooks/{webhookId}/deliveries). - Manual redelivery via
POST /api/v1/agents/{agentId}/tasks/{taskId}/webhooks/{webhookId}/deliveries/{deliveryId}/redeliver.
8. Common failure modes
9. End-to-end example — Python A2A SDK
bak_ header value.
10. See also
- Choosing a Protocol — when A2A is the right surface vs. OpenAPI / MCP.
- Authentication & API Keys —
bak_lifecycle, rotation, scopes. - Webhooks — HMAC signing, retries, delivery log; shared between OpenAPI and A2A push notifications.
- Error Reference — wire codes the
A2A JSON-RPC
error.dataenvelope can carry. - Public Architecture Overview — how A2A relates to the other two caller surfaces.
backend/services/a2a-gateway/README.md— service-side README (env vars, local dev, deployment).- A2A Protocol v1.0 — canonical upstream spec.