Level up loops with pipelines

Loops are useful. They get more useful when they are not asked to own the whole workflow.

After watching our own AI workflows break in boring ways, we have a sharper claim than “loops versus pipelines”: the best agent loops are usually the ones a pipeline can contain.

A loop can be exactly the right tool when the next move depends on feedback from a check. But when the whole workflow becomes “let the agent keep trying until it says it is finished,” costs rise, quality drifts, and accountability disappears.

Our rule at AIStackWorks is simple: build the pipeline first, then put the loop where feedback belongs.

That means we do not treat release as something an agent loops toward. We treat release as a gate. Loops can live inside build or QA, but approval, review, and release stay explicit.

The clean answer

An AI agent loop repeats observe → act → check until an exit condition is met. A pipeline moves work through predefined stages with explicit gates. Use a pipeline when the sequence is known and approval or review matters. Use a bounded loop inside a stage when the next action should depend on feedback from a fixed check.

That is the useful distinction behind the debate.

OpenAI describes agent orchestration as a run that is typically implemented as a loop until an exit condition is reached. Anthropic distinguishes workflows from agents by saying workflows follow predefined code paths, while agents dynamically direct their own process and tool use. LangChain makes a similar split between workflows with predetermined code paths and agents that decide their own process and tool usage.

None of those sources say, “make every important business process one giant loop.”

The stronger reading is more useful and more pro-loop: when the path is known, make the path explicit. When the next step depends on feedback, put a bounded loop inside the stage so it can do focused work without inheriting authority it should not have.

One word is hiding three different systems

“Loop” gets overloaded fast.

Sometimes people mean the inner tool-use loop: the model reasons, calls a tool, observes the result, then decides whether to call another tool or answer.

Sometimes they mean a goal loop: run a task, check the result, make a bounded change, check again, stop when the target is met or the budget is gone.

Sometimes they mean an outer automation loop: wake up on a schedule, find work, assign work, check work, write state, and decide the next thing.

Those are different control systems. Collapsing them into “agent loop” hides the question that determines whether a loop levels up the workflow or quietly takes it over:

Who owns the stop condition?

OpenAI’s loop framing is useful precisely because it pairs the loop with exit conditions such as tool calls, structured output, errors, or maximum turns. Every loop needs a brake.

A task without a check is hope, not a control system.

The failure mode: keep trying until the agent says it is done

The problem is not the loop. The problem is the unbounded loop.

Consider the anti-pattern: a builder writes a shell loop that feeds the same coding agent the same broad instruction until the agent says the task is complete.

There is no failing test. No max turn count. No cost cap. No no-progress rule. No separate reviewer. No durable state except whatever the chat remembers. No acceptance condition that exists outside the model.

The loop keeps editing, “fixing,” and spending. The agent looks productive because it is busy, but activity is not convergence.

This is where the cost and quality problem shows up. Anthropic recommends starting with the simplest solution possible and adding agentic complexity only when needed, because agentic systems often trade latency and cost for task performance. OpenAI similarly advises validating that an agent is needed before building one, because deterministic approaches may be enough unless the workflow has complex decisions, brittle rules, or heavy unstructured data.

Treat that as control-surface advice.

If the task already has a known sequence and known acceptance checks, the default should not be “give the agent more autonomy.” The default should be “write down the stages and gates, then decide where a loop can safely help.”

The model that wrote the code is often too forgiving when grading its own homework. We have seen the same pattern in our content workflow: a draft can satisfy its own checklist and still fail the independent review that matters. You need a check that can say no.

The gate that caught this article

We put this article through the same control shape we use for product work: idea → plan → approval → draft → review → polish.

The first draft had the thesis, the outside sources, the three-shape taxonomy, and the comparison table. It also had a problem the writing loop did not catch. The draft’s first-party evidence was too thin. If you removed the AIStackWorks rule and the staged workflow example, too much of the piece could have been written by a chatbot with the same public sources.

So the review gate rejected it.

That rejection was the system working. The draft did not get to declare itself done because it was source-linked and coherent. The next editorial stage stayed blocked until the article added a real AIStackWorks example, fixed the opening claim, and replaced the action section with a concrete run a builder could try.

That is the positive case for pipelines: they make loops safer, sharper, and easier to trust. A loop can improve a draft against a rubric, fix citations, and tighten prose. It should not be allowed to wave itself through the gate that exists to catch generic work.

The useful control was: revise while the independent gate names a fixable failure, then stop and return to the gate.

A loop worth running has a measurable exit

Now compare the failure mode with a loop worth running.

A useful loop has a target that can say yes or no. “Make the app faster” is vague. “Bring average request latency for /api/search below 200ms with no correctness regression” is a control target.

A useful performance loop looks like this:

1. Measure the current average latency with the same benchmark.
2. Identify one likely bottleneck.
3. Make one bounded change.
4. Rerun the same benchmark and correctness checks.
5. Continue only if average latency improves without breaking correctness.
6. Stop when average latency is below 200ms.
7. Stop if the budget is hit, two attempts produce no measurable improvement, the diff becomes too broad for review, or the next fix requires product trade-off approval.

This is where agents can be genuinely useful. The route can be uncertain while the outcome stays concrete: average latency below 200ms, tests still green, diff still reviewable.

A useful prompt is:

You are inside the performance stage of a software pipeline.

Goal: reduce average request latency for `/api/search` below 200ms without changing user-visible behavior.

Check: run the same benchmark and the same correctness tests after every attempt.

Loop rule:
1. Measure baseline average latency.
2. Identify one likely bottleneck.
3. Make one bounded change.
4. Rerun the benchmark and tests.
5. Continue only if latency improves and correctness still passes.

Attempt cap: three bounded changes.

Stop when:
- average latency is below 200ms;
- the three-attempt cap is reached;
- correctness regresses;
- two attempts produce no measurable improvement;
- the next change needs a product trade-off; or
- the diff becomes too broad for review.

Report after each attempt: benchmark command, latency before/after, tests run, files changed, diff summary, and whether the loop should continue.

That loop is worth running because the check is stable and external to the model.

Anthropic’s evaluator-optimizer pattern is designed for cases where clear evaluation criteria exist and iterative refinement provides measurable value. LangChain’s evaluator-optimizer pattern likewise describes generation, evaluation, feedback, and repeated improvement until the result is acceptable. Forward Future’s practical loop framing describes useful loops as work plus a check, with measurable goals, bounded changes, fixed checks, explicit stops, and budget states.

Current builder discussion is pointing the same way, though we would treat it as signal rather than proof. A Reddit harness writeup argues for orchestrator, worker, and reviewer separation, persistent state, verification gates, and custom stop conditions. A Jacob Labs X post compresses the checklist to goal, context, tools, stop condition, state, checks and recovery, approval, and budget. Another X post argues for the same bounded-loop thesis: agent loops are impressive when they have clear limits and deterministic gates.

The loop does not get to redefine success, decide that QA is optional, or quietly move from “reduce latency without changing behavior” to “redesign search ranking” because the first approach failed. It operates inside a box defined by the product decision.

Build the pipeline around the loop

For known work, a staged pipeline is the control surface that lets loops do useful work without owning decisions they should not own.

At AIStackWorks, we think about this pattern as:

idea/intake → plan → approval → build → QA → review → release

That sequence says where autonomy is allowed and where it is not.

A loop can help during build. A loop can help during QA. A loop can try to pass a test, improve a draft against a rubric, or check a workflow against acceptance criteria.

But approval is a gate. Review is a gate. Release is a gate.

A loop can try to pass QA. It does not get to redefine QA. A loop can prepare a release candidate. It does not get to release itself.

This is why “pipelines versus loops” is the wrong fight. The better question is how pipeline structure levels up the loop.

The pipeline decides what kind of loop is allowed. The loop does not decide its own authority.

“But real work is open-ended”

This is the strongest counterargument, and it is right often enough to deserve a serious answer.

Some work does not fit a clean pipeline. Anthropic says agents are a better fit when flexibility and model-driven decision-making are needed at scale, especially for open-ended problems where the number of steps is hard to predict. OpenAI says agents fit workflows where deterministic approaches fall short, such as complex decisions, hard-to-maintain rules, or heavy unstructured data.

A rigid pipeline can create false safety if the work genuinely requires adaptation.

There is also a builder reality here: sometimes direct human steering beats elaborate harnesses. Peter Steinberger argues for “just talk to it” style work in some coding contexts, where the human manages blast radius and guides multiple agents directly. Geoffrey Huntley’s Ralph writeup shows a literal bash while-loop approach, but the useful part is the external plan/spec state and fast backpressure from checks.

Those counterexamples sharpen the thesis: loops are not the enemy. Unowned loops are.

If the work is open-ended, the loop may be the primary engine. But it still needs controls: success criteria where possible, exit conditions, budgets, durable state, observability, and a human escape hatch. LangGraph’s docs emphasize durable execution, human-in-the-loop control, memory, debugging, and deployment discipline for long-running stateful agents.

With those controls, you are running a measured system. Without them, you are renting uncertainty by the token.

The builder template

Do not start by mapping your whole company.

Start with one stage and fill in the control surface before you add an agent loop:

/goal
Outcome: [specific result the user or system needs]
Success check: [test, eval, benchmark, rubric, verifier, or human approval gate]
Current baseline: [what is true before the loop starts]
Allowed changes: [files, tools, scope, actions]
Not allowed: [decisions the loop cannot make]
Budget: [attempts, time, tokens, cost]
Evidence to report: [logs, diff, tests, screenshots, metrics, blockers]

/loop
1. Observe the current state.
2. Choose one bounded action.
3. Act.
4. Run the same check.
5. Compare against the baseline.
6. Continue only if the evidence improves.
7. Stop on success, no progress, budget hit, blocked decision, or widened scope.

Here is the quick version for a repo:

1. Pick one failing check, benchmark, or eval.
2. Give your coding agent the /goal and /loop contract.
3. Cap it at three bounded changes.
4. Require the same check after every attempt.
5. Require evidence after every attempt: command, result, files changed, diff summary, and whether the loop should continue.
6. Escalate if the cap is hit, the diff widens, the check stops being the right check, or the next move requires a product decision.

Success should be boring: the check passes, the diff is small, and a human reviewer can explain why the change fixed the problem.

A cap hit is also a result. It means the loop found the edge of what it can safely do. Escalate with the check, the attempts, the final diff, and the reason the loop stopped.

If you cannot fill in the template, do not automate the loop yet.

Loops do the feedback work. Pipelines decide where authority belongs.

The rule

Level up your loops by building pipelines around them.

A pipeline is how you say, “This is the work, these are the stages, and this is who can move it forward.”

A loop is how you say, “Within this stage, keep trying while the check says another attempt is useful.”

The while loop is not the danger. The unowned loop is.

If you are building AI into a real product workflow, do not start by asking how autonomous the agent can be. Start by asking where the gates belong, what the loop is allowed to change, and what evidence it must bring back.

Then let the loop do what loops do best: improve the work inside a bounded stage.