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.
| 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.
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.
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:
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.
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:
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.
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.
/loop (in-session) and Routines (cloud-run schedules).