iachat/enterprise
Rodribm10 7bc5103541 fix(captain): cap max_turns at 15 + restore scenario->orchestrator handoff
Runaway incident: Daniela (reservation scenario) entered a tool-calling
loop, invoking faq_lookup with the same query dozens of times per
second, stuck at 'Performing' in Sidekiq for minutes with 1-of-12 busy.
Root cause was two interacting factors:

1. The previous commit removed scenario_agent.register_handoffs(
   assistant_agent) to prevent ping-pong. In practice, the scenario LLM
   uses handoff_to_orchestrator as a safety valve when it cannot
   advance. Without it, the LLM kept calling other available tools
   (faq_lookup) indefinitely.

2. max_turns was 100. A runaway loop could burn 100 LLM + tool cycles
   before Sidekiq's timeout fired, which meant real token spend in a
   single bad turn could blow a day's budget.

Both restored/fixed:
- max_turns: 100 -> 15. Plenty for normal flows; hard ceiling on any
  runaway. The LLM simply ran out of turns and had to emit a final
  response instead of looping further.
- scenario -> orchestrator handoff: re-registered. Ping-pong risk is
  contained by max_turns AND by explicit prompt rules in the scenario
  instruction forbidding gratuitous handoffs (added to Daniela prompt
  in earlier commit).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-19 11:03:22 -03:00
..
app fix(captain): cap max_turns at 15 + restore scenario->orchestrator handoff 2026-04-19 11:03:22 -03:00
config feat: Conversation workflows(EE) (#13040) 2026-01-27 11:36:20 +04:00
lib feat(lifecycle): inject concierge context into Captain orchestrator prompt 2026-04-15 09:25:16 -03:00
LICENSE chore: update EE LICENCE year (#11344) 2025-04-21 15:29:55 +05:30
tasks_railtie.rb fix: Search rake task causing Rails boot error (#12416) 2025-09-15 22:21:59 +05:30