Three terms now compete for the same line in AI engineering job descriptions. Prompt engineering is the established one. Loop engineering entered the AI vocabulary in late 2025 and dominated developer discussion through June 2026. Graph engineering followed roughly six weeks later.

They get used interchangeably. Should they be?

The three are not competing techniques. They are three different units of control, stacked. A prompt controls one model response. A loop controls one agent’s behavior cycle. A graph controls the organization of many agents. Each layer preserves the layer beneath it. A prompt does not disappear once a loop is built around it. it stops being the thing typed by hand.

This article separates the three: what gets designed at each layer, what the published claim says about when the higher layers pay for themselves, and where the skepticism is warranted.

Interactive explainer · 01

One task, three layers — watch what changes

The three terms are not competing techniques. They are three different units of control. Here is the same job handled at each layer, step by step. Orange dots mark the moments a human is required.

Task

Fix the failing tests in the auth module, then open a pull request.

Layer 1

Prompt engineering

You control one model response. You are the loop.

Your turns

· Model calls

Layer 2

Loop engineering

You control one agent’s cycle. The loop does the prompting.

Your turns

· Model calls

Layer 3

Graph engineering

You control how many agents are organised.

Your turns

· Nodes

· Parallel

What actually differs

	Prompt	Loop	Graph
Unit of control	One model response	One agent’s behaviour cycle	An organisation of agents
What you write	Instructions, examples, output format	Trigger, tools, stop condition, retry budget	Nodes, edges, shared state, failure routes
Who says “again?”	A human, every turn	A verifier the loop calls itself	A routing rule written in advance
Where it breaks	Ambiguous or overstuffed instruction	It cannot tell done from stuck	Context never crossed an edge you forgot to draw
Enough when	One shot, a person reads the result	Repetitive, machine-checkable, one domain	Cross-domain work with parallel branches

Illustrative walkthrough · step counts are not benchmarks

Built by Marktechpost

The stack, in order

Each step in the progression was named in practice before it appeared in vendor documentation.

1. Prompt engineering covers writing and structuring the instruction for a single call. Anthropic’s guidance is to separate a system prompt into labeled sections — background information, instructions, tool guidance, output description — delineated with XML tags or Markdown headers. The recommendation is to supply the minimal set of information that fully specifies the expected behavior. Minimal does not mean short.
2. Context engineering came next. Anthropic describes it as the natural progression of prompt engineering. The question moves from finding the right words to deciding what configuration of tokens belongs in the window at all. Context is a finite resource, and the engineering problem is optimizing the utility of those tokens against model constraints.
3. Harness engineering covers the environment a single agent runs inside: files, tools, memory, feedback.
4. Loop engineering sits one floor above the harness. A June 2026 arXiv paper on agentic AI in building engineering, Buildrix, sets out the same four-step progression explicitly — prompt, then context, then harness, then loop — with the final layer defining how a system repeatedly observes, acts, verifies and recovers.
5. Graph engineering is the newest label and the least settled. One enterprise writeup notes that the term’s provenance is unresolved and that it collides with an older knowledge-graph usage of the same word. The underlying practice, graph-based orchestration, has a documented lineage in multi-agent systems research.

Layer 1: Prompt Engineering

The defining assumption is that a human is present at every iteration. A prompt is written, the model responds, the output is judged, the prompt is revised.

That assumption is what breaks. High volume. Multi-step tasks. No human available to grade the output. Results that feed the next step automatically. Any one of these, and the prompt alone stops being sufficient.

Nothing about the prompt got worse. The surrounding conditions changed.

Prompt engineering also does not vanish inside the higher layers. Anthropic’s multi-agent research writeup reports that prompt engineering was the primary lever for fixing coordination failures. Early versions spawned 50 subagents for simple queries, and the fix was prompting rather than topology.

Interactive explainer · 02 · Layer 1

What prompt engineering is

Prompt engineering is designing the text of a single call to a model. One input, one forward pass, one output — and a human who reads the result and decides whether to run it again. That last part is the assumption everything above this layer exists to remove.

Swipe the diagram sideways →

The cycle exists here too — but you are the one closing it, every single turn.

Anatomy of a prompt

Tap a section. Anthropic’s guidance is to delineate parts with XML tags or Markdown headers rather than writing one undifferentiated block.

What this section does

Background information

The assumption that breaks

Prompt engineering assumes a human is present at every iteration. Tap a condition to see what happens when that stops being true.

Layer 1 of 3 · the layer most tasks stop at

Built by Marktechpost

Layer 2: loop engineering

The framing is that a coding agent is a brute-force tool for finding solutions. The craft is designing the goal, the tools and the loop and not only the prompt.

The term reached mainstream developer discussion in June 2026, after a widely shared post argued that engineers should stop prompting coding agents and start designing the loops that prompt them. The Claude Code team at Anthropic described the same shift on stage that week.

The most detailed public breakdown identifies five primitives, plus a sixth element that holds them together:

1. Automations: a schedule or event that performs discovery and triage without supervision
2. Worktrees: isolation so parallel agents cannot edit the same files
3. Skills: project knowledge written down once in a SKILL.md, rather than re-explained every session
4. Plugins and connectors: MCP-based access to the issue tracker, database or staging API
5. Sub-agents: a maker/checker split, since the model that wrote the code grades it too generously
6. State: a markdown file or board outside the conversation, because the model forgets between runs

Two in-session features are very important. /loop re-runs on a cadence. /goal runs until a written condition is actually true, with a separate small model checking after each turn — so the agent that wrote the code is not the agent grading it. Both Claude Code and the Codex app ship equivalents.

The cycle is not the hard part. The stop condition is. A loop that cannot mechanically distinguish done from stuck does not fail loudly. It keeps spending tokens.

Interactive explainer · 03 · Layer 2

What loop engineering is

Loop engineering is designing the system that prompts the agent, instead of prompting it yourself. The prompt does not disappear — it becomes a component inside a cycle that decides when to fire, what counts as passing, and when to stop trying. The skill was named in September 2025 and became the dominant developer topic in June 2026.

The cycle

Four phases and a memory. Press run to watch one complete, then force a failure to see why the guardrails exist.

Run log

Everything below happens with nobody watching. That is the whole point, and the whole risk.

Idle. Press “Run the loop”.

A loop needs a stopping rule it can evaluate without you. Without one it does not fail loudly — it just keeps spending.

What you actually build

A working loop needs five primitives plus a place to remember things. Both Claude Code and the Codex app now ship all six. Tap one.

Layer 2 of 3 · illustrative simulation, not measured

Built by Marktechpost

Layer 3: graph engineering

In July 2026 the discussion moved from loops to graphs. Loops made agent behavior programmable. Graphs make agent organizations programmable.

The structural point most often missed is that production multi-agent systems run two graphs at once.

The org graph is stable. Long-lived agents hold named roles, own a zone, and accumulate context over time. It changes on redeploy.

The work graph is ephemeral. Task nodes exist only while the work does. Edges split for parallel paths, merge on convergence, and disappear when evidence makes a branch unnecessary.

The org graph answers who. The work graph answers what, right now.

The skepticism around the label is fair. Sub-agents with a defined purpose already form a graph, and the technology preceded the vocabulary. LangGraph shipped its graph API long before the term existed. Anthropic’s five workflow patterns from December 2024 — prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer — are graph topologies described in prose. What is new is a shared name for decisions those frameworks always forced: what are the nodes, what are the edges, what is in the state.

The concrete artifact is worth knowing. In LangGraph a StateGraph is declared over a state schema. Nodes register with add_node. Edges wire up with add_edge and add_conditional_edges. START and END are marked, then the graph compiles. Nodes are plain functions that receive state and return partial updates. Context does not cross a node boundary unless an edge carries it. That last part describes the entire failure mode.

Interactive explainer · 04 · Layer 3

What graph engineering is

Graph engineering is designing the organisation of many agents, rather than the behaviour of one. Loops made agent behaviour programmable; graphs make agent organisations programmable. You declare which nodes exist, which transitions are legal, and what happens when a branch fails. In practice two graphs run at once — a stable one that answers who owns what, and a per-task one that answers what needs doing right now.

resident agent

ephemeral worker

spawned at runtime

tap a node for detail

Node detail

Nothing selected. In a graph the node is the unit you name, scope and give tools to. Writing one is closer to writing a job description than writing a prompt.

Graph events

ready.

What you actually declare

A graph is not a metaphor here — it is the literal artifact you write. In LangGraph you build a StateGraph over a state schema, register nodes, wire edges, then compile it. Tap a primitive.

Layer 3 of 3 · illustrative topology, not a specific product’s runtime

Built by Marktechpost

How to choose the layer

Work through the questions in order. The first “no” is usually the answer.

1. Does a person read every output before anything acts on it? If yes, the prompt layer is sufficient. A loop buys unsupervised execution, not autonomy.
2. Can “done” be checked by something other than a human? Tests, a schema, a rubric, a second model. If not, there is no stop condition — only a budget.
3. Does the task fit inside one agent’s context and one domain? If yes, build the loop. A single reasoning trace is the cheapest way to keep assumptions consistent.
4. Do independent branches need to run at the same time? If yes, this is a graph problem: declare the nodes, the edges, the shared state and the failure routes. If no, extend the loop’s tools before adding agents.

A July 2026 arXiv paper on coding-agent loops states the relationship correctly. A loop is a prompt repeated with scaffolding around it, and loop engineering is complementary to prompt engineering rather than its replacement. The same holds one floor up. Graphs are built from loops, and loops are built from prompts.

The final caution is about the operator rather than the architecture. Two engineers can build an identical loop and get opposite outcomes. One moves faster on work they understand deeply. The other avoids understanding the work at all. The system cannot tell the difference. That is what makes the higher layers harder to design than prompts, not easier.

Key Takeaways

• Three units of control, not three competing methods: a prompt controls one response, a loop controls one agent’s cycle, a graph controls the organization of many agents.
• A loop is only as good as its stop condition — without a mechanical check for “done,” an unattended run terminates on token budget rather than correctness.
• Two graphs run simultaneously in production: a stable org graph answering who owns what, and a per-task work graph that splits, merges and cancels as evidence arrives.
• Published numbers set the price: +90.2% on an internal research eval, but roughly 15× the tokens of a chat, with token spend alone explaining 80% of the variance.
• Most tasks never reach the top of the stack: the counter-case stands for writing-heavy work, where dispersed decisions produce conflicting assumptions.

---

Sources

• anthropic.com/engineering — Effective context engineering for AI agents
• anthropic.com/engineering — Building effective agents (Dec 2024)
• anthropic.com/engineering — How we built our multi-agent research system (13 Jun 2025)
• simonwillison.net — Designing agentic loops (30 Sep 2025)
• addyosmani.com — Loop Engineering (7 Jun 2026)
• firecrawl.dev — Loop Engineering
• explainx.ai — Graph Engineering (18 Jul 2026)
• truefoundry.com — Graph Engineering for Multi-Agent Systems
• aibuilderclub.com — Graph Engineering Guide 2026
• cognition.com — Don’t Build Multi-Agents (Jun 2025)
• langchain.com — How and when to build multi-agent systems
• docs.langchain.com — LangGraph Graph API
• arXiv — Buildrix · Stop Hand-Holding Your Coding Agent