The Agentic Loop: Building a Software Factory Worth Its Tokens

Loops, factories and graphs oh my!

Loops are out, graphs are in. That's the story going around. Graphs are how you build with agents now and the loop was the clumsy thing we did before we knew better.

It's a tidy story, and it's wrong. Graphs didn't replace loops, they wrapped them. And none of this is new, it's the same work we've done in software for decades, we just handed it to an agent. The question hasn't moved either: how do you ship the best software as fast and cheap as you can? Agent coding hasn't changed that.

What the bleep is an agentic loop?

Let’s keep running with the opening example: The LLM produces tokens, or chunks of text, in a loop feeding the running total back into itself until it hits some stop-word. We can train an LLM to write us Shakespearean prose or some TypeScript, it’s all just text in the end. Then some people realized that we can take that same idea and loop it. Have the LLM build some text and then a program can do something with that text and then add it to a list and feed that list back into the LLM and now you have a chatbot, or an agent. With a little training the models started using structured responses and tools were born. This loop is the agentic loop and we can keep working our way upwards. Multiple tool calls and outputs linked together create the agent run or loop.

There is no magic here and you can really think about it the same way you would think about how a human software developer works. They read the code, read the requirements and have conversations that help them understand what needs to be done, one chunk at a time. When they start writing code they break the solution down into blocks and modules and start building, looping all the while.

From token to factory

I think you know where this is going: we loop the loops and then we loop some more. LLM models generate tokens in a loop, and agents generate lists of the tokens and then we write programs to analyze and interact with, runs of agents produce the conversations and long running tasks that produce the actual code results and we keep going. Like starting with a scalar number and then moving to a vector, a matrix, and beyond, we get to a factory.

A factory is a fancy term for looping our agents. A concrete example is as follows: A software development team wants to do some long running task with a goal, like refactoring some code or switching a library. Those types of tasks aren’t one-and-done and they generally have many intermittent steps with each step having a prerequisite and some steps can be done in parallel. That team of developers IS the factory, they sit at their computers and write code, step-by-step, until the overarching goal is done. Factories in AI-driven development are just a way of distilling that process for agents.

To continue with that last analogy we introduce graphs: the individual step and its connection to each step around it. Before that team can start migrating to library X it needs to add it to the dependency list. Once that is done they can start on a refactor needed to decouple from the old library Y, and on and on. Some tasks can be done in parallel, some have no prerequisites, some rely on testing, validation and QA. The shape that comes out of those task steps and their relationships to each other is the graph. Graphs aren’t replacing loops, they are just the next step above them. Factories are just a set of graphs that wrap agent runs, that wrap agents that wrap LLMs. Loops, all the way down.

You are the adapt janitor: an autonomous loop that ships the adapt roadmap as a stream of tiny, high-quality, independently-shippable PRs. This repo is your project memory.

The steps are fixed; the conclusions are yours. The DAG is a hypothesis about what to do, not an order queue. If reality disagrees with the plan, fixing the plan is the job. A run whose best outcome is a better plan and zero PRs is a successful run.

Highest quality is the point. You are the last line of defense, assume no bot, CI, or human catches anything. One open PR at a time. You never merge, a human merges. No DB migrations, ever.

Flexibility is first-class. Any run can call an audible: obsolete, skip, needs-human, split, re-scope, re-order, defer. Each one is a complete, successful run.

Excerpts from the janitor loop creation prompt

The trap: factories tend to burn tokens

So you built a loop that works. The obvious next move is to run twenty at once. Fan out twenty with no gate and you burn 20x the tokens. And if the loop was wrong, you just paid to be wrong twenty times.

No one selling you on software factories is going to bring that up. A factory multiplies output, and garbage in is garbage out, multiplied or not. Every loop that finishes hands you a diff a human has to actually look at, run twenty and twenty diffs pile up waiting on you. I call that review debt, and it’s a hefty bill that stings.

So who needs twenty loops running at once? Well, most of the time, you don't. Wasting tokens only helps the providers, it burns our time and our money, and a factory that can't say why it exists is just an expensive way to bombard yourself with review, it has to earn the fan-out.

What actually works is smaller. Smaller scope per loop, a hard cap on how far it can wander. The freedom to skip work that's already done and the ability to fail fast and quit when it's stuck. A loop that quits early is a loop that saved you money.

And an LLM will run away with scope the second you let it. Every. dang. time. It'll fiddle with files you never touched, spruce up code that was fine, chase a refactor nobody asked for. It will keep going long after the job is done. As the developer, you have to shove your own intuition into the loop prompt, the taste for when to stop, when to skip, when to bail, when to hand it back to a human. Feed it well-scoped feedback and last run's mistakes, or the factory never learns a thing.

Making the loop worth it

So how do you build a loop that doesn't burn your money? You give it the ability to call an audible, make changes to its plan, stop early and raise flags so that a human can jump in and control the situation. At the heart of that is a graph. The graph is really just the tasks, stories, issues, whatever you call them. The individual units of work that need to be done and how those units connect to each other. Another key piece is the memory and more specifically the place where the agents can write out what they have already done and how they have already done it.

I find that giving the agents a directive to distill repetitive tasks into scripts and giving enough description about those scripts to the next agent that comes along massively speeds up task execution and reduces tokens used. This is like cached intelligence. And with a graph, the loop wakes up, looks at what's ready to work on and picks the one piece it can actually do right now. Take that and loop it and you get to the very point that I have been making.

Again, the graph isn't set in stone. The loop can add to it, it can drop nodes that reality makes pointless, and even re-arrange the order when a dependency shifts. A plan that can't change is really just a wish. So the loop gets to fix the plan as it goes, and a run that ends with a better graph and zero code is still a good run.

One of my loops moves through it like this:

• Find the work. Read the graph. Grab the next ready piece, adapt if things changed. If a PR is already open, go tend that first instead of starting something new. Don't let the PRs pile up.
• Size it up and make sure the piece is small and clear. Too big? Break it down, or hand it to a human to make the call and move on.
• Stay in your lane. Do the work and nothing else. Cap the lines so you're not handing a human slop soup to review. Lines should be capped in two places: at estimation time, if it estimates the code will be too long it can break down the task into sub-tasks or kick it up to a human. The second place is after the work is done, if it is still too many lines or too complex it can create sub-tasks and hand off what it did to a human.
• Build a running memory of what tasks were done, cache behavior with scripts and make sure that everything is ready for the next agent to get in there and start on the next task.
• Check yourself. Look at what you did and make sure it stayed in scope. If it wandered, cut it back or flag a human.

Every step allows the agent to bail early and avoid burning tokens where it can. This lowers cost and can mean better complexity management through smaller pull requests.

Example: the janitor and the reviewer

Let me show you how I do this for real. On the Adapt codebase I run several loops working together in a code factory like explained above. These are backed by GitHub repositories acting as long-running memory. Each repo gets a few standard files: MISSION.md, RULES.md, START_HERE.md, STATE.md, dag.json, and cookbook.md. The agent’s individual looping directive is to start at the START_HERE.md file which gives it the lay of the land. The dag.json is where our graph is held and cookbook.md is where we index scripts and previously found shortcuts.

1. Load the three mandatory skills (Memory boundary below): typescript-code-style, pre-pr-checks, code-review. If any fails to load, STOP and journal skill-load-failure — never ship code without them.
2. MISSION.md — what you are and the exact loop.
3. RULES.md — the authoritative rules (single source of truth; other files point here).
4. STATE.md — the run lease and sweep timestamp.
5. dag.json — the source of truth. Compute the ready frontier live: status in AND every dep in a satisfied state (merged or obsolete); highest priority first. dag.md is a generated view — never trust a hand list.
6. cookbook.md — house patterns + verified facts; read the refs your slice names.

Excerpt from a loop’s START_HERE.md

This shows the full read order given to the agent and illustrates some of the early escape hatches available. This is from a loop that I call “The Janitor.” It goes through the code base looking for areas to improve - stale or excessive comments, places to reduce complexity, TypeScript types improvements, code smells, etc.

This is all a part of a chain of agents as well. With the first being the janitor. It ships small, boring PRs off that graph, one at a time. The second is the reviewer, our own AI code reviewer that runs on every PR. Point them at each other and you get a little conversation:

• The janitor grabs a ready piece off the graph and opens a PR, small and scoped, with tests if needed.
• The reviewer looks it over and leaves comments right on the PR, same as it would for any of us. A human can chime in too.
• The janitor reads those comments, fixes what's fair, pushes back to the same branch, and replies with what it changed.
• The reviewer re-reviews the new push. Round and round until the PR is actually solid.
• Then, and only then, a human approves and merges. The loops never merge their own work.

That last part is one that matters a lot. Two agents can go back and forth all day, but a person still has the final say. The reviewer scores its confidence and the check goes green or red, and green just means a human can take a look without dreading it.

The two loops sharpen each other over time. The reviewer keeps flagging the same kind of thing, so the janitor learns to quit doing it. The janitor scopes tighter, so the reviewer has less junk to catch. I've run around 66 PRs through this by now, and both ends have gotten better the whole way. I have merged all but 2 or 3 of them and was able to direct the system on how to split up that work, letting it get back to its thing. That’s why it’s better to run loops instead of firing off one big agent and praying it gets it right. The industry learned this a long time ago and conventional wisdom tells us that many small refactors are much safer than one giant one.

Where this goes: loops that spawn loops

Right now I wire the loops together by hand, but the next step is loops that spin up their own loops. An agent takes a big task and breaks it into pieces. Each piece gets its own fresh loop, and the factory starts assembling itself.

Fun to think about, and it drags along the two things I've been focused on this whole time. More loops running on their own means a bigger review pile, so the gate means more and more, and once an agent can spin up other agents that reach into real systems, there's a new question to answer: what is each one actually allowed to do?

We have a saying here at Adapt: “bet on LLMs.” I think it will get easier and easier to explain to these agents exactly what their bounds are and they will get better at coloring inside the lines. I believe that natural language will allow us to plainly explain what these agents can do, to what and how they can do it. I also think that this future is closer to us than ever before.

The real loop

None of this is new and we've been breaking big work into small pieces and checking each one for as long as we've written software. Agents just do it faster and cheaper, and they'll run off the rails just as fast if you let them.

So the whole game is the graph and the gate where the graph tells the loop what's worth doing and lets it quit when there's nothing good left and the gate keeps the junk from ever reaching a human. The balance between those two is where you find the best bang for your buck. Skip them and you will have built a very expensive way to make slop. And remember it’s loops all the way down.

The reviewer half of this is real, running on every Adapt PR. Sign up or book a demo, and go put a gate on your own factory.

FAQ

What is an agentic loop?

An LLM that works in a loop. It produces some output, a program acts on that output and hands the result back, and the model goes again until it hits a stop. That loop is what turns a text predictor into something that can finish a task on its own.

How is this different from plain automation?

Automation follows a fixed script, the same steps in the same order every run, and it breaks the moment reality doesn't match. A loop decides what to do each time around, so it handles the messy parts a script can't. You trade some predictability for that, so you put a gate on it.

Do graphs replace loops?

No, they wrap them. The graph is the plan, the work and what depends on what. The loop is what does each piece. Take the loop out of each node and you've got a workflow builder with an LLM bolted on, the thing we already moved past. You want both: the graph outside, a real loop in every node.

How do you keep loops from burning tokens?

Give the loop permission to quit. Small scope per piece, a hard line-count cap, freedom to skip what's already done, and freedom to bail when it's stuck. A loop that stops early saved you money. The other half is memory, let it write down what it already did so the next run doesn't redo the work or wander off.