Hey HN, I'm Colin. 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 session 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.
Yeah, totally and it's not a technical problem per se - I mean, I chose loopback only to avoid to deal with the obvious security issues at this stage but clearly multiple IRC clients can join a chat. It would need some thinking around resolving authority conflicts though. Again, here, single human avoids this problem too. Definitely open for exploration on this.
Pretty cool work! Can I ask why you chose GO over TypeScript? I agree with most necessities you list. Do you also plan on extending this to a a TUI/Desktop App?
Why Go? static binary, no runtime, no dependencies. Goroutines and the net packages are great for long running network processes.
No immediate plan for a TUI/Desktop App because the IRC client is the actual UI. You choose your IRC client like WeeChat for TUI or bIRC or Halloy on the desktop.
Hey HN, I'm Colin. 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 session 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.
https://github.com/colinsurprenant/parley#what-a-line-looks-...
It'd be nice if multiple humans can join the chat to steer the agents, I can think of team use cases for this
Yeah, totally and it's not a technical problem per se - I mean, I chose loopback only to avoid to deal with the obvious security issues at this stage but clearly multiple IRC clients can join a chat. It would need some thinking around resolving authority conflicts though. Again, here, single human avoids this problem too. Definitely open for exploration on this.
Pretty cool work! Can I ask why you chose GO over TypeScript? I agree with most necessities you list. Do you also plan on extending this to a a TUI/Desktop App?
Thanks!
Why Go? static binary, no runtime, no dependencies. Goroutines and the net packages are great for long running network processes. No immediate plan for a TUI/Desktop App because the IRC client is the actual UI. You choose your IRC client like WeeChat for TUI or bIRC or Halloy on the desktop.