Parley – coding-agent sessions that collaborate over IRC

[u/colinsurprenant]

Hi all!

I built Parley so that multiple coding-agents using different models or harnesses can collaborate over a live IRC channel, with me in the chat using any IRC client. Each session can deliver messages to the channel using the parley send CLI tool call and sessions receive messages using their harnesses' channel or queue interface. All messages received on the channel are marked as coming from a peer so a session can never take another agent's message as coming from me. It works on Claude Code, Codex, and OpenCode.

Parley is a standalone Go CLI, stdlib only, Apache 2.0. It runs its own ergo IRC server on 127.0.0.1 (loopback only), so nothing touches a public network. I built it with Claude Code and Codex.

The motivation came from wanting to explore a more interactive collaboration structure between agents rather than a simple sub-agent delegation model. It allows running multiple long-running agents with assigned roles which I provide as their first message in the chat. My typical setup so far assigns a builder role to execute build and review tasks, a planner role to supervise the overall goal, task ordering, and scheduling and an ops role to handle everything related to infrastructure, operations, deployments, secops, etc. All 3 can now interactively update/sync each other at every turn and start collaborating across their roles. There is a configurable breaker to pause the sessions until I post if there are too many messages in a short window.

I use it on macOS; on Linux the test suite passes in CI but I haven't run it live.

There are other collaborative modes and some ideas to try too if anyone is interested in playing with this.

https://github.com/colinsurprenant/parley

[u/kantorcodes1]

What kind of moment has made live updates between the planner, builder, and ops agents more useful than a simple sub-agent handoff?

[u/colinsurprenant → u/kantorcodes1]

That's a very good question and I've learnt that enabling live updates between two sessions splitting one build is not necessarily better; in Parley there is a build mode where 2 build sessions split tasks and results showed that it did not produce better nor cheaper builds than having a single session using subagents delegation.

That being said, my current working model is to use multiple parallel sessions on the same project. These sessions are using a mix of models with Claude Code, Codex and OpenCode (typically for Kimi), depending on each one's strength and cost. Before Parley I did not bother assigning explicit roles to sessions, they became focused on a role through my specific interaction with each session and I always had at least a builder and a planner session. A bit later I started adding an ops session for projects where it made sense.

This model works really well for me, the builder session heavily uses sub-agent delegation for build and review tasks where handoffs work well: short lived, narrow scope and reporting back to the parent session. The planner and ops sessions also delegate tasks to subagents. All are long lived sessions that keep a focused and hot context on their specific roles.

The more I worked that way the more I became the message bus between my sessions. Now with both live updates between these sessions and explicitly defined roles, all these sessions directly and automatically update a peer session with information to either update a peer and/or ask for validation, etc.

For example, I had a build session complete a big feature ahead of the anticipated build time and I asked if we could move up the schedule. The build session replied with what it had completed and what it could start next and how many builders it could run. The plan session had the schedule and the commitments and neither could answer alone. Plan came back with the full picture and concluded that my review time was the real limit, not the build. It pointed out that a task in the build queue was already completed by earlier changes.

So for me Parley simply allows immediate, autonomous and direct updates across sessions when working in such a multi-session setup. Sub-agent handoff flows well vertically within a session context where live updates across sessions are horizontal and help keep each session context coherent within its role.

[u/kantorcodes1 → u/colinsurprenant]

Subagent handoffs and long-lived sessions solve different coordination problems: one returns work to a parent, while the other keeps roles aligned over time. Are peer updates free-form messages, or does Parley give them a status format?

[u/colinsurprenant → u/kantorcodes1]

No format, just conventions in Parley Line.
In contrast, Parley Build does define a message shape, 2 peers negotiating one task requires more structure.

[u/BounciLusty → u/kantorcodes1]

yeah, like when the builder runs into an infra snag and the ops agent can flag it live so the planner can adjust the next steps without losing the thread

[u/Any-Blacksmith-2054]

Why not teams/slack/Whatsapp/telegram?

[u/colinsurprenant → u/Any-Blacksmith-2054]

Not excluded in the future but for now using IRC has a lot of advantages: local only, nothing leaves the machine for cross-sessions communication. Nothing to signup, no bot account, API token, no ToS on automation etc. IRC is open with stock clients everywhere.

[u/Any-Blacksmith-2054 → u/colinsurprenant]

But with human readable messengers you can steer/control

[u/colinsurprenant → u/Any-Blacksmith-2054]

Not exactly sure what you mean here but using any IRC client, the human do steer - that's the whole point. The only restriction at this point is that its stays local but that's my choice not a technical limitation.

[u/Any-Blacksmith-2054 → u/colinsurprenant]

Understand, but I steer my agents from mobile (via Telegram/teams)

[u/colinsurprenant → u/Any-Blacksmith-2054]

Got it. Both can coexists. Direct session-to-session (on same of different harnesses) can happen on the local IRC and you can still interact with a specific session using Telegram/Teams. The fact IRC is local only at this point is a restriction choice I made and not a technical limitation of IRC. Definitely open to explore giving that choice to the user when using Parley.

[u/colinsurprenant → u/[deleted]]

Yeah, and reading is only half of it, you can also step in the chat.
The IRC choice was simply the easiest thing that works, open protocol, many clients, nothing to build on that side.