ZAP
Zero-Copy Agent Protocol
The wire format is the data structure
ZAP · the buffer that arrivedpointer + offset 56
JSON · the same message as text39 characters walked
How it is put together
Many agents on one side, many tool servers on the other, one address in the middle.
N:1
Every agent, one address4:11:M
One schema over every backend1:30
Copies of the same tool server9 → 0
Agent Swarm4
- Schema Federation
- Request Routing
- Capability Control
┌─────────────────────────────────────────────────────────────────┐ │ Agent Swarm │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ Agent 1 │ │ Agent 2 │ │ Agent 3 │ │ Agent N │ ... │ │ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ │ │ │ │ │ └────────────┴─────┬──────┴────────────┘ │ │ │ │ │ ▼ │ │ ┌───────────────────────┐ │ │ │ ZAP Gateway │ │ │ │ zap://localhost:9999│ │ │ │ │ │ │ │ • Schema Federation │ │ │ │ • Request Routing │ │ │ │ • Capability Control │ │ │ └───────────┬───────────┘ │ │ │ │ │ ┌──────────────────┼──────────────────┐ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │MCP Srv │ │ZAP Srv │ │MCP Srv │ │ │ │ GitHub │ │ Native │ │ Slack │ ... │ │ └─────────┘ └─────────┘ └─────────┘ │ └─────────────────────────────────────────────────────────────────┘
An MCP server beside every agent
12 tool-server processes · 3 more of each
One zapd in front, servers shared
3 tool-server processes and zapd · none repeated
Four lines and it is running
One daemon in front of the servers you already have. Agents hold a single connection to it.
zapd presents the tools and resources of every backend as one schema, whether the backend speaks MCP or ZAP.
# Connect 12 MCP servers → 1 ZAP endpoint $ zapd serve --port 9999 $ zapd add mcp --name github --url stdio://gh-mcp $ zapd add mcp --name slack --url http://localhost:8080 $ zapd add mcp --name db --url zap+unix:///tmp/postgres.sock # Agents connect once: zap://localhost:9999
Why bother
JSON over HTTP is fine until a hundred agents are calling the same tools. Then the cost is the copies, and the fix is to stop making them.
Running an MCP server beside every agent duplicates the process, the schema and the idle memory as many times as you have agents. Put the servers behind one endpoint and the agents share them.
Fewer processes to schedule and no text to turn into objects on either side of a call. That is where the time goes at scale, and the way to get it back is not to do it.
MCP, A2A and ACP layer on ZAP without changing what your code says. ZAP is underneath them, not instead of them.
Structs, lists, text and bytes are laid out on the wire in the shape a reader wants them, eight-byte aligned. Reading a field is a pointer and an offset into the buffer that arrived.
A reader that walks the buffer in place allocates nothing per message, so there is no garbage to collect and no pause to tune away later.
Point the daemon at the MCP servers you already run — over stdio, over HTTP, over a Unix socket — and it presents their tools as one federated schema. Agents connect once and see everything.
ZAP carries its own key distribution: a service subscribes once and receives the snapshot, then rotations and revocations as they happen. Nothing polls a JWKS endpoint, and a revoked key stops working when it is revoked rather than when a cache expires.
Go, Rust and TypeScript, held wire-compatible against a single schema file. The schema is the contract, and an incompatible change bumps its identifier rather than hoping nobody notices.
Point one agent at it
Go · Rust · TypeScript
Start the daemon, add the MCP servers you already run, change one address in your agent.
Nothing else about your setup has to move.
What ZAP saves depends on your workload, your payload size and your topology. The claim here is about mechanism, not about a number: a reader that walks the buffer in place does no parsing and no allocation, and shared backends run one process where per-agent sidecars run many. Measure it on your own traffic — we have not published a benchmark and will not quote one we cannot show you.
Get ZAP
Zero-copy application protocol