Many AI agent projects eventually collapse into a while loop that keeps calling a model: context grows, responsibilities blur, and the output begins to drift.
They don’t route. They don’t branch. They don’t parallelize. They run a loop, hoping it works, and debug for weeks when it doesn’t.
The next 11 stages turn one loop into a task graph that can branch, validate itself, and converge on an explicit output.
Start by drawing one real workflow. Every edge should state what data it carries and where failure returns.
Loop engineering is true progress. You’re not just having Claude execute once and copy the output; you’re building a system where each iteration retries, verifies, and improves. This is the third era.
But loops are still an agent executing a single task. When tasks get complex, a loop gets lost in context, mixes concerns, and tries to do everything at once. Graph engineering is the next level: you design the workflow.
Graph Engineering makes four things explicit: which agent is running, what happens after failure, where the result goes, and when a human must intervene.
A loop is when an agent becomes smarter. A graph is multiple agents coordinating work.
01 Why one loop is not enough
A loop grants autonomy to an agent. It will retry, learn from failures, and improve with each execution. For single-purpose tasks—fix this bug, summarize this document, clean this dataset—a loop is enough. You define the goal, attach validators, set stop conditions, and then let it run.
The problem begins when tasks involve multiple areas of focus: research + analysis + coding + review. If an agent tries to accomplish all four tasks, it fills the context window with mixed information, loses track of earlier steps, and produces seemingly complete work that collapses upon inspection.
Research seeps into analysis. Code ignores review. The agent is doing four tasks, but only has one context budget.
This is not a limitation of the model. Sonnet and Opus are more than capable of handling each individual task. The limitation lies in the architecture. You are asking a worker to play the roles of researcher, analyst, builder, and reviewer all in the same conversation.
The solution is not a bigger context window. The solution is to assign tasks to individual agents who are good at doing one thing and connect them so that the output of one becomes the input of the next.
The shift from loops to graphs is like the shift that happens when a solo developer joins a team. One person doing everything is fast when the project is simple. But when the project is complex, you need role division, handoffs, and reviews.
02 . Four building blocks
Every graph, no matter how complex, is made up of four basic elements. You don’t need a framework. You need functions, dictionaries, and if statements.
-
Node. A function that does only one thing. One Claude call, one tool execution, one database query, one file write. It takes an input state and returns an output state. The node does not know what happened before or what will happen afterward. It only knows its own work.
-
Edge. The connection between two nodes. "Research first, then run analysis." An edge can be unconditional (always) or conditional (only when state["status"] == "needs_more_data"). Conditional edges are how the graph makes decisions.
-
Router. A special node that checks the current state and selects the path to take. It does not perform work itself. It classifies the input and sends it to the correct expert. You can think of it as a dispatcher rather than a worker.
-
State. A dictionary that runs throughout the entire graph. Each node reads from and writes to it. State is the memory of the graph. Without it, each node would start from scratch, and the graph would not know what has already happened.
03 – Four eras
Each generation of AI engineering has absorbed the achievements of the previous generation. Prompt engineering taught us how to write good instructions. Context engineering taught us how to provide the right data. Loop engineering taught us how to build an autonomous agent.
Graph engineering teaches us to connect many agents into a coordinated system.
Most people are still at the first or second stage. They write a prompt, perhaps include some context, and expect a single Claude call to complete the entire task. The developers who are now releasing real products are at the third or fourth stage. They are not writing better prompts, but designing better workflows.
04 . Pattern: Sequential chain
The simplest graph. Node A runs and passes its output to Node B, which then passes it to Node C. No branching, no routing. Most "AI pipelines" are like this.
Sequential execution is effective when each step always succeeds and the order never changes. Data extraction, format conversion, translate first then summarize. Once any step may fail or the path may change, you need to use one of the other four patterns.
The biggest risk of a sequential chain is error propagation. If node A produces an incorrect output, node B will continue processing based on that incorrect output, and node C will process based on that. By the time you reach the end, the error has accumulated across three layers.
This is why even simple sequential diagrams benefit from validation nodes at the end.
05 . Pattern: Router
The router checks the input and selects one of several paths. Not every node runs. The router will choose the appropriate expert for the task. This is how to build a system that can handle multiple types of tasks without loading every tool into a single agent.
Key insight: routing is a classification task, not a reasoning task. You don’t need Sonnet to determine whether a ticket is about a billing issue or an error. Haiku can handle it in milliseconds, and the cost is only a small fraction. Leave the expensive model for the actual work inside the expert.
Each expert should have their own system prompts and their own toolsets. The code agent needs run_tests and write_file. The research agent needs web_search and read_doc. Giving all tools to every agent means incorrect tool calls, wasted tokens, and messy outputs.
For nuances: if your router makes a wrong call, the usual solution is better system prompts, not a bigger model.
Write 5 Input six real examples from each category into the router’s prompt. On routing tasks, few-shot classification on Haiku outperforms zero-shot classification on Sonnet.
06 Mode: Parallel Stream
Multiple nodes run simultaneously on the same input. The collector waits for all of them to finish and merges the results. Running three agents in parallel means your total time depends on the slowest agent, not the sum of the three agents’ times.
The constraint is independence. If Agent B needs the output of Agent A, they cannot be processed in parallel. If both handle the same input and produce independent outputs, then it is possible. Competition analysis is a clear example: each competitor has an agent, all run at the same time, and the results are merged at the end.
Merging nodes is where most people underinvest. Merging three JSON data blocks is easy. Merging three research reports into a coherent comprehensive report requires specialized prompts and independent quality standards. Treat the merging node as a real agent, not just a string concatenation process.
07 Pattern: Gated Loop
The builder agent completes the work. A separate reviewer agent performs the check. If the review fails, the builder retries and appends the failure reason to the state. This is the pattern behind every self-correcting agent system.
Key rule: The builder and the reviewer must be different entities. Usually, different system prompts are used, and sometimes different levels of models are employed. The builder’s job is to generate content. The reviewer’s job is to reject. If the same entity reviews its own work, it ends up approving its own mistakes, because the reasoning that causes the defects is the same as the reasoning evaluating them.
The reviewer’s prompt should be adversarial. Not ‘Is this good?’, but ‘Find all defects, inconsistencies, and edge cases that are missing. If no issues are found, reply {passed: true}. If uncertain, mark as failed.’ A strict reviewer finds real errors. A polite reviewer lets everything pass.
08 . Mode: Human-in-the-loop
The chart pauses at specific nodes, waiting for human approval before continuing. The agent is responsible for researching and drafting an action plan. Humans review key decisions. Once approved, the agent executes.
This model is mandatory for anything expensive, irreversible, or high-risk. Sending emails to clients, deploying to production, executing financial transactions, deleting data. The chart handles the work. Humans make the judgment calls.
Approval nodes should accurately show humans what will happen and what the cost will be. Not ‘Do you approve?’, but ‘This action will send 2,400 emails to the billing department, with this subject, and this content. Estimated cost: $12 . Do you approve?’
Specifically, humans can make real decisions within 5 seconds.
09 . State flow and model layering
State is a flat dictionary, with each node reading from and writing to it. Be explicit: each node should declare which keys it reads and which keys it writes. When a chart goes wrong, the first thing you check is the state. If you can’t track which node writes to which key, you can’t debug anything.
Model layering is the second production concern. Not every node requires the same model. The router performs classification: haiku. The builder performs reasoning: sonnet. Final quality gating for high-risk outputs: epic. Using a sonnet for routing is like hiring a senior engineer to sort mail. It works, but you are wasting budget on the wrong task.
10 . Fallback paths and error handling
The normal flow can run correctly. Any unexpected error will cause the entire graph to crash. Graphs in production need to set fallback edges for every node that may fail.
Fallback is not ‘ignoring errors.’ It is an independent path to handle failures in the graph. If the research agent times out, return partial results and flag it. If the reviewer crashes, skip automatic review and move to manual review. If the entire graph fails after the maximum number of retries, save the state to disk and send an alert. What the user receives will be something useful, not a stack trace.
11 . Complete working example
This is a complete diagram for handling customer support tickets. It uses Haiku to classify tickets, uses Sonnet to assign them to specialists, the specialists draft responses, reviewers check them, and if they pass review, the response is sent.
If rejected, experts will retry based on the reviewers’ feedback. All five modes are in the same chart.
Classification (haiku) -> Routing -> Draft (sonnet) -> Review (sonnet) -> Publish or Retry. After reaching the maximum number of retries, revert to manual processing. 60 Within lines. No framework.
6 Chart built with Claude this week
-
Work order classification: Claude classifies received work orders according to category and urgency. Each work order is assigned to a specialized agent with specific domain instructions. Reviewed before sending.
-
Competitive Analysis: Claude generates a sub-agent for each competitor. All agents conduct research in parallel. A merge node consolidates the research results into a single report.
-
PR Review Process: Claude reads the diffs, runs tests, and writes review comments. A second agent audits these comments before release to check for false positives.
-
Blog Article Process: Research agents gather information. Writing agents draft the article. Editing agents check facts and tone. The cycle repeats until the edits pass.
-
Verified ETL: Claude extracts data from PDFs, transforms the schema, and loads it into a database. Verification agents sample rows and flag anomalies before submission.
-
Incident Response: Alert-triggered chart. Claude reads the logs, identifies the root cause, drafts a fix plan and incident summary. The fix is approved manually before deployment.
Five ways people break their first chart
-
× Giant monolithic node. One node handles all functions. If it fails, everything fails. Split it into smaller nodes with a single responsibility.
-
× No state between nodes. Each node starts from scratch. No shared dictionary, no passing context. The graph forgets what the previous node learned.
-
× No fallback path. The normal path works. Any error causes the entire graph to crash. Always build a fallback edge.
-
× Use sonnets for routing. Routing is classification. Haikus are faster and cheaper. Use sonnets in important places: construction and review.
-
× Skip levels. No review checkpoints. The first wrong answer sent to the client is the last time everyone trusts the system.
Conclusion:
Loops are agents. Graphs are teams.
Loop engineering is the breakthrough that turns prompts into construction. You have learned to create an agent that can retry, verify, and improve. This is a real skill. It still is.
But once the work becomes complex, each team will outperform every individual operator. A chart is how you build a team of agents: one researcher is responsible for collecting, an analyst for reasoning, a writer for drafting, and a reviewer for rejecting. Each agent is very simple. The chart makes them powerful.
The core code does not depend on a framework. Functions, dictionaries, and if statements can express a minimal graph; LangGraph or CrewAI are implementation choices. Understand the five structural patterns before adding a framework.
Two types of builders in 2026 . Some people still run a loop for everything. Some people design processes. The models are the same. The architectures are different.
Implement the roadmap into a minimally verifiable diagram
Don’t build an "omnipotent multi-agent platform" yet. Pick a task that has real branches: research can be done in parallel, writing must wait for information, if fact-checking fails revisions are needed, and final release must be manually confirmed.
Routing workflows are suitable for first classifying the input, then sending tasks to the corresponding processing path.Independent sub-tasks can run in parallel, and the same output can be sent to different checkers for review from multiple angles.When sub-tasks cannot be enumerated in advance, then consider an orchestrator-worker, letting the orchestrator dynamically split and aggregate results.
Regardless of the structure used, each node must have clearly defined input, output, and failure states. The agent loop of Claude Code itself still consists of collecting context, taking action, and verifying results; the graph merely organizes multiple such loops according to their dependencies.Configure tests, screenshots, or expected outputs for each node, and in complex tasks, explore and plan first, then implement and verify.
Minimum acceptance checklist:
- Each edge can be explained as to why it exists;
- There are no hidden write conflicts between parallel nodes;
- Retries have budgets and stopping conditions;
- States can be persisted and support restoration from checkpoints;
- Manual approval is retained before high-risk actions;
- In case of failure, it can point out the specific node and evidence, rather than just returning "agent failed."