Feature description
Add a loop guard for consecutive successful backend iterations that emit no valid routing/completion event.
Motivation
event_loop.stall_iterations only catches repeated identical output. An agent can produce different progress prose—or an empty response—on every iteration while never invoking the required event tool. The recent event therefore never advances and the same role is activated repeatedly until max_iterations or wall-clock timeout.
Observed examples:
iteration 5: critic says it will publish review.passed; emittedTopic=""
iteration 6: critic says it is publishing review.passed; emittedTopic=""
iteration 7: output="(empty)"; emittedTopic=""
iteration 8: same recent_event=review.ready, critic activated again
The outputs differ, so ordinary stall detection does not stop the loop.
Proposed solution
Add a setting such as:
event_loop.max_no_event_iterations = 2
Count consecutive completed backend turns with no accepted emitted event while a topology role has a non-empty allowed-events set. Reset on an accepted event. When exceeded, stop or emit a dedicated actionable terminal event such as routing_event_missing containing:
- active role;
- recent event;
- allowed events;
- output tail;
- number of no-event turns.
A stricter optional mode could treat one no-event turn as an immediate role failure and reroute to a configured blocked event.
Alternatives
- Folding this into
stall_iterations would be less precise because semantically stalled turns can have non-identical prose.
- Prompt hardening helps but does not protect against empty responses, tool failures, or model noncompliance.
Environment
- AutoLoop 0.10.1
- Hermes ACP backend
- Multi-role AutoCode/AutoFix presets
Feature description
Add a loop guard for consecutive successful backend iterations that emit no valid routing/completion event.
Motivation
event_loop.stall_iterationsonly catches repeated identical output. An agent can produce different progress prose—or an empty response—on every iteration while never invoking the required event tool. The recent event therefore never advances and the same role is activated repeatedly untilmax_iterationsor wall-clock timeout.Observed examples:
The outputs differ, so ordinary stall detection does not stop the loop.
Proposed solution
Add a setting such as:
Count consecutive completed backend turns with no accepted emitted event while a topology role has a non-empty allowed-events set. Reset on an accepted event. When exceeded, stop or emit a dedicated actionable terminal event such as
routing_event_missingcontaining:A stricter optional mode could treat one no-event turn as an immediate role failure and reroute to a configured blocked event.
Alternatives
stall_iterationswould be less precise because semantically stalled turns can have non-identical prose.Environment