OpenClaw A2A Gateway: letting agents on separate servers find and call each other

What the plugin is, and what problem it is aimed at

The openclaw-a2a-gateway is a production-ready OpenClaw plugin that implements the A2A, Agent-to-Agent, version 0.3.0 protocol from Google, enabling OpenClaw agents to discover and communicate with each other across servers, with zero-config install and automatic peer discovery.

The problem underneath that is specific. An agent framework gives you one agent that can do things on one machine. As soon as there are several agents, the questions become: which one should this message go to, how does agent A learn that agent B exists, and what happens when agent B's machine is switched off. A multi-agent setup is not a framework feature, it is a distributed systems problem wearing an agent-shaped hat, and the plugin is squarely aimed at that problem.

The architecture diagram in the documentation shows the shape of it. Two OpenClaw servers, Server A and Server B, each with an agent on it, each listening on an A2A port of 18800, each naming the other as a peer, and talking A2A over JSON-RPC across a Tailscale or LAN link.

The prerequisites are OpenClaw at 2026.3.0 or later installed and running, network connectivity between servers over Tailscale, a LAN or a public IP, and Node.js at version 22 or later.

The project describes itself as the only A2A gateway with adaptive, bio-inspired routing, discovery and resilience, designed for multi-agent ecosystems at scale. That claim is worth setting aside for now, because the interesting question is what the routing and resilience actually do, and whether the biology is load-bearing or decorative.

Transports, message parts, and the fallback that carries the design

The transport layer is the part of a protocol implementation that determines where it can actually run, and this one is unusually thorough.

There are three transports, JSON-RPC, REST and gRPC, with automatic fallback that tries JSON-RPC, then REST, then gRPC. That ordering is a statement about what the author considers the best protocol, and the fallback is a statement about what real networks do. An agent on a corporate network may have a JSON-RPC endpoint blocked while REST survives, and a peer behind a gRPC-only ingress is reachable by the last fallback rather than not at all. The result is that the gateway can talk to a heterogeneous fleet rather than requiring everyone to expose the same port.

On top of that there is SSE streaming with a heartbeat keep-alive for real-time task status. The heartbeat is the detail that matters, because an idle SSE connection that is silently dropped by a proxy leaves the client waiting for an event that will never arrive, and a periodic heartbeat is how the two ends notice the link is dead.

The message layer supports the full Part type set: TextPart, FilePart with both a URI and base64 forms, and DataPart for structured JSON. There is also auto URL extraction, where file URLs found in an agent's text response are promoted into outbound FileParts. That is a convenience with a real effect, because an agent that answers with a URL in prose would otherwise require the caller to parse the prose to find the artefact.

The dependencies match the design. The @a2a-js/sdk at version 0.3.13 is the protocol implementation, @grpc/grpc-js and @bufbuild/protobuf cover the gRPC transport, express serves the HTTP side, ws handles the WebSockets, and multicast-dns handles the mDNS side of discovery.

Routing with a Hill equation, and what the parameters cost you

The routing layer is where the bio-inspired framing lives, and it is the most interesting part of the plugin and the most debatable.

There is a rule-based routing mode, which auto-selects a peer by message pattern, by tags, or by the peer's skills, and on top of that a hill equation affinity scoring that does multi-dimensional routing with sigmoid scoring. The formula given is score = affinity^n / (Kd^n + affinity^n), with the skills, tags, pattern and success rate weighted into the affinity, and the reference is Hill's 1910 equation from biochemistry, which is the classic saturating binding curve where the response rises steeply and then flattens out as the binding sites fill.

The analogy is defensible. A saturating response is exactly what you want from a peer-affinity score: a peer that matches strongly should score high, and once it is saturated further increases in raw affinity should not keep changing the routing decision. The n exponent sharpens the transition, and Kd is the half-saturation point, the affinity at which the score is half of the maximum.

So the model is reasonable. The problem is that Hill's equation comes with parameters that mean something in one field and nothing in the other, and here you have to choose Kd and n for a score whose scale is arbitrary because it is a weighted sum of skills, tags, pattern and success rate. There is no physical meaning to a half-saturation point of peer affinity, so Kd becomes a tuning knob whose right value depends on the weights, and the weights are not documented in the project documentation at all.

There is a second mechanism under the scoring, and it is the one that does the real work. Peer skills caching extracts Agent Card skills during health checks, which is what makes skills-based routing possible at all, because otherwise every routing decision would need a round trip to ask the peer what it can do. The success rate dimension is a feedback loop over observed outcomes, which is a good idea and also a slow one, since a peer's success rate reflects its history rather than its current behaviour.

There is also per-message agentId targeting, which routes to a specific OpenClaw agent on the peer through the OpenClaw extension mechanism. That is a useful escape hatch from scoring altogether, and it is the feature to reach for when you know which agent you want and the automatic routing gets it wrong.

Discovery and resilience: quorum sensing, a four-state breaker, and soft concurrency

The resilience section is where the plugin is most distinctive, and it borrows from three different biological models.

Discovery is DNS-SD based, auto-discovering peers through _a2a._tcp SRV and TXT records, and the gateway advertises itself with mDNS by publishing SRV and TXT records so other gateways find it automatically. The quorum-sensing part is the density-aware adaptive polling: short intervals when few peers are known, which is the explore phase, long intervals when the network is established, which is the stable phase, and a Schmitt-trigger hysteresis to prevent oscillation between them. That last part is the correct engineering answer to a real problem, since a naive density heuristic with a single threshold will flip back and forth around it.

The circuit breaker has four states, closed, desensitized, open and recovering, with an exponential recovery curve, and it is described as a bio-inspired desensitization model. The extra state is what distinguishes it from the usual three-state breaker, and the useful part is the idea that a service which is failing intermittently should be treated differently from one that is down, and that half-open probing with a gradually widening window is a better recovery policy than a single retry.

Adaptive transport selection tracks per-transport success rate and latency with composite scoring, ranks the transports by recent performance, and uses static priority to break ties. The static tie-break matters, because a purely performance-based ranking will oscillate between transports when the measurements are close, and two agents then talking different protocols about the same task is a bug rather than an optimisation.

Push notifications use webhook delivery with signal-decay importance management and decay-aware retry, and Michaelis-Menten soft concurrency applies a progressive delay before the hard queue limit, delay = baseDelay times load divided by Km plus load. The idea is a soft pressure zone where requests wait a little longer rather than being rejected outright, and the same caveat applies as with the Hill equation: Km has a physical meaning in enzyme kinetics and no intrinsic meaning here, so it is another constant to tune.

On the security side there is bearer token auth with multi-token zero-downtime rotation, SSRF protection with a URI hostname allowlist, a MIME allowlist and file size limits, Ed25519 device identity for OpenClaw 2026.3.13 and later scope compatibility, a JSONL audit trail for all A2A calls and security events, a telemetry metrics endpoint with optional bearer auth, and a durable task store on disk with TTL cleanup and concurrency limits.

Installing it, and the Agent Card you will need to edit

The quick start claims zero configuration, and the install command is one line:

openclaw plugins install openclaw-a2a-gateway

Installing from source is longer, and the sequence is worth copying because the verification step at the end is the part people skip:

mkdir -p ~/.openclaw/workspace/plugins
cd ~/.openclaw/workspace/plugins
git clone https://github.com/win4r/openclaw-a2a-gateway.git a2a-gateway
cd a2a-gateway
npm install --production

openclaw plugins install ~/.openclaw/workspace/plugins/a2a-gateway
openclaw gateway restart
openclaw plugins list          # should show a2a-gateway as loaded
curl -s http://localhost:18800/.well-known/agent-card.json | python3 -m json.tool

That last command is the real check. A gateway that is loaded and serving an Agent Card at the well-known path is working; one that is loaded but not answering is a configuration problem, and the difference between those two states is what the curl tells you.

The manual route exists for people who want to keep their existing plugin configuration, and it uses the OpenClaw config commands:

openclaw config set plugins.allow '["telegram", "a2a-gateway"]'
openclaw config set plugins.load.paths '["<FULL_PATH_TO>/plugins/a2a-gateway"]'
openclaw config set plugins.entries.a2a-gateway.enabled true

The note attached to that block says to replace the placeholder with the actual absolute path, giving /home/ubuntu/.openclaw/workspace/plugins/a2a-gateway as an example, and to keep any existing plugins in the plugins.allow array, which is the kind of instruction that saves a broken configuration when a team already had Telegram working.

Every A2A agent needs an Agent Card that describes itself, and the defaults are listed in a table. The name is OpenClaw A2A Gateway, the description is A2A bridge for OpenClaw agents, and the skills are a single chat skill. The card is customised with the same config mechanism, for example setting plugins.entries.a2a-gateway.config.agentCard.name, and the card's url points at the JSON-RPC endpoint, which is what a peer uses to find the gateway.

The repository, the release history and what the versions say

The repository is a TypeScript plugin with a CLI, a skill directory, source, tests and documentation, and it is published to npm under the name openclaw-a2a-gateway at version 1.5.1.

The build is a plain tsc compile with a prepack hook that runs it, and the tests run with the Node test runner through tsx over the files in tests, with supertest and the openclaw package as development dependencies. The plugin is registered with OpenClaw through the openclaw.extensions entry pointing at index.ts, and the main field is index.ts as well, which means the published package ships TypeScript source as the entry point.

That last point connects to the most recent release. Version 1.5.1 was released with the note that it fixes stale compiled output in the npm package, and a version 1.5.0 that added a DevTools CLI, WebSocket pooling and OpenClaw 2026.5 compatibility. The 1.4.0 release earlier in the year added stale task recovery, CLI developer experience work and connection pooling. So the published artefact has shipped with stale compiled output at least once, and the fix was in the very next patch release, which is a reasonable response but also a warning for anyone pinning a version in a production fleet.

The test badge claims 486 passing tests, and the repository carries a TEST-REPORT.md and an A2A_SDK_REVIEW_CN.md, which is a review of the upstream protocol SDK written in Chinese, and there are eleven translations of the readme.

The licensing is MIT and the project is TypeScript, with the last push to the repository on 2026-07-17. That date is worth holding in mind alongside the release dates, because the releases stop in July while the branch was pushed in July too, and the plugin's compatibility claims are tied to specific OpenClaw versions, so a fast-moving host framework is the dependency that will age first.

Editorial conclusion

The OpenClaw A2A Gateway is worth evaluating if you run more than one OpenClaw agent, because it solves the discovery and routing problem that stops a fleet of agents from being useful to each other, because the three transports with automatic fallback mean a peer behind a restrictive network can still be reached, and because the Agent Card and its skills are the basis for both discovery and routing rather than a bolt-on. It is the wrong tool if you have one agent, and it is the wrong tool if you want a protocol implementation with no opinions in it. Before you deploy it, check three things: that the peers can reach each other, since the prerequisites call for OpenClaw at 2026.3.0 or later, Node 22 or later, and network connectivity between servers over Tailscale, a LAN or a public IP; that you read the security configuration rather than the defaults, since the features list bearer token auth with multi-token zero-downtime rotation, SSRF protection with a hostname allowlist, a MIME allowlist and file size limits, and an Ed25519 device identity for OpenClaw 2026.3.13 and later scope compatibility, and a gateway that can call other agents is a gateway that can reach anything those agents can reach; and that you check the packaging history, because version 1.5.1 was released to fix stale compiled output in the npm package, which tells you the published artefact and the source tree can disagree.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. win4r/openclaw-a2a-gateway on GitHub