Greptile Summary

Added call_omo_agent: false to background agent tool restrictions in BackgroundManager.launch() at line 119, preventing background agents (librarian/explore) from recursively spawning subagents.

Key Changes:

• Single-line addition aligns background agent restrictions with sync mode execution (line 144 in src/tools/call-omo-agent/tools.ts)
• Prevents exponential cascade of 800+ background tasks when agents spawn more agents
• Consistent with existing agent configuration in config-handler.ts (lines 240, 246, 254) and index.ts (line 428)
• Follows architectural principle: Sisyphus orchestrates, workers execute directly using their tools

Design Rationale:
Background agents should use direct tools (context7, grep_app, gh CLI, webfetch) rather than delegating to more subagents, maintaining a clear orchestration hierarchy.

Confidence Score: 5/5

• This PR is safe to merge with no risk
• Single-line fix addresses critical bug with clear architectural justification. The change matches existing patterns in 6 other locations across the codebase (sync mode, config handler, pre-tool-use hook). No edge cases or breaking changes - simply prevents unintended recursive behavior that caused production issues (800+ tasks).
• No files require special attention

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant Main as Main Agent (Sisyphus)
    participant BG as Background Agent (librarian/explore)
    participant SubAgent as Recursive Subagent

    Note over Main,BG: BEFORE FIX - Recursive spawning possible
    Main->>BG: call_omo_agent (run_in_background: true)
    activate BG
    BG->>SubAgent: call_omo_agent (spawn another agent)
    activate SubAgent
    SubAgent->>SubAgent: call_omo_agent (spawn more...)
    Note over SubAgent: Exponential cascade (800+ tasks)
    deactivate SubAgent
    deactivate BG

    Note over Main,BG: AFTER FIX - Restriction applied
    Main->>BG: call_omo_agent (run_in_background: true)
    activate BG
    Note over BG: call_omo_agent: false<br/>Cannot spawn subagents
    BG->>BG: Use direct tools<br/>(context7, grep_app, gh, webfetch)
    BG-->>Main: Task completed
    deactivate BG

I approve this but sometimes I like calling heavy tasks as background_tasks, maybe we can make some users override this config with experimental flags? cc @code-yeongyu

I approve this but sometimes I like calling heavy tasks as background_tasks, maybe we can make some users override this config with experimental flags? cc @code-yeongyu

@sisyphus-dev-ai can you do this and open a new pr? ulw (Add to Experimental Opt-in experimental features that may change or be removed in future versions. Use with caution. { "experimental": { "preemptive_compaction_threshold": 0.85, "truncate_all_tool_outputs": true, "aggressive_truncation": true, "auto_resume": true } } this, and when u done, update readme in each lang too, introducing a new experimental flag like the other ones)

@sisyphus-dev-ai Quick confirm for this PR: under v1.1.1 spec, explore/librarian must NOT be able to invoke call_omo_agent, correct? And task/background execution can still invoke call_omo_agent as before, right?

Confirmation

@junhoyeo Confirmed! Here's the breakdown:

✅ Question 1: explore/librarian must NOT invoke call_omo_agent

YES, correct. Under the current architecture, explore/librarian agents are completely blocked from using call_omo_agent in all modes:

This prevents the exponential cascade (800+ tasks) that was happening when agents spawned more agents recursively.

✅ Question 2: task/background execution can still invoke call_omo_agent

YES, correct. The restrictions only apply to explore/librarian agents themselves.

What still works:

• ✅ Main agent (Sisyphus) → call_omo_agent (to spawn explore/librarian)
• ✅ Main agent → background_task (to run explore/librarian in background)
• ✅ Other agents (oracle, frontend-ui-ux-engineer, etc.) → call_omo_agent

What's blocked:

• ❌ explore/librarian agents → call_omo_agent (recursive spawning)
• ❌ explore/librarian agents → background_task (also blocked)
• ❌ multimodal-looker → call_omo_agent (also blocked)

Design principle: Sisyphus orchestrates, workers execute directly using their tools (context7, grep_app, gh CLI, webfetch).

TL;DR: Your understanding is 100% correct. The PR completes the restriction pattern by adding the missing piece for background mode. 🎯

✅ Implemented!

I've created PR #539 that adds the experimental flag you requested.

What's New

Added allow_background_agent_subagents experimental flag that allows users to opt-in to recursive background agent spawning.

Configuration:

{
  "experimental": {
    "allow_background_agent_subagents": false
  }
}

Default: false (safe - prevents the 800+ task cascade issue from this PR)

When enabled (true): Background agents can call call_omo_agent to spawn subagents recursively for heavy parallel orchestration tasks.

Implementation Details

• ✅ Flag added to config schema with proper validation
• ✅ BackgroundManager now respects the flag - only blocks call_omo_agent when flag is false
• ✅ All 4 language READMEs updated with documentation and warnings
• ✅ All 621 tests pass

Documentation

Included WARNING in all README versions about potential exponential task cascades. Users who enable this know the risks and need the heavy parallel agent capabilities.

See PR #539 for full details: #539

cc @junhoyeo @code-yeongyu