From 20 Agent Loops to One Guarded PR

What is Loop Engineering?

Loop Engineering treats software work as a closed, instrumented feedback system: trigger, act, evaluate, decide, record, and repeat until a verified exit condition or explicit failure budget is reached. The loop owns the outcome while deterministic gates and humans control irreversible actions.

A conventional CI stage has completed its job when it reports red. A closed engineering loop has not. The red test becomes a typed input that obligates the debugger and QA roles to produce a green test run, request a justified exception, or exhaust a visible failure budget.

That difference sounds small, but it changes the unit of automation. The atomic move is no longer generate code. It is generate, measure, decide, record, and act again until an exit condition is met. The system can then be evaluated by outcome, not by how convincing one model response looked.

The design starts with stable names and state

The blueprint freezes a canonical roster of 17 agents and a registry of 20 loops. Stable IDs are not cosmetic. They let prompts, database rows, traces, evaluations, permissions, and dashboards refer to the same actor or workflow without semantic drift.

PostgreSQL is the system of record for tasks, subtasks, runs, tool calls, files changed, evaluations, test runs, prompt versions, memory, decisions, deployments, incidents, feedback, releases, audit logs, and approvals. A canonical task state machine constrains forward movement and makes blocked, failed, cancelled, and changes-requested paths explicit.

Twenty loops cover the full engineering lifecycle

The first ten loops move from idea to specification, task, code, test, review, documentation, pull request, and deployment. The next ten close the operational learning cycle: observability to bug, feedback to feature, prompt improvement, agent evaluation, memory consolidation, architecture decisions, incidents, refactoring, performance, and release learning.

Each loop declares its trigger, agents, inputs, output artifact, exit condition, retry policy, and human gate. That contract prevents a supervisor model from improvising a new process every time it sees an ambiguous task.

Evaluation is ordered from cheap certainty to expensive judgment

The evaluation wall has eight layers. Deterministic checks run first: schema validity, permissions, lint and type checks, tests, and policy rules. Only surviving artifacts reach more expensive model-based review for correctness, architecture, security, documentation, product relevance, or agent reliability.

The order is both a cost control and a safety control. There is no value asking a frontier model to debate the elegance of code that does not compile. Composite scores can help route work, but a weighted average never overrides a blocking security or approval gate.

Human approval is a capability boundary, not a courtesy prompt

The non-negotiable gate list includes merge, production deploy, schema changes, external communications, secret operations, spend, destructive data actions, authorization changes, frontier-prompt promotion, and release. No agent can approve its own request.

Every decision records the gate, actor, rationale, artifact, verification plan, and rollback path. A rejected action returns to a typed state instead of disappearing into chat. This makes the human review surface smaller but more consequential: people review irreversible boundaries, not every intermediate token.

Reliability comes from bounded blast radius

The design does not assume models become generally trustworthy. It restricts each run to a repository, branch, subtask, tool permission set, cost ceiling, and retry budget. Checkpointing makes interrupted runs resumable. Tool calls are typed and permission-checked. Audit records preserve who changed what and which prompt version produced it.

Prompt injection is treated as an input-security problem. Retrieved text is data, not authority; secrets and protected paths remain outside model control; and a model-generated instruction cannot grant a capability that the tool registry did not already authorize.

The design got better when adversarial review cut the MVP

The first complete blueprint was coherent but too large to prove. An adversarial build review found three structural problems: the implementing state did not yet name a real runtime coder, several safety properties existed only as prompt instructions, and the initial scope demanded roughly 60 files and 16 tables before one useful loop had earned trust.

The corrected v0.1 removed LangGraph, the dashboard, production deployment, vector memory, and most of the roster. A plain state machine asks a read-only coding model for a unified diff; a wrapper owns git apply checks, path confinement, final risk classification from the actual diff, allowlisted commands, tests, scanners, budgets, and commit creation. The credible starting point is one guarded PR, not 20 simultaneous loops.

What would falsify the design

Loop Engineering is only valuable if it improves verified throughput without moving hidden work into review and incident response. The implementation should measure cycle time, first-pass eval rate, retries, human review minutes, escaped defects, rollback frequency, and cost per accepted artifact.

If reviewers spend longer untangling agent output than they saved, if deterministic gates are routinely bypassed, or if memory increases confident repetition of stale decisions, the loop is not working. Those are product signals, not prompt-tuning problems.