I mapped the API and test path. I can take the relay and protocol work.
Agent coordination, human control
Two agents.
One plan.
Both humans.
Inzo pairs your coding agent with a teammate's. They negotiate the plan while you both watch — and nothing runs until you both approve it.
npm i -g inzo-cli- Apache-2.0
- Self-host the relay, or use ours
- No account required
Agent pairing
2 agents connected
PLAN READY · v3
Ship a scoped coordination loop
Relay + testsInterface + deploy
One place for the agents your team already uses
- Claude Code
- Codex
- Cursor
- Qwen
- Ollama
THE NEW BUILD TABLE
Coordination is the feature.
The trust boundary is the product.
Letting two agents talk to each other is easy. Letting them talk to each other across two different people, two different machines, and two different companies — without either side having to take the other's word for anything — is the part worth building. That is what Inzo is.
Pair with intent
One short code pairs exactly two agents. Nothing is open by default, and the pairing is the only thing that authorizes them to speak.
Watch the thinking
The negotiation and task split stream to both humans live, as they happen — not summarized afterward.
Keep the final say
A plan locks only when both humans approve the same version. Re-proposing resets every approval, so consent is always attached to text a human read.
THE TRUST BOUNDARY
Don't take our word for it.
Most agent tools ask you to trust a relay. Inzo is built so you don't have to — every guarantee below is one your teammate's organization can check independently, without asking us and without a prior agreement between you.
Identity is derived, never asserted
Every call is authenticated by a signed credential that resolves to one principal, agent, and pairing. A request that tries to name itself in the body is rejected outright, not quietly ignored.
A stolen credential is inert
Each credential is bound to a key generated on your machine that is never transmitted. Requests are signed over the method, path, and body — so a copied credential can't be replayed, and a plan can't be altered in flight.
Authority only narrows
A credential carries capabilities and can hand out a subset of them. Narrowing
is one-way and re-checked by every verifier. Strip plan:approve and
your agent cannot approve on your behalf, however it gets prompted.
Consent is a signature, not a row
Approving signs a hash of the exact text you were shown, with a key we have never held. A relay that lied about consent would produce a record that fails verification — and anyone can run that check.
A kill switch that actually works
Either human can revoke either credential instantly, without the other side's cooperation. It kills the whole delegated subtree, fails reads as well as writes, closes open streams, and withdraws consent given with that credential.
Execution is sandboxed, always
Shared commands run in a local Docker sandbox — no network, dropped capabilities, non-root, time- and resource-limited, scoped to the one directory you named. There is no host-execution path to opt into.
RUNWAY
Know when you run dry.
Token burn, spend, and elapsed time become one number that matters: how long you can keep going at the current rate, and whether that lands before your deadline. Budget pressure should be a clear choice, not background anxiety.
- Tokens left
- 84k
- Burn rate
- 12k/hr
- Dry at
- 17:20
- Deadline
- 18:00 ✓
QUICKSTART
Two terminals. Same code.
No account, no install step. Both people run this — the hosted relay is free to try, with no setup on your side.
1 · one person pairs, from their project directory
npx inzo-cli pair2 · the other joins with the printed code
npx inzo-cli pair <code>3 · both watch live
npx inzo-cli watch4 · approve the plan you both read
npx inzo-cli approveQUESTIONS
Before you pair.
What does Inzo actually see?
The relay carries messages, the proposed plan, and usage numbers between the two agents — not your source code. Commands run in a local Docker sandbox scoped to one directory on the machine that issued them, not on the relay.
Can I self-host the relay?
Yes — it's a single Node process with a SQLite file. Run it locally, on Fly.io, or on Render; config for all three is in the repo. The hosted relay is there so you don't have to, not because you're required to use it.
What if my teammate's agent starts doing something I don't like?
Revoke their credential. It's instant, doesn't need their side's cooperation, and kills the whole delegated subtree — reads and writes, not just new commands.
What happens if the relay goes down?
Today, one relay instance handles a pairing's message fan-out — fine for a team or a hackathon, not yet a multi-tenant service. v3's credentials and consent are signed by keys the relay never holds, so it can't lie about what happened. It can still drop messages or stall, which is exactly why self-hosting is a real option, not a footnote.
Do I need an account?
No. No accounts, no billing — a pairing is the only unit. A short code authorizes exactly two agents to talk, and that's it.
Is this open source?
Yes, Apache-2.0. The self-hostable core is meant to stay open; a hosted offering is a separate, later concern.
INZO EARLY BUILD
The next great build
should feel shared.
Open source, Apache-2.0. Bring your own relay or use ours.