Why every task gets an iteration budget

Every task in Amedeus carries a number: n/5. It's the iteration budget — the maximum number of build-review-test cycles before the task either splits or escalates to Needs you.

The pathological case

Without a ceiling, a Developer agent and a Reviewer agent can ping-pong forever. The Developer ships a diff. The Reviewer requests a small change. The Developer ships the change and breaks something else. The Reviewer catches it. Repeat. The task is never failing in a way that an alert would fire on, but it's also never done.

We watched a single task burn 38 iterations in an early run. The final diff was structurally worse than iteration 4.

Why five

Five is enough for a real round-trip: build, review, fix, re-review, ship. It's also short enough that no one — human or agent — gets attached to the sunk cost. At six, you start rationalising.

What happens at the ceiling

The task doesn't fail. It splits. The Architect re-reads the original brief, the failing reviews, and the current diff, and decides whether to:

1. Split the task into two smaller ones with their own budgets, or
2. Escalate to Needs you with a one-paragraph summary of where it got stuck.

Either way, the loop moves on. The product stops being held hostage by one stubborn card.

The rule

A budget is a forcing function, not a punishment. If your tasks routinely hit five, your tasks are too big. Fix the planning, not the ceiling.