Agentic Loops for Knowledge Workers

Special episode: Hour-long practical webinar with Nufar Gaspar.

MAIN STORY

Agentic Loops and Graphs for Knowledge Workers

One of the hot topics among advanced AI users all summer has been loops — the shift from prompting an AI and telling it what to do, to setting up conditions where an agent can run over and over against a measurable goal until the job is actually done. Loops took hold in software engineering first, because the tasks are definable and success is clear, and the entire practice has stayed stuck there. Today's episode is a full webinar with Nufar Gaspar on moving loops and graphs into knowledge work, where success is fuzzier and the finish line has to be built by hand. A loop is a job; a graph is an organization.

The Naming Ladder
Prompt, context, harness, loop, graph — each hands over more
First everyone obsessed over what you say to the model, which was prompt engineering. Then over what the model knows, which was context engineering. Then over where it runs and what tools it can touch, which became harness engineering. This year the question became how long agents can run on their own — loop engineering — and now how many of them work together, which is graph engineering. Every step hands the AI more independence at a bigger scale, and while some of this is rebranding a natural evolution, chasing each new term every couple of months is exhausting. The skill that survives every rename is knowing how to get agents to work effectively and how to orchestrate them.

Six Words, and an Obituary
"We're no longer talking about loops, we're talking about graphs"
The whole thing kicked off in July with six words from OpenClaw's founder, which did millions of views almost immediately and was followed just as quickly by an obituary for loop engineering. That is primarily a naming event, but the joke stuck because it pointed at something real. A more substantive data point landed three weeks ago: Jeff Dean, arguably the most renowned engineer in the history of modern technology, left Google to start a company literally called Discovery Loop. There is genuine merit to running AI in loops to get progressively better results — and science, where more experiments eventually converge on the right direction, is exactly the shape that rewards it.

Every Tool Is Already a Loop
Plan, act, check, adjust — that's what the harness is doing
Whatever agentic tool you use — Cowork, ChatGPT Work, Codex, Cursor — what's implemented under the hood is already a loop: an iterative cycle of planning how to get the job done, acting via tools, checking whether the results are good enough, and adjusting. The catch is that those built-in loops are only as good as what the vendor implemented, and they are deliberately generic. That's why even with excellent tools you find yourself nudging, or prompting unusually hard to get an agent to work another iteration before it stops.

The Loop You Control
A schedule answers when. A loop answers until.
The advanced loop is the one where you extend the native cycle and own the end goal — /goal in Claude Code, a literal loop command in Cursor. The entire purpose is to hand the tool a concrete end goal that is highly verifiable, plus a way to progressively test itself against it. Which makes the important distinction not loop versus prompt but loop versus automation: a schedule answers when something runs, off the clock or off a trigger like an inbound email, while a loop stops when the work meets the bar, however long that takes. Those are profoundly different promises, and confusing them is the most common mistake.

Coding Got Verification for Free
Nobody's compiler tells you the report is good enough
Coding has a superpower most knowledge work doesn't: verification is abundant. The code compiles or it doesn't; the tests pass or they fail. Is this report good enough to present to management, is this analysis deep enough — no compiler answers that. So when someone says just put it on a loop, they're forgetting they had free verification and you don't. The central move of the whole discipline is that verification for knowledge work can be designed: you manufacture the referee that decides whether the job is done. And if you can't design a finish line that's clear and verifiable, don't loop it.

What Deserves a Loop
Long-running, checkable, and it failed your one-shot already
A loop-worthy task is long-running — not something one prompt handles, and with modern models one shot is often plenty, so use it when you can. It has to pair with the ability to check whether results are good enough or headed the right way; that pair is the whole thing. Good indicators: you want to send it off over lunch or overnight and come back to a finished result rather than a draft; it should run until a bar is met or keep watching indefinitely; you already tried it one-shot with Fable or the smartest GPT and it wasn't good enough; you need the model to work harder than one polite pass; and it has a natural retry-and-improve shape. If the task is short, or your judgment is the actual work and can't be offloaded to a referee, a normal conversation with your agent is the right call — and choosing that is the smart move, not the cop-out.

What People Actually Loop
Autonomy does not have a taste of its own
Research is the flagship case: send the agent deep and wide and make it keep going until the sourcing is actually there. Ad and campaign optimization is the highly verifiable version, because click-through and other analytics give you hard data to iterate against, either indefinitely or with a cap on attempts. Competitive analysis, content audits, verifying results and compliance scans all qualify. What doesn't: anything that requires human judgment and can't be fully automated — executive communications, hiring, strategy. Also worth remembering that loops are among the most token-hungry executions you can run, so spend them where the value is.

Boring Is a Compliment
"Make it insightful" is not something an agent can converge on
Knowledge work succeeds on a loop exactly when you invent a very boring, very checkable finish line. Two hundred verified data points. Every competitor covered. Every claim cited. Summary under a hundred and fifty words. Boring, concrete, machine-checkable — and there's an equivalent in every domain. Two other requirements sit alongside it: a bounded sandbox where mistakes are cheap, which is why you don't turn a loop loose on your highest-stakes live campaign, and a task that can actually converge. Without convergence the agent just asks itself is it good enough, doesn't know, and tries again, forever.

The Goal Card
Objective, artifact, stopping criteria, fail-safes
Think of configuring a loop as designing a goal card, and append it after the loop command. Start with a concrete, machine-readable objective — create the definitive token efficiency playbook as of August 2026. Define the output; in the demo it's a file. Then the stopping criteria, which is what makes or breaks everything: at least two hundred unique data points, each with URL, date and type, a specific mix of forty vendor docs, forty practitioner sources and twenty benchmarks, zero duplicates. Stages are optional, and often worth leaving out so the agent keeps judgment over how to hit the bar. What isn't optional is the fail-safe — cap it at thirty turns, cap it by time, restrict it to the sandbox — because there may not be two hundred data points out there, and without a second stopping mechanism it will run forever. Asking the model to log its cycle number out loud is also a very good habit, especially while you're new to this.

The Demo
Some irony in burning tokens to research token efficiency
The worked example is that token efficiency research, run with /goal in Claude Code on Opus in auto mode. The log shows cycle one checking the workspace, cycle two landing at 56 of 200, cycle three at 90, and the run finishing in around eight cycles — actually overshooting the target, and in other executions going all the way to 300, which is a reminder the discipline isn't perfect and the thirty-cycle cap is doing real work. The output is a full playbook artifact with an executive summary and a large body of data points on using tokens better.

Four Ways Loops Fail
Met the letter of your finish line, still bland
Runaway spend is the first: it just keeps going, which is what the hard cap exists for, and people run loops far longer than they intended all the time. Second, it gets stuck — cycling without progress because the conditions aren't there — and the answer is stopping it manually or telling it upfront to stop and report. Third, and the sneakiest, it finishes and the result is mediocre. That is not a loop failure; if it met your goals verbatim and you're unhappy, your goal definition was wrong, usually around quality and taste. And fourth, sometimes the task was never a loop in the first place, in which case the turn cap is your best friend.

Four Stations
One agent, one loop, a work graph, an org graph
The progression runs from a single agent doing one pass, to a single agent on a loop, to the work itself splitting across several agents each doing one piece and passing work between them — a work graph, built for one job — to those agents becoming a standing team, an org graph. There's no graduation ceremony here, and plenty of tasks never leave station one. But in some cases the quality and scale only unlock at the far end, so move when there's justification rather than because the fourth station exists.

Dots and Arrows
A node pointing back at itself is the textbook definition of a loop
A graph is dots and arrows. The dots are nodes, and for knowledge work a node is an agent or a task. The arrows are edges, and they carry work and information; when they have a direction — research flowing into the writing agent — the graph is directed. Which means loops and graphs were never different things: one node with an arrow pointing back to itself is a loop, the smallest possible graph. The real question is and always was how many nodes your work deserves. Computer science has drawn work this way for fifty years; what's new is that AI made the drawing operational, so you can sketch it and it actually runs.

Three Graphs, One Word
Knowledge graph, LangGraph, work graph — not the same thing
The same week this trended, half of X and LinkedIn blended three unrelated things into one word. A knowledge graph stores facts and how they connect — beautiful technology, different job. LangGraph is a developer framework for building agent systems in code, also good, also not what's being discussed. The work graph is the execution question for knowledge work: who does what, in what order, and what flows between them.

The Org Chart Was Never the Work
Work skips levels and flows straight up at 11PM before board meetings
Every organization already has a graph, and it's the org chart — which pretends work flows in one direction, top to bottom, from the CEO down. Nobody actually believes that. Work branches, loops back, goes sideways, skips levels. The org chart is a diagram of authority and never was a diagram of how work gets done, and a graph with arrows going wherever the work actually goes is the picture you need to paint for your agents.

What Changed Is the Node
Agents got reliable enough to be building blocks
The obvious skeptic's objection is that engineers have been wiring agents into graphs for years. What changed is the node itself. It used to be one fragile model call, and orchestrating a complex graph out of those meant working very hard for very little. Today a node is a whole agent — a worker you hand a job to — and it has two gears, a quick single pass or a full loop running until done. Loops are simply your heavy duty nodes. Nothing was invented this summer; the technology got reliable and democratized enough that a graph drawn on a whiteboard actually works.

Five Signals to Fan Out
Models tend to agree with themselves
Only compose multiple agents when one worker stops doing the job. The first tell is the rubber stamp: your agent says done, everything checks out, and you keep finding issues it should have caught — self-review is unreliable for critical work, and there's substantial evidence models agree with themselves, so GPT verifying GPT is a weaker check than Claude verifying GPT. The second is context overflow, where one agent wears too many hats and starts confusing them, like an objective researcher that gets creative too early because it's also the designer. Third is serial waiting on work that could run in parallel. Fourth is the finish line moving mid-run, which usually means one goal card is hiding two different jobs. Fifth is quality flatlining despite your best efforts. If none of these apply, stay with the single agent and don't overcomplicate it.

Ways to Build a Graph
You just built a seven-node graph in one sentence. Congratulations.
There's a progressive ladder here and every rung works. Draw it — on paper, on a whiteboard — because sketching forces you to confront everything about the process that isn't well defined, and once it's drawn you can hand a photo of it to any agentic tool and have it built. Let the tool improvise, which it already does every time it announces it's spawning sub-agents to divide and conquer. Prompt the graph directly: research these five competitors in parallel with separate sub-agents, then have a fresh-context reviewer check the merged results against this rubric. Build persistent workers — sub-agent files or folder agents like a benchmark collector, a citation verifier, a report visualizer — summoned ad hoc, or wrapped in a skill that defines the phases and names which workers each phase calls, with the model choice configured per agent. Use a canvas tool like n8n if you want to see the flow visually. Or write it in code, where LangGraph will even render a diagram of what you built. It's not a competition to reach the top rung; most knowledge work lives in the middle.

Six Habits
What passes between nodes is the contract
Match the model to the node — cheap and fast for mechanical steps and yes/no verdicts, strong models where judgment lives. Give each node only the relevant context, and be deliberate about what passes between them: a draft, a rubric, findings in a format, never the whole conversation. Spend where verification pays, because a beautiful graph turns into an enormous token consumer fast, and built-in deep research can burn millions of tokens without batting an eye. Verify early and add clear boundaries, since mistakes compound expensively as the graph gets more complex. Put humans at the right gate, deliberately — approving the plan up front, signing off at the end. And don't replicate how humans do the work today, because that process is shaped by human limits on attention, bandwidth and breadth that simply don't apply to your agents; designing a good graph takes fairly radical thinking about the job to be done rather than the current process for doing it.

Knowledge Workers Have the Edge Here
A graph is a confession of how your work really flows
Loops are the more forgiving of the two, because a graph is an admission of how work really moves, who really owns what, and where quality actually gets decided. Which is exactly why knowledge workers will likely be better at this than most engineers: a career spent learning how a specific kind of work moves through an organization is now the technical skill, and injecting that subject matter expertise is what makes these systems correct. As of August 2026, the four things the best practitioners have mastered are understanding agents and the loop already running in the harness, defining concrete agentic workflows, configuring loops that run autonomously and well, and configuring teams of agents. One caveat on the commands: things move fast enough that you should web search or ask the tool itself, and not assume a command available in a CLI is available on desktop.

An MBA in Agent Management
There are no experts — just people who've done it more
What makes this moment matter is that AI skills have shifted from useful new tools to fundamental changes in work primitives. Learning Midjourney or prompting a few years ago was valuable and could get you leverage, but the way work got done hadn't fundamentally changed. Now big chunks of what we used to do are becoming things we manage agents to do instead — piecemeal, not all at once, and everyone is involved in discovering what managing agents even means. That's why loops and graphs stick where other buzzwords don't: they feel like core primitives rather than fly-by-night skills. And nobody should expect to be perfect at advanced management technique in a single session, so expect the same here. Being in the room already puts you ahead.