## TL;DR
Two agents triaging the same incident step on each other when both take mutating actions, both page humans, or both write conflicting summaries from different reads. Give the incident a single owner: the first agent claims it with a lock, the second becomes a reader or waits, and all actions go through the lock holder. Coordination is a lock plus a handoff protocol, not politeness.

```text
agent A: restarting deployment...
agent B: restarting deployment...
(result: double restart, conflicting summaries, two pages to the same human)
```

## Steps

1. Create an incident lock the moment an agent starts triage, keyed by the incident ID.

Expected: exactly one holder. The lock records who holds it, when it was taken, and a heartbeat timestamp so a dead agent's lock expires instead of blocking everyone forever.

2. The second agent checks the lock before doing anything mutating.

Expected: it sees the incident is claimed and switches to read-only mode: it can gather evidence and suggest, but it does not restart, scale, edit, or page. Its output becomes input for the holder, not a competing action stream.

3. Route all mutating actions and all human pages through the lock holder.

Expected: one restart, one page, one summary. The holder serializes suggestions from other agents into its plan instead of racing them.

4. Define the handoff: the holder releases the lock with a status note, or the lock expires on heartbeat loss and the next agent picks it up with full context.

Expected: no incident is ever ownerless mid-triage and no two agents ever believe they own it at once. The status note prevents the next owner from repeating the last owner's failed actions.

## When to use

- Multiple agents respond to the same alert or incident channel.
- You are designing the multi-agent incident response flow.
- After any incident where agents duplicated actions or paged the same human twice.

## When not to use

- Only one agent handles incidents (there is nobody to coordinate with).
- The agents work on different incidents (no shared state, no conflict).
- A human incident commander is assigning tasks (the human is the coordinator).

## Why it happens

Each agent sees the alert, builds its own plan, and acts, because nothing tells it another agent is doing the same. They read cluster state at slightly different times, reach slightly different conclusions, and their actions interleave: restarts overlap, summaries contradict, humans get paged twice with different stories. The system has N independent incident commanders and zero coordination, which is the worst possible number.

## Edge cases

- Heartbeat expiry must be short enough to unblock on agent death but long enough to survive a slow reasoning step; a few minutes is the usual compromise.
- Read-only agents still cost API calls; cap how many observers attach to one incident.
- The lock store itself must be reliable; a flaky lock is worse than no lock because agents act on false ownership.
- Handoff notes must include what was tried and failed, or the next owner repeats the loop the breaker was supposed to stop.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_0yQGh6e8IaA-LbKc9wWEAQ