fix(agent): resolve iteration cap from the agent definition, not the global default (#4868)#4870
Conversation
…global default (tinyhumansai#4868) Direct-invocation agent builds (flows_build, flows_discover, tinyflows agent nodes, cron, subconscious, skill_runtime, task_dispatcher) all funnel through `Agent::from_config_for_agent` -> `build_session_agent_inner`, which unconditionally stamped the global `config.agent.max_tool_iterations` (default 10) onto every session agent -- ignoring the per-agent `AgentDefinition.max_iterations`/`iteration_policy` declared in each `agent.toml`. Only the sub-agent-runner path (used for delegated sub-agents) applied `effective_max_iterations()` correctly. The fix is one shared resolution point: `build_session_agent_inner` now clones `config.agent`, and when a `target_def` is present, overwrites `max_tool_iterations` with `target_def.effective_max_iterations()` before handing it to the builder. No definition -> unchanged global fallback. Four callers pre-set `max_tool_iterations` before calling `from_config_for_agent` and would otherwise have their override silently clobbered by the new shared logic: - `flows/ops.rs`: deleted the now-redundant `apply_builder_iteration_cap` scoped fix for `workflow_builder` -- the shared fix gives it the same 50. - `cron/scheduler.rs`: removed the manual `def.max_iterations` set, which also fixes a latent bug where it used the raw `max_iterations` instead of `effective_max_iterations()` (so extended-policy agents got shortchanged). - `skill_runtime/run_machinery.rs` and `agent/task_dispatcher/executor.rs`: moved their 200-iteration workflow/task-run override to a new post-construction `Agent::set_max_tool_iterations` setter, since the shared fix would otherwise stamp `orchestrator`'s definition cap (15) over their intentionally larger budget. - `subconscious/session.rs` and `subconscious/profiles/memory.rs`: same post-construction pattern, re-applying their mode-specific 15/30 cap after construction -- `profiles/memory.rs` in particular builds via `Agent::from_config` (-> `orchestrator`, cap 15), so without this the Aggressive/EventDriven tick would have silently dropped from 30 to 15. `tinyflows/caps.rs`'s agent-node runtime now also scales its wall-clock timeout for extended-cap agents (new `scale_timeout_for_iteration_cap`, floor of `effective_cap * 12s` capped at the existing 600s ceiling), since a 50-iteration agent can legitimately run past the previous 240s default. Full audit of every built-in `agent.toml`'s effective cap before/after is pinned by a new snapshot test (`all_builtin_agent_definitions_have_expected_effective_max_iterations`) so a future agent.toml edit can't silently change runtime behavior. Closes tinyhumansai#4868
📝 WalkthroughWalkthroughDirect agent construction now applies each named definition’s effective iteration cap. Runtime callers can override that cap after construction, subconscious modes preserve their budgets, and tinyflow agent-node timeouts scale with the resolved iteration limit. ChangesIteration cap resolution and runtime budgets
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant Caller
participant AgentDefinition
participant SessionBuilder
participant Agent
Caller->>SessionBuilder: build agent for named definition
SessionBuilder->>AgentDefinition: resolve effective_max_iterations()
AgentDefinition-->>SessionBuilder: return effective cap
SessionBuilder->>Agent: construct with definition cap
Caller->>Agent: set_max_tool_iterations(explicit budget)
Possibly related PRs
Suggested labels: Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
coderabbitai
Bot
added
agent
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 329f8571e0
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| let timeout_secs = | ||
| scale_timeout_for_iteration_cap(base_timeout_secs, effective_iteration_cap); |
There was a problem hiding this comment.
When an agent node provides timeout_secs, this now still passes the clamped explicit value through scale_timeout_for_iteration_cap, so any extended-policy agent with a 50-iteration cap turns a requested 30s/120s timeout into 600s. The existing contract in this file says the node's requested timeout_secs is clamped to 10..=600, and the unit test in src/openhuman/tinyflows/tests.rs asserts Some(120) -> 120; this change makes explicit fast-fail/SLA bounds ineffective for code_executor, tools_agent, etc. Scale only the default/no-timeout case, or otherwise preserve caller-supplied lower bounds.
Useful? React with 👍 / 👎.
| def_cap, | ||
| config.agent.max_tool_iterations, | ||
| ); | ||
| effective_agent_config.max_tool_iterations = def_cap; |
There was a problem hiding this comment.
This shared assignment also gives flow_discovery its extended effective cap of 50, but flows_discover still wraps the turn in FLOW_DISCOVER_TIMEOUT_SECS = 300 at src/openhuman/flows/ops.rs:3198-3200. With slower providers or tool calls averaging just over 6s per loop, the fixed 300s wall-clock timeout fires before the newly applied definition cap can be reached; workflow_builder was moved to a 600s bound for the same 50-iteration budget, so Flow Scout needs the same treatment or equivalent scaling.
Useful? React with 👍 / 👎.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/openhuman/subconscious/session.rs (1)
177-195: 📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick winCorrect mode-cap preservation; same missing state-transition log.
Shares the same root cause as the other three specialized-budget override sites; see the consolidated comment below.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/openhuman/subconscious/session.rs` around lines 177 - 195, The build_agent method correctly reapplies mode_iteration_cap after constructing the subconscious agent; add the missing state-transition log at this specialized budget override, matching the logging behavior used by the other three override sites.Source: Coding guidelines
🧹 Nitpick comments (1)
src/openhuman/agent/harness/session/runtime.rs (1)
161-174: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConsider logging the override for observability.
set_max_tool_iterationsmutates a state established by the newly-introduced definition-cap resolution flow (issue#4868), but the setter itself is silent — none of its current call sites (task_dispatcher::executor,subconscious::session,subconscious::profiles::memory) log the override either, they only carry a code comment. Given this is exactly the kind of state transition that caused confusion before this fix, alog::debug!/tracing::debug!line here (old cap → new cap, stable prefix) would make future cap-mismatch bugs much easier to diagnose across all call sites at once.♻️ Proposed logging addition
pub fn set_max_tool_iterations(&mut self, cap: usize) { + log::debug!( + "[agent::runtime] set_max_tool_iterations agent_id={} {} -> {}", + self.agent_definition_name, + self.config.max_tool_iterations, + cap + ); self.config.max_tool_iterations = cap; }As per coding guidelines, "New or changed flows should log entry/exit, branches, external calls, retries/timeouts, state transitions, and errors with stable prefixes and correlation fields."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/openhuman/agent/harness/session/runtime.rs` around lines 161 - 174, Update set_max_tool_iterations to log the override as a debug-level state transition using a stable prefix, including the previous self.config.max_tool_iterations value and the new cap before assigning it. Keep the setter’s existing mutation behavior unchanged so all current call sites gain consistent observability.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/openhuman/agent/task_dispatcher/executor.rs`:
- Around line 153-159: In the post-construction override near
agent.set_max_tool_iterations, add a state-transition log recording that the
autonomous task-run iteration budget is being pinned to TASK_RUN_MAX_ITERATIONS,
using the project’s established stable prefix and correlation fields consistent
with factory.rs definition-cap logging.
In `@src/openhuman/skill_runtime/run_machinery.rs`:
- Around line 198-204: Add the missing state-transition log alongside the
post-construction WORKFLOW_RUN_MAX_ITERATIONS override in the workflow-run
execution path. Match the task-dispatcher executor’s logging behavior and ensure
the log records that the agent’s tool-iteration budget was updated after
construction.
In `@src/openhuman/subconscious/profiles/memory.rs`:
- Around line 163-175: Preserve the post-construction override in the memory
tick, and add the missing state-transition log around
agent.set_max_tool_iterations(mode_iteration_cap). Log the agent’s transition to
the mode-specific iteration cap so this specialized budget change is observable,
consistent with the other budget sites.
---
Outside diff comments:
In `@src/openhuman/subconscious/session.rs`:
- Around line 177-195: The build_agent method correctly reapplies
mode_iteration_cap after constructing the subconscious agent; add the missing
state-transition log at this specialized budget override, matching the logging
behavior used by the other three override sites.
---
Nitpick comments:
In `@src/openhuman/agent/harness/session/runtime.rs`:
- Around line 161-174: Update set_max_tool_iterations to log the override as a
debug-level state transition using a stable prefix, including the previous
self.config.max_tool_iterations value and the new cap before assigning it. Keep
the setter’s existing mutation behavior unchanged so all current call sites gain
consistent observability.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 7b01c64f-c300-4676-a256-c9421db7e29a
📒 Files selected for processing (13)
src/openhuman/agent/harness/definition_tests.rssrc/openhuman/agent/harness/session/builder/builder_tests.rssrc/openhuman/agent/harness/session/builder/factory.rssrc/openhuman/agent/harness/session/runtime.rssrc/openhuman/agent/harness/session/tests.rssrc/openhuman/agent/task_dispatcher/executor.rssrc/openhuman/cron/scheduler.rssrc/openhuman/flows/ops.rssrc/openhuman/flows/ops_tests.rssrc/openhuman/skill_runtime/run_machinery.rssrc/openhuman/subconscious/profiles/memory.rssrc/openhuman/subconscious/session.rssrc/openhuman/tinyflows/caps.rs
| // Issue #4868 — apply the autonomous task-run iteration budget AFTER | ||
| // construction. The session builder now stamps the resolved agent | ||
| // definition's own cap onto the agent; an autonomous task run | ||
| // intentionally needs a much larger budget (200), so this must be a | ||
| // post-construction override rather than a pre-set on `config` (which | ||
| // the builder would otherwise clobber). | ||
| agent.set_max_tool_iterations(TASK_RUN_MAX_ITERATIONS); |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
Post-construction override is correct; missing state-transition log.
The override logic itself is sound and matches set_max_tool_iterations's documented contract. However, this is a state transition (pinning the iteration budget to 200) with no log line, unlike the definition-cap resolution logging in factory.rs.
As per coding guidelines, "New or changed flows should log entry/exit, branches, external calls, retries/timeouts, state transitions, and errors with stable prefixes and correlation fields."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/openhuman/agent/task_dispatcher/executor.rs` around lines 153 - 159, In
the post-construction override near agent.set_max_tool_iterations, add a
state-transition log recording that the autonomous task-run iteration budget is
being pinned to TASK_RUN_MAX_ITERATIONS, using the project’s established stable
prefix and correlation fields consistent with factory.rs definition-cap logging.
Source: Coding guidelines
| // Issue #4868 — apply the workflow-run iteration budget AFTER | ||
| // construction. The session builder now stamps `orchestrator`'s | ||
| // definition cap (15) onto the agent; a full workflow run | ||
| // intentionally needs a much larger budget (200), so this must be | ||
| // a post-construction override rather than a pre-set on `config` | ||
| // (which the builder would otherwise clobber). | ||
| agent.set_max_tool_iterations(WORKFLOW_RUN_MAX_ITERATIONS); |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
Correct override; same missing state-transition log as the task-dispatcher executor.
Shares the same root cause as src/openhuman/agent/task_dispatcher/executor.rs — see the consolidated comment below.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/openhuman/skill_runtime/run_machinery.rs` around lines 198 - 204, Add the
missing state-transition log alongside the post-construction
WORKFLOW_RUN_MAX_ITERATIONS override in the workflow-run execution path. Match
the task-dispatcher executor’s logging behavior and ensure the log records that
the agent’s tool-iteration budget was updated after construction.
Source: Coding guidelines
| let mode_iteration_cap = effective.agent.max_tool_iterations; | ||
|
|
||
| let mut agent = Agent::from_config(&effective).map_err(|e| { | ||
| warn!("[subconscious:memory] agent init failed: {e}"); | ||
| format!("agent init: {e}") | ||
| })?; | ||
| // Issue #4868 — `Agent::from_config` builds as the `orchestrator` | ||
| // definition (max_iterations=15, strict), so the session builder | ||
| // would stamp orchestrator's cap onto this agent regardless of mode | ||
| // — silently dropping `Aggressive`/`EventDriven` mode's intended | ||
| // 30-iteration budget set above to 15. Re-apply the mode-specific | ||
| // cap post-construction so this tick keeps its previous behavior. | ||
| agent.set_max_tool_iterations(mode_iteration_cap); |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
Correct fix for the orchestrator-cap clobbering; same missing state-transition log.
Confirmed against Agent::from_config's delegation to from_config_for_agent(config, "orchestrator") — the override is necessary and correctly applied. Shares the same missing-log root cause as the other three specialized-budget sites; see the consolidated comment below.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/openhuman/subconscious/profiles/memory.rs` around lines 163 - 175,
Preserve the post-construction override in the memory tick, and add the missing
state-transition log around agent.set_max_tool_iterations(mode_iteration_cap).
Log the agent’s transition to the mode-specific iteration cap so this
specialized budget change is observable, consistent with the other budget sites.
Source: Coding guidelines
…ut, log cap pins Post-merge follow-up on PR tinyhumansai#4870 (issue tinyhumansai#4868) addressing Codex/CodeRabbit findings that shipped unaddressed: - caps.rs: scale_timeout_for_iteration_cap was applied unconditionally to base_timeout_secs in run_via_harness, so an agent node that explicitly set timeout_secs (a fast-fail/SLA bound) got silently scaled up to match a high iteration cap. Added resolve_run_timeout_secs, which only scales the *default* 240s timeout — an explicit caller value is clamped (10..=600) but never widened. - flows/ops.rs: flow_discovery now resolves to a 50-iteration cap (like workflow_builder), but FLOW_DISCOVER_TIMEOUT_SECS was left at 300s while workflow_builder's equivalent got bumped to 600s. Raised it to 600 to match. - Added state-transition debug logs at the three post-construction agent.set_max_tool_iterations(...) overrides (task_dispatcher/executor.rs, skill_runtime/run_machinery.rs, subconscious/profiles/memory.rs) noting the iteration budget was pinned after construction, mirroring factory.rs's cap-resolution logging convention.
…ut, log cap pins Post-merge follow-up on PR tinyhumansai#4870 (issue tinyhumansai#4868) addressing Codex/CodeRabbit findings that shipped unaddressed: - caps.rs: scale_timeout_for_iteration_cap was applied unconditionally to base_timeout_secs in run_via_harness, so an agent node that explicitly set timeout_secs (a fast-fail/SLA bound) got silently scaled up to match a high iteration cap. Added resolve_run_timeout_secs, which only scales the *default* 240s timeout — an explicit caller value is clamped (10..=600) but never widened. - flows/ops.rs: flow_discovery now resolves to a 50-iteration cap (like workflow_builder), but FLOW_DISCOVER_TIMEOUT_SECS was left at 300s while workflow_builder's equivalent got bumped to 600s. Raised it to 600 to match. - Added state-transition debug logs at the three post-construction agent.set_max_tool_iterations(...) overrides (task_dispatcher/executor.rs, skill_runtime/run_machinery.rs, subconscious/profiles/memory.rs) noting the iteration budget was pinned after construction, mirroring factory.rs's cap-resolution logging convention.
2 participants
Summary
Direct-invocation agent builds —
flows_build,flows_discover, tinyflowsagent nodes, cron, subconscious,
skill_runtime,task_dispatcher— allfunnel through
Agent::from_config_for_agent→build_session_agent_inner,which unconditionally stamped the global
config.agent.max_tool_iterations(default 10) onto every session agent, ignoring the per-agent
AgentDefinition.max_iterations/iteration_policydeclared in eachagent.toml. Only the sub-agent-runner path (delegated sub-agents spawnedvia
spawn_subagent) appliedeffective_max_iterations()correctly — everydirect invocation silently got 10, regardless of what the agent's own
agent.tomldeclared (e.g.tools_agent— the repro agent from the issue —declares
iteration_policy = "extended"for an effective cap of 50, but got10).
Closes #4868
The one-place fix
src/openhuman/agent/harness/session/builder/factory.rs→build_session_agent_inner: before the builder chain, cloneconfig.agentand, when a
target_defis present, overwritemax_tool_iterationswithtarget_def.effective_max_iterations(). No definition → unchanged globalfallback (10). This is the single shared resolution point that closes #4868
for every direct-invocation call site at once.
Retiring the scoped
apply_builder_iteration_capflows/ops.rshad a previous scoped fix (apply_builder_iteration_cap,issue B31) that manually resolved
workflow_builder's effective cap beforecalling
Agent::from_config_for_agent. The shared fix makes this redundant— deleted the function and its call site;
flows_buildnow just passesconfigstraight through and gets the same 50.The 4 reconciled callers
Four call sites pre-set
max_tool_iterationsbefore callingfrom_config_for_agent/from_config; the shared fix would otherwisesilently clobber their override. Each is reconciled:
cron/scheduler.rs— removed the manualeffective.agent.max_tool_iterations = def.max_iterations;line. Thisalso fixes a latent bug: it used the raw
max_iterationsinstead ofeffective_max_iterations(), so extended-policy cron agents (e.g.tools_agent) got shortchanged to 10 instead of 50 even under the oldscoped behavior.
skill_runtime/run_machinery.rs— the 200-iterationWORKFLOW_RUN_MAX_ITERATIONSoverride moved to post-construction viaa new
Agent::set_max_tool_iterations(cap)setter(
session/runtime.rs), since the shared fix would otherwise stamporchestrator's definition cap (15) over the intentionally largerworkflow-run budget. Verified still resolves to 200.
agent/task_dispatcher/executor.rs— same pattern,TASK_RUN_MAX_ITERATIONS(200) moved to post-construction. Verified still resolves to 200.
subconscious/session.rs+subconscious/profiles/memory.rs—both hardcode a mode-specific 15 (Simple) / 30 (Aggressive/EventDriven)
cap before construction. Both moved to post-construction re-application
of the mode's cap via
set_max_tool_iterations. This turned out to benecessary, not just a nice-to-have: the plan's original assumption
was that both callers build via the
subconsciousdefinition (effectivecap 30, so only
Simplemode's 15 would've been silently widened to 30 —a minor issue). In fact
profiles/memory.rsbuilds viaAgent::from_config,which targets the
orchestratordefinition (effective cap 15, not30) — so without the post-construction fix,
Aggressive/EventDrivenmode's tick would have silently dropped from 30 iterations to 15, a
real regression the plan didn't anticipate for this specific call site.
Both are now fully decoupled from whatever the builder resolves.
Timeout scaling for extended-cap agent nodes
tinyflows/caps.rs's agent-node runtime (run_via_harness) now scales itswall-clock timeout for agents whose effective cap exceeds 10, via a new pure
helper
scale_timeout_for_iteration_cap(base_timeout_secs, effective_cap)—floor of
effective_cap * 12s, capped at the existing 600s ceiling. A50-iteration agent node (e.g.
code_executor,tools_agent) can legitimatelyrun past the previous 240s default and would otherwise be killed by timeout
before exhausting its own declared budget.
Full before/after cap audit (re-verified against every
agent.toml)Re-derived directly from all 39 built-in
agent.tomlfiles in this branch(not just carried over from the plan) —
effective_max_iterations()=max_iterations(strict) ormax(max_iterations, 50)(extended). Matchesthe plan's audit exactly, no discrepancies. Pinned by a new snapshot test:
all_builtin_agent_definitions_have_expected_effective_max_iterations(
src/openhuman/agent/harness/definition_tests.rs), which is exhaustiveover every built-in id — a future
agent.tomledit that changes aneffective cap (or a new agent landing without a reviewed cap) fails this
test instead of silently changing runtime behavior.
Agents whose cap INCREASES (extended policy, or high declared
max_iterations)orchestratorcode_executorcontext_scoutintegrations_agentmcp_agentmcp_setupplannerresearcherskill_creatortask_manager_agenttools_agentflow_discoveryworkflow_builderskill_executortinyplace_agentsubconsciousAll side-effect tools on every extended-policy agent are approval-gated and
cost-budgeted independent of iteration count — the fix only restores the
budget each agent's
agent.tomlwas authored to have.Agents whose cap DECREASES (declared
max_iterations< old global default of 10)agent_memoryaccount_admin_agentarchivistcriticcrypto_agentdesktop_control_agentgoals_agenthelpimage_agentmarkets_agentmorning_briefingprofile_memory_agentscheduler_agentscreen_awareness_agentsettings_agentsummarizertool_makertrigger_reactortrigger_triagevideo_agentvision_agentEvery decrease aligns an agent with the budget its own author declared in
agent.toml— none was relying on the inflated global 10 as a floor.Unchanged
presentation_agentskill_setupTests
build_session_agent_applies_extended_policy_definition_cap/build_session_agent_applies_strict_cap_below_global_default/build_session_agent_falls_back_to_global_default_when_no_definition(
session/builder/builder_tests.rs) — drivebuild_session_agent_innerdirectly (now
pub(crate)) with a hand-pickedtarget_def, independentof the global registry singleton's init-once state.
agent_node_runtime_resolves_to_the_definitions_effective_iteration_cap+
scale_timeout_for_iteration_cap_*(tinyflows/caps.rs) — agent-noderuntime path resolves to the definition cap, and the timeout scaling
formula is unit tested in isolation.
flows_discover_applies_the_flow_discovery_definitions_effective_iteration_cap(
flows/ops_tests.rs) —flows_discoverresolves to 50, not 10.flows_build_applies_the_builder_definitions_effective_iteration_cap(
flows/ops_tests.rs) — updated for the retiredapply_builder_iteration_cap; now asserts the shared fix aloneproduces 50 with no per-caller override.
all_builtin_agent_definitions_have_expected_effective_max_iterations(
agent/harness/definition_tests.rs) — audit snapshot test,exhaustive over all 39 built-in agents, pinning every value in the
tables above.
set_max_tool_iterations_overrides_the_builder_resolved_cap/set_max_tool_iterations_survives_after_definition_backed_construction(
session/tests.rs) — the new setter wins over the definition-resolvedcap, mirroring exactly what
skill_runtime/task_dispatcherrely on.build_agent_preserves_simple_modes_15_iteration_cap/build_agent_preserves_aggressive_modes_30_iteration_cap(
subconscious/session.rs) — mode-specific cap survives the shared fix.profiles/memory.rs's equivalent path (run_agent) isn't unit-testablewithout a live model call (it runs a real turn inline), so it's covered
by the same building-block tests above (
Agent::from_config+set_max_tool_iterations) rather than an end-to-end test — noted herefor reviewer visibility rather than silently skipped.
Verification run (this branch)
GGML_NATIVE=OFF cargo check --manifest-path Cargo.toml— cleanGGML_NATIVE=OFF cargo check --manifest-path app/src-tauri/Cargo.toml— cleancargo test --manifest-path Cargo.toml --lib openhuman::agent:: -- --test-threads=1— 965 passed, 1 failed. The 1 failure
(
turn_triggers_configured_memory_agent_before_parent_prompt) is apre-existing flake, confirmed identical on
upstream/mainbefore thischange (verified via
git stash).cargo test --manifest-path Cargo.toml --lib openhuman::flows:: -- --test-threads=1— 289 passed, 0 failed.
cargo fmt— clean.Risk
iteration_policy = "extended"agents change, and that policy is a deliberate author choice;all side-effect tools stay approval- and cost-gated independent of
iteration count.
with its own declared
max_iterations; nothing depended on the inflatedglobal 10 as a minimum.
from_config_for_agent/build_session_agent_inner, so there's no double-apply risk.subconsciousdiscrepancy against the plan's assumption is called out explicitly rather
than silently fixed.
scale_timeout_for_iteration_cap.Test plan
cargo check(both crates) cleancargo test --lib openhuman::agent::(single-threaded) — only thepre-existing, branch-independent flake remains
cargo test --lib openhuman::flows::(single-threaded) — all greencargo fmtcleanagent.tomlinthis branch and pinned by a snapshot test
Summary by CodeRabbit