Let your agent talk to mine

Coding agents are pretty powerful, as far as dev tools go. They enable you to hand off a big chunk of work, which opens up a whole world of possibilities to do things like debug a service, plan a migration, review a PR, and more.

Your agent knows a ton about your side of a project, and nothing about mine. And that makes working together a little painful:

• I have to copy a question out of my terminal, and paste it to you in Slack.
• I have to wait for you to paste it into your agent, then paste the answer back to me.
• Even then, my agent only gets what I remembered to copy. So most of the context is out of the picture.

So I had a thought: why not give the two agents a link, and let them talk to each other directly? That would mean:

• No copying and pasting between people
• No server in the middle reading the conversation
• No accounts
• Nothing for you to install!

With all this in mind, I spent a couple of days hacking on something I've dubbed peertalk. You make a room, send the link to a friend, and each of you pastes a prompt into your own agent. The agents find each other, connect directly, and talk. Everything your agent runs is in a public gist, if you just want to read the code.

Your agent and Sam's, agreeing an api. The same conversation from both sides.

Be warned: it's an experiment at the moment, essentially a hack project. But it should work well enough for you to try it with a friend

Who is this for?

Anyone with an agent that runs on their own computer and can keep a small program going in the background: Claude Code, Codex CLI, Gemini CLI, Cursor, OpenClaw, and so on.

The possibilities are pretty endless, and a few ideas which spring to mind immediately are:

• Two agents on the same project, comparing notes
• Agreeing the api between two codebases before anyone writes it
• "Works on my machine", meet the other machine
• Claude Code and Codex, both yours, arguing about a plan
• A second opinion on a plan, without sharing your whole repo

What if the other person doesn't have an agent? No problem! They can pick "Just me" on the room page, and chat with your agent, and everything it knows about your project, directly from their browser.

There's an MCP server too, so you don't need to open the room page at all: add it to your agent and just ask it to "make a peertalk room so my agent can talk to Sam's". Your agent makes the room, hands you the link to send, and joins it.

Can ChatGPT and Claude join, in the browser? Yes, and no. A chat app can't hold a connection open between turns, so it needs a Chrome extension to do that part for it. That works, but for now it's a developer preview, loaded unpacked from a zip on the site.

So how does it work?

The idea is, peertalk.ai only introduces the two agents. It's the friend who introduces you at a party, then goes to get snacks and never comes back.

What happens is:

• You click "Make a room". Your browser makes a random key and puts it in the link, after the #. (Browsers never send that part of a url to a server.)
• You send the link to your friend, however you like. Each of you copies the prompt from the room page and pastes it into your own agent.
• Each agent sets up a WebRTC connection (with one library it installs itself), seals its connection details with the key, and leaves them in the room on peertalk.ai.
• Each agent then picks up the other's details, unseals them, and connects straight to the other machine.
• From then on, messages go directly between the two machines, encrypted, and peertalk.ai is out of the picture.

Three steps, and peertalk.ai is only needed for the first one.

Notice that peertalk.ai didn't need to know the key, and it also didn't need to see a single message from either agent. It just swapped two sealed notes (which it can't open) and the agents did all of the connecting themselves!

It feels like you're just chatting with your own agent in your own terminal, but actually you're watching it talk to an entirely different agent on an entirely different machine. Behind the scenes, each agent runs a small client in the background, saves every message that comes in as its own file, and quotes each one to you as "Them:" or "Me:", without you having to copy anything.

A room gives the two agents 30 minutes to connect. Once they have, they don't need the room any more, so they can talk for as long as they like

How did I build it?

A little googling showed up a handful of projects which do something similar. This is awesome, but none of them quite fit with what I was looking for, for a few reasons:

• Most of them pass every message through their own server.
• The ones that really are peer to peer need something installed on both machines first.
• Some of them fall back to a relay when a direct connection fails. I'd rather it just told me.

So, over the next couple of days, I built peertalk. It's a small Express server and a Next.js site on DigitalOcean, with the rooms in Valkey.

There are a few observations I made along the way. In no particular order:

• The agents really are capable. Writing a working client from the protocol in the prompt usually takes them a few minutes, and they mostly get it right first time.
• The prompt really is the product. The first version handed agents a script, and I was finding myself asking people to trust way too much code. So I killed it, and put the whole protocol into the prompt instead.
• Writing your own client is time consuming, especially if you're hoping to get two agents talking in under a minute. For peertalk, I was originally having every agent write its own client from scratch. I soon had to add a ready made one too, which the agent is told to read before running it, and that's now the default.
• Turns out, if you ask an agent to list its tools and wait for a go-ahead before it connects to a stranger, Claude Code's own safety classifier will block it as "Exfil Scouting". Pretty fair call, too. I took that step out again.
• Mobile networks are a pain. Connections from my phone on 5G kept failing. The reason is, some home routers care about which side's packets arrive first, so trying both orders at once fixed it.
• Hand-rolled UDP hole punching works, technically speaking. In fact, it's really the only way to connect two machines with nothing but a language's built-ins, unless you start throwing libraries into the mix. But one WebRTC library connects faster and more reliably, so that's the default now

So is it safe?

Yes, and no.

Security is obviously crucial here. In each conversation we want to verify:

• Am I sending messages to the agent I expect?
• Am I receiving messages from the agent I expect?

Only the two agents with the full link can join a room like this. Without the key, nobody can read or change the connection details the agents leave there. And of course the key is never sent to peertalk.ai: it lives after the # in the link, which browsers never send to a server.

Here's what peertalk.ai does see:

• The room ID
• A hash of a hash of the key, so it can tell an agent has the link
• The IP address each request comes from
• Two sealed blobs it can't open

We want to be able to limit a room to the two agents holding the link, otherwise we run the risk of a stranger guessing a room ID and taking a place. Or a server in the middle could swap in its own connection details, and read everything.

This is secure: only connection details sealed with the key are accepted by the other agent, and those details include the fingerprints each side checks the other against. All peertalk.ai can do is hold the sealed notes and pass them along.

Now I can sleep easy knowing that it's not possible for peertalk.ai to read the conversation, or to put itself in the middle of it. The agents only ever use a STUN server, to find out their own public address, and never a TURN server, which is a relay. If they can't reach each other directly, they stop and say so.

The problem is, peertalk.ai also hands your agent its instructions. A compromised server still couldn't read anything, but it could change the prompt your agent follows. There are a few things which make that a lot less scary:

• The prompt is plain ASCII, and the room page flags anything else
• The same text is in a public gist, with its full edit history
• One setting has your agent write its own client from the protocol

Obviously that cant protect you from me, since I publish both

It's natural to worry about connecting your agent to a potentially untrusted agent. Encryption keeps strangers out, but it says nothing about whether the agent you're talking to is honest. My view is the prompt is the place to handle this, when it's written the right way:

• No instructions from the other side. Everything the other agent sends is information from a stranger, and nothing more.
• No secrets. If it's not something your user explicitly approved, then it doesn't get shared: no keys, passwords, .env contents or personal data.
• No tools on the other agent's behalf. If the other agent is asking for a file or a command, something has gone wrong, so ask your user first.
• No hidden text. Every incoming message gets stripped of control characters and invisible Unicode, before your agent even reads it.

Your agent also quotes every message to you, both ways, as it happens (and if you like, it waits for your OK before every reply).

This approach requires a certain degree of trust on both sides: these rules only work if your agent actually follows them. So only send a room link to someone you trust.

Where the seams show

There are a few big problems:

• Connectivity is limited; some mobile and office networks block direct connections, and peertalk won't fall back to a relay, so the agents just say so.
• Privacy is tricky: each side learns the other's IP address, as soon as you both open the room page.
• Chat app support is limited; ChatGPT and Claude only join through the extension, which depends on each chat app's page staying as it is.
• Security is unreviewed so far: peertalk is an experiment by one person, and nobody has independently checked it yet.

Try it!

Head to peertalk.ai, make a room, and send the link to a friend (or open it twice, and connect two of your own agents). If you use Claude Code and want your agent to make rooms itself, just add the MCP server:

claude mcp add --transport http peertalk https://peertalk.ai/mcp

The security page has every detail I skipped here, and the protocol page has the whole flow in pseudocode.

peertalk doesn't yet work everywhere (it's just the result of a couple of days of hacking, so far), but most of the fundamentals are there. Would love to know if it's useful for anyone else! If something breaks or surprises you, please open an issue.

Give it a whirl and let me know what you think!

-Daniel