Most people who build a multi-step agent end up with a straight line

step one, step two, step three. Each one waiting for the last to finish before it starts

Here’s what almost nobody checks: half those steps never needed to wait

They just queue, one job at a time, until the context window fills and the agent forgets what it was doing

• It wasn’t slow because the model was weak

• It was slow because you drew a line where the work was a graph

This guide takes you from that line to a graph that fans out across a fleet and checks its own work

Five steps. By Step 2 you’ll have built one - It gets you a working graph and names the traps that break real ones and I’ll flag where the hard parts begin

before the alpha - subscribe to my substack for more fresh alpha ↓

https://substack.com/@0xcodila

Chapter 0 - What graph engineering actually is

A month ago the field was talking about loops.

Peter Steinberger caught it in nine words:

Are we still talking loops or did we shift to graphs yet?

A loop is one cycle of getting better:

try something → check the result → adjust → go again

That’s the atom: a single agent improving one thing on repeat

But the single loop has a known failure - a support team ties a feedback loop to one metric: ticket resolution rate

The number climbs for months while satisfaction drops. The bot learned to close tickets fast instead of solving them

That’s Goodhart’s law. A loop can only see its own metric. It can’t ask whether the target is right, or notice its own measurement drifting.

The answer isn’t a better loop. It’s a graph of loops - a network where cycles watch and correct each other

For agents, that means one thing:

Stop writing one agent that does everything in a line - design the shape of the work - what runs before what, what runs at the same time, what waits.

Nodes do the thinking. Edges carry the results

And Claude Code shipped the tooling to build these directly:

dynamic workflows

Step 1 - See the edges that aren’t there

A graph has two parts:

• A node is one unit of work: one agent, one job, one input, one output

• An edge is a dependency: this node’s output feeds that node’s input

The mistake everyone makes is treating “and then” as an edge.

“Summarize this file and then tell me the weather”

The weather doesn’t read the summary.

Those are two independent jobs a linear script chains for no reason. Each one waits on the last for nothing

The habit that starts everything:

For every “and then,” ask - does the next step actually read the previous step’s output?

• If yes → real edge. Keep the order.

• If no → no edge. The wait is wasted. Run them side by side.

If no data crosses between two boxes, they’re independent.

That independence is what you’ll exploit for the rest of this guide

Your plain “do A, then B, then C” agent is already a graph - just the saddest one: a single chain where if C stalls, D never happens.

Step 2 - Build your first graph (start to finish)

Enough theory. Build one and watch it run.

Before you start:

• Claude Code v2.1.154+ (check with claude --version)

• A paid plan. On Max, Team, or Enterprise, workflows are on by default. On Pro, switch on the Dynamic workflows row in /config

1. Open a repo you know.

A real one, so the result means something.

2. Paste this prompt (off by Anthropic):

Create a workflow to audit every route file under src/routes/
for missing auth checks. Spawn one agent per file, then run an
independent verifier on each finding before reporting.
Analyze a maximum of 20 files to start.

Swap src/routes/ for where your files live. The “max 20” line keeps your first run cheap.

3. Watch “workflow” light up.

Claude Code highlights it: “Dynamic workflow requested.” That’s your signal a graph is building, not a normal chat

4. Approve the plan.

Claude writes a JavaScript orchestration script and shows the phases first. Read them, pick “Yes, run it.”

5. Let the fleet run.

One agent per file, in parallel, while your session stays free.

Type /workflows to watch it live: scope, fan-out, verify, synthesize.

6. Read the one answer.

Not twenty separate chats. One report - because the intermediate results lived in the script’s variables, not your context.

That’s a graph. A dozen agents, from one sentence.

About the “zero tokens” claim you’ll hear

The coordination script is code
So passing results between agents doesn’t re-spend context the way a chat handoff does.

But the agents still cost usage. A workflow costs meaningfully more than a normal session.

The saving is in coordination, not the work. Start scoped, watch usage, then widen.

• Make it yours

When a run is good, press s.

It saves to ~/.claude/workflows, re-runnable by name

Now change the task and keep the shape. Swap “missing auth checks” for “unhandled promises,” or “functions over 100 lines

How far this scales (article name)

One workflow run can fan out to 1,000 agents, with up to 16 working at once

That’s where “1000+ loops in one window” comes from - not a metaphor, the feature’s actual ceiling

• And the scale is the point
  
  A thousand agents means a job no single context could ever hold - a whole codebase audited at once, a migration that touches every file, a search that runs a thousand angles in parallel
  
  The 16-at-once limit just means the fleet moves in waves, chewing through all thousand without you babysitting a single one

Start at 20 to see how a run behaves and what it costs - then open it up - because this is the ceiling nobody else is building against

Step 3 - The part that actually breaks

You built a graph. Here’s where real ones fall over.

Two failures matter most

• Failure one: the graph agrees with itself

When an agent checks its own work, it goes easy on itself. Models prefer their own outputs

So you put a verifier on the edge - a separate node that confirms a finding before it flows downstream.

The catch nobody names: the verifier needs clean context

Hand it the same conversation the executor had, and it isn’t verifying. It’s agreeing with itself in a different font

A graph of agents sharing one context is a single loop in a costume. It fails the same way - later, more expensively, with more green lights on the way down

So the verifier is a fresh node - Own context - Checking a real signal - not “did the agent say it’s done,” but “does the test actually pass“

• Failure two: agents stepping on each other

This isn’t hypothetical

When Bun’s team first fanned a large port across many agents, the run failed operationally and agents used shared git commands in one workspace and overwrote each other

The fix was structural, not clever prompting. They forbade the unsafe commands and gave each group its own isolated worktree

That’s the real lesson of parallelism - two agents writing the same file race

Before you fan out, answer three questions:

• Where does each agent work?

• How do results merge?

• What happens when two disagree?

A graph without that plan doesn’t scale - It fails faster

Step 4 - Six graphs to build this week

The method: find the real edges → fan out → verify on independent context → isolate the workers

///

Each of these is that same shape, aimed at a new job. Change the task line and go:

• Security sweep - one agent per file hunting missing auth, a verifier confirming each hit (the one you built)

• Cited report with /deep-research - ships already: splits your question into angles, searches in parallel, agents refute each other before writing

• Port a module - file by file, tests as a gate, failures looped back

• Adversarial diff review - routed by size: small change → one pass; big one → full parallel audit

• Scheduled ecosystem scan - save once, re-run by name

• Discovery of unknown size - finders run in parallel, each result checked against everything seen, looping until two rounds find nothing new
  
  //

https://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/

Bun’s Zig-to-Rust port ran on this exact machinery.

Around 50 workflows, a peak of 64 agents in parallel. Roughly 535,000 lines of Zig turned into over a million lines of Rust, in 11 days.

It also cost about $165,000 in usage, It needed a human designing and monitoring the whole thing
And it drew public criticism over whether that much AI-authored code can be safely reviewed.

The scale is real. So is the price, and the supervision

Step 5 - The anchors that keep a graph honest

Topology alone doesn’t buy truth

A network of agents all confirming each other, none of them touching anything real, fails exactly like the single loop did - just with more moving parts

The graph needs anchors: nodes that can’t be argued with

• Tests that actually ran - not “should pass,” did pass

• A verifier on evidence, not vibes

• Frozen rules the agents are never allowed to tune - because they’re the ones an optimizer would weaken

The graph is only as honest as the things in it that refuse to move

When a graph is the wrong choice

Most tasks are not graphs. Reaching for one when you don’t need it just burns money and adds ways to fail.

Skip the graph when:

• The task is small or isolated. Adding a function, fixing one bug. A workflow is pure overhead here - a single agent is faster and cheaper.

• You need tight oversight. If you want to read and approve every step before the next one runs, a graph’s whole point (running wide without you) works against you.

• You don’t know what you’re looking for yet. Exploratory work wants one agent you can steer, not a fleet committed to a plan before you understand the problem.

• The steps genuinely depend on each other. If every step reads the last step’s output, it’s a real chain. Parallelism has nothing to grab. Forcing a graph onto a truly sequential task just adds coordination cost for zero speedup.

The tell is Step 1. If you can’t find two boxes with no arrow between them, there’s no graph to build. It’s a loop, and a loop is fine.

A graph is a tool for width - independent work, done at once
When the work isn’t wide, the line was never the problem...

The shift

A prompter asks a question. An architect draws a graph.

The linear agent was never the ceiling.

It was the first shape - the one everyone reaches for because it matches how we type: one line, one thing at a time.

Once you see the nodes and edges, you stop asking the agent to do more and start asking the graph to do it wider:

• Fan out where the work is independent

• Gate the edges where confidence matters

• Freeze the nodes that hold the truth

Most people will keep queueing steps in a line.

The few who learn to draw the graph, and to respect what breaks it, will run a fleet.

Draw the graph. Stay the architect.

Start with the prerequisite:

Loop Engineering

- the single loop this is built on

That worked fine for two years. It does not work anymore.

The people getting 10x more out of AI right now are not writing better prompts and not using secret models.

They are building loops. And the person who made this idea impossible to ignore is Andrej Karpathy

This article will explain:

1 - from scratch what a loop is

2 - show you how to use them the way Andrej Karpathy does

3 - then describe a method to improve this approach by a factor of 5

4 - and provide tips for getting started.

Part 1 · The Basics

1.1 - What a loop actually is ?

A prompt is one instruction. You ask, you get an answer, you decide what to do next.

A loop is a goal the AI keeps working toward until it gets there - without you sitting in the chair prompting every step

The AI discovers what needs doing, plans how to do it, does the work, checks the result, and if it is not there yet - feeds the result back in and goes again. You define the purpose once.

The loop handles the rest.

Three parts make or break it:

• A verifier is what turns repetition into progress. Without a real check on the result, you do not have a loop - you have the agent agreeing with itself on repeat. The check can be a test that passes or fails, a metric that goes up or down, a build that compiles or crashes. No gate means the agent grades its own homework.

• State is what makes the loop learn. Each pass, the AI has to know what it already tried. Without that, it repeats the same mistake every cycle. A small file on the side records what is done, what failed, what is next. Tomorrow’s run resumes instead of starting from zero.
  
  A stop condition keeps it sane. A loop with no exit runs until it succeeds, breaks, or drains your account. Every working loop has two ways to stop: the goal is met, or a hard limit says “after N tries, stop and report”

2.2. Do you actually need one? Run this test first.

Most articles sell you the loop before they tell you when it is a mistake.

A loop earns its cost only when all four of these are true. Miss one and it costs more than it returns.

• The task repeats - at least weekly. Less than that and the setup cost never pays itself back. A one-time job is still better served by one good prompt.

• Verification is automated - a test suite, a type checker, a linter, a build. Something that can fail the work without you in the room. No automated check means you are back reading every diff - the exact job the loop was supposed to remove.

• Your token budget can absorb the waste - loops re-read context, retry, explore. That burns tokens whether the run ships anything or not. This scales with budget, which is why it reads as obvious to people with free tokens and reckless to people on a $20 plan.

• The agent has real tools - logs, a reproduction environment, the ability to run the code it writes and see what breaks. Without that, the loop iterates blind.
  
  The honest take: loop engineering is real, and most people do not need the heavy version yet. If you are on a consumer plan with limited tokens, a heavy loop will hit your rate limit or your wallet before the productivity gain arrives.

Part 2 · The Karpathy Loop

How Karpathy stopped prompting and started looping

In March 2026, Andrej Karpathy released a GitHub repo called AutoResearch.

Three files. About 630 lines of code.

Within a month it had 66,000+ stars and Fortune magazine gave it a name: The Karpathy Loop.

-

karpathy autoresearch

-

The setup is almost absurdly simple:

• train.py

  - the training script. The only file the agent is allowed to touch.

• prepare.py

  - the evaluator that scores the model. The agent cannot touch it. If it could, it would just make the test easier instead of making the model better.

• program.md - the instructions that tell the agent what to explore and what constraints to respect.
  
  
  The agent runs in a loop:

Read the code → propose a change → train for five minutes → check if the result improved → commit if it did, roll back if it did not → repeat.

You go to sleep. You wake up to a log of experiments and hopefully a better model.

The human never touches

train.py

. You write program.md. - the agent handles execution.

- The results:

Karpathy pointed it at a model he had already carefully tuned by hand over two decades of experience. He let it run for two days.

• The agent ran 700 experiments

• Found 20 improvements he missed

• Things like a missing scalar multiplier in the attention mechanism that made attention too diffuse across heads

• Not a bug a fuzzer would catch - a subtle optimization that a careful human could have found but did not

Because humans get tired after experiment number twelve. The agent does not get tired at all.

Shopify CEO Tobi Lutke tried it overnight on an internal model:

• He woke up to a 19% quality improvement

• The optimized model was half the size of his previous one

• A smaller model beating a bigger one - because the agent optimized for the hardware instead of defaulting to “bigger is better”

The Karpathy Loop Fortune

Karpathy’s core insight: if you have an objective metric, you should not be the one running the experiments. You are the bottleneck. Remove yourself from the loop and let it run.

Part 3 · The Building Blocks

Five pieces that make a loop work

Every working loop - whether you build it in Claude Code, Codex, or bash scripts - is assembled from five pieces.
Both Claude Code and Codex ship all five now.

• Automation - the heartbeat. Something that fires the loop on a schedule, on an event, or on a trigger.
  
  In Claude Code: /loop for cadence, /goal for running until a condition holds. In Codex: the Automations tab. Without the heartbeat, you ran a script once and forgot about it. That is not a loop.

• A skill - stores project knowledge so the agent stops guessing every session. Your conventions, your build steps, the thing you do not do because of that one incident three months ago.
  
  Written once in a markdown file, read by every run.
  
  Without skills, the loop re-derives your entire project context from zero every cycle. With skills, intent compounds.

• Sub-agents - split the maker from the checker.
  
  The model that wrote the code is too generous grading its own homework.
  
  A second agent with different instructions catches the things the first one talked itself into. Your writer can be fast and cheap, your reviewer slow and strict. That separation is most of the quality.

• Connectors - let the loop act inside your real environment. Read your issue tracker, open a PR, ping Slack, update a Linear ticket.
  
  The difference between an agent that says “here is the fix” and a loop that ships the fix and tells you about it in the morning.

• A verifier - the gate. The test, type check, or build that automatically rejects bad work.
  
  Everything else is plumbing.
  
  This is the part that makes the loop real. Without it you are paying for an agent to agree with itself all night

Part 4 · What Comes After Karpathy

The Bilevel - a Loop on top of the Loop

- this is where it gets interesting, hehe xD

• In March 2026, two researchers published a paper on arxiv called “Bilevel Autoresearch: Meta-Autoresearching Itself.”

They took Karpathy’s loop and asked a simple question:

If autoresearch is itself a form of research - can you autoresearch autoresearch?

Bilevel Autoresearch

They built a second loop on top of the first one:

• Inner loop - does what Karpathy’s original does: propose a change, train, evaluate, keep or discard

• Outer loop - watches the inner loop work, reads its code and traces, identifies where the search process itself is getting stuck, and generates new Python code that changes how the inner loop searches.
  Then it injects that code and lets the inner loop run again.

- The result:

On Karpathy’s GPT pretraining benchmark:

• 5x improvement over the standard single loop (-0.045 vs -0.009 val_bpb)

• Not 5% better. Five times better.

• Both loops used the same LLM - you do not need a smarter model for the meta level

• The improvement comes from the architecture, not from raw intelligence

What the outer loop actually found: the inner loop kept falling into the same search patterns. The LLM has priors about what optimizations to try, and it keeps going back to those priors even when they stopped working. The outer loop broke those patterns by forcing exploration in directions the model’s instincts avoided.

The paper ends with a line worth sitting with: “If autoresearch can meta-autoresearch itself, it can in principle meta-autoresearch anything with a measurable objective.”

Part 5 · Try It Yourself

Run a loop right now - no tools needed

You do not need Claude Code or Codex to feel how this works. Paste this into any LLM and watch what happens:

You will work in a loop until the task meets the bar.

TASK:
[describe exactly what you want produced]

SUCCESS CRITERIA (be strict):
- [criterion 1]
- [criterion 2]
- [criterion 3]

LOOP PROTOCOL, repeat every turn:
1. PLAN   - state the single next step.
2. DO     - produce or improve the work.
3. VERIFY - score the result 1-10 on each criterion.
            Be brutally honest. List exactly what is still weak.
4. DECIDE - if every criterion is 8+, print FINAL and stop.
            Otherwise print ITERATING and go again, fixing
            the weakest point first.

RULES:
- Never call it done until every criterion is 8 or higher.
- Each pass must fix the weakest score from the last VERIFY.
- Do not ask me questions. Make a sensible assumption
  and keep going.

Begin.

The model drafts, grades its own work against your criteria, finds the weak spot, rewrites, and repeats until it clears the bar.

That is a loop. You just built one with a paragraph.

It is limited - you are still the trigger, there is no schedule, no persistent state, close the tab and it is gone. But it shows the core mechanic. The jump from this to a full autonomous loop is adding the automation, the state file, and the gate.

Part 6 · The Honest Part

What the loop does not fix

Loops change the work. They do not delete you from it.

And two problems get sharper as the loop gets better - not easier:

• Comprehension debt. The faster the loop ships code you did not write, the larger the gap between what exists in your repo and what you actually understand. A smooth running loop charges compound interest on that gap. The day you have to debug a system nobody on the team has read will cost more than the tokens ever did.

• Cognitive surrender. When the loop runs itself, it is tempting to stop forming an opinion and just accept whatever comes back. Designing the loop is the cure when you do it with judgment - and the accelerant when you do it to avoid thinking. Same action, opposite result.

Two people can build the exact same loop and get completely opposite outcomes. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all.

The loop does not know the difference. You do!

Karpathy stopped writing code. Cherny stopped prompting. Neither of them stopped thinking. If you take one thing from this, take that.

I put together 4 steps that fix the memory and token-spend problem for good and +1 step that will create self managed agent system for you

Step 1 - Get the context out of the window

The instinct is to load everything up front so the model “has what it needs“

That’s the trap - everything you load is something you pay for on every turn until the conversation ends

• Put the big stuff in a file instead - the book, the codebase, the docs, the logs
  
  Then let the agent reach into that file only when it actually needs a piece of it - It can grep for a keyword, read one section, and move on

The 108,000-token book sits on disk. The question costs you the question.

→ This one move is where most of the savings come from. The rest of the steps are about not undoing it

How Claude Code uses prompt caching

Step 2 - Send the messy work to a subagent

Some jobs generate a wall of tokens you don’t want in your main thread - running a test suite, reading a stack trace, crawling a doc site.

- All of that noise lands in your context window and stays there, costing you on every following turn.

- Hand those jobs to a subagent

It does the dirty work in its own separate window, burns through the noise there, and hands you back a clean summary.

Your main thread never sees the 4,000 lines of test output - it sees “three tests failed, here’s why“

→ Think of the subagent as a filter- everything loud goes in, one quiet answer comes out

Subagents build their own cache and context

Step 3 - memory self-managed agent

(the crazy part)

Your agent starts every session from zero. You re-explain the same context, and you pay tokens to reload it

Claude Code fixes this natively -and most people don’t know it’s already on

Auto Memory means Claude writes its own notes between sessions - build commands, bug fixes, the workarounds you found - and loads them at the start of the next one

you don’t write anything - It decides what’s worth keeping

Do this today:

→ Run /memory to see what Claude has already recorded on its own. You’ll usually find it’s captured conventions and fixes you never documented.

→ Delete those lines from your CLAUDE.md. Anything Claude learns after one session doesn’t belong in the file you pay for on every turn - the memory holds it for free.

→ For bigger projects, make MEMORY.md a table of contents, not a dump

One line per topic file (gotchas.md, conventions.md), so Claude pulls in only the file the current task needs - not all 200 lines.

• That last move is the whole game in miniature: the agent carries its knowledge forward, but only the slice it needs enters the prefix
  
  Small prefix, small bill, and you stopped re-explaining yourself.

→ It’s already running. Your only job is to stop duplicating in CLAUDE.md what memory already holds.

Source:

Claude Code auto memory docs

and

Anthropic - Agent memory & “dreaming

Step 4 - Stop breaking the cache

(my favorite step)

Here’s the part most people don’t know is running

Everything stable at the front of your prompt - tools, system prompt, that tidy CLAUDE.md - gets cached after the first turn. A cached token costs a tenth of a fresh one

The catch: the cache matches an exact prefix. Change one character before the cache point and everything after it goes back to full price

Silently. No error.

The usual culprits:

• A timestamp or date baked into the system prompt - changes constantly, breaks the cache every time.

• Switching models mid-session - each model keeps its own cache, so a /model swap re-reads the whole thing from scratch.

• A stray space, a reordered tool list, or an MCP tool added halfway through.

The rule is simple, static stuff at the top, in a fixed order.
Anything that changes - the date, the user’s turn, session junk - goes at the bottom, below the cache point

Anthropic treats this as serious enough that internal teams declare an incident when their hit rate drops

Anthropic prompt caching docs

GitHub keeps theirs above 94% and calls a drop to 70% a bug.

Their CPO put it well - it’s like high-frequency trading, where 1% of efficiency is millions of dollars

→ Most people are sitting at 40% and have no idea

Step 5 - Manage the context by hand

Claude Code will compact your context on its own when it fills up

The problem is it does this on its schedule, not yours, and compaction can quietly eat most of your remaining tokens at the worst moment

Two commands give you the wheel back:

/context

• - shows you what’s actually taking up space right now - you’ll usually find something bloated you forgot about.

/compact

• - lets you squash the conversation at a clean break, like when you finish one task and start another, instead of waiting for the automatic version to trigger mid-thought.

→ The habit is small, Check /context when a session feels heavy. Compact between tasks, not in the middle of one

Part 6 · Honestly

The five steps above genuinely cut your bill - you just learned the thing most people never touch - and that alone puts you ahead of them

One thing worth saying out loud, so this keeps working

None of it is set-and-forget. Caching lives on a number you only see if you go look - your hit rate, your cache_read_input_tokens.

Setting it up once is great - Glance at it once a week, and a stray timestamp in your prefix won’t quietly steal the savings back.

A cheap agent is a state you hold, and holding it is easy now, because you know where to look

Here’s the good news: you’re in good company.

Andrew Ng and Anthropic arrived at the same place from the other side

- Ng teaches you to move an agent’s memory out of the window - that’s step one, just from the memory angle

- Anthropic went further: an agent that cleans its own memory in the background, so the prefix stays small on its own

Three different doors, one room - stop carrying everything, start carrying what the task needs - you just walked in

The tools will change: cache, subagents, memory stores - half these names will be different in six months

One thing won’t: the engineer who knows what their agent is holding, and why, always beats the one who dumped everything into the window and hoped

Now you’re the first one, so run your agent like an engineer.

@0xCodila