Summary
The Rust code already supports a per-adapter max_bot_turns soft cap on consecutive bot turns per thread (src/config.rs:106, :165; default 20 via default_max_bot_turns() at src/config.rs:109; soft-cap behaviour in src/bot_turns.rs). config.toml.example:32 documents max_bot_turns = 20 as a settable key.
However, the Helm chart does not render this field in either the Discord or Slack block of charts/openab/templates/configmap.yaml. The chart currently renders allow_bot_messages, trusted_bot_ids, allow_user_messages, allowed_channels, allowed_users — but not max_bot_turns. So tenants deploying via the chart are stuck on the hardcoded default of 20 with no override path.
Why this matters
In multi-agent setups (e.g., the Krabs/Bob/Patrick three-agent collaboration we run in prod-common/openab/openab-{krabs,bob,patrick}-dev), the natural conversation length in a single thread can exceed 20 bot turns before a human intervenes — especially during plan review (Phase 2) and the up-to-six review rounds in Phase 4 of the team workflow. Hitting the soft cap at 20 throttles the workflow mid-conversation with no operator-visible knob to raise it.
Proposed change
Add two-line gated rendering in charts/openab/templates/configmap.yaml for both Discord and Slack:
{{- if hasKey ($cfg.discord | default dict) "maxBotTurns" }}
max_bot_turns = {{ ($cfg.discord).maxBotTurns | int }}
{{- end }}(equivalent block for ($cfg.slack)).
Then tenants override per-environment, e.g. in fleet-infra:
agents:
claude:
slack:
maxBotTurns: 50
discord:
maxBotTurns: 50Defaults remain 20 (Rust-side) when the field is not set in chart values.
Out of scope
- The hardcoded
HARD_BOT_TURN_LIMIT = 100 in src/bot_turns.rs:14 stays a Rust constant — adjusting that is a code-level decision, not a deployment knob.
- No Rust code change is required.
- No new tests required (existing
bot_turns.rs tests already cover soft-limit semantics; this PR only wires the value through the chart).
Summary
The Rust code already supports a per-adapter
max_bot_turnssoft cap on consecutive bot turns per thread (src/config.rs:106,:165; default 20 viadefault_max_bot_turns()atsrc/config.rs:109; soft-cap behaviour insrc/bot_turns.rs).config.toml.example:32documentsmax_bot_turns = 20as a settable key.However, the Helm chart does not render this field in either the Discord or Slack block of
charts/openab/templates/configmap.yaml. The chart currently rendersallow_bot_messages,trusted_bot_ids,allow_user_messages,allowed_channels,allowed_users— but notmax_bot_turns. So tenants deploying via the chart are stuck on the hardcoded default of 20 with no override path.Why this matters
In multi-agent setups (e.g., the Krabs/Bob/Patrick three-agent collaboration we run in
prod-common/openab/openab-{krabs,bob,patrick}-dev), the natural conversation length in a single thread can exceed 20 bot turns before a human intervenes — especially during plan review (Phase 2) and the up-to-six review rounds in Phase 4 of the team workflow. Hitting the soft cap at 20 throttles the workflow mid-conversation with no operator-visible knob to raise it.Proposed change
Add two-line gated rendering in
charts/openab/templates/configmap.yamlfor both Discord and Slack:{{- if hasKey ($cfg.discord | default dict) "maxBotTurns" }} max_bot_turns = {{ ($cfg.discord).maxBotTurns | int }} {{- end }}(equivalent block for
($cfg.slack)).Then tenants override per-environment, e.g. in fleet-infra:
Defaults remain 20 (Rust-side) when the field is not set in chart values.
Out of scope
HARD_BOT_TURN_LIMIT = 100insrc/bot_turns.rs:14stays a Rust constant — adjusting that is a code-level decision, not a deployment knob.bot_turns.rstests already cover soft-limit semantics; this PR only wires the value through the chart).