buzz-acp: terminal turn failures (provider 403/auth errors) are never surfaced to the channel — the agent just goes silent

[zacklavin11]

Summary

When an agent seat's turn fails terminally (turn.ended with reason: "failed"), buzz-acp records the failure in the session wire log and does nothing else. Nothing is posted to the channel, the mentioning user gets no signal, and from every other participant's point of view the agent simply vanishes mid-assignment.

We hit this in production use: a seat running the kimi-code agent ("agent_command": "kimi", model kimi-code/k3-256k) exhausted its provider's billing quota mid-build. Every subsequent turn — including direct @mentions asking for status — died in under 2 seconds with:

"turn.ended","turnId":8,"reason":"failed","error":{
  "code":"provider.auth_error",
  "message":"403 You've reached your usage limit for this billing cycle. Your quota will be refreshed in the next cycle. To continue now, purchase extra usage or upgrade your plan: https://www.kimi.com/code/#pricing",
  "name":"APIStatusError",
  "details":{"statusCode":403},
  "retryable":false
}

Thirteen consecutive turns failed this way across ~13 hours (wire.jsonl, ~/.kimi-code/sessions/.../agents/main/wire.jsonl). The channel showed zero trace. The team concluded the agent was unreliable and reassigned its work — the actual cause (a paywall 403) was only discovered by manually reading the harness session logs.

Why this matters

• A human teammate who can't work says so. An agent seat that hits a provider error goes silent forever, which reads as the agent being broken rather than the account being out of quota.
• The error is retryable: false — no amount of waiting or re-mentioning recovers it, so every future mention silently fails too. The seat is a black hole until someone thinks to read wire logs.
• We have seen at least one agent runtime surface its own retry-failure to the channel ("⚠️ I couldn't process the last request after multiple retries (code -32603)…"), so the channel is clearly a viable place for this — it's just not done for terminal turn failures generally / uniformly at the harness level.

Requested behavior

When a turn ends with reason: "failed" and a non-retryable error (or after retries are exhausted), buzz-acp should post a short failure notice to the channel the triggering event came from — e.g.:

⚠️ couldn't complete this request: provider error 403 (usage limit reached). No further requests will succeed until the account is restored.

Ideas that would make it even better (optional):

• Distinguish provider/auth/quota errors (permanent until human action) from transient ones in the wording.
• Rate-limit the notice (once per failure streak, not once per mention) so a dead seat doesn't spam.
• Also reflect the failing state in presence, so other agents/humans can see the seat is down before mentioning it.

Environment

• Buzz Desktop (macOS, Apple Silicon), buzz-acp harness, seat configured in managed-agents.json with "acp_command": "buzz-acp", "agent_command": "kimi", turn_timeout_seconds: 320.
• Reproduces with any provider returning a terminal error; observed with kimi-code's 403 quota wall.