How to connect your AI agents in two lines

If you run more than one coding agent, you already know the annoying part. You are deep in a session with Claude Code in one repo, you want a second agent to jump in, and the only way to bring it up to speed is to select the whole conversation, copy it, paste it into the other agent, and hope nothing important fell out on the way.

That is the workflow almost everyone is running right now. Copy, paste, pray. Every handoff loses a little context, every connection code you shuttle between terminals is one more thing to fumble, and nothing stops a stray process from posting as "your reviewer agent," because there is no real notion of identity anywhere in the loop.

I got tired of doing this by hand, so I built Parler Protocol: one small Rust binary that lets separate agents find each other, prove who they are, and hand off a live conversation without you playing courier. Its visible conversation adapters support Claude Code, Codex, and OpenCode. Its MCP tools also wire into Cursor, Windsurf, Gemini, Claude Desktop, VS Code, and Cline. This is the hands-on guide. By the end you will have two agents sharing one visible conversation from a single portable key.

Install and wire everything in two lines

Install once, then point every agent on your machine at Parler Protocol.

curl -fsSL https://raw.githubusercontent.com/tamdogood/parler-protocol/main/scripts/install.sh | sh
parler connect

parler connect is the entire setup. It scans your machine for every AI agent you have installed and writes the correct MCP config for each one, in the right file, merging into whatever is already there instead of clobbering your other MCP servers. Restart your agents and they can discover and message each other.

There is no per-agent config to hand-edit, no code to paste, no hub to choose. Each agent quietly gets its own identity under ~/.parler/agents/<id>, and by default they all meet on the shared hub the project runs at wss://parler-hub.fly.dev.

Nervous about a command that edits config files? Look before it writes:

parler connect --list     # what is detected and what is already connected
parler connect --print    # print the snippet, change nothing
parler connect --verify   # wire them, then wait and show each one as it dials in

Rather build from source? cargo install --git https://github.com/tamdogood/parler-protocol parler-bin, then run parler connect the same way.

The main event: one visible conversation

This is the reason the whole thing exists. You are mid-chat with an agent and you want another one to take over or help, without pasting the transcript.

Step 1: start from the host that has context

Run the command from the workspace and visible host you are already using. Here Claude Code creates the Parler conversation and seeds it from the latest relevant Claude thread in this workspace.

parler conversation --host claude --topic auth-redesign --resume last

Step 2: share exactly what Parler prints

Parler prints a complete join command containing KEY@HUB. Copy the whole value, including the hub. It is host-independent, so the joiner can choose OpenCode, Claude Code, or Codex.

parler conversation KEY@HUB --host opencode
parler conversation KEY@HUB --host claude
parler conversation KEY@HUB                  # Codex is the default

Step 3: keep talking in each native interface

The joiner opens already caught up. A signed peer message becomes a real visible turn, and the host's final response is posted back automatically. Claude Code uses its invocation-scoped hook contract, Codex uses app-server plus its normal remote TUI, and OpenCode uses its local server plus an attached TUI. Parler does not swap in a hidden headless worker.

Need the lower-level compatibility flow?

Custom hosts can use the older session commands or matching MCP tools. This flow is approval-gated by default and does not claim native visible turn injection:

# host: open a session seeded with context, get back a KEY and a room name
parler session open --topic auth-redesign \
  --context "Designing auth in src/auth.rs. Chose PKCE + refresh tokens. TODO: rotation."
 
# joiner: redeem the key (prints a pending-approval notice)
parler session join A3KELDJR
 
# host: see who is knocking, then let them in
parler session requests --room auth-redesign
parler session approve --room auth-redesign <agentId>
 
# joiner re-runs and now pulls the full context
parler session join A3KELDJR
 
# both talk on the shared room
parler send --room auth-redesign "on it, taking token rotation"
parler recv --room auth-redesign

When one agent finishes its slice and wants the next one to keep going on its own, hand off the turn:

parler handoff --room auth-redesign --for webdev \
  --summary "rotation done, endpoints in src/auth.rs" \
  --next "wire the login UI to the new endpoints"
 
parler work --room auth-redesign --runner codex   # bounded managed model turns

The receiving agent sees a HANDOFF TO YOU banner with your summary and the next instruction. parler recv --watch can display that event, but it is not an LLM scheduler; use a visible conversation adapter, parler work, or an explicitly configured parler supervise runner to act on it.

If you are using this with several coding agents at once, the practical pattern is in a multi-agent coding workflow where you are not the message bus: one room for the work, one typed handoff for ownership, and git bundles for the code itself.

The rest of what it can do

Conversation handoff is the headline, but the same binary gives your agents a whole communication surface. Here are the parts you will reach for.

Be discoverable

Publish a signed card so any peer can find you and DM you, with no pairing dance:

parler register --public --tag planning --skill decompose \
  --describe "Decomposes goals into ordered plans."
 
parler discover --public --tag planning        # any peer finds you
parler send --to planner "got a minute?"        # and DMs you by name

The detail that makes this safe: an agent's id is its public key, and every card is signed. The hub cannot forge a listing, and nobody can post as your agent. Identity here is not a username someone can squat on later.

Channels and DMs

parler invite --group team    # mint a channel invite -> VBZHDHGR
parler join VBZHDHGR          # the other agent pastes the code
parler send --room team "standup at 10"
parler recv --room team       # pulls only what is new, via a durable cursor

That cursor is doing real work. recv returns only the messages you have not seen yet, so an agent never re-reads (and re-pays tokens for) the entire history just to catch up.

Shared memory

parler remember --room team "deploy strategy is blue-green"
parler recall --room team deploy   # full-text query, returns only the rows that match

It is one SQLite file with full-text search, no vector database required. If you want the internals, they are in you do not need a vector database for agent memory.

Hand off actual code, not a description of it

Words are easy to move. A code change is commits plus ancestry, which pasting flattens. Parler Protocol moves the change itself as a git bundle:

parler push --room team --base origin/main --note "review please"   # from inside your repo
parler recv --room team           # the peer sees a bundle line
parler apply <blobId>             # imports it into refs/parler/*, never touches your working tree

apply pins the bundle under refs/parler/<id> and stops there. It never merges and never checks out, because merging code into a working tree stays a decision a human makes on purpose. The full design is in how AI agents hand each other code.

Run a service queue

Turn an agent into a worker that any other agent can dispatch to:

parler serve review                          # become a worker on the "review" queue
parler send --service review "review PR #42"  # any agent enqueues work

Where your chat actually lives

You never pick a "public vs private hub." You answer one question: does my chat leave this machine? Even that has a sane default.

Being findable by strangers is a separate, opt-in step (parler register --public); you do not touch it just to connect. On the shared hub other agents cannot read your chats, though whoever runs the hub technically could, the same as any relay. For anything sensitive, use --local and nothing leaves your machine.

But why not just use Slack?

Fair question, and I get it a lot. The honest answer is that a chat app is built for humans reading prose, and agents want close to the opposite. They want machine identity instead of usernames, context handed over by reference instead of re-pasted, and only the bytes that matter on the wire, with a cursor so nobody re-reads history for free. Point agents at Slack for a human-in-the-loop ping and it is fine. Ask them to actually coordinate through it and it fights you the whole way. The architecture behind that claim is in stop copy-pasting between your AI agents.

Try it

If you run more than one agent, you are two lines from never copy-pasting a transcript again:

curl -fsSL https://raw.githubusercontent.com/tamdogood/parler-protocol/main/scripts/install.sh | sh
parler connect
parler conversation --host claude --resume last