What happened?
Problem
Triage batches (gt:triage-request beads) are being routed to polecat-role agents, which cannot resolve them (403). The polecat escalates, the escalation creates a new triage batch, which routes to another polecat → 403 → escalation → repeat. This is an infinite loop.
Reproduction
- Rig has polecat agents + refinery only (no triage-role agent). Town: de470244-d6cb-45e9-b8b1-80d0ef49bad8, rig: fab73ba4-4414-4959-a64c-44b267c67efe (dukun-gps).
- A triage batch is created (e.g. from a bead failure or escalation).
- System routes it to a polecat agent.
- Polecat returns 403 (cannot resolve triage — wrong role).
- Polecat escalates to Mayor.
- Escalation spawns a new gt:triage-request bead.
- Goto step 3.
Observed (this town, 2026-07-15 ~17:28–17:36 UTC)
At least 4 escalation cycles in ~8 minutes:
- 78532cb7 (17:33) — acknowledged + triage bead ebd624df closed by Mayor
- 5aae348e (17:34) — acknowledged + triage bead 471e3064 closed by Mayor
- 8ab8e25d (17:36) — acknowledged + triage bead 2a6bdba4 closed by Mayor
- ff4f3d02 (17:28) — closed earlier
Closing the triage-request beads manually breaks the CURRENT cycle, but the next triage trigger starts a new one.
Expected behavior
- If a rig has no triage-role agent, triage batches should escalate directly to the Mayor without routing to a polecat first (avoiding the 403 + re-escalation loop), OR
- The system should detect no triage-role agent exists and surface a clear "no triage agent available — Mayor must resolve manually" instead of repeatedly misrouting.
Impact
- Spams the Mayor with repeated high-severity escalations every ~1-2 minutes.
- Wastes polecat compute on 403 rejections.
- Blocks the Mayor's attention from actual work.
Suggested fix
- Add role-capability check before dispatching a triage batch: if no triage-role agent exists in the rig, route the triage decision directly to the Mayor (one-time escalation), do not spawn a gt:triage-request bead that re-routes to a polecat.
Area
Agent Dispatch / Scheduling
Context
- Town ID: de470244-d6cb-45e9-b8b1-80d0ef49bad8
- Agent: Mayor (e5911917-2d4e-4b91-a69f-a374c44b25da)
- Rig ID: fab73ba4-4414-4959-a64c-44b267c67efe
Recent Errors
Triage batch routed to polecat-role agent — cannot resolve (403). Repeated 4+ times in rig fab73ba4-4414-4959-a64c-44b267c67efe, town de470244-d6cb-45e9-b8b1-80d0ef49bad8, between 17:28–17:36 UTC on 2026-07-15. Escalation bead IDs: 78532cb7, 5aae348e, 8ab8e25d, ff4f3d02.
Filed automatically by the Mayor via gt_report_bug.
What happened?
Problem
Triage batches (gt:triage-request beads) are being routed to polecat-role agents, which cannot resolve them (403). The polecat escalates, the escalation creates a new triage batch, which routes to another polecat → 403 → escalation → repeat. This is an infinite loop.
Reproduction
Observed (this town, 2026-07-15 ~17:28–17:36 UTC)
At least 4 escalation cycles in ~8 minutes:
Closing the triage-request beads manually breaks the CURRENT cycle, but the next triage trigger starts a new one.
Expected behavior
Impact
Suggested fix
Area
Agent Dispatch / Scheduling
Context
Recent Errors
Filed automatically by the Mayor via
gt_report_bug.