Context

Over the summer, "loops" and "graphs" became the buzzy topics among advanced AI users, but they stayed abstract for anyone outside software engineering. This episode is a webinar where Nufar Gaspar (who runs Super Intelligent's agent training programs) and host NLW translate those ideas into plain knowledge-work terms. The core shift they describe: stop thinking of AI as something you prompt once, and start setting up an agent to run on its own until it meets a goal it can verify itself against. For a PM, this is directly about how you get real work out of AI tools, how you decide which tasks are worth automating this way, and how you avoid burning a fortune in tokens doing it badly.

The Big Idea

Once every model is already state-of-the-art, the leverage moves from writing better prompts to designing better finish lines. A "loop" runs an agent over and over until it hits a goal you can mechanically check, and a "graph" composes several such agents into a workflow. The one skill that unlocks both is defining a done condition specific enough that the machine can grade itself.

Coders got this for free because code either compiles or it doesn't. Knowledge workers have to manufacture that referee themselves, and the episode is mostly about how to do that without overcomplicating it.

Key Insights

Every agent tool already runs a loop

Any agentic tool you use (Claude Code, Cursor, codex, co-work, GPT work) already runs a loop under the hood: it plans, acts with tools, checks whether the result is good enough, and adjusts. The catch is that this built-in loop is generic and often stops too early, which is why you find yourself nudging it or re-prompting to make it work harder. The "advanced loop" the episode teaches is you taking control of the end goal, usually through a dedicated command (/goal in Claude Code, the loop command in Cursor), so the tool keeps iterating against a target you set instead of quitting at its own default bar.

A loop answers "until," not "when"

• Loop: stops when the work meets a bar you defined, however long that takes.
• Schedule or automation: answers when something runs (a clock time, or a trigger like an incoming email).
• Why it matters: these are different promises, and treating a loop like a scheduled job is a category error. A loop is about persistence toward a quality target, not timing.

Knowledge work has no free referee

Coders can loop easily because verification is abundant: the code compiles or it fails, the tests pass or they don't. Most knowledge work has no built-in compiler to answer "is this report good enough for management?" or "is this analysis deep enough?" So when someone says "just put it on a loop," they are forgetting they had free verification and you don't. The central move of the whole talk: you can design that verification yourself. If you cannot design a clear, checkable finish, the correct answer is to not loop the task at all.

What makes a task loop-worthy

A task earns a loop only when several things are true together, and Gaspar is explicit that most work should stay as a single normal agent run:

• Long-running: a single strong-model prompt won't get you there. If one shot works, use one shot.
• Checkable progress: you can verify whether output is good enough or headed the right way. This pairs with the point above and is the most important pair.
• Worth sending away: you want to hand it off, do something else, and come back to a finished result instead of a draft.
• Already failed one-shot: you tried it with a smart model (Fable, a strong GPT) and it didn't clear the bar.
• Has a "draft then improve" shape: more iterations genuinely make it better, like deep research getting more complete.

A loop is just a one-node graph

A graph is only "dots and arrows": nodes are agents or tasks, edges are the work or information flowing between them. A single node with an arrow pointing back to itself is the textbook definition of a loop, so a loop and a graph are not different things. The loop is the smallest possible graph. The real question, Gaspar says, "was always how many nodes does your work deserve." Computer science has drawn work this way for 50 years; what is new is that AI made the drawing actually runnable, because a node used to be one fragile model call and is now a whole reliable agent.

Fan out to more agents only on signals

Adding more agents is not automatically better, and the episode gives concrete triggers for when a single agent or loop is no longer enough:

• Rubber stamp: the agent says "done, all checks pass" but you keep finding issues it should have caught.
• Unreliable self-review: a model tends to agree with itself, so GPT verifying GPT will usually pass its own work, where Claude verifying GPT is more objective.
• Context overflow: one agent wearing too many hats (objective researcher and creative designer) starts bleeding one role into another.
• Parallelizable work: independent sub-tasks (research vendors, practitioners, and benchmarks separately) can run at once instead of making you wait.
• Shifting finish line: you keep rewriting the goal mid-run because it is secretly two jobs on one card.
• Quality flatlines early: no matter how you tune it, output plateaus, which often means it needs a second perspective.

Design graphs for agents, not humans

A common mistake is to copy exactly how humans do the work today into the agent graph. Human workflows are shaped by human limits: attention span, bandwidth, the fact that one person can't be expert at many things. Those are mostly not the agent's limits. Agents get tired and confused far less, and can run many things in parallel, so mirroring the human handoff structure leaves value on the table. Designing a good graph takes "radical thinking" about the actual job to be done, not the current human process for doing it.

Mental Models & Frameworks

The four-stage agent progression

The field moves left to right, and you only advance when the current stage stops doing the job:

• One agent, one pass: a normal single task. Where most work should stay.
• One agent, looped: the same worker running until a verifiable goal is met.
• Work graph: several agents each doing a piece, passing results along, built for one job.
• Org graph: those agents become a standing, reusable team.

The point is not to climb to stage four. Many tasks are perfectly served at stage one, and you move up only when the quality or scale genuinely requires it.

The goal card

The way you define a loop's target. You configure these and append them to the loop command:

• Objective: concrete and machine-readable (for example, "a definitive token-efficiency playbook as of August 2026").
• Output: what the loop produces, often a file. This is what defines the judging and stopping criteria.
• Stopping criteria: the checkable bar, for example "200+ unique data points, each with a URL, date, and type; at least 40 vendor docs, 40 practitioner sources, 20 benchmarks; zero duplicates."
• Stages (optional): specific gates or steps, only when you want to constrain the path rather than leave the agent judgment.
• Fail-safe caps: hard limits so it can't run forever, for example "try up to 30 turns, sandbox only," plus optional time and tool caps.

Three tests for a loopable task

Before looping anything, check all three:

• Checkable finish line: "boring is a compliment." "200 verified data points" or "summary under 150 words" is boring and machine-checkable; "make it insightful" is not, because the agent can never decide it's done.
• Bounded sandbox: run it where mistakes are cheap (a draft, an experiment), not against your highest-stakes live surface.
• Can converge: each pass measurably gets closer to done. Research converges (more sources, fewer gaps); a vague, open-ended goal loops forever asking itself "good enough? not sure, try again."

The prompt-to-graph evolution

A single arc explains all the jargon: prompt engineering (what you say to the model), context engineering (what it knows), harness engineering (where it runs and what tools it touches), loop engineering (how long it runs on its own), and graph engineering (how many agents work together). Every step hands the AI more independence at a bigger scale. The names churn every few months; the durable skill underneath is getting agents to work effectively and orchestrating them, which survives each rebrand.

Six habits of cheap orchestration

What separates an effective graph from an expensive one:

• Match the model to the node: cheap and fast models for mechanical steps and yes/no verdicts, strong models where real judgment is needed.
• Give each node only its context: what passes between nodes is a contract (a draft, a rubric, findings in a format), never the whole conversation.
• Spend where verification pays: fanning out costs tokens; summarize between nodes and cap turns per node so a pretty graph doesn't quietly burn millions of tokens.
• Verify early: add verification nodes and boundaries up front, because mistakes compound and get expensive deeper in the graph.
• Human at the right gate: deliberately place a person where it matters, whether approving the plan early or signing off at the end.

Decision Principles

Principle: One-shot before you loop

• When: you're about to set up a loop for a task.
• Why: loops are among the most token-hungry things you can run. If a single prompt to a strong model gets a good-enough result, that is the smart call, not a cop-out. Reserve loops for work where the extra iteration genuinely buys quality.

Principle: No checkable finish, no loop

• When: you can't define a clear, non-ambiguous "done when" condition for a task.
• Why: without a boring, machine-checkable finish line the loop will run too short or forever, and the output can technically "finish" while being useless. If your judgment is the actual work and can't be handed to a referee, a normal conversation with the agent is the right tool.

Principle: Graph only when one agent stalls

• When: a single agent or loop keeps rubber-stamping bad work, overflows its context, or plateaus in quality.
• Why: more nodes add coordination and token cost, so composing multiple agents should be a response to a real failure of the single agent, not a default. Keep it simple until simplicity stops working.

Common Mistakes

Mistake: Letting a loop run away

The most common failure is runaway spend: the loop just keeps going. This is exactly why a hard turn cap (or time cap) is critical, not optional. People routinely leave loops running far longer than intended because they skipped the fail-safe.

Mistake: Looping something non-convergent

A loop can stack cycles without making progress because the task can't converge or the conditions aren't right. It keeps asking "good enough? not sure, try again" indefinitely. The fix is to stop it manually (tools have stop commands) or, better, to recognize up front that the task doesn't converge and not loop it.

Mistake: Blaming the loop for a bland result

Sometimes a loop finishes and the output is mediocre. It met the letter of your finish line but the result is bland. This is not a loop failure, it is a failure of your goal definition. If it hit exactly the criteria you set and you're still unhappy, the finish line or referee guidelines were too weak, usually around quality and taste that are harder to specify.

Mistake: Same model grading itself

Using one model to verify its own output is unreliable, because models tend to agree with themselves. If correctness matters, route verification to a different model (Claude checking GPT, not GPT checking GPT) or a human, ideally with fresh context that knows nothing about how the work was produced.

Practical Application

Write a goal card first

Before your next long AI task, write the objective, the exact output, and a "boring" checkable stopping condition (a specific count, a required source mix, a length limit, a citation rule). If you can't write a condition the tool could grade itself against, that's your signal the task shouldn't be a loop at all.

Always cap every loop

• Do: append a hard turn cap and, where relevant, a time cap and "sandbox only" constraint to every loop you start.
• Why it works: it's the direct guard against runaway spend and against a non-convergent task looping forever. Treat it as mandatory, not a nice-to-have.

Add a fresh-context verifier node

Hand the finished output to a separate verifier, ideally a different model, with fresh context that knows nothing about how it was made, and give it a concrete check (for example, "sample 10 data points, confirm each against its real URL, then report the totals and source mix"). This catches the rubber-stamp problem that same-model self-review misses.

Sketch the work as a graph

Draw the task as dots and arrows on a whiteboard before automating it. The act of drawing forces you to confront every step that isn't well defined, and in many orgs a lot is undefined. Once you can draw it, you can literally photograph the sketch, hand it to an agent tool, and have it build the workflow.

Questions to Consider

• Which recurring task of mine actually has a "boring," machine-checkable finish line (a count, a length, a citation rule), and which ones am I only imagining I could automate because I can't define done?
• Where am I nudging an AI tool repeatedly to work harder, when I should instead be setting a controlled loop with an explicit end goal?
• For my highest-stakes AI output, am I letting the same model grade its own work, and where could a different-model or human verifier catch what it rubber-stamps?
• When I design an AI workflow, am I copying how my team hands work between people today, even though the agent doesn't share the human limits (attention, bandwidth, one-thing-at-a-time) that shaped that process?

Bottom Line

The advanced skill in this era is not prompting, it's defining a finish line an agent can check itself against, then choosing the simplest structure that meets it: one pass, a capped loop, or a graph of agents. Design that "boring" done condition well, cap the spend, verify with a fresh set of eyes, and reserve multi-agent graphs for when a single agent genuinely stops delivering.

Tools & Products

Notable Quotes

"A loop is basically a job and a graph is an organization." (Nufar Gaspar)

"The org chart is the diagram of the authority. It's not and never was a diagram of how work gets done." (Nufar Gaspar)

"There are no experts at this. They're just people who have done it more." (NLW)