← seansooch.devField Toolkit
Force Multiplier 01 · Method

Graph vs Loop

Two ways to wire the work of an AI agent, and how to tell which one a job needs.

Bottom line

Start with a loop. Draw a graph when the work is parallel, when someone other than the author has to check it, or when it has to survive being interrupted. A graph is not the opposite of a loop. It is what decides where loops are allowed and what stops them.

1 · In plain wordsOne cook, or a kitchen

A loop is one cook making one dish: taste, adjust, taste again, stop when it is right. Everything the cook knows is in one head, and that is the strength. Nothing has to be explained to anyone.

A graph is a kitchen during service. There are stations, a ticket that says exactly what each station owes, and a pass where one person checks every plate before it leaves. The stations do not share a head, so the ticket has to carry what matters.

With AI agents the cook is a model working in one conversation, and the kitchen is several of them handing each other written work. The question on this card is when one cook is enough.

2 · The mechanismWhat each one is made of

The loop

An agent loop fits in one line: read the state of the work, take one action, check the result, repeat until the check passes. One context holds the goal, the history and the judgement.

A loop: read the state, act, check, and repeat in the same context until the check passes. Read the state files, errors, the goal Act one edit, one command Check run it, read the result Done PASS NOT YET: SAME CONTEXT, NEXT TURN
Figure 1. The loop. Its whole state lives in one conversation.

It is the right tool when one context can hold the whole task and a wrong turn is cheap to undo. It runs out in three ways. The context fills, so early details fall out. The author grades its own work, so a confident mistake passes. And if the session dies, the state dies with it.

The graph

A graph breaks the work into nodes and says, in writing, what passes between them.

Node
One nameable job with a stated input, a structured output, and a named way to fail.
Edge
An arrow that means "this step reads what that step produced". Nothing else earns an arrow.
Fan-out
One node hands independent work to several. They can run at once because none of them reads another.
Join
Where branches meet. A strict join waits for all of them. A lenient join takes what landed and says what is missing.
Gate
A check that can say no. It sits between the work and everything downstream of it.
Back-edge
An arrow that points upstream. It is a loop inside the graph, so it needs an owner and a limit.
Ledger
One record per node per run: what happened, why, and what it wrote. It is how a failed run gets read afterwards.

Choosing

AskLoopGraph
Who holds the task?One context holds all of it.No single context can, or should.
What does a mistake cost?Little. You run it again.A lot, or the author cannot see it.
Who checks the work?The context that made it.A context that did not write it.
Can parts run at once?No. Each step needs the last.Yes. Branches do not read each other.
What if it is interrupted?Start over.The record says where it stopped.
What do you pay?Almost nothing to set up.Contracts, joins and gates to design and keep true.

3 · A small exampleThe arrow audit

Most pipelines are written as a line, because code runs top to bottom. That makes every step look as if it depends on the one before it. The audit is one test, applied to each arrow in turn.

An edge is real only if the next step reads what the previous step produced. Sequence is not dependency.

The fantasy football tool on this site refreshes its data with a script of twelve steps. Written down, it was a line with eleven arrows. Checked against the source, six of the eleven failed the test. The real shape was four levels deep.

The twelve steps drawn by what each one reads: six fetches, then a snapshot and a board, then three derived layers, then one explanation layer. LEVEL 1 · SIX FETCHES LEVEL 2 LEVEL 3 LEVEL 4 Draft rankings Projections Player prop lines Game lines Player list Finished weeks Daily snapshottakes what landed The boardgated before it writes Movers Projections, vendor 2 Projections, vendor 1 Explanationsbuilt last
Figure 2. The same twelve steps, drawn by what each one reads. Six fetches never look at each other. One of them feeds nothing downstream at all.

What landed afterwards was smaller than the drawing. Each of the twelve steps now writes one record to a ledger for the run, and each derived file names the inputs it read and the day of each one. The steps still run in a line. The whole run takes about two minutes, so speed was never the argument. The gain was that "which layer is stale, and why" became something you look up.

4 · A real one, stop by stopReading a delivery graph

This is a working diagram for how projects on this site get built across three AI subscriptions. It is a good graph to learn on because it has almost every part from section 2, and because it contains loops. Step through it, or tap any box.

SUBSCRIPTION DELIVERY SYSTEM Opus leads · Grok executes and challenges · ChatGPT by agent preference 01 · CLAUDE SUBSCRIPTION · $100/mo Primary pool · approximately 70% of work 02 · SUPERGROK PLUS · $100/mo Second pool · approximately 25% of work 03 · CHATGPT SUBSCRIPTION · $20/mo Optional pool · approximately 5% of work REQUIRED PROJECT DELIVERY · Opus owns the whole; workers own bounded changes Continuous security Backend Frontend Verification CALLABLE LEVERAGE LOOP · only on explicit request · 5-10× is a target to test You Outcome · constraints · acceptance criteria CURRENT SUBSCRIPTIONS · $220 / MONTH Claude $100  /  SuperGrok Plus $100  /  ChatGPT $20 Suggested work allocation: 70% / 25% / 5% Allocation is flexible; subscription spend is fixed. OPUS 5.5 Primary driver and final integrator Product judgment · architecture · risk Owns plan, routing and acceptance One brief · one accountable driver Sonnet 5.5 Bounded implementation · UI polish Tests · fixes · documentation Medium by default; raise for difficulty Keep context-sensitive work here SUPERGROK Default second execution lane Underlying model selected by service Services · migrations · test coverage Research and independent challenge Default external delegation AGENT-PREFERRED SPECIALIST GPT-6.1 Sol / Astra when available Use the model exposed by the account Debugging · alternate solution · tooling Only when the agent prefers it SHARED WORK CONTRACT Task · file ownership · interface · acceptance checks · budget Workers return changes + commands + results + unresolved risks Grok Bot · available frontier model Delegated app and site operations Research · recurring maintenance Within the assigned task scope When persistent work fits Small, bounded work packet Return patch, findings and evidence No mandatory invocation or quota Threat model and risk decisions Opus 5.5 API and data contracts Opus 5.5 UX and interface implementation Sonnet 5.5 · Opus for hard design Acceptance cases and edge cases SuperGrok · critique the plan Auth, privacy and dependency review SuperGrok · independent challenge Remediation and regression tests Assigned worker · Opus resolves risk OPUS 5.5 · INTEGRATION AND ACCEPTANCE Resolve cross-stream contracts · review evidence · verify the outcome High for difficult work; highest effort only for unresolved hard decisions Services, migrations and tests SuperGrok first · Sonnet as needed Reliability and observability SuperGrok Components and integration Sonnet 5.5 / SuperGrok Accessibility, performance, visual QA Independent worker + browser checks Tests · types · build · scans · E2E Run tools; capture actual results Independent review of changes Cross-provider when useful ChatGPT only by agent preference Mechanical gates pass? Unresolved product, architecture or risk exception? Yes Return BLOCK to owner Reproduce · repair · rerun No User decision packet Evidence · tradeoff · recommendation Yes SHIP User approval None Bounded rework Decision back to driver Invoke leverage loop Opus owns the program 1 · Baseline Measure current system 2 · Target + audit One metric · dominant bottleneck 3 · Redesign hypothesis Opus proposes · Grok challenges 4 · Bounded rebuild Same delivery streams and gates 5 · Benchmark Compare with the baseline Target achieved? Evidence-backed upgrade User approval before ship Yes Two hypotheses attempted? No No · revise hypothesis Stop and present decision packet Baseline · attempts · evidence · options Yes ROUTING POLICY Keep critical decisions and final integration with Opus. Send independent, well-scoped work to Grok. Use ChatGPT only for a concrete capability, tool fit or alternate perspective the agent prefers. At limits: checkpoint and redistribute eligible work; preserve Opus capacity for integration. Rebalance by accepted output, rework and remaining limits, not by matching subscription dollars. MODEL / SERVICE SNAPSHOT · 07 OCT 2026 Claude Opus 5.5 · Sonnet 5.5 · SuperGrok (model-agnostic) · ChatGPT available models. Use subscription-supported surfaces. API billing and unattended cross-provider routing are not assumed.

  1. The whole graph

    Read it top to bottom: a person, a driver, three pools of workers, one contract, four streams, one join, two gates, and a loop that sits apart at the bottom.

    Solid arrows are always taken. Dashed arrows and dashed boxes are optional. Diamonds are decisions. A box drawn around other boxes is a pool or a stream. The heavier outlines are the driver's own nodes.

  2. One brief, one driver

    The graph starts with a person, not a model. You hand over an outcome, constraints and acceptance criteria once, to one accountable driver (Opus 5.5 in this snapshot). Everything downstream traces back to that brief, and there is exactly one place to ask why something was done.

    The box beside it is a note, not a step: three subscriptions, a fixed monthly spend, and a suggested split of the work.

  3. Three pools, one router

    The driver fans work out to three pools. Claude takes most of it and keeps anything that depends on context the driver already holds. SuperGrok is the default outside lane for well-scoped work and for an independent challenge, with Grok Bot under it for work that persists.

    The dashed lane is ChatGPT: a path the driver may take when it wants a specific capability. Its box says so in plain words: no mandatory invocation or quota.

  4. The shared work contract

    Every lane, whoever runs it, meets at the same contract. It states the task, which files the worker owns, the interface it must keep, the checks it must pass and the budget. It also states what comes back: the changes, the commands that were run, their results, and the risks left open.

    This is the node contract from section 2 made into one box. It is why a worker on another vendor's model can be handed a slice of the job without being handed the whole conversation.

  5. Four streams, side by side

    Under the contract the work splits into security, backend, frontend and verification. No arrow crosses from one stream to another, so all four can start at once. Inside each stream the three steps are a short chain, and those arrows are real: the review reads the threat model, the fix reads the review.

    The header says who owns what: Opus owns the whole, workers own bounded changes.

  6. Checked by someone else

    Look at verification on its own. Adjacent steps change hands all over this graph: the driver writes the threat model and a different model challenges it, and here a different model writes the acceptance cases and critiques the driver's plan. The middle box says to run the tools and capture actual results, which rules out reporting that tests pass without running them. The last review crosses providers when that is useful.

    Run the arrow audit on the drawing itself and it finds something. Acceptance cases can be written from the contract alone, but running the tests means reading what backend and frontend built, and no arrow shows that. The dependency is real. On this graph it is paid at the join.

  7. The join

    Four streams converge on one node, and it is a strict join: integration needs all four. This is where contracts between streams get resolved, such as the frontend's idea of the API against the backend's, and where the evidence is reviewed.

    Notice what the driver is doing here. It is not rewriting the work. It is reading results against the brief.

  8. Gate one: the machines decide

    Do the mechanical gates pass? If not, the work goes back to the owner of the failing piece with a BLOCK: reproduce, repair, rerun. Follow the arrow up the right-hand side. It returns to the contract.

    That arrow is a loop. It is safe because it is bounded rework: it goes back in through the contract, with an owner and a scope, and not through an open-ended "try again".

  9. Gate two: a person decides

    Passing every test is not the same as being right. The second gate asks whether anything is left that a machine should not settle: a product call, an architecture call, a risk.

    If so, the user gets a decision packet (evidence, tradeoff, recommendation) and the answer travels all the way back up to the driver. If nothing is open the work ships, and the ship box still says user approval.

  10. A loop you call on purpose

    The box at the bottom is a loop, drawn as one: measure a baseline, pick one metric and the dominant bottleneck, propose a redesign (one model proposes, another challenges), rebuild through the same streams and gates, benchmark against the baseline.

    If the target is missed, revise and go again, but only until two hypotheses have been tried. Then it stops and presents a decision packet. The header is careful twice over: the loop runs only on explicit request, and its multiplier is a target to test, not a result.

  11. The fine print

    The footer holds the routing policy that arrows cannot show. Critical decisions and final integration stay with the driver. Independent, well-scoped work goes out. Near a usage limit, checkpoint and move the eligible work, and save the driver's capacity for integration.

    The split is rebalanced by accepted output and rework, not by trying to get equal value out of each subscription.

Figure 3. The delivery graph as drawn, re-inked to match this card: 36 working boxes, 42 arrows, 4 decisions. Snapshot 7 October 2026; model names and prices are of that date. Open the full drawing.

Three arrows point backwards

Count them: rework back to the contract, a decision back to the driver, and the revise arrow inside the leverage loop. Each one names who owns the next pass and what ends it: an owner and a rerun, a person's answer, a limit of two attempts.

That is the relationship between the two ideas on this card. The graph does not replace the loop. Every node here is still a model working in a loop. The graph decides where a loop may run again, and what stops it.

5 · What most people get wrongSix traps

  1. Treating order as dependency. A script looks like a chain because code runs top to bottom. Audit the arrows before you believe the shape.
  2. Drawing the graph first. A graph costs contracts, joins and gates. If one context can hold the job and a mistake is cheap, the loop is the better engineering. Start there, and draw the graph when the dependencies force it.
  3. Running things at once for speed. On the script in section 3, running the six fetches together would save about a minute of a two-minute run. What was worth having was the record. The usual case for a graph is that you can read it and resume it, not that it is fast.
  4. Letting the author grade the work. A check belongs between the work and everything downstream, and it has to be a different context. Written, approved and published by one context is one opinion counted three times.
  5. A back-edge with no limit. "Retry until it passes" is an endless loop with good intentions. Give each one an owner, a bound and an exit, like the three on the graph above.
  6. Trusting the graph's own suggestions. The audit in section 3 found the real shape, and it also produced three fixes that were wrong. One added a gate after a step that already refuses to write when its checks fail. One skipped a rebuild when a vendor was down, where rebuilding on yesterday's data and saying so on the page was the deliberate design. One skipped any step that had already succeeded that day, which sounds free: the script runs twice a day into the same dated folder, so it would have quietly kept the morning's numbers all evening. The method finds real gaps and also invents fixes for problems the code already solved. Check each one against the source.

6 · Check yourselfThree questions

RecallWhat makes an arrow between two steps real?
Show the answer

Reading is the test. Order is an accident of how code is written, and dependency is about data. If step two would produce the same output with step one deleted, there is no arrow between them.

Apply itYou need 2,000 practice questions written from a list of facts, each checked for accuracy before it is published. Loop or graph?
Show the answer

Graph. No question reads another, so the work is parallel, and it needs a checker that is not the author. Those are two of the three reasons on this card. The question bank on this site was built that way: authors, an independent review, then a second pass whose only job was to find faults.

What would breakOn the delivery graph, delete the "Two hypotheses attempted?" diamond from the leverage loop. What breaks?
Show the answer

With the diamond gone, a missed target has one way out: revise and go again. A target that cannot be reached would keep the loop running and spending, with no point at which a person is asked. The diamond is the bound.

SourcesWhere this comes from

More Force Multipliers
Obsidian ReaderAnkiThe whole set
Field notes, not doctrine. Check the linked sources before you rely on them.Written with Claude Opus 5.5 · All Force Multipliers