Graph Engineering Explained: Control Graphs, LLM as Graph vs Code as Graph

Graph engineering is three different things wearing one word, and only one of them is useful to most teams today: the control graph, an SOP your agent follows with nodes, edges, and state. You can enforce it two ways - write it as code (dynamic workflows, LangGraph) or write it as a skill the model reads - and most of the time the skill wins. This is the argument from my video, plus the four design patterns for cutting a process into nodes and two of the graphs my team actually runs.

Watch the full walkthrough, including both production graphs on screen:

Why Is "Graph Engineering" So Confusing?

If you were on X in July you saw the term everywhere, and the more you read the less it meant. It started with Peter Steinberger asking whether we are still talking about loops or have shifted to graphs. Nobody could agree on what he meant, because "graph" was doing triple duty. Three separate conversations were happening under one word.

1. Control graph. Think LangGraph, Claude Code's dynamic workflows, or just an SOP written in text. Most agentic tasks have a procedure behind them, and a control graph is how you make the agent follow it so you get a reliable result. This is what Peter meant. The example in his tweet was the flow for shipping a change to a codebase, and that is control flow.

2. Knowledge graph. A completely different idea that got dragged in because Andrew Ng happened to release an agentic knowledge graph course the same week. A knowledge graph represents relationships between entities so retrieval is more effective. Agent memory products have shipped on graphs for years. Real, useful, and unrelated.

3. Graph of loops. The interesting one, and the one nobody has an answer to. If a company is run by many autonomous loops, how do you make sure they all execute well and improve continuously, given that one loop is already hard and errors compound across several? My team has been running loops for a few months and this is still mostly unexplored. Most teams have not got one loop working yet, so this is not where to start.

The rest of this article is about type 1, because that is the one with broad practical use right now. For the broader map of the discussion, the Graph Engineering guide covers the discourse and the frameworks; this piece is how I actually build one.

Why Does the Term Matter Now? (I Don't Prompt Agents Anymore)

The reason a decades-old idea suddenly has a name is a shift in who prompts the agent. Teams are moving from a human prompting the agent to something else prompting the agent on the human's behalf. Two patterns are being pushed hard by the most AI-native companies I know:

• Loops. Instead of prompting the agent for every task, you set a trigger. Time-based: every day, pull the latest GitHub issues and fix them. Goal-based: keep optimizing the frontend until performance is up 200%. Event-based: every incoming email wakes the agent. The human is involved only when the agent decides it is necessary, which makes "what can it do alone vs what needs a person" the single most important design decision in every loop.
• Orchestrator. You stop talking to individual agents. You talk to one orchestrator with full context, and it spins up a team of agents to execute and monitors them. Boris Cherny, who created Claude Code, describes his day the same way now: he mostly talks to a Claude that talks to other Claudes, and runs thousands of agents overnight on complex work.

Both patterns keep you one layer above the actual work. You no longer babysit every step and checkpoint. And that is exactly why reliability became the thing everyone needs before they can trust either pattern. The minimum is a verifier in your codebase so you have some confidence in what the agent ships. But a verifier is one guardrail. Most business processes have several, plus an SOP, and the control graph is how you inject all of them.

What Is a Control Graph, and What Is New About It?

Graph-based workflow automation is old. It has three parts:

What changed is only what a node means. In traditional automation a node was a basic action: run a script, do a conditional check. A few years ago platforms let you drop an LLM call in as a node to handle long-tail cases. Now a node can be an agent that can do almost anything. Same graph, much more capable vertices. That is the entire novelty, and it is enough.

You Are Already Running Graphs

If you use Claude Code or Codex you are already running control graphs, you just did not draw them.

• The goal feature is a graph: user prompt goes into the agent loop, and when the agent stops, a stop hook asks a model "is the goal satisfied?" If yes, finish. If no, send a new message back into the loop. Agent loop plus stop hook, that is the implementation.
• Karpathy's autoresearch is a graph. A program.md tells the agent to edit train.py with an experimental idea, run it, check the metric. Better: keep and commit. Worse: revert and try the next idea. Repeat forever. State is two files, the training script and a results.tsv log. No fancy mechanism at all, it had no goal feature or Ralph loop back then. The prompt said "repeat this process" and the agent did.
• Deep research is a graph. Prompt, an orchestrator plans topics, fan out subagents per topic, review whether there is enough to write the report, loop back or finish.

The autoresearch example matters most, because it proves the point of the next section: a graph does not have to be code.

The Two Ways to Enforce a Graph

Code as graph. Dynamic workflows in Claude Code, Codex code mode, LangGraph. The harness gives you a few primitives - agent() to spawn a session, pipeline() for stages with dependencies, parallel() to fan out - and you write the control flow as JavaScript. Each agent() call takes a prompt, a model, and an output schema, so when that session finishes it returns typed state you can use to build the next node's prompt. It is not sophisticated. It is a few new API endpoints, and that is enough to write any graph shape you want. Full mechanics in Dynamic Workflows.

LLM as graph. You describe the SOP in text - numbered steps, JSON, a mermaid diagram, whatever - and turn it into a skill the agent loads as context. Modern models follow a written SOP well, and the harness already supplies the deterministic parts where you need them:

• bash for predefined scripts, so deterministic steps stay deterministic
• subagents and agent teams so an orchestrator can decompose the SOP and wake a team
• hooks to inject real checkpoints into the runtime (the goal feature is the reference implementation)

I default to LLM as graph. The main reason is practical: with dynamic workflows or Codex code mode, every node starts a brand new session and cannot resume the previous one. Agent teams can send a follow-up message into an existing session, which is both more capable and cheaper (the persistent-session argument is the whole sidekick paradigm). Code as graph earns its place when the task is genuinely huge, or when what you need protected is the record of every stage rather than the reasoning.

Either way the process is the same. Map the SOP. Group the steps into nodes and edges using the patterns below. Define an artifact document that holds state. The only difference is the output: a skill a loop can wake up, or a JavaScript file the harness can run.

Four Design Patterns for Cutting a Process Into Nodes

The LLM-as-graph method looks trivial - you just give it a prompt - but there are a few patterns that decide whether the SOP is actually followed.

1. Split agents at capability boundaries, not for tidiness. You could put the whole SOP in one agent, and as models improve one agent finishes more of it. But there are boundaries the model does not cross well no matter how strong it is. It is not good at verifying its own work, so the verifier is always a separate node. For complex tasks, both OpenAI and Anthropic's own research points to a dedicated planner that only researches and reasons. And think about what can run in parallel, and what a weaker, cheaper model can take.

2. Use code where it makes sense. This is the cheapest reliability win there is. Complex-but-common data fetching should be a script, not an agent stitching four API calls together. Getting the dev server up should be a script so the agent does not fight it. Evals and end-to-end tests should be scripts the agent can call. Code is faster, and it makes fewer pointless mistakes.

3. Define input and output per agent node. Each node should have a clear boundary and a clear output expectation. In code as graph that is the schema. In a skill it is a sentence: "return a ranked list with these fields."

4. Make state readable in one glance. Whether the graph lives in code or in prose, every agent needs to understand where the work stands fast. The simplest version works: one markdown file with the latest status, plus an append-only log per agent or per run.

Two Graphs My Team Actually Runs

Both come from SuperDesign, the vibe-design platform my team builds. We keep a separate repo (we call it SuperDesign AGI) as the state store and knowledge base for the whole business - every support ticket, every shipped engineering ticket, every loop's output - and most days I start the agent there rather than in the product codebase, because it has context on everything that ever happened. At the top of that repo sit the skills, and several of them are small graphs.

Example 1: Daily bad-design triage (LLM as graph)

Users generate designs on the platform every day, and we want to catch the ones that came out badly so they feed an eval set and, eventually, a better agent. The graph, once a day:

1. A script pulls candidate designs from the database using a list of heuristic indicators. No candidates, the run ends.
2. A second script surfaces the issues that can be checked programmatically - errors, a design that is plainly broken, not responsive - and adds those straight to the list.
3. For the rest, fan out a batch of subagents. Each one screenshots the design, compares it with what the user actually asked for, and judges the result against an agreed output schema.
4. The main agent ranks everything and publishes today's list as a simple file in the repo.

From there we either add items to the eval set or spin up another group of agents, one per issue, to improve the design agent itself. The whole thing is enforced by one skill plus a few scripts: the skill says which script to run for candidates, which script to run for the programmatic checks, how to fan out the vision judges and what schema they return, how the main agent ranks, and the output contract and guardrails for the loop. Every day a loop starts, points the agent at the skill, and the agent does the rest.

Example 2: Ship a change (code as graph)

We trigger this dynamic workflow whenever a change already has a well-defined scope and plan. Three phases: setup and implement, then verify, and if verification passes, simplify and open the PR. Each phase is an agent() call with its own prompt, model, and schema, so the verify agent's typed output is what builds the prompt for the simplify agent. The smallest possible version of the same shape is a two-stage writing workflow: stage one outlines against an outline schema (title, sections, bullets), stage two writes the article from that outline.

One thing I keep having to say: breaking the task into stages like this is not what makes it work. What makes it work is that the agent has tools to test properly. This is the step I see most people skip before wondering why their loop failed. If you do not have a verifier yet, the verifier-setup skill is a copy-paste start, and most of this article depends on it.

What Comes Next

That covers control graphs, the part of "graph engineering" you can use today. The open question is the third meaning: what happens when you have many loops running one company, and how you make them compound instead of compounding their mistakes. That is the next video.

Related Content

• Graph Engineering: What Happens When Your Agent Outgrows the Loop - The wider map: the July discourse, LangGraph vs ADK, and when not to reach for a graph at all.
• Dynamic Workflows: Orchestrate Subagents at Scale - The code-as-graph primitives in detail: agent(), pipeline(), parallel(), schemas.
• The Sidekick Paradigm: Orchestrator-Worker Agents - Why a persistent, resumable worker beats a fresh spawn, the argument behind defaulting to LLM as graph.
• Graph Engineering with Claude Code - Subagents as nodes, the orchestrator as edges, with the tool you already have open.
• Loop Engineering: The Complete Guide - A node is a loop. This is how to design one, and why the verifier is the bottleneck.
• Graph Engineering and the Karpathy Loop - What autoresearch actually does, and what the viral PDF around it does not.

Start Here

Pick one process you repeat every week. Write the SOP as numbered steps, mark which steps are deterministic and turn those into scripts, split out a verifier, and save the whole thing as a skill. Run it by hand once, then put a loop in front of it. That is a control graph, and you built it without a framework.

The verifier-setup and Open Agent Teams skills are free in the AI Builder Club skills repo. For the full walkthrough of both production graphs, and the weekly live workshops where we build these together, come build with us.

Join AI Builder Club