Loop Engineering and Graph Engineering

Last week, I suddenly heard a new term—Loop Engineering. So I spent the weekend researching it. But the more I researched, the more confused I got, and then I stumbled upon Graph Engineering.

Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering → Graph Engineering. In less than half a year, five "Engineerings" have emerged. But each one corresponds to a real engineering challenge. This article organizes what Loop Engineering and Graph Engineering are really about, and in which tools you can find corresponding practical implementations.

1. Why So Many "XX Engineering" Terms Have Emerged

LangChain's official summary of three years of experience with LangGraph puts it bluntly: these terms are essentially different facets of the same thing—LLMs are a new type of software that is somewhat unreliable and highly uncertain. We have been constantly looking for ways to make them work stably, and every time a new strategy is found, a new term is born (LangChain, 2026).

This gave rise to:

• Prompt Engineering optimizes individual messages
• Context Engineering optimizes the information an LLM can see in a single call
• Harness Engineering optimizes the entire infrastructure for Agent operation (tool gating, context management, entropy management)
• Loop Engineering optimizes the very act of "who drives the Agent round by round"
• Graph Engineering optimizes "how multiple Loops / multiple Agents are orchestrated, who can communicate with whom, and how state flows"

Back to our main thread--Loop Engineering & Graph Engineering

Loop and Graph are not in competition; they are two layers of different granularity: Loop concerns how a single Agent node gets things done internally; Graph concerns how multiple nodes (which could be Agents, ordinary functions, routers, or human approval checkpoints) are connected. TrueFoundry's definition is very clear:

Graph engineering designs the topology of a multi-agent system... while loop engineering designs how each agentic node actually executes. —— TrueFoundry, 2026

2. Loop Engineering: Turning "Manual Prompting" into an Automated System

2.1 Definition

This term was first ignited by Peter Steinberger (author of OpenClaw) in a post in June 2026

Subsequently, Addy Osmani, Boris Cherny (head of Anthropic Claude Code), and others systematized this idea, giving a widely accepted definition:

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.

A Loop's most basic building blocks are four things: Agent + Verifier + Feedback Path + Stop Condition (iteration limit / budget limit / successful exit). These four elements are indispensable—without a Verifier, the Agent will stop when it feels "it looks done"; without a stop condition, the Loop may spin indefinitely, burning tokens.

2.2 Simple Practice

If you learn slowly enough, you don't have to learn =。=, I originally thought this was new knowledge, but it turns out various vendors have already implemented it.

kiro: goal feature

kiro, claude code have already implemented the goal feature.

kiro goal feature introduction: https://kiro.dev/docs/cli/chat/goal/

Peter Steinberger's Example

This is a simple loop process: let Codex maintain your code repository, wake up every 5 minutes, and then distribute work to different threads (task threads). This makes it easy to parallelize as needed and adjust task direction at any time. I used an "orchestrator skill", combined with my "task triage + autoreview + computer use" skills, so some work can be completed autonomously and automatically merged and deployed.

2.3 Suitable Scenarios

• Repetitive work with clear, machine-determinable "completion" criteria: fixing lint errors, batch upgrading dependency versions, supplementing test coverage, generating CRUD code from fixed templates
• Tasks that can be fully verified in a sandbox/isolated environment: existing CI, staging environment, automated tests, where the cost of Agent mistakes is controllable
• Scenarios where the task duration itself is lengthening and worth running unattended for a while: "long tasks" are precisely where Loop should deliver the most value
• Scenarios where the writer and the judge can be separated: having an independent Evaluator (another model review) or Sub-agent dedicated to checking, not relying on the Agent to score itself

3. Graph Engineering: Connecting Multiple Loops into a Topology

It's this person again!!!

3.1 Definition

The core action of Graph Engineering is to change "how to proceed between Agents/steps" from implicit (throwing it to the LLM to judge "what to do next" by itself) to explicit (drawing a graph that specifies which paths are legal).

LangChain's statement is the most direct:

Representing agentic systems as graphs... allows you (as the builder) to impose your preconceptions of how the system should work into more constrained paths, not relying solely on the judgement of the LLM. ——LangChain, 2026

In the graph:

• Node: Can be deterministic code, a single LLM call, a tool call, or a complete Agent with its own internal Loop
• Edge: Can be deterministic (fixed sequence) or conditional (dynamically deciding the next step based on node results / current state / external signals)
• The whole thing can be seen as a state machine: the graph defines the workflow, state flows within the graph, edges define state transitions

TrueFoundry adds a finer distinction: nodes in the graph are not necessarily all Agents; they can also be Routers, Joins, Human Checkpoints—Graph Engineering manages the topology, communication, and delegation relationships between these heterogeneous nodes. Whether each node thinks autonomously is not important; what matters is whether the topology itself is an explicit, programmable, versionable artifact.

3.2 When to Use a Graph, When Not To

LangChain provides a very practical criterion, worth excerpting and rewriting (Content was rephrased for compliance with licensing restrictions):

• Scenarios for using a graph: Real business processes often have predictable structures—customer service Agents first classify then answer or escalate, coding Agents first look at the repository then propose changes, compliance processes require approval before external execution. In these scenarios, what you want is code as a safety net + the model only playing a role where judgment is truly needed. The graph can directly encode "where to fix and where to hand over to the model" into the topology.
• Scenarios for not using a graph: The task itself is highly autonomous, and steps are hard to predetermine (e.g., Deep Research: planning, delegation, retrieval, reading, synthesis all need to unfold dynamically). Forcing it into a deterministic path is the wrong direction. In this case, it's more suitable to directly use an Agent Harness (like the Deep Agents framework), letting planning and context management emerge inside the harness, rather than being hardcoded in the graph.

The LangChain team themselves stepped on this pitfall when building the Deep Research feature: they initially implemented it with a predefined LangGraph workflow, but later found the research task was too dynamic, so they switched to a more agentic core loop—this also confirms that Graph and Loop (more precisely, a free Loop wrapped by a Harness) are two paradigms to be chosen based on the scenario, not one replacing the other.

Additionally, LangChain emphasizes a counter-intuitive fact: Agent graphs in production environments are basically never DAGs (Directed Acyclic Graphs), because retrying failed tool calls, asking users for missing information, revising answers after verification, repeatedly calling tools until information is sufficient, pausing to wait for human input... all of these require "cycles", so Agent graphs are essentially Directed Cyclic Graphs.

3.3 Simple Practice

LangGraph

It seems various vendors don't have ready-made implementations yet (if anyone knows, please comment), but graphs have existed for a long time, such as the aforementioned LangGraph. Although it has existed for 3 years, it is currently one of the best practices. I'm still looking into it, so I won't embarrass myself by trying to demonstrate.

LangGraph: https://docs.langchain.com/oss/python/langgraph/overview

Accidental Discovery

Real graph engineering. Directly feeding a graph...

4. Putting Them Together: A Comparison Table

Dimension	Loop Engineering	Graph Engineering
Concern	How a single Agent node is automatically driven to complete a task	How multiple nodes (Agents/functions/routers/human checkpoints) connect and flow
Core Components	Agent + Verifier + Feedback Path + Stop Condition	Node + Edge (including conditional edges) + Shared State
Typical Problem	Who drives it round by round? When is it considered done?	Who can communicate with whom? Which path is legal? How does state transfer between nodes?
Representative Tools/Concepts	Kiro Autopilot, Claude Code Hooks, Munk AI Verification Sub-Loop	LangGraph, Spring AI Alibaba Graph
One-Sentence Relationship	A loop is the simplest graph (a directed, cyclic graph)	A graph is a topology orchestrated from multiple loops/nodes, and a Graph can nest Loops

5. Final Words

If you only remember one sentence: Loop Engineering solves "how to make one Agent get things done by itself", Graph Engineering solves "how to make multiple Agents / steps collaborate along the path you designed".

They are not in competition, but rather the unfolding of the same idea—"taming uncertain LLMs with engineering methods"—at different granularities. LangChain puts it very accurately: behind this is the same belief, which is to place the model's reasoning ability where it is truly needed, and leave the rest to deterministic code.

References

• Peter Steinberger's Original Post
• LangChain, "3 Years of Graph Engineering with LangGraph"