EngineeringIn progress2026
Loop
An agent-orchestration hub that turns Linear tickets into shipped PRs using parallel AI coding agents.
In active build: 200+ tickets through Loop, review agents on every change.
TL;DR
01 / What it is
Loop turns a Linear ticket into a reviewed pull request. An AI agent does the work, review agents check it, and I only see what needs a human.
02 / Why it existed
AI writes code faster than I can review it. I was the bottleneck, so I built the thing that takes most of the reviewing off me.
03 / What I achieved
Over 200 tickets through Loop so far, every change checked by review agents before it reaches me. Still in build, and in daily use.
- Linear tickets processed
- 200+
Overview
Loop is my agent-orchestration hub, and I use it every day while I keep building it. A ticket comes in from Linear, an agent picks it up, and a reviewed pull request comes back. There are four parts: the Hub, which is the screen I watch it all from; the Router, which picks a model for each job and keeps an eye on spend; the Runner, the agent on my own machine that does the work; and Connectors, which plug in wherever tickets live, Linear first. Before an agent starts, the ticket passes a checkpoint. Before anything merges, two review agents go over it.
Why it existed
I was building Edgeways with AI and hit the wall everyone hits: an agent drafts a screen in seconds, then I spend twenty minutes checking it against the design system, the money maths and basic UX sense. Generation was never the problem. Review was, and I was the only reviewer. Loop exists so the dull checks happen before I look, and my time goes on the calls that actually need me.
My role
All of it: design, engineering and product. I designed the Hub and the Route Dial, the control that picks a model. I built the Router, Runner and Connectors, wrote the spec, built the n8n workflows, and I still review every pull request. The security model, where the Hub never holds anyone's keys, is mine too.
Approach
Engineering
Engineering
The Router is the orchestration engine, built on n8n workflows. It offers three model tiers, Recommended, Faster and Stronger, picked per ticket by label, and keeps a running allowance so spend is always visible. Any model can be switched off without touching the rest. The Router dispatches to the Runner, the agent on the user's own machine, which builds in an isolated copy of the codebase, opens a pull request and reports back.
The Runner is signed and keyless. It registers with a public key, so the Hub can verify what it sends without ever holding the user's credentials. If the Hub were compromised, the user's keys would not be.
Connectors hold integration state in a Postgres database; Linear is the first. The Hub itself is a Next.js app with ticket views, a Decisions page for the judgement calls Loop has made, and a Status page for its health.
Two kinds of gate protect every change. Before dispatch, a checkpoint comment is posted on the ticket so the brief is agreed before any agent starts. Before merge, two review agents run on the pull request: one audits the money maths, one checks the UI against the design system. A watchdog flags anything stuck or waiting on me.
Design
Design
The Hub is designed for one thing: seeing what is happening across the pipeline without reading logs. Ticket views show status at a glance; the Decisions and Status pages show the calls Loop has made and whether it is healthy.
The Route Dial is the human-facing control for choosing a model. It makes the trade-off visible: Stronger costs more allowance, Faster is quicker but less thorough, Recommended is the balanced default.
Key decisions
Decision
Signed keyless runner vs shared credentials
- Why
- A money-sensitive product cannot have credentials sitting in a dispatch hub. The Runner signs its pushes with a public key; the Hub verifies but never holds the private key. If the Hub is compromised, the user's credentials are not.
- What it cost
- More complex onboarding (public key registration); the Hub cannot dispatch without the Runner being online.
Decision
Model ladder (Recommended/Faster/Stronger) vs single model
- Why
- Different tasks need different models. A spacing fix does not need Opus; a calc-engine change does. The ladder lets me spend allowance where it matters and save it where it does not.
- What it cost
- More routing complexity; the model-choice logic is a real system, not a config flag.
Decision
Automated review gates vs human-only review
- Why
- If I am the only reviewer, I am the bottleneck. The gates catch the common cases and I review what they flag.
- What it cost
- The gates are only as good as their prompts; a bad gate lets bad code through. The prompts are maintained like code.
Highlights
Outcome
- Linear tickets processed
- 200+
Loop runs my own projects today and still changes most weeks. Over 200 tickets have gone through it, many to completion, and the checkpoint has caught tasks Loop created itself. The write path is under security review and more connectors are coming. It is my build infrastructure first; whether it becomes a product is a question for later.
Learnings and what's next
The lesson I keep relearning: with AI, the bottleneck is never writing code, it is checking it. I ran out of capacity to review by hand, so I built the thing that reviews first. If you are the bottleneck, build your way out of it.
Next: harden the write path, add connectors beyond Linear, and decide whether Loop stays mine or goes public.