⚖️ Agentic × Loop × Graph

The layer everyone knows: the instruction you write for the model. It’s where most people start—and where most people get stuck.

Because almost every problem of “the AI didn’t do what I wanted” is addressed by trying to improve the prompt, even when the flaw is in a higher layer.

Prompt is the cheapest layer to change and the most limited. On its own, it never solves what requires memory, tools, or repetition.

Files, history, documentation—everything that enters the context window before the model decides what to do next.

Wrong context leads to wrong decisions, even with a perfect prompt. Too much context clogs the window and degrades the model’s attention.

The context window is a finite resource. What clogs it — raw logs, old drafts, past reasoning — is this layer's silent enemy.

The infrastructure around the model: available tools, permissions, output capture, retries, token budget.

The harness sets the agent’s capability ceiling. A brilliant model without the right tool can’t execute anything—it can only describe what it would do.

The harness is the boundary between “the model thought” and “the model acted.” It’s where permissions, security, and cost come into play.

How many times the agent tries and how it knows it’s done. That’s all of Track 2, summed up in one sentence.

Without a loop, each attempt is isolated—there’s no correction. With a loop, the system can make a mistake, measure, and try again.

The loop needs a verifier and a stopping condition. Without both, it isn’t a loop—it’s blind repetition.

A set of loops connected by explicit edges — the layer that only makes sense after mastering the previous four.

Moving up to the graph without a solid loop underneath just multiplies the problem: now you have several bad loops talking to each other.

A graph doesn’t replace the layers below it—it organizes them. Each node in the graph still needs its own prompt, context, harness, and loop.

The loop harness fits in a script: input, context, budget, retry, output. The graph harness looks more like a distributed runtime: message routing between nodes, isolating node failures, state consistency, dynamic node creation, and observability into who ran, when, and with what latency.

And that’s why frameworks gain traction when the conversation shifts from loops to graphs — the infrastructure problem changes category, not just size.

It's not “more loops”; it's a distributed systems problem. Partial failure, shared state, and observability become mandatory, not optional.

You describe the goal and provide tools, and the model decides what to do. No drawn-out cycle or explicit output test.

And the most common starting point and the fastest to set up — and also the hardest to predict or debug when something goes wrong.

The model’s judgment replaces structure you designed. It works well on short tasks; it degrades on long or repeated tasks.

You stop writing prompts and start designing the cycle and stopping condition — discover, plan, act, verify, stop.

And the cheapest quality improvement there is: the same model, with a designed cycle, makes fewer mistakes and converges faster.

The verifier becomes the quality ceiling — the entire topic of Track 2. Here it reappears only as a component of the comparison.

Several nodes, each with its own loop, with the path between them written down before running—not inferred by the model in real time.

And the only one of the three formats that allows true parallelism and separate contexts by role. It’s also the most expensive to maintain.

Explicit edges are the key difference: control flow becomes something you can read in a diagram, not something you reconstruct from a transcript.

As a single loop, one agent does everything in one window, reads the sources one by one, and reviews its own text in the same context (rubber-stamps it). As a graph: researcher (opens N sources in parallel) → writer (only the notes, clean context) → reviewer (fresh context, sees only the text and criteria, and has a "rejected" edge back).

Looking at the same case in all three formats is the only way to compare without rhetoric—the numbers and failures are visible side by side.

Fan-out (parallel researcher) and clean context per role (the writer only sees notes; the reviewer only sees the text and criteria) are the two differences that really matter.

Specialized parallel nodes with clean, separate contexts; fan-out and fan-in as first-class operations; control flow that's readable as a diagram instead of reconstructed from a transcript.

These are the three benefits that a loop, no matter how well written, cannot reproduce — because a loop is sequential by definition.

None of these benefits are just rhetoric: each addresses a specific structural failure of the single loop seen in Track 2.

Three prompts to maintain instead of one; a state schema between nodes (what exactly does the researcher hand off to the writer?); and new failure modes—a merge that swallows a source, routing that keeps going back and forth, state that leaks from one node to another.

For a task that runs every day, it’s worth it; for a task that runs once, it’s pure overhead. Knowing this helps you avoid adopting graphs just because they’re trendy.

The degenerate case: a graph with ONE node and all the tools is a reinvented loop—the structure isn’t doing anything.

Loops did not die: they became the nodes in the graph. You do not graduate from loops to graphs; you compose loops into graphs when a loop is no longer enough.

This myth makes people dismiss loops before mastering them—and poorly mastered loops underneath guarantee a bad graph on top.

Composition, not replacement. Every graph node, when opened, is a loop with its own verifier and stopping condition.

One is an INFORMATION graph that the agent consults; the other is an EXECUTION graph, showing what runs and in what order. The industry mixes them up all the time.

Confusing the two makes you buy the wrong tool for the problem you have — GraphRAG doesn't orchestrate agents, and vice versa.

A knowledge graph answers “what do I know?” An execution graph answers “who does what, in what order?” They’re two different graphs with the same marketing name.

DSPy optimizes language model programs — prompts and parameters — not knowledge graphs. This is a common misattribution in discussions about graph engineering.

Repeating the wrong attribution makes you reach for DSPy to solve a problem it can't solve, and ignore the tools that would.

DSPy = program optimization. Don’t confuse it with graph storage or querying — they’re different tool categories.

Anthropic didn’t announce any discipline called graph engineering — it uses orchestration written in code, which is different from launching a methodology by that name.

Citing "Anthropic launched graph engineering" as an authoritative source is a specific factual error that circulates a lot — it's good to know how to point it out.

Orchestrating agents with code (graphs, queues, routing) is a long-standing engineering practice. The label "graph engineering" is recent; the practice is not.

They came from a specific study on industrial diagrams, not a general agent benchmark. Repeating this as if it applied to any system is dishonest.

It’s the clearest example of a marketing number floating around without context — useful for recognizing the pattern in any other stray number that comes up.

Always ask: benchmark for what task, compared against what baseline, measured by whom. Without that, the number is just noise that looks like data.

State machines, XState, graph orchestration in LangGraph, AutoGen, and Google ADK predate the term. What is new in 2026 is the VOCABULARY.

Judge the pattern, not the label. That’s the practical takeaway: most agents still don’t need a graph — many tasks are still just one model, a tool cycle, and a good stopping condition.

A finite-state machine is the direct ancestor. Renaming it does not make the idea new — but it does not make the idea useless either.