I Built the Loop Before I Knew It Had a Name

It's Tuesday morning, and I'm grabbing water between pickleball games with my father. The heat is already miserable and it isn't even 11 a.m., but it beats an hour of Zone 2 on a treadmill. He is 71 and still taking games off me.

I check my phone to see how Nora and Telo are doing. Each has been leading an epic for a day or two. I open Telo's chat just before a notification comes through.

The team has reached a product decision that the plan, specification, and source code do not answer. Telo has already worked through the implementation details and narrowed the issue to the choice that belongs with me.

I answer from my phone. He confirms that he has what he needs, and the work continues. I put the phone down and head back to the court.

I built this workflow in late June and came across the term loop engineering shortly afterward. The term describes a system that assigns work to coding agents, checks the results, records state, and decides what happens next. My version centers on a high-context orchestrator that runs full software epics through Claude Code.

Parallel Agents Still Need Coordination

A single coding agent can be extremely productive. It also remains tightly coupled to the person using it. It asks questions, loses context, gets stuck on assumptions, declares success before the evidence is in, and needs someone to decide what happens next.

Adding more agents increases output and coordination at the same time. Someone still has to sequence dependencies, decide which work can happen in parallel, resolve conflicting reviews, and adjust the plan when an assumption fails. Without an orchestrator, I spend the day moving context between terminals.

A fixed workflow handles a known sequence. Software epics regularly move outside the original sequence because implementation and review uncover information that was unavailable during planning. The system needs a technical lead with enough context to understand the reason behind the plan and enough authority to revise its execution. I place that responsibility on the orchestrator.

Planning the Epic

I start with a structured Superpowers brainstorm. The system interviews me, and we work through the product, the user experience, the constraints, the non-goals, the unanswered questions, and the decisions that should remain with me.

Then I do the technical spikes and research the work requires. That might mean reading the current source, tracing an interface across repositories, checking a white paper or specification, testing a dependency, or building a small proof of concept around the riskiest part.

The technical spikes reduce the uncertainties that would force the orchestrator to guess at product intent or interrupt me every twenty minutes.

The result is a detailed plan with file and line references, definitions of done, dependencies, locked decisions, known problems, and the documents that control each part of the implementation. It records what we are building and what has already been decided.

The authority split is explicit. Product behavior, scope, risk decisions, and major architectural choices stay with me. The orchestrator controls technical execution within those boundaries. It can reorder tasks, split work, assign agents, add investigations, and revise later steps as new information appears.

The plan becomes the initial state for the epic and continues to change as the team learns more.

Breaking the Plan Into Waves

The orchestration skill breaks the plan into waves based on the dependency graph.

Some work can start immediately. Other work waits for a shared schema, protocol contract, registry, or wire format. Some branches stack on earlier branches. Some integration work begins after several pull requests are ready.

The orchestrator knows which workstreams can run now, which ones are blocked, what each dependency provides, and when a later wave can begin.

HUMAN
Product intent · locked decisions · risk decisions · final landing
                         |
                         v
INTELLIGENT ORCHESTRATOR
Epic-wide context · dependencies · adjudication · replanning
                         |
          +--------------+--------------+
          |                             |
          v                             v
IMPLEMENTERS                        REVIEWERS
Bounded workstreams                 Independent review
Code · tests · discoveries          Findings · evidence · challenges
          |                             |
          +--------------+--------------+
                         |
                         v
                   PRs ready for me to land

Each implementer gets one bounded workstream, one branch, one isolated git worktree, explicit source documents, and a concrete definition of done. It writes the code and tests, opens a pull request to the integration branch, reports completion, and stops. Merge and deployment remain human actions.

The worktrees prevent Git conflicts and enforce ownership. Each branch has one writer. Reviewers work in isolated worktrees with no writable path to the branch under review. An autonomous reviewer with access to a writable branch may decide to help by changing it. The setup prevents that collision by removing the writable path.

The Orchestrator's Role

The orchestrator normally runs in Claude Code. I use Remote Control so the local session can keep working while I monitor it and answer the occasional high-level question from my phone.

The orchestrator has the broadest view of the epic. It knows the plan, the dependencies, what each agent has learned, which pull requests are open, what CI is doing, and which decisions remain unresolved.

Each implementer knows its workstream in depth. Each reviewer focuses on the pull request it is examining. The orchestrator combines those local views with the state of the rest of the epic.

Earlier today, an implementer found that point three would not work the way we expected. The original plan placed it before point four.

The orchestrator determined that point four was still unblocked. It moved point four forward, deferred the affected part of point three, and continued the epic. The new order may produce a cleaner result.

The product goal stayed the same. The execution sequence changed because the reason behind the original ordering no longer applied.

Implementers and reviewers regularly uncover facts the plan could not know in advance. An interface behaves differently from its documentation. A dependency turns out to be unnecessary. A reviewer finds a constraint in another repository. A later task can begin earlier. The orchestrator evaluates the effect on the remaining work, updates the sequencing in STATUS.md, and continues.

Review and Adjudication

My standard review gate uses fresh reviewers from different model families, normally Claude, Codex, and Antigravity. They review correctness, security, specification compliance, and the definition of done. Each reviewer works independently and writes a complete verdict file.

Multiple models improve coverage. The orchestrator evaluates each finding on its evidence.

I have seen reviewer agreement fail in both directions. In one review, two agents recommended a change that would have broken a working pull request because they shared the same incorrect assumption about the surrounding system. In another, one agent found a real security vulnerability at a validation boundary that the other two missed.

The agents do not vote. They make claims.

Every material finding has to be concrete enough to prove or disprove. The reviewer identifies the disputed behavior, the affected code path, the source that controls, and the evidence that would settle the question.

A vague concern such as “this may cause a compatibility problem” still needs investigation. A useful finding looks more like this:

The implementation emits value X for condition Y, but the canonical registry assigns X to a different condition. The downstream decoder therefore classifies Y incorrectly.

Authority depends on the question.

A white paper may establish intended protocol behavior. Source code establishes current implementation behavior. A targeted test shows whether a patch reproduces and fixes the failure. A disagreement between the specification and implementation becomes a finding of its own.

The orchestrator handles most adjudication. It reads the specification, follows the source code, inspects the dependency, traces the encoder and decoder, runs a test, or dispatches a narrow investigation. It records the disposition of each finding and sends only product or specification ambiguity to me.

Reviewers often support a finding more carefully than the remedy attached to it. A reviewer may cite the exact line where behavior is wrong and then recommend a change without reading the repository or downstream consumer that determines whether the change works. The finding and the remedy are evaluated separately.

Negative claims carry the same evidence requirement:

• “That path is unreachable.”
• “No caller depends on this.”
• “The API does not exist.”

Those claims require a stated search scope beyond the pull-request diff. A proposed fix points to the code that makes it valid. Until then, it remains a hypothesis.

Phase R (Review) and Phase G (Grind-to-Green)

I separate review into two operations.

Phase R is one advisory round. Reviewers inspect the pull request, write their verdicts, and stop. They leave the branch unchanged.

Phase G runs the same gate repeatedly until the pull request is ready to land or the orchestrator has a concrete reason to escalate.

A Phase G round looks like this:

1. Run the independent review gate.
2. Collect the verdict files.
3. Adjudicate contested findings against the controlling source.
4. Select exactly one writer for the accepted fixes.
5. Push the change and wait for CI to complete.
6. Run another gate against the updated pull request.
7. Stop when all reviewers are ready, CI has finished green, and every review thread is resolved. Escalate when the loop fails to converge.

The observed CI result matters because an agent's explanation of why a patch should work is still a prediction. A green check proves only the checks that ran. When a pull-request workflow omits deployment or integration, the orchestrator records that limitation.

The loop usually stops after about three serious rounds. Persistent disagreement, repeated regressions, or genuine specification ambiguity goes to the human at that point.

Reviewer verdicts are stored in files. Bus messages tell the orchestrator where to look. I added that rule after a long-running bus lost an identity while the review files remained intact. The files provide the durable state for the round.

Human Escalation

The orchestrator handles technical decisions supported by the plan, specification, source code, tests, or runtime behavior. It can reorder work, split tasks, defer a blocked step, choose a writer, add an investigation, change the test strategy, and decide whether another review round is needed.

It contacts me when the available sources leave a genuine choice, several valid options would change the product, scope or risk changes, a locked decision needs revision, or the original objective may no longer be achievable as written.

The internal status document separates decisions needed from me from decisions the orchestrator has already resolved. When a question reaches my phone, the message includes what the team discovered, which sources were checked, the remaining options, and the effect of each option.

Model Selection

My model preferences change often. Claude Code Opus 4.8 (yes, 4.8) normally serves as the orchestrator. I reserve Claude Fable 5 for my most difficult engineering work. Currently I find GPT-5.6 Sol at Max reasoning effort best for implementation and adversarial review. Gemini 3.1 Pro has been relegated to reviews only.

The standard gate still includes Claude, Codex, and Antigravity because they catch different things. I assign models by role and expect those assignments to keep changing.

My Role

This workflow increases throughput and reduces the amount of coordination I handle personally.

Once the epic starts, I coordinate through one orchestrator. It assigns work, handles most technical disagreements, watches CI, and updates the plan when the agents learn something new. A well-scoped epic can run for hours while I check in from my phone.

I still decide what we are building, which tradeoffs are acceptable, what risk we are willing to take, and what gets landed. The orchestrator handles the technical decisions that fit inside those boundaries.

The coding agents write the code; the orchestrator runs the epic. I set product intent, make the real tradeoffs, and decide what gets landed. That division of labor is what makes the workflow scale.

I open-sourced the orchestration skill behind this workflow. Have your agent adapt it to your own setup →