feat: raise max_bot_turns default to 100, raise hard cap to 1000

[chaodu-agent]

Summary

• Default max_bot_turns: 20 → 100 (both Discord and Slack)
• Hard cap: previously hardcoded MAX_CONSECUTIVE_BOT_TURNS = 10 — now configurable via max_consecutive_bot_turns (default: 100)

Motivation

The old default of 20 was too conservative for multi-agent collaboration scenarios. Many users already override it to 100+. The hardcoded cap of 10 consecutive bot messages was also too restrictive and not configurable at all.

Changes

File	Change
src/config.rs	default_max_bot_turns() → 100; new max_consecutive_bot_turns field (default 100) in both DiscordConfig and SlackConfig
src/discord.rs	Remove const MAX_CONSECUTIVE_BOT_TURNS; use self.max_consecutive_bot_turns
src/slack.rs	Remove const MAX_CONSECUTIVE_BOT_TURNS; use function parameter
src/main.rs	Wire new field through to both adapters
docs/config-reference.md	Document new field and updated defaults
docs/discord.md	Update bot turn limits section
config.toml.example	Add commented example
charts/openab/values.yaml	Document maxConsecutiveBotTurns
charts/openab/templates/configmap.yaml	Render new field

Migration

No breaking changes. Existing configs without the new field get the new defaults (100/100). Users who previously set max_bot_turns keep their value.

[github-actions]

⚠️ This PR is missing a Discord Discussion URL in the body.

All PRs must reference a prior Discord discussion to ensure community alignment before implementation.

Please edit the PR description to include a link like:

Discord Discussion URL: https://discord.com/channels/...

This PR will be automatically closed in 3 days if the link is not added.

[shaun-agent]

OpenAB PR Screening

This is auto-generated by the OpenAB project-screening flow for context collection and reviewer handoff.
Click 👍 if you find this useful. Human review will be done within 24 hours. We appreciate your support and contribution 🙏

• Title: feat: raise max_bot_turns default to 100, raise hard cap to 1000
• Source: feat: raise max_bot_turns default to 100, raise hard cap to 1000 #741
• Status: moved to PR-Screening
• Generated at: 2026-05-05T11:31:39.382Z
• Discord thread: https://discord.com/channels/1488041051187974246/1501184368977248359

Screening report

## Intent

PR #741 is trying to make OpenAB tolerate longer bot-driven conversations by raising the default bot turn budget and removing an overly low hardcoded consecutive-bot-message cap.

The operator-visible problem is that multi-agent or long-running collaboration flows can stop too early under the current defaults. The existing max_bot_turns default of 20 and the hardcoded consecutive bot cap of 10 are too conservative for workflows where agents legitimately need many turns before handing control back to a human.

Feat

This is a feature/configuration change.

Behaviorally, it changes Discord and Slack defaults so bots can continue longer by default:

• max_bot_turns: default increases from 20 to 100
• consecutive bot turn cap: changes from a hardcoded constant to configurable max_consecutive_bot_turns
• new default for max_consecutive_bot_turns: 100
• Helm/config/docs are updated to expose and document the new setting

The PR title says “raise hard cap to 1000,” but the body describes a configurable field defaulting to 100. That mismatch should be clarified before merge.

Who It Serves

Primary beneficiaries:

• Agent runtime operators running multi-agent workflows
• Discord and Slack deployers who need longer autonomous sessions
• Reviewers and maintainers who want bot-loop limits to be explicit configuration rather than hidden constants

Secondary beneficiaries:

• End users who currently see useful agent work stop prematurely
• Future maintainers debugging runaway bot behavior

Rewritten Prompt

Implement configurable bot turn limits for Discord and Slack.

Raise the default max_bot_turns from 20 to 100 for both adapters. Replace the hardcoded consecutive bot message limit with a new config field, max_consecutive_bot_turns, available under both Discord and Slack config, defaulting to 100 unless a different intended hard cap is confirmed. Wire the value through runtime code, Helm chart values, generated config, examples, and docs.

Preserve backward compatibility for existing configs. Add or update tests to verify default values, config deserialization, and adapter behavior when the consecutive bot cap is reached. Ensure the PR title, docs, and implementation agree on whether the maximum allowed value is 100, 1000, or simply operator-configurable.

Merge Pitch

This is worth advancing because it removes an artificial ceiling that blocks realistic multi-agent collaboration. Making the consecutive cap configurable is better than forcing every deployment into the same short limit.

Risk profile is moderate. The functional change is small, but the operational impact is meaningful: higher defaults can increase token usage, longer bot loops, and noise in shared channels if guardrails are weak.

Likely reviewer concern: whether raising defaults to 100 is safe for public Discord/Slack deployments, and whether there is still a clear upper bound or runaway-loop protection.

Best-Practice Comparison

OpenClaw principles that apply:

• Explicit delivery routing is relevant because longer bot loops should still respect channel/thread routing and avoid leaking responses into the wrong context.
• Retry/backoff and run logs are relevant as future guardrails for long autonomous interactions.
• Durable job persistence and isolated executions are only partly relevant. This PR is about turn limits inside chat adapters, not full scheduled job execution.

Hermes Agent principles that apply:

• Fresh session per scheduled run is not directly relevant unless these bot turns are part of scheduled/background runs.
• Self-contained prompts for scheduled tasks are not directly relevant to this config change.
• File locking and atomic persisted state are not relevant unless OpenAB persists bot-loop state across process restarts.
• The broader Hermes lesson that does apply: long-running autonomous work needs explicit anti-overlap and termination controls. Increasing limits should be paired with clear stop conditions and observability.

Overall, the PR aligns with the “make limits explicit” principle, but it does not by itself provide OpenClaw/Hermes-style durable execution safety, run logs, or stronger loop isolation.

Implementation Options

Conservative option: expose the new config field but keep defaults lower.

Add max_consecutive_bot_turns, remove the hardcoded constant, and document it, but keep max_bot_turns at 20 or raise only to a smaller value such as 50. This reduces operational risk while still giving deployers control.

Balanced option: merge the PR direction with clarified caps and tests.

Raise max_bot_turns to 100, add max_consecutive_bot_turns defaulting to 100, wire it through Discord, Slack, Helm, examples, and docs. Add validation if there is an intended hard maximum, and add tests for defaults and cap enforcement.

Ambitious option: introduce richer autonomous-run guardrails.

In addition to configurable turn caps, add structured run tracking, reason-coded termination, per-adapter observability, optional token/time budgets, and admin-facing logs. This would better support multi-agent workflows but should probably be split from the current PR.

Comparison Table

Option	Speed to ship	Complexity	Reliability	Maintainability	User impact	Fit for OpenAB right now
Conservative: configurable cap, smaller/default unchanged limit	High	Low	Medium	High	Medium	Good if maintainers are worried about runaway loops
Balanced: raise defaults to 100 and make consecutive cap configurable	Medium	Low-Medium	Medium	High	High	Best fit if tests and docs/title are aligned
Ambitious: add full autonomous-run guardrails and observability	Low	High	High long-term	Medium	High	Better as follow-up work, not bundled into this PR

Recommendation

Advance the balanced option, but require cleanup before merge.

The PR addresses a real friction point and the implementation scope appears appropriately small. The next reviewer should focus on consistency and safety: resolve the title/body mismatch around “hard cap to 1000,” confirm whether any validation maximum exists, and add tests around default config values plus enforcement of max_consecutive_bot_turns.

Recommended sequencing: merge the configurable limits as a focused change, then open a follow-up for stronger long-run observability and termination reasons if OpenAB expects multi-agent sessions to become common.

[chaodu-agent]

Review Summary

Three monks reviewed and approved. Looking for additional community feedback before merge.

What this PR does

• Soft limit (max_bot_turns): default 20 → 100 (configurable, per bot per thread)
• Hard cap (MAX_CONSECUTIVE_BOT_TURNS): 10 → 1000 (hardcoded, not configurable)

Design decisions

• Hard cap is intentionally hardcoded — no config field exposed
• Discord HTTP fallback path (max 100 messages) will never trigger the 1000 hard cap; cache path can
• Slack API limit clamped to 1000 (API max)
• Both limits are per-bot, per-thread; no global thread total cap

Files changed

• src/config.rs — default_max_bot_turns() → 100
• src/discord.rs — const MAX_CONSECUTIVE_BOT_TURNS: u32 = 1000 (was u8 = 10)
• src/slack.rs — const MAX_CONSECUTIVE_BOT_TURNS: usize = 1000 (was 10), limit clamped
• src/main.rs — no new wiring needed (hardcoded)
• docs/, charts/, config.toml.example — updated accordingly

cc @openabdev/contributors — any NITs or concerns?