Field Log: AI Engineering • 9 min read
For a long time, the software engineering community has been skeptical of autonomous agent loops. Early implementations frequently suffered from infinite repetition, spiraling token costs, and a tendency to rewrite the same lines of code without resolving the underlying logic errors. However, a major paradigm shift has occurred. By combining recursive agent fanout (parallel subagent orchestration) with an autonomous /goal or /autoresearch validation loop, running on the highest-tier reasoning models like GPT-5.5 with xhigh effort, developers can achieve 100% unattended code generation and debugging with unprecedented accuracy and quality.

Deconstructing the Workflow: What Does It Mean?
To understand why this is currently the most effective workflow for raw accuracy, we must break down its technical components:
- Recursive Agent Fanout: Instead of a single agent writing a large application line-by-line, a parent agent plans the architectural layout and spawns parallel subagents (fanout) to implement independent modules or files simultaneously. These subagents can recursively spawn grandchildren to write sub-modules.
- Greenfield Implementation: Building new features or codebases from scratch is a perfect candidate for parallelization. Subagents operate in isolated workspaces (such as APFS/Btrfs clones or Git worktrees) writing decoupled components, which are later merged seamlessly back into the main branch.
- Autonomous Loops (/goal or /autoresearch): Once code is generated, the agent harness enters a closed evaluation loop. In /goal mode, the agent receives a strict checklist (e.g., compile without errors, pass all tests, and enforce static types). In /autoresearch mode, the agent iteratively optimizes a codebase against a specific performance or accuracy metric, automatically rolling back changes that degrade the score.
- GPT-5.5 xhigh Reasoning: Frontier reasoning models support adjustable thinking budgets. By configuring GPT-5.5 to 'xhigh' effort, the model is allocated a massive reasoning token allowance. The model uses this space to outline edge cases, simulate executions, and verify logic before emitting code, preventing the loops from getting stuck.

Step-by-Step Implementation Guide in Oh My Pi
We can implement this pipeline natively in the Oh My Pi (OMP) agent harness. OMP is highly optimized for parallel subagent execution, git-based workspace isolation, and customizable reasoning parameters. Let's configure and run the workflow step-by-step.
Step 1: Configure the OMP Agent and Model Parameters
First, we configure the OMP environment settings to support high concurrency, parallel batch task spawning, and reasoning overrides. Update your config.yml (or run the respective omp config set commands) to enable background jobs, batching, and reasoning models:
# .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 executorsSetting task.batch: true allows us to spawn multiple subagents in a single tool call. The harness schedules these parallel spawns through a queue bounded by the maxConcurrency semaphore.
Step 2: Initialize the Greenfield Task Plan
Before triggering the subagents, the parent agent must map out the architecture. The parent reviews the directory layout and writes a plan listing all decoupling points. Let's say we are building an API integration with three independent modules: client.ts, parser.ts, and cache.ts.
We construct a batch task payload. The parent provides a shared context defining the design system, data contracts, and API schemas. It then maps out individual tasks with explicit assignments and isolated targets:
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)."
}
]
});Because async.enabled: true is configured, OMP's TaskTool spawns the subagents in parallel background jobs (each getting a distinct jobId). The isolation layer captures files written inside temporary worktrees and commits them to individual git branches (e.g. omp/task/WeatherClientAgent).
Step 3: Monitor Progress and Merge
You can monitor the active subagents using OMP's job or irc tools. Once a background task finishes, the job manager delivers the completion event and auto-merges the branches into HEAD:
# 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"Step 4: Spin Up the Autoresearch/Goal Loop
Now that the greenfield files are written and merged, the harness must verify and polish the integrated code. We enter the autonomous `/goal` or `/autoresearch` loop.
In this phase, we instruct a high-effort model to continuously compile, run typechecks, run unit tests, and fix errors until everything is green. We can set up a validation command that executes a test suite and pipes errors back to the agent:
# 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."Under the hood, the OMP agent handles the error output by loading the affected code, searching for references using lsp references, finding definition bounds, and using edit or ast_edit tools to apply precise patches.

Why This Paradigm Dominates
This hybrid workflow solves the classic failure modes of autonomous coding agents:
- Token Budget Efficiency: Fanning out greenfield files to parallel child agents keeps the prompt context small and clean for each worker. Spawning child workers prevents the parent prompt from bloating, avoiding prompt-cache misses and latency spikes.
- Logic Sanity: GPT-5.5's 'xhigh' thinking tier allows the model to map out execution flows and anticipate boundary cases before modifying code, meaning it rarely gets stuck in recursive coding bugs.
- Safe Merging: Since OMP uses isolated Git workspaces, parallel subagents cannot corrupt each other's state or cause layout conflicts. If a task fails or times out, it is safely rolled back without polluting the main branch.
Recursive fanout separates planning from implementation, and the /goal loop separates implementation from verification. With high-reasoning models driving both, AI agents can achieve production-quality output completely unattended.

