Context, Loop, and Graph engineering

How the layers nest

Prompt, context, loop, and graph engineering are not competing techniques. Each one wraps the one before it. A prompt is a single instruction. Add the right supporting material and you have context engineering. Put that context in a repeating decision cycle and you have a loop. Coordinate several loops as one system and you have a graph.

Because each layer sits on the one below, the higher layer is only as good as its base. Coordinating a dozen agents whose individual context is sloppy multiplies the mess, not the quality — a graph of badly-briefed nodes is just an org chart of unreliable employees. So the rule is simple: use the smallest layer that solves the task, and add the next only when the current one fails for a reason you can name.

task
 │
 ├─ finishes in one informed model pass?  ──────▶  context engineering
 │        no
 ├─ one goal, and the agent can grade itself? ──▶  loop engineering
 │        no
 └─ needs parallel work, hard gates, or an
    outside reviewer?  ─────────────────────────▶  graph engineering

Context engineering: one informed pass

Context engineering controls a single inference: of everything you could put in front of the model this turn, what belongs there? Instructions, retrieved documents, tool schemas, prior messages — chosen for high signal and low noise. Anthropic calls it the successor to prompt engineering (their guide): the work moved from asking well to supplying the right material.

It's enough when the task is a briefing. If one well-stocked pass finishes the job — hand a sales rep the account history and open tickets before a call — a single turn ends it.

The limit is that one pass can't react to its own output. When finishing the work means running something, reading the result, and trying again, a single turn has nowhere to put the retry. That's why the loop exists.

Loop engineering: one agent, many passes

A loop lets that single pass repeat. The agent plans, acts, observes the result, and goes again, carrying state between rounds. Some people file this under harness engineering, but the point is the same: one agent calls a tool, reads the result, picks a next move, and checks its own answer before it stops.

Context rot — when an agent's context window fills with its own history until quality drops and it drifts off task.

Make it concrete. Tell a coding agent to make a failing test pass. It reads the error, edits the file, re-runs the test, reads the new error, and edits again — looping until the test goes green or it runs out of road. Nobody re-prompts it between rounds; the agent steers off what it just observed. That is the whole shape: plan, act, observe, check, repeat.

The load-bearing part is the check. Without a step that grades the output against the goal, the agent ships wrong answers with full confidence; add one and a bad result triggers another pass. In the test example the check is free — the test passes or it doesn't. When the goal is fuzzier, like "summarize this contract," you have to build the check yourself: a rule, a second model reading the draft, or a schema the answer has to fit. Around the check sit the tool definitions, the retry logic, and a scope tight enough to keep the agent on task.

One loop handles most work: a single job with a clear endpoint, like summarizing a document, writing a function, or fixing that failing test. A scoped agent with a real check is cheaper and easier to debug than any multi-node system — so this is where most tasks should stop.

A loop breaks at three limits, and any one of them is the signal to move up. Its memory fills as it runs, until the model loses the thread — that's context rot. It runs sequentially, so independent subtasks wait their turn instead of running at once. And it judges its own work, so nothing external checks the result. A tighter loop won't fix these; they come from its shape.

Graph engineering: many agents, one network

1/ What a graph actually is

A graph models the system as a network of nodes and edges. A node is where work happens — a function, a single model call, or a whole agent with its own loop. Edges are the routing rules: what runs next, and how state moves between nodes.

Directed acyclic graph (DAG) — a flow where steps only move forward, never back; the shape behind schedulers like Apache Airflow.

Unlike a DAG, these graphs can circle back — retry a step, revise after a review, or pause for a human and resume. Three parts make it work: nodes, edges, and a shared state object, usually a typed record every node reads and updates. Conditional edges route the flow: a decision step, often a model call, reads the state and picks the next node. Interrupt nodes pause execution, save the state, and wait for a person to approve or supply something before the graph resumes.

The frameworks differ in flavor, not skeleton:

• LangGraph (a low-level runtime for stateful, cyclical graphs)
• LlamaIndex Workflows (event-driven)
• AutoGen (a manager steering a team, now in Microsoft's Agent Framework)
• Google's Agent Development Kit (parallel and loop primitives)
• Mastra (TypeScript-native).

2/ What the structure buys you

A graph answers the loop's three limits directly, and each answer takes a concrete shape.

• Context isolation. Each node gets a clean window, so no agent chokes on the full history. A research node reads fifty documents; the writer node never sees them, only the three-line summary the researcher passes forward. Context rot has nowhere to build.
• Parallelism. Independent nodes run at once. A market brief that pulls from five sources fans those reads out simultaneously instead of walking them one at a time, cutting wall-clock time to the slowest branch.
• Deterministic control. Routing on the edges lets you force a path instead of trusting the model to route itself. Wire a refund agent to stop at a human-approval node before it moves any money, and the pause is mandatory — not a suggestion the model might skip on a bad day.
• Independent review. A separate reviewer node stops the system grading its own work. A skeptic node with a different prompt — or a different model — checks the output before it ships, and the explicit routing leaves an audit trail of what ran and when.

3/ What a graph costs you

Every one of those wins is paid for, and the bill arrives as a distributed-systems problem you created for yourself.

• Over-engineering. A five-node system to summarize one PDF is engineering an org chart to answer an email — slower to build, harder to debug, and more expensive to run than a single loop that does the same job.
• Token burn. Several agents active at once cost far more tokens than one loop grinding through the task in sequence.
• Cascading, hidden failures. One bad node poisons the final output, and since you usually see only that final result, the broken step is hard to trace.
• Measurement decay. Dashboards stay green while nodes grade each other's reports instead of checking reality, so the system drifts off the goal without tripping an alarm — a live case of Goodhart's Law.

Goodhart's Law — when a measure becomes a target, it ceases to be a good measure.; push a ticket-resolution rate hard enough and you can wreck the retention it was meant to protect.

Reach for a graph only when the loop has clearly broken, and keep the bar high: three or more independent checks, different models or toolsets per stage, a real audit trail, genuine parallel work, or an outside reviewer. Below that bar, you pay the full distributed-systems tax for structure the task never needed. The honest test: if you can collapse the graph back into one agent's loop without losing anything, you should.

When to use each

Match the architecture to the task. Three gut-checks, each with the kind of work it fits.

• Context engineering — one informed pass. The right documents and instructions, and a single turn lands it. Reach for it when the job is a briefing: hand a sales rep the account history, open tickets, and last quarter's deal notes before a call, and one read gets them ready.
• Loop engineering — one job with an endpoint. A scoped agent that plans, acts, observes, and grades itself. Reach for it when there's a clear finish line the agent can check against: make a failing test pass, summarize a contract, write a function. Most tasks live here.
• Graph engineering — the loop has broken. Reach for it only on the signals: context rot, real parallel work, a required human sign-off, different models per stage, or an independent reviewer. The fit is a task like a daily market brief that fans out across five sources, synthesizes them, then runs a skeptic pass before anything publishes — work no single loop can hold without drowning or grading itself.

The rule: structure has to pay for itself. A heavier architecture is worth it only when it makes the system provably safer, faster, or easier to grade than the lighter one.

How to add structure without over-building

Don't design the org chart first. Start at the lightest layer and add structure only where the current one strains.

1. Get the context right. The right material in one pass. If a single turn closes the task, stop.
2. Wrap it in a loop with a real check. One agent that plans, acts, observes, and grades its output. If that holds, stop — most tasks stop here.
3. Make the state explicit. Move the working memory into a typed, shared object every node can read and update.
4. Split only what's rotting. Lift the one step flooding the window — a heavy retrieval or research leg — into its own node. Leave the rest in the loop.
5. Add routing, then a reviewer, then human gates. A decision step routes between nodes; an independent reviewer stops the system grading itself; a pause-for-a-person node guards costly or irreversible actions.

Every step is reversible. After each one, ask whether it could fold back into the layer below with nothing lost — if so, fold it. Add a piece only after the layer under it proves it can't cope alone.

What's actually new

Most of the machinery is old — directed graphs, state machines, and orchestration engines predate this by decades. Three things are new. The model now sits inside the control flow: a routing decision made by a model call is what makes this a cognitive architecture instead of a script. The graphs allow cycles natively, where older acyclic engines had to fake a loop. And one node can hold a whole agent run, so you orchestrate loops, not just calls.

Beyond that, graph engineering packages existing practice into something teachable more than it invents anything. The term went viral in mid-July 2026 after Peter Steinberger, who built OpenClaw, asked whether the field had moved "from loops to graphs." The tools underneath — LangGraph, AutoGen, ADK — had done this for years.

The discourse took a hit when a widely shared claim of a $3.1M Stanford grant turned out to be fabricated (according to this post). Critics calling it state machines with a new name have a point. Much stays unsettled: where autonomy ends and enforced routing begins, whether nested-graph terms like "holonic" will standardize, and how to score a multi-node run when many different paths could all be correct. What the label delivers isn't a breakthrough — it's shared vocabulary for a decision every builder now faces.

The order holds: get the context right, wrap it in a loop that checks itself, and reach for a graph last. Add each layer when the one below it fails — not when a new term trends.