AI teams keep inventing new names for old problems. In 2026 alone, "loop engineering" and "graph engineering" both showed up, promising to redefine how we build agents, but strip away the branding and they're describing two components we already build into every serious agentic system: the execution loop and the orchestration layer. Here's what the new vocabulary actually means, where it came from, and how it maps to the way enterprises can design and ship agent pipelines.

TL;DR

Term What it describes
Loop engineering Designing the outer loop so an agent finds work, does it, verifies it, and repeats — without a human prompting each step
Graph engineering Making multi-agent control flow explicit: agents, validators, and humans as nodes; conditional routing as edges

Neither term adds a new era to the prompt → context → harness sequence. Both zoom in on components inside the harness layer, one names the execution loop, the other describes orchestration.

Loop engineering

Popularized in June 2026 by Addy Osmani (Google Chrome) in his essay Loop Engineering, synthesizing ideas from Boris Cherny (Anthropic) and Peter Steinberger. The core idea: the lever has moved from you prompting the agent to a system prompting the agent. Loop engineering asks what system to build so the agent finds the work, does it, verifies it, and records what it did — with the human reviewing outcomes rather than driving each step.

Osmani's essay proposes four loop types, distinguished by their trigger, which later writers adopted:

Loop type Trigger Example Where you'd build it today
Heartbeat Fixed short interval; asks whether there is work Agent polls a queue for the next task Claude Code's /loop — session-scoped recurring prompts
Cron Fixed time; runs a known task Nightly dependency audit Claude Code Routines (cloud-run cron schedules), session-scoped cron tasks for in-session polling, or plain cron invoking a headless run
Hook Event PR opened, CI failure detected CI/CD triggers (GitHub Actions), or Claude Code hooks for in-session events
Goal Runs until a success condition Iterate until the test suite passes A Ralph-style outer loop gated on tests

The pattern is already productized: Linear's Loops (July 2026) runs recurring agent workflows (bug triage, documentation updates) on a schedule or in response to events, with team-level visibility into each run's instructions and outcomes. Claude Code ships the same primitives natively: /loop for in-session recurring prompts and Routines for cloud-run schedules.

How it relates to the harness. Loop engineering is the outer loop component of the harness given its own name and taxonomy. The Ralph pattern documented in our recent harness post (a while loop, a spec on disk, tests as the gate) is a goal loop, described a year before the term existed. Each loop type also has an older ancestor (heartbeat and cron are scheduler patterns, hooks are CI/CD triggers); the new ingredient is the LLM step inside them.

What's useful to keep: the four-type taxonomy. It's compact, accurate vocabulary for describing autonomy triggers, and worth using when designing agent workflows.

Graph engineering

Took off in mid-July 2026 from a one-line Peter Steinberger post, "Are we still talking loops or did we shift to graphs yet?" expanded into fuller accounts by Carlos E. Perez and others. The claim: once a workflow branches across multiple specialized agents with conditional routing and long-running state, an implicit loop becomes hard to manage. Implicit here means the routing lives in the model's judgement: the agent reads the state and decides what to do next. In a graph the routing lives in code — agents, validators, deterministic functions, and humans as nodes; transitions as edges; conditional routing as guards, conditions attached to the edges. The value is inspectable control flow: you can see, test, and reason about which agent runs next and what state it receives.

How it relates to the harness. This is the orchestration component of the harness. Structurally, a graph of agents with conditional edges is a state machine, a construct software engineering has long-established names and tooling for. Workflow orchestration engines and DAG schedulers operationalized it decades ago, and LangGraph has offered exactly this for agents (graph traversal, persistent state, checkpoints, conditional edges) since 2024. PALO IT's agentic Gen-e2™ (Generative AI Enhanced Engineering) pipeline is a working example: conditional routing on task type, parallel context agents, a test-runner/debugger cycle, hard quality gates. It was built before the term existed, using the word "orchestration".

When the question underneath actually matters. Strip away the terminology and there is a real engineering decision here, and it is not a new one. Anthropic's Building effective agents (December 2024) drew the line between workflows, where the control flow is predefined in code, and agents, where the model directs its own process, and advised starting with the simplest structure that works. Loops versus graphs is that question again: when does an implicit loop stop being enough? Stay with a loop plus verification gates while a single agent with good sensors can carry the task, it is simpler to run, debug, and roll back. Reach for explicit graph structure when you hit any of these:

  • Conditional routing between specialised agents — which agent runs next depends on the previous one's output, not a fixed sequence.
  • Long-running state — the workflow must survive restarts, span hours, or resume from a checkpoint.
  • Paths that need independent testing — you want to exercise a routing decision or a failure branch without running the whole pipeline live.

A graph has a cost. Every branch you write in code is a decision the model no longer makes for itself. That is fine while the model cannot make it reliably. But models improve quickly, and a branch the model could soon handle on its own becomes code you have to maintain and eventually remove. So when tasks vary a lot and the routing is hard to pin down in advance, keep the loop and spend the effort on better sensors instead (tests, linters, review agents) the things that tell the model whether it is done.

The agentic Gen-e2™ pipeline sits on the graph side for exactly these reasons; most single-repo coding tasks don't, and a Ralph-style loop remains the better tool for them.

In its smallest form, a graph has four things a loop leaves implicit: a guarded route, a gate, a bounded retry, and a human node.

 

Loop Engineering GraphicA minimal agent graph. Amber nodes are agents, the green node is a deterministic gate, the blue node is a person, and the dashed edge is the bounded retry.

Every edge label is a guard. The gate is a deterministic node, not an agent. The retry has a ceiling, and the ceiling routes to a person rather than looping forever. Each of those is a decision you can read and test without running the pipeline.

Two disambiguations worth knowing:

  • Not knowledge graphs. Andrew Ng's graph course that circulates in these discussions is about modeling data as entities and relations for retrieval (GraphRAG territory). Graph engineering is about modeling execution. Same word, unrelated practice, a common source of confusion in client conversations.
  • Improvement graphs. Some writers extend the term to governance loops that watch other loops for metric gaming and measurement decay. This is currently an idea rather than an established practice, but it's the part of the discussion with the fewest existing names, worth watching.

How they fit together

Harness Engineering GraphicEach era wraps the one before it; loop and graph engineering name components inside the harness layer rather than adding new layers above it.

The naming cadence has accelerated. Prompt engineering held for roughly two years, context engineering for one, and harness engineering was followed by two would-be successors within five months.

A useful test when the next term arrives: does it name a practice that had no name, or rename one that already did? Every technique predates its term, so that alone proves nothing. Harness engineering earned its place by naming a bundle of converging practices that no existing vocabulary held. Loop engineering partially passes the test: the autonomy shift is real, though it names one harness component rather than a new layer. Graph engineering mostly renames orchestration.

Part of the community says the same. Critics such as David Khourshid, creator of the XState state-machine library, argue that the loops-versus-graphs debate is the industry rediscovering decades-old patterns (state machines, the actor model) and repackaging them as innovations rather than applying what it already knows.

Both coinages were community synthesis rather than a single author planting a flag; the "new era" framing comes mostly from the wave of guide content that followed.

Using the vocabulary in practice

  • Keep the three-era frame. Prompt → context → harness remains the layered model in delivery practice.
  • Borrow the loop taxonomy. Heartbeat / cron / hook / goal is a practical way to specify autonomy triggers when designing agent workflows.
  • Say "orchestration" when you design it. Which agent runs next, what state it receives, where the gates sit, the established word is precise and every engineer knows it.
  • Translate when clients use the new terms. "We need graph engineering" means explicit multi-agent orchestration with inspectable control flow. Meet the vocabulary, deliver the practice.

Where to next

Curious how these patterns show up in a production system rather than a blog post? Explore how PALO IT's Gen-e2™ pipeline puts orchestration and execution-loop design into practice, or get in touch to talk through how agentic architecture could fit your own stack.

FAQ

Loop engineering is about designing the outer loop that lets an agent find work, do it, verify it, and repeat without a human driving each step. Graph engineering is about making multi-agent control flow explicit — agents, validators, and humans as nodes, with conditional routing as edges between them. One names the execution loop; the other names orchestration.

Not really. Both describe practices that already exist inside what we call harness engineering. Loop engineering names a pattern (the Ralph-style goal loop) that predates the term by about a year. Graph engineering largely renames orchestration, a construct workflow engines, DAG schedulers, and tools like LangGraph have supported for years.

Stick with a loop plus verification gates while a single agent with good sensors (tests, linters, review agents) can reliably carry the task, it's simpler to run, debug, and roll back. Move to an explicit graph when you hit conditional routing between specialized agents, long-running state that must survive restarts, or paths that need independent testing.

Heartbeat (fixed short interval, checks for work), cron (fixed time, runs a known task), hook (triggered by an event like a PR or CI failure), and goal (runs until a success condition is met, like a passing test suite). This taxonomy is useful shorthand for specifying autonomy triggers when designing agent workflows.

Yes. Gen-e2™ uses conditional routing on task type, parallel context agents, a test-runner/debugger cycle, and hard quality gates, all built before the term "graph engineering" existed, using the word "orchestration" instead. It's a working example of what the term now describes.

 

References
Ready to kickstart your next big project?
Let's innovate together.
Work with Us