Looper Is Not a Replacement for Our Agent Workflow

A few people pointed us at Looper and asked the obvious question: does this replace what you built?

Short answer: no.

Longer answer: it solves a real part of the problem we also care about, and it solves it well, but it sits downstream of the part that decides whether the work is worth doing.

So let me be precise about where it fits, because precision is the whole point.

What Looper actually is

Looper is a local daemon plus CLI for running coding agents against your repos. It is open source under MIT, written in Go, and at a fresh check it sat at 75 stars and 19 forks. The repo is at https://github.com/nexu-io/looper.

It ships two binaries:

• looperd, the daemon
• looper, the CLI

The design choice that matters most: the forge is the source of truth. Looper works against GitHub or Forgejo, and issues, pull requests, labels, reviews, and assignees drive the state machine. There is no hosted control plane to depend on. You run it locally.

The loop itself is clean. A planner sets up the work, a reviewer and a fixer go back and forth, and a worker executes. Each unit of work runs in an isolated git worktree, so agents are not stepping on each other. It supports the coding agents people already use: opencode, claude-code, codex, and cursor-cli.

If you read that and thought “this is a productized daemon version of the execution layer,” you read it right.

That is exactly what it is.

That is also exactly why it does not replace our workflow.

Where the overlap is, and where it is not

Our workflow has two halves:

• the upstream half decides what to build and turns a messy product conversation into a clean, dependency-aware execution graph
• the downstream half takes that graph and runs coding agents against it under gates and proof

Looper overlaps the downstream half.

It does execution and supervision: worktrees, the planner-reviewer-fixer-worker loop, agent dispatch, forge-native state, PR flow. It does not do the upstream half. It does not interrogate the product, produce the spec, generate the issue graph, map dependencies, or separate parent epics from child build issues.

It assumes the issues already exist and are correct.

That assumption is the entire gap.

The hard part of agent-driven engineering is not running the agent. It is deciding what the agent should run on, in what order, with what context, and how you will know it worked.

Looper takes “the issues are good” as a given. Our upstream workflow exists because that is almost never a given.

The first skill: build the execution graph

Our grill-to-linear-execution-graph workflow sits before the coding loop.

Its job is to turn messy decision material into an executable plan. In the workflow we have been running, that means producing artifacts like:

• a source packet
• SuperSpec or Oracle artifacts
• PRD drafts and critique passes
• a canonical PRD
• a parent epic spine
• a child execution graph
• Linear issues
• repo-native context packs
• receipts and route evidence

This is not decorative paperwork. It is the part where the product intent becomes structured enough for agents to use.

If that layer is weak, the execution layer will move faster in the wrong direction. That is worse than being slow. Slow is annoying. Fast and wrong creates archaeology.

The second skill: package the execution safely

The downstream skill is cursor-project-execution-pack.

That one is closer to Looper’s territory, but it still does a different job. It is not a daemon. It is a control-plane recipe and context-pack generator.

It requires a live audit of the repo, docs, Linear state, branch, gates, and project context. It maps Linear IDs back to source IDs without ordinal guessing. It distinguishes parent epics from child build issues. It creates an approved queue. It writes coding-agent prompts and context packs. It defines the receipts and proof commands that decide whether a run is acceptable.

It also fail-stops on the things that usually turn agent autonomy into a mess:

• stale or mismapped issues
• banned terms
• bad proof commands
• failed gates
• missing receipts
• missing approved queue
• wrong branch

It generates at least these named handoff artifacts:

• plan.md
• cursor-single-issue-prompt.md
• cursor-bounded-queue-prompt.md
• linear-cleanup-manifest.md
• linear-cleanup-manifest.json
• linear_id_to_source_id.json
• .project-gate.example.json
• preflight-checklist.md
• Entity FS link instructions
• a run-state example

That is the operational contract around execution.

Looper is the local loop that can execute work. The execution pack is the contract that says what work is allowed, what context is canonical, and what proof survives.

Those are complementary pieces, not substitutes.

Where Looper is stronger

Looper is stronger than a hand-rolled local loop in several obvious places:

• it has a daemon
• it has a CLI
• it treats the forge as a state machine
• it uses isolated git worktrees
• it has a reviewer and fixer loop
• it supports PR takeover
• it integrates directly with GitHub and Forgejo concepts
• it can coordinate local execution without needing a hosted control plane

That is a serious set of primitives.

The thing I like most is that Looper does not pretend agent coding is magic. It models the boring bits: assignment, review, fix, state, branch isolation, and handoff.

Boring is where most of the value is.

Where our system is stronger

Our system is stronger upstream and around the edges:

• product interrogation
• Linear-native planning
• deep spec generation
• evidence discipline
• critique before execution
• context packs
• issue graph generation
• review gates
• cross-system orchestration
• receipts

Looper asks the forge what should happen next.

Our workflow asks whether the work should exist in the first place, how it should be decomposed, what evidence should survive, and what execution surface should be trusted.

Those are different questions.

If we skip our planning layer and jump straight into a forge-driven agent loop, we get speed without judgment. That is not progress. That is just a faster way to create cleanup work.

The useful integration path

The right question is not “Looper or our workflow?”

The right question is: where should Looper sit inside our workflow?

The cleanest path looks like this:

• use our planning workflow to generate the spec, issue graph, and execution context
• mirror or create the relevant GitHub issue
• use Looper locally to execute the issue with codex or cursor-cli
• let Looper handle worktrees, loop state, PR flow, and reviewer/fixer behavior
• keep our proof and receipt requirements around the run

In other words: our workflow produces the work. Looper may help run the work.

Looper could consume the output of grill-to-linear-execution-graph if we mapped Linear to GitHub issues and labels cleanly. That mapping is the important seam. Linear remains where the product and execution graph lives. GitHub becomes the forge-native execution surface Looper knows how to operate.

This is not hard conceptually. The risk is operational slop.

If Linear and GitHub drift, the agent loop becomes a well-engineered machine pointed at stale context. We should not do that.

The pilot I would run

I would not roll this into a critical repo first.

The right next move is a narrow pilot:

• choose one non-critical repo
• use our planning workflow to produce the issue and spec
• mirror or create the corresponding GitHub issue
• run Looper locally with codex or cursor-cli
• evaluate how it handles repo rules
• inspect its worktree behavior
• test the PR review and fix loop
• check what proof receipts survive
• measure noise
• confirm whether Linear coexistence is clean or annoying

The success condition is not “did an agent open a PR?”

That bar is too low.

The better questions are:

• Did the issue preserve the upstream intent?
• Did the local loop respect repo rules?
• Did the reviewer/fixer cycle converge without making noise?
• Did the worktree isolation behave cleanly?
• Did the proof survive in a form another operator can inspect?
• Did GitHub and Linear stay aligned?
• Did the system stop when it should stop?

That is the real test.

My take

Looper is not a replacement for our workflow.

It is a promising execution primitive we should test inside our workflow.

The mistake would be treating a better coding loop as a replacement for upstream judgment. That is how teams confuse velocity with progress.

The useful version is more boring and much stronger: keep the product interrogation, spec generation, issue graph, context packs, and proof gates. Then let a local daemon like Looper handle the part it is actually built for.

That is the shape I trust.