Halt

Undefined failure semantics are how multi-agent systems hang for hours while burning tokens. This policy is deliberately blunt.

The policy

Transport-level failure — timeout, rate limit (429), connection reset, transient provider error:

Retry ONCE, with backoff. If the retry succeeds, continue and note it in the delivery. If the retry fails, halt.

Anything else — a non-transport error, a malformed or empty return, an agent that contradicts its own work order, a crash:

Halt immediately. Do not retry.

There is no third attempt. A second failure is a signal, not noise.

Halting means halting

1. Stop dispatching. No new sys_session_send calls.
2. Let in-flight work finish if it can. Do not kill sessions mid-write — a half-written file is worse than a stopped run. Collect what returns.
3. Preserve state. Write to .agentic/convenes/<id>/ or the work order: what was in flight, what completed, what returned nothing, the exact error text. The next run resumes from this, so vagueness here costs a re-run.
4. Notify the PM using escalate, with the error text verbatim. Do not paraphrase an error message — the exact string is usually the diagnosis.
5. Do not proceed on a degraded roster. Continuing with two of three council members silently converts a three-way convene into a two-way one, which no longer meets the >=50% threshold it was designed around.

What is NOT an error

• An agent returning "I could not do this, here is why" — that is a valid delivery. See delivery.
• A convene that deadlocks — that is escalate, not halt.
• A QA finding, however severe — that is a finding, and the Scrum Master decides.

Recording

Log every halt as a setback using the project's existing incident format if it has one (setback-logger / tracking-setbacks). Halts that recur in the same place are the cheapest available signal about where this framework is weak.