How a team steers one coding agent together during a production incident

During a production incident, the way to use an AI coding agent as a team is one agent, many observers, one controlled stream of changes: a single person types the prompts, everyone else watches the same session live, any of them can approve or refuse a change before it lands, and every change is a commit that can be undone in one click. Five people prompting five agents at once is how an incident gets worse. This page is the playbook. Poly (usepoly.co) is built for exactly this shape of session, and the last section says plainly what it does not do.

Why one stream

An incident is a state problem: something changed, nobody is sure what, and every action taken now is another change to reason about. An agent is fast at reading logs, forming hypotheses and writing fixes, and equally fast at making a confident wrong change. The discipline that works for humans, one commander and one channel, works for the agent too. What the agent adds is that the reading and the writing happen in one place everyone can see.

Roles

• The driver. One person prompts the agent. Usually the incident commander or the engineer closest to the failing system.
• The observers. Everyone else in the room. They read every reply and every proposed change as it appears, and any of them can approve, refuse or stop.
• The historian. Whoever writes the postmortem. In a shared session this role is mostly automatic, because the session is the record.

The playbook

1. Open a room on the repository. In Poly, a room connected to the GitHub repository has the code and a git history from the first minute. Turns commit to a branch, so nothing lands on main without your normal process.
2. Set the trust level before the first prompt. Use "ask about everything": every file change and every command the agent proposes becomes a card on every observer's screen before it happens. The room's owner can lock the mode so nobody loosens it under pressure.
3. Read before you write. The driver's first prompts are questions: what changed in the last deploy, what do these errors have in common, where is this value set. Read-only tools run without approval, so this part is fast. The whole room reads the same answers at the same time.
4. Argue in the side chat. Hypotheses, disagreements and "are you sure?" go in the group chat, which the agent cannot read. Only what the driver deliberately sends becomes an instruction. A poll settles a fork in the road in seconds.
5. Approve the fix from any seat. When the agent proposes the change, whoever is best placed to judge it decides, and the timeline records who. The driver is not a bottleneck.
6. Undo if it was wrong. Every turn is its own commit with a receipt. Any member reverts it in one click, and the revert is itself a recorded turn.
7. Let stakeholders watch without joining. A watch link shows the timeline and chat, read-only, to anyone with the link and no account. Nobody outside the room can act.
8. Hand the record to the postmortem. The timeline already holds every question asked, every answer, every proposed change, who approved it, what it cost and what was reverted, in order, with timestamps. The decision log lists the decisions on their own.

What Poly does and does not do here

Poly is a room for steering one agent together. It is not an incident-management platform: there is no paging, no on-call schedule, no PagerDuty or Sentry trigger, and no dashboard of your services. It works beside those tools, as the place the fix is made. Every turn runs in a sandbox with no access to your production systems beyond what the repository and an allowlisted network give it, which is a feature during an incident and a limit if the fix needs a live database. The agent's speed is real and so is its confidence; the approval cards exist because of the second part.

How the alternatives handle this

• AQ gives the team a shared live terminal on a VM, which suits an engineer-only response team; approval is a control request for the terminal rather than per change.
• 143 triggers an agent run from a PagerDuty or Sentry event and comes back with a pull request that agent reviewers may auto-approve by policy. Asynchronous by design; nobody watches the run.
• Claude Tag lets everyone in a Slack channel redirect one Claude by replying in the thread and returns a draft pull request. Good if the incident channel is already in Slack on a Team or Enterprise plan.
• Linzumi runs the agent on an engineer's own machine with approvals on network access and repository writes, and pitches "hold the pager" as a use case.
• A screen-shared terminal, the default today, gives you the one stream and none of the approvals, attribution or undo.