ZAP ⚡

Zero-copy Agent Protocol

Cap'n Proto for AI agents.

Introduction

ZAP is an insanely fast binary protocol for AI agent tool calls. It's what you get when you take the zero-copy philosophy of Cap'n Proto and apply it to the specific problem of AI agents calling tools.

You know how MCP (Model Context Protocol) uses JSON-RPC? That means every time your agent reads a file, searches code, or runs a command, the response gets:

1. Serialized to JSON on the server
2. Base64 encoded if there's binary data (inflating size by 33%)
3. Transmitted over the wire
4. Parsed back into objects on the client
5. Copied into your language's native structures

For a single tool call, who cares? But AI agents make dozens of tool calls per task. A simple bug fix might involve 6-10 file reads, a few searches, some edits, and test runs. That overhead adds up.

ZAP eliminates steps 1, 2, 4, and 5.

Messages are read directly from network buffers with zero parsing and zero copying. The result? 1,000-2,000x faster than JSON-RPC for typical agent workloads.

The Numbers

Here's a real benchmark comparing ZAP to MCP for a typical coding task (6 tool calls, ~63KB of payload):

And here's the kicker: ZAP is fully compatible with MCP. The ZAP Gateway bridges to existing MCP servers, so you can migrate incrementally.

How It Works

ZAP uses a dead-simple wire format:

┌──────────┬──────────┬──────────────────────┐
│  Length  │ MsgType  │      Payload         │
│ (4 bytes)│ (1 byte) │     (variable)       │
│  LE u32  │          │                      │
└──────────┴──────────┴──────────────────────┘

That's it. No framing complexity, no HTTP overhead, no protobuf schema compilation. Just length-prefixed messages that can be read directly from the socket.

The payload uses JSON structure you're already familiar with—but transmitted as raw bytes, not base64-encoded strings. When you read a file, you get the actual file bytes, not a 33% inflated base64 blob that you then have to decode.

Zero-Copy Magic

The real magic is in how ZAP handles responses. Traditional protocols work like this:

Network Buffer → Parse JSON → Allocate Objects → Copy Data → Your Code

ZAP works like this:

Network Buffer → Your Code

When you call result.content, you're reading directly from the network buffer. No intermediate copies. No allocations. No garbage collection.

This isn't just faster—it's fundamentally different. Your agent can process gigabytes of file contents without proportional memory growth.

Real-World Scenarios

Scenario 1: Simple Bug Fix (9 tool calls)

User: "Fix the authentication bug in login.rs"

Agent:
  1. read_file("/src/auth/login.rs")        → 15KB
  2. grep("authentication", "/src/**/*.rs") → 8KB
  3. read_file("/src/auth/session.rs")      → 12KB
  4. read_file("/src/middleware/auth.rs")   → 9KB
  5. edit_file(login.rs, patch)             → 2KB
  6. run_command("cargo test auth")         → 25KB
  7. edit_file(login.rs, fix)               → 2KB
  8. run_command("cargo test auth")         → 3KB
  9. git_commit("Fix auth bug")             → 1KB

Total: 77KB payload

Savings: 1,480x faster parsing, 100% fewer allocations

Scenario 2: Code Review (50 tool calls)

Files read: 25 files × 8KB = 200KB
Searches: 10 greps × 5KB = 50KB
Suggestions: 15 edits × 2KB = 30KB
Total: 280KB

Scenario 3: 8-Hour Coding Session (5,000 tool calls)

Getting Started

Rust (Native)

[dependencies]
hanzo-zap = "0.1"

use hanzo_zap::Client;
use serde_json::json;

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let client = Client::connect("zap://localhost:9999").await?;

    let result = client.call_tool("read_file", json!({
        "path": "src/main.rs"
    })).await?;

    println!("{}", result.content);
    Ok(())
}

Python

pip install hanzo-zap

from hanzo_zap import ZapClient

async with ZapClient("zap://localhost:9999") as client:
    result = await client.call_tool("read_file", {"path": "src/main.rs"})
    print(result.content)

Node.js

npm install @hanzo/zap

import { ZapClient } from '@hanzo/zap';

const client = await ZapClient.connect('zap://localhost:9999');
const result = await client.callTool('read_file', { path: 'src/main.rs' });
console.log(result.content);

Go

go get github.com/hanzoai/zap-go

client, _ := zap.Connect("zap://localhost:9999")
result, _ := client.CallTool("read_file", map[string]any{"path": "src/main.rs"})
fmt.Println(result.Content)

The Gateway

Don't want to rewrite your MCP servers? No problem. The ZAP Gateway bridges between protocols:

┌─────────────┐      ZAP       ┌─────────────┐     JSON-RPC    ┌─────────────┐
│   Agent     │◄──────────────►│   Gateway   │◄───────────────►│ MCP Server  │
│  (fast)     │    (binary)    │ (aggregator)│    (stdio)      │ (existing)  │
└─────────────┘                └─────────────┘                 └─────────────┘

Configure your MCP servers:

# gateway.toml
[[mcp_servers]]
name = "filesystem"
command = "npx"
args = ["-y", "@modelcontextprotocol/server-filesystem", "/workspace"]

[[mcp_servers]]
name = "github"
command = "npx"
args = ["-y", "@modelcontextprotocol/server-github"]
env = { GITHUB_TOKEN = "${GITHUB_TOKEN}" }

Benchmark: ZAP gateway adds <5% overhead while aggregating 20+ MCP servers. The bottleneck is always the MCP servers themselves.

Security Model

ZAP enforces security at the protocol level with two orthogonal policies:

AskForApproval

When should the agent pause and ask a human?

SandboxPolicy

What operations are physically allowed?

These policies are enforced at the protocol level. A rogue agent can't bypass sandbox restrictions.

Tool Categories

ZAP defines 14 tool categories with 167 typed operations:

Language Support

Transport Schemes

Benchmarks

Measured on Apple M3 Max:

Parse Latency

Round-Trip (localhost)

vs The Competition

vs JSON-RPC (MCP)

MCP is great for interoperability. But it's slow. ZAP gives you 1000x+ performance while maintaining full MCP compatibility via the gateway.

vs gRPC

gRPC requires protobuf schemas, code generation, and HTTP/2. ZAP is simpler: just connect and call tools. No schema compilation, no HTTP overhead.

vs Cap'n Proto

Cap'n Proto inspired ZAP's zero-copy design. But Cap'n Proto is a general-purpose serialization format. ZAP is purpose-built for AI agents, with built-in tool schemas, security policies, and MCP compatibility.

Documentation

• Getting Started - Installation and first agent
• Schema Language - Define tool schemas
• Wire Format - Binary protocol details
• RPC Protocol - Request/response patterns
• Security - Permission and sandbox policies
• Language Bindings - Use ZAP in your language
• Tool Reference - Complete API documentation

Specifications

• HIP-007 - ZAP Protocol Specification
• MCP - Model Context Protocol (Anthropic)

License

MIT License - Copyright 2025 Hanzo AI Inc.

ZAP: Because your AI agent shouldn't wait for JSON parsing.