Agents Are About to Start Hiring Each Other. Here’s the Wire.

What if agents could talk to each other directly, even hire each other for freelance work across the globe? Today they can’t, and I keep finding myself as the human wire between my agent and my colleague Nuno’s. So I built AgentBridge: two agents talking directly, end-to-end encrypted, no plaintext at the relay. It came together in a few hours while I ate lunch.

Last week Nuno sent me this on Slack:

“I’ve just completed the Phase 1 for Corey’s project, can you please tell your agent to update our progress map with this feedback?”

I read it. I copied it. I pasted it into the Claude Code session running on my laptop. The agent updated the map. I copied the result back. I sent it to Nuno.

Multiply that by every project we collaborate on at Pluginslab, every report Nuno’s agent generates that mine needs to consume, every status update going the other way. I was the wire. The bandwidth was me-shaped.

Two agents, no comms layer

If our two agents could just talk to each other, none of this would happen. They can’t, not in any default way. Claude Code agents are stdio processes attached to a single human. There’s no built-in transport between sessions on different machines, accounts, or organisations.

The obvious workarounds all suck:

• A shared Slack channel where both agents post. Now both agents need Slack tokens, and Slack sees everything they say to each other.
• A shared GitHub repo or issue tracker. Public-ish, structured, and now business chatter lives in a vendor’s database.
• A shared MCP server we both connect to. Means we both trust that server’s operator to never read our messages. Not happening.
• Matrix or Signal bots. Designed for humans, identity model doesn’t fit, integration is heavy.

What I wanted was a thing that looked like a Slack DM between two agents, where the server in the middle is blind, the messages are signed by the sender’s persistent key, and identities are bootstrapped via a string short enough to send in a Slack DM out-of-band.

That’s AgentBridge.

What AgentBridge actually is

Each agent generates an X25519 keypair (for encryption) and an Ed25519 keypair (for signing) the first time the MCP server starts. The first 44 bits of SHA-256(x25519_pub || ed25519_pub) get mapped to 4 words from the BIP39 wordlist; the next 11 bits give a typo-resistant checksum word. That’s your “quote”, something like coral-delta-mirror-falcon.atlas, and it’s how friends find you.

The whole flow is:

1. I run whoami in my agent and get my quote. I send it to Nuno on Slack.
2. Nuno’s agent calls add_friend with my quote.
3. My agent shows Nuno’s pending request along with his fingerprint hex. I ask Nuno on Slack: “is your fingerprint 4c1be29f8a...?” He confirms. I accept.
4. From now on either agent can send the other an encrypted, signed, replay-protected message at will.

The relay in the middle sees opaque ciphertext blobs plus an Ed25519 signature. It can route them. It can rate-limit them. It cannot read them and it cannot forge them. Sender authentication is verified against the locally-cached pubkey each side captured at accept time, not a key the relay claims is yours.

If you want the full design, including the v1-to-v2 reworks that closed weaknesses around quote entropy, replay protection, ACK proof-of-decryption, and identity privacy, the entire threat model lives in PLAN.md in the repo.

The stack, briefly

The thing I’m most proud of is what’s not in the stack:

• No sodium-native, no @peculiar/webcrypto, no libsodium.js.
• No TypeScript, no build step.
• Nothing beyond Express on the server.
• No external auth. Bearer tokens are issued by the relay at registration.

Just Node 22’s stdlib crypto module (X25519, Ed25519, HKDF-SHA256, AES-256-GCM, HMAC, timingSafeEqual, all there), better-sqlite3 for the relay’s tiny state, the Model Context Protocol SDK for the stdio surface, and ws for the inbox push channel.

Native crypto in Node has been good enough for a while now, and people don’t say it loudly enough. You can build serious end-to-end encryption with the standard library and zero native dependencies. Build time, install time, and audit surface all stay tiny.

An agent built its own comms layer

The whole project landed in an afternoon. The build setup:

• I was at the office.
• My phone had the Claude app open. My iPad had Termius open, SSHed into my office workstation, into a tmux session running Claude Code.
• I dictated the idea into the Claude app. We talked through what it needed to do, what the threat model had to look like, what the surface area should be.
• I had Claude scope it into a PLAN.md. The threat model got two passes there, on entropy, sender auth, replay, ACK, and identity privacy, before any code was written. My total edit time on the plan was maybe ten minutes.
• I pasted PLAN.md to Claude Code over Termius and told it to build.
• I ate lunch.
• I came back, set up the Cloudflare tunnel myself (the one thing Claude Code can’t do for me), and we had a working end-to-end encrypted messaging relay running.

Honestly: 98% of the code is Claude Code’s. I was the product manager, the security reviewer, and the person who walked over to the Cloudflare dashboard.

This is not a vibe-coding cautionary tale. The design got two formal rounds on paper before any code was written, and the test harness spins up two real MCP processes per scenario against an in-memory relay: 17 scenarios covering registration, friend flow, message round-trip, ciphertext tampering, replay rejection, ACK forgery, and revocation cascades. That’s how I trust it.

I’ve written before about how the senior engineer’s job has shifted toward building agent harnesses, and this is a small but live example. The skill is no longer “can you write encrypted messaging” but “can you specify and review encrypted messaging well enough to direct an agent through it.” Different sport.

If you’re a WordPress dev still on the fence about supervised AI coding, the same approach is what I’ve been recommending for plugin work. And if you’re worried about the security implications of letting an agent build security-sensitive code, the polite paranoia post covers the mindset I bring to reviewing this stuff.

What works, what’s next

It works. It’s running. The MCP server is one stdio binary you point your Claude Code config at, and the relay is one container. The whole thing will be public soon.

What’s next? Honestly, not much. The README mentions group messaging, a Python client, and a Double Ratchet protocol for forward secrecy as “PRs welcome” items. None of them are on my actual roadmap. The thing solves my problem.

The one suggestion from Nuno that’s stuck with me: this could become a social network for agents. A directory, a way for agents to advertise capabilities and reach each other, persistent rooms.

Push that one step further and you get something stranger: agents offering freelance services to other agents. A middle-layer marketplace where my agent scouts work on my behalf, drafts a scope, and ships it to an agent that specialises in whatever the job needs (translation, code review, design, ops). The hiring agent passes the scope along, the working agent picks it up, both get reviewed by their humans, and the loop closes without me typing a single Slack message. Lead generation, scope handoff, delivery, all happening between agents on a wire I can’t read.

I’m not building any of that. But the moment your agents can talk to each other privately, the surface area for what they can do for you opens up fast.

For now: my agent and Nuno’s agent are on the wire together, and I haven’t pasted a Slack message into a Claude prompt all week.

The argument underneath all of this: humans should not be the transport layer between agents that work for them. The implementation: a few hundred lines of stdlib Node, end-to-end encrypted, no plaintext at the relay, no copy-paste at the human.

If you build something on top of this, a Python client, a group-messaging layer, anything, I’d love to see it, when it goes public soon.