OpenClaw and A2A
The Agent Card, authenticated tasks over JSON-RPC, outbound peers, session isolation, and the limits of the 1.0 plugin
Agent-to-agent is a channel in OpenClaw: the A2A plugin connects the Gateway to other agents through the Linux Foundation Agent2Agent protocol. External agents discover the Gateway through a public Agent Card and submit authenticated text tasks over the A2A 1.0 JSON-RPC binding, and OpenClaw can send messages to configured peer agents in return. Here is the setup, the calls, the isolation model, the security rules the docs spell out, and the protocol features the current plugin does not support.
Setup and discovery
- Enable the bundled plugin, set the advertised URL to your externally reachable HTTPS origin when the Gateway sits behind a reverse proxy, and define a separate bearer token for each trusted peer through an environment variable, then restart.
- The Agent Card is fetched without authentication from the well-known agent card path; it advertises the JSON-RPC endpoint, text input and output, and one skill per exposed OpenClaw agent, with an expose list to limit which agents appear and a legacy path for older clients.
- A task is an authenticated send-message JSON-RPC request to the A2A endpoint; by default it waits for the reply and returns a completed task with the answer in an artifact, a context id continues the same conversation, a return-immediately flag hands back a working task instead, and a request past the reply timeout also returns the working task rather than cancelling it.
- A working task is polled with get-task until it completes, fails or is rejected; cancel is refused with a JSON-RPC error rather than acknowledged, because a dispatched run has no abort seam and reporting a cancelled state would tell the peer the work stopped while the run kept using tools.
A2A peers send tasks, not user commands.
Outbound peers and isolation
To send messages to another agent, give the peer a URL and, if it needs one, an outbound token; outbound messages are addressed to the peer name under the a2a prefix, go straight to the configured URL without card discovery, and reuse a stable conversation context per peer. Every authenticated peer and context pair gets its own agent session, pinned to the most isolated direct-message scope rather than inheriting the session default, so remote content never joins the operator’s main session and one peer cannot read another’s history. The configuration is small: a reply timeout of two minutes by default within a five-second to ten-minute range, a sliding-window rate limit of thirty requests per minute per peer with zero disabling it, the expose list, and peers keyed by lowercase names.
The security rules
- Card discovery is intentionally public, so anyone who can reach the Gateway reads the description and exposed agent ids; every JSON-RPC request needs a configured peer token, there is no unauthenticated mode, and the authenticated peer is the sender identity for normal channel ingress policy. Use a different high-entropy token per peer, keep them out of source control, and rotate by updating the environment and restarting.
- Peers send tasks, not commands: a message starting with a slash is rejected with an explanation, command-like text inside a task stays literal, the protocol’s user role does not authenticate a human, and work that needs approval still waits for an authorized operator on a user channel or the Control UI while the task stays working.
- Requests are capped at one mebibyte, batches at thirty entries, responses at one mebibyte and extracted text at 64 KiB with a truncation marker; schema-invalid requests count against the rate limit, rate-limited requests return a JSON-RPC error with HTTP 200, and outbound destinations come only from operator-configured peer URLs.
The OpenClaw API covers the Gateway’s own HTTP surface the A2A endpoint sits beside, and OpenClaw Gateway security controls the auth path that protects it.
What 1.0 leaves out
The plugin supports text messages and structured JSON data parts, appended as compact JSON text; file URL and raw binary parts are ignored, and streaming, server-sent events, push notifications, task cancellation, task listing, extended Agent Cards and multi-tenant routing are not supported. Tasks live in memory only: terminal tasks are kept for up to twenty-four hours with a cap of five hundred entries, and a Gateway restart discards them all. OpenClaw subagents is the in-process cousin of this pattern, delegation without a network hop.
On Diali
On Diali agent-to-agent messaging between your own assistants is live, each one an isolated instance, with the peer tokens generated for you rather than pasted into a config file, and an outside A2A agent connects with a token you mint in the dashboard. Hosted OpenClaw on Diali is the assistant and Diali security describes the boundary.
- A public card, a private token per peer.
- Tasks, never commands; cancel is refused on purpose.
- One session per peer and context, in memory only.
Stop reading about it, build one
Set up an agent, pick a channel, and have it working inside the app you already keep open.
