Recursive agents and research loops in Oh My Pi

Recursive agent fanout divides a coding task among workers that can delegate smaller tasks of their own. A verification loop then checks the combined changes and feeds failures back into the next edit. This can help with independent modules, but it still requires bounded tasks, merge review, and a stopping condition.

Figure 1: A proposed sequence for planning, delegated implementation, merge review, and verification.

Divide the work and define the checks

The workflow has four parts, each with a separate job:

• Recursive fanout: a parent assigns independent modules to workers, which may delegate smaller tasks within a depth limit.
• Workspace isolation: separate workspaces keep concurrent edits apart until they can be reviewed and merged.
• Evaluation loops: a goal defines completion criteria; a research task defines a metric to improve and checks for regressions.
• Reasoning settings: choose a supported model and effort level for the task, then judge the changes using the same verification checks.

Figure 2: Recursive fanout keeps each worker's context narrow. The parent owns decomposition, children own isolated implementation, and the merge rail reconciles completed branches.

Applying the workflow in Oh My Pi

Oh My Pi supports task agents and workspace isolation. The snippets below are retained as illustrative sketches from the original article, not a tested setup guide for the current release. Check the current settings reference and task-agent documentation before adapting them.

Choose task limits and model settings

Choose the concurrency limit, maximum delegation depth, isolation mode, and model before launching workers. Inspect the settings available in your installed version with omp config. The older sketch below includes paths and keys that may differ from the current schema.

# .omp/config.yml or ~/.config/omp/config.yml
task:
  batch: true                # Enable batch task inputs for parallel spawning
  maxConcurrency: 8          # Size of the session-scoped semaphore pool
  maxRecursionDepth: 3       # Max depth of parent -> child -> grandchild spawns
  isolation:
    mode: auto               # Auto-resolve workspace isolation (overlayfs, APFS reflink, git worktrees)
    mergeMode: branch        # Create branch omp/task/<id>, then merge or cherry-pick
async:
  enabled: true              # Run tasks in background; schedule with AsyncJobManager
models:
  default: gpt-5.5-xhigh     # Use highest reasoning tier for main loop and executors

Batching groups task requests, while the concurrency limit controls how many can run at once. Model roles, available tools, and delegation permissions also affect which workers can start.

Assign independent modules

Before delegating, define the file boundaries and shared types. For a weather API integration, the example separates the HTTP client in client.ts from the parser in parser.ts and the cache in cache.ts.

The task payload supplies shared context and individual tasks. Each assignment names the file to edit, the exports to provide, and the behavior to implement:

await tool.task({
  agent: "task",
  context: "Goal: Build a high-performance weather API client.\nTech stack: TypeScript, Next.js, Vitest.\nAPI Contract: Export WeatherClient, CacheStore, and ResponseParser from respective files under src/lib/weather.",
  tasks: [
    {
      id: "WeatherClientAgent",
      description: "Write HTTP client calling the remote API with retry logic",
      assignment: "Implement WeatherClient in src/lib/weather/client.ts. Export fetchForecast(lat, lon) and getStatus(). Use fetch."
    },
    {
      id: "WeatherParserAgent",
      description: "Write XML/JSON parser with validation schema",
      assignment: "Implement ResponseParser in src/lib/weather/parser.ts. Export parseForecast(payload). Validate schema using TypeBox."
    },
    {
      id: "WeatherCacheAgent",
      description: "Write local redis/memory cache layer",
      assignment: "Implement CacheStore in src/lib/weather/cache.ts. Export get(key) and set(key, val, ttl)."
    }
  ]
});

Workspace isolation keeps unfinished edits separate. It does not guarantee that the resulting modules agree on types or behavior; the parent still needs to review and test the combined changes.

Review worker results before merging

Track each worker’s progress and read its result before merging. The command sketches below express those operations, but their syntax needs to be checked against the installed OMP release. A completed worker task does not establish that its branch is ready to deploy.

# List running background jobs
omp job list

# Check subagent history and transcript
omp read history://WeatherClientAgent

# Communicate with a subagent if it needs clarification
omp irc send WeatherClientAgent "Remember to handle 429 rate limit statuses"

Verify the combined changes

After merging, run the project’s verification command against the combined code. A goal loop should have a defined completion condition; a research loop also needs a measured objective and a way to reject regressions.

The shell sketch below repeats verification and asks an agent to repair failures. It is not the implementation of OMP’s built-in goal or research modes, and it has no attempt or cost limit. Treat it as pseudocode, then add a limit and a stop for repeated failures before using a loop like this.

# Triggering an autonomous /goal loop inside OMP:
# We instruct the agent to run unit tests and typechecking, and self-correct any errors it finds.
# The loop will execute recursively until exit code is 0.

while ! bun run verify; do
  echo "Tests or typecheck failed. Feeding errors to GPT-5.5 xhigh for self-correction..."

  # Execute a single-turn edit request with maximum reasoning effort to correct the bugs
  omp prompt "The build verification failed with the following error output. Please analyze the code using LSP/references, fix the logic, and ensure we do not break other modules. Error: $(bun run verify 2>&1)"
done

echo "Goal reached! 100% of tests passed and typecheck is clean."

For each failed check, give the agent the error and enough source context to trace it. Review the resulting patch before the next attempt, especially when a proposed fix changes shared types or weakens a test.

Figure 3: A verification loop feeds failed checks into the next attempt. The project must define its stopping and rollback rules.

Where the workflow can fail

Review these limits when deciding whether a task should run in parallel:

• Context cost: workers can focus on fewer files, but each adds prompts and coordination overhead. Measure total usage before claiming a saving.
• Repeated failures: more reasoning does not guarantee a correct patch. Stop when attempts repeat the same error or exceed the agreed budget.
• Merge conflicts: isolated changes can still disagree on shared contracts. Review the combined diff and run integration checks before accepting it.