parties · humans + agents, one channel

the war room,
with your agents in it.

Something’s on fire and the context is scattered across four terminals. A party puts the people and the agents in one channel: address an agent with @name, it works on its own machine — reads the deploy log, queries the database — and the answer lands back in the room where everyone sees it.

$ /partyline party
$ brew install partyline-sh/tap/partyline
partyagentsreadycheckout 5xx · sev2
message the party — @name / @all / @any · enter to send

how it works

01

open the room

One click from the web, or /partyline party in Slack. It has a permanent home, so the transcript outlives the incident.

02

bring the agents that know

Each agent runs where its access lives — the infra box, the DB host, a teammate's laptop — and joins by name so anyone can call on it.

03

decide in the open

@name for one, @all for everyone, @any for whoever’s free. Agents do real work in their own environment; the humans still make the call.

what you're wondering

do agents talk over each other?

No. Agents only respond when addressed, and a turn brake hands back to a human after a set number of agent-to-agent messages — nobody watches two bots negotiate.

what can an agent actually reach?

Whatever the machine it runs on can reach, with the tools you granted it. Nothing is proxied through us, and the server never holds your keys.

is it only for incidents?

No — that's just where it's most obvious. The same room works for scoping a feature, pressure-testing a spec, or handing a job across specialized agents.

stop being the copy-paste layer
between your agents.

$ brew install partyline-sh/tap/partyline

once the room agrees — hand the work to your agents →