"Graph engineer" is being used on the internet for three unrelated things: control graph (reliable SOP-shaped agent workflows), knowledge graph (entity-relationship memory), and graph of loops (many self-running loops compounding). Only the first is broadly useful today.
The real shift driving all this: teams are moving from humans prompting agents to something else prompting agents on the human's behalf (time/goal/event-triggered loops, and orchestrator agents that run teams). Once the human steps one layer up, reliability is what earns the trust to let go, so a verifier and clear structure become essential.
A control graph is decades-old workflow automation with three parts: node (action), edge (what happens next), state (data carried between steps). What is new is that a node can now be a whole agent, not just a script or a single LLM call.
You already use graphs: Claude Code's "go"/stop-hook loop, Karpathy's autoresearch program.md loop, and the deep-research fan-out are all control graphs.
Two ways to build one: LLM-as-graph (write the SOP as a skill; enforce with bash scripts, subagents, hooks) or code-as-graph (dynamic-workflow JavaScript with agent()/pipeline()/parallel()). Both are valid; the author prefers LLM-as-graph in most cases because code-as-graph starts a fresh agent session per node and can't resume a conversation.
The single biggest mistake that makes people's loops fail: breaking a task into steps but not giving the agent tools to actually test its own work. Add a verifier.
What "graph engineering" actually means
The term blew up after a Peter Steinberger tweet ("Are we still talking loops or did we shift to graphs yet?", 2.7M views) and immediately got confusing, because people were folding three different concepts into one word (00:25).
The three things people mean by "graph," split apart. Source: 0:40
Control graph (LangGraph, dynamic workflow, or an SOP written in text): ways to make an agent produce a more reliable result. The author believes this is what Peter actually meant, and it is the one with broad practical use today (00:40).
Knowledge graph: a way to represent relationships between entities so retrieval is effective (agent memory tools have shipped this for years). A completely different topic that got dragged in only because Andrew Ng happened to release a 1-hour course on building an agentic knowledge graph around the same time (00:55).
Graph of loops (an idea the author attributes to Cursor; transcription uncertain): if the future company is run by many independent loops, how do you make them all execute well and improve continuously? Errors and improvements both compound fast once you have more than one loop. Genuinely new, unexplored, and mostly unanswered, because most teams have not yet stood up even one or two loops successfully (01:30).
Why reliability suddenly matters
Everything here sits on top of a modern harness (Claude Code, Codex). The author claims a 10x-to-100x gap between someone who opens a terminal, sends a prompt, and hopes, versus someone who uses every part of the harness (03:02). (This is also where the sponsored HubSpot "Claude Code playbook" pitch sits.)
The deeper driverthe biggest shift with agents right now is teams moving from a human prompting the agent to something else prompting the agent on behalf of the human. Two patterns the most AI-native companies are experimenting with (03:40):
Loop vs orchestrator: the two ways "something else" prompts the agent. Source: 6:55
Loops: instead of a human prompting for every task, a trigger prompts the agent. Triggers are time-based (every day, pull the latest GitHub issue and fix it), goal-based (keep optimizing the front end until performance improves 200%), or event-based (every inbound email wakes the agent). The human is involved only when the agent decides it is necessary, so defining what the agent may do alone vs what needs a human is critical (04:32).
Orchestrator: you no longer talk to individual agents. You talk to one orchestrator that holds full context and spins up a team of agents to execute and monitor. Boris (creator of Claude Code) has said he mostly talks to a Claude that talks to other Claudes, running at minimum a few agents at any moment and often a few thousand overnight (05:20).
Both patterns keep the human one layer above the actual work, so you stop babysitting every step. That is exactly why reliability becomes the gate: you need confidence in what the agent ships. The author's standing advice is to at least set up a verifier in your codebase (he ships a verifier setup skill in his public repo) (06:03).
The control graph, defined
A verifier is just one guardrail. More generally, business processes you want to automate have SOPs and guardrails to inject, and this is where the control graph fits. It is not new: graph-based workflow automation has existed for decades with three components (06:35):
The three parts of any control graph. Source: 7:40
Node = the action it takes.
Edge = what happens next after each node.
State = the data carried over between every step.
What is genuinely new is what a node can be. In traditional automation a node is a basic action (run a script, do a conditional check). About three years ago, platforms let you drop a large language model in as a node for longer-tail cases. Most recently, a node can be a full agent capable of many things (07:34).
Graphs you already use
You are already using control graphs, whether or not you call them that.
Claude Code / Codex "go" feature (07:50): at its core it is a graph. A user prompt runs through the agent loop; when the agent finishes a turn, an LLM classifies whether the goal is satisfied. If yes, finish; if not, send a new message back to the agent. It is implemented with the agent loop plus a stop-hook system.
Claude Code's "go" drawn as a control graph. Source: 8:27
Karpathy's autoresearch (07:55): Andrej Karpathy put an agent in a for-loop to continuously improve a language-model training setup. The surprise is how simple it is, and that the "graph" here is achieved by prompting alone, no rough-loop or "go" feature, no fancy mechanism. The prompt lives in a program.md file describing the process; the agent edits train.py with an experimental idea, runs the experiment, checks the metric, keeps the change if better and reverts if not, then tries the next idea. State is two files: train.py (the thing being changed) and results.tsv (the log of everything tried).
The actual autoresearch result (left), its SOP written as a plain program.md (center), and that SOP drawn as a control graph (right). The point: the graph is just a documented SOP the agent follows. Source: 8:40 / 9:08 / 9:16
Deep research (09:04): the familiar pattern, also a graph. A prompt goes to an orchestrator that plans the topics, fans out subagents to research each, then reviews whether there is enough information for the report. If not, loop back; if yes, finish and generate the report.
Deep research is an orchestrator + fan-out + review-loop graph. Source: 10:20
The takeaway across all threethere are multiple ways to enforce a graph, and one of them is just prompting.
Two ways to build a control graph
Code as graph: real code that builds the workflow (Claude Code / Codex dynamic workflow or "code mode", or LangGraph). Useful and precise.
LLM as graph: include the SOP as text, JSON, or a mermaid chart. Modern models already understand and follow SOP workflows, so you can describe the design in text and turn it into a skill the agent invokes as context, exactly like Karpathy's autoresearch (09:40).
The modern harness gives you primitives to enforce either: bash (run predefined deterministic scripts), subagents plus an agent-teams communication protocol (an orchestrator decomposes an SOP into steps and wakes a team), and hooks (inject real deterministic checkpoints into the agent runtime) (11:00).
LLM-as-graph: the SOP lives in a skill, and bash / subagents / hooks enforce the deterministic parts. Source: 12:15
Design patterns that make it work
For the LLM-as-graph approach, the SOP will not follow itself well without some design discipline (12:06):
The design patterns for reliable LLM-as-graph. Source: 13:25
Know when to separate agent nodes. You can cram the whole SOP into one agent, and as models improve you can get away with more, but respect the model's boundaries for best performance. A model is not great at verifying its own work, so a verifier is its own node. Per OpenAI and Anthropic research, complex tasks also want a dedicated planner node focused on researching and reasoning. Also think about what can be parallelized and what can be handled by stronger or weaker models.
Use code when it makes sense. It raises reliability and speed. Good candidates: complex/common data fetching (a script instead of the agent chaining API calls), a script to get the dev server running so the agent does not fight it, and the ability to evaluate results or run end-to-end tests.
Define each agent node's input and output so the boundary and output expectation are clear.
State: give every agent a fast way to understand the current state of the work. Simplest version: one markdown file documenting the latest status, plus an append-only log from each agent or run.
The general processmap out the SOP, think through all steps, group them into nodes and edges using the patterns above, and define an artifact doc for state. Output is a skill (LLM-as-graph) or JavaScript (code-as-graph).
Real example: bad-design triage (LLM-as-graph)
The author's team runs Super Design, a "vibe design" platform. They keep a separate repo, "Super Design AGI", as a state-tracking and knowledge base for everything happening across the business (every support ticket, every engineering ticket shipped). Most changes now start in this repo rather than the platform code. At the top sit skills, some of which are small graphs (15:07).
The "Super Design AGI" repo: a knowledge base + a library of skills, each a small graph. Source: 15:45
The daily bad-design triage skill: every day, review the designs users generated, pick the ones that look bad or missed expectations, and add them to a review list that feeds an eval dataset for improving the agent (16:00).
The triage graph: pull candidates by heuristic, run deterministic script checks for the obvious breakage, then fan out one vision reviewer per remaining design, rank the worst, and publish a list. Source: 16:48 / 17:12
It is enforced as a skill plus a few scripts. The skill documents which script to run to get bad-design candidates, has the agent run deterministic checks to surface issues early, then fans out vision-model judge agents (each with an agreed output schema), and the main agent ranks the worst of the day into a report, all under an output contract and guardrails (18:10).
The skill body (left) with its vision-judge output schema, and its guardrails (right), each one a bug they already hit. This is a genuinely complex workflow achieved by injecting a skill plus scripts. Source: 18:10 / 18:28
Real example: ship-change (code-as-graph)
The team also uses dynamic workflow as the code-as-graph method. The agent writes JavaScript using new agent-specific primitives: spawn an agent, pipeline (dependencies between stages), and parallel (fan out a batch of agents). With those, the agent can build any graph it wants (18:10).
Their ship-change workflow triggers after a scope and plan are well defined. It breaks into three phases: setup + implement, verify the work, and (if verification passes) simplify and open a PR (19:00).
Code-as-graph: ship-change.js declares its three phases and even routes each to a specific model. Source: 19:28
Inside the JavaScript, each agent node defines a schema, so when a session finishes it returns its result in that schema (a state output from the node). That lets you construct the next node's prompt with the important context from the last session. His article-writing example has two stages, outline (returns an outline schema of title + section bullets) then write, where phase two references the previous node's output. There is an open-source project, de workflow, that implements dynamic workflow in an open way, where each node can be Claude, Codex, or any agent library (19:41).
The open-source de-workflow project: agent() calls carry an output schema (state passing between nodes), with tutorial files for fan-out, conditional edges, and pipeline vs parallel. Source: 20:28
The one mistake that makes loops fail
Breaking a task into steps like this will not work on its own. You have to give the agent tools so it can test things properly. The author calls this the single biggest missing step behind loops that do not work, and points again at his verifier setup skill in the public repo (21:13).
His personal preferenceLLM-as-graph in most cases, because with dynamic workflow (or Codex code mode) every node starts a new agent session that cannot resume the previous conversation, which gets annoying. But for an extremely big task, code-as-graph is genuinely good. Next video teased: graph of loops, and how to make many company loops compound (21:50).
The "10x-to-100x" gap between naive prompting and full-harness use is a rhetorical estimate, not a measured figure (03:02).
Attribution of "graph of loops" to Cursor and the "colors" reference are uncertain transcriptions; confirm the actual source before citing (01:30).
Boris's "a few thousand agents overnight" is quoted from another video; treat as his claim, not independently verified (05:20).
The exact name and URL of the "de workflow" open-source project were spoken, not clearly shown; verify before adopting (20:30).
"OpenAI and Anthropic research" supporting a dedicated planner node is referenced without a citation; find the actual papers if it matters (12:30).
Glossary
Control graph: a workflow that makes an agent produce reliable results by structuring it as nodes, edges, and state (an SOP the agent follows).
Knowledge graph: a representation of relationships between entities, used to retrieve information effectively (agent memory). Unrelated to control graphs despite the shared word.
Graph of loops: the emerging problem of coordinating many independent agent loops in one company so their errors and improvements compound favorably.
Node: a single step/action in a graph; can now be a script, a single LLM call, or a whole agent.
Edge: the transition rule deciding what happens after a node.
State: the data carried between nodes (often one status markdown file plus an append-only run log).
SOP (standard operating procedure): the documented step-by-step process a graph encodes.
LLM-as-graph: enforcing a graph by writing the SOP as text/JSON/mermaid inside a skill the agent invokes, rather than as code.
Code-as-graph: enforcing a graph with real code (dynamic-workflow JavaScript, LangGraph).
Dynamic workflow: Claude Code / Codex feature letting an agent write JavaScript with agent-specific primitives to build a graph.
pipeline (primitive): run each item through a chain of stages with dependencies between stages.
parallel / fan-out (primitive): run a batch of agents concurrently.
Orchestrator: an agent that holds full context and spins up and monitors a team of agents.
Subagent: an agent spawned by another agent to handle a scoped piece of work.
Stop hook: a runtime hook that runs at the end of an agent turn (used to check whether a goal is satisfied and loop or stop).
Verifier: a separate agent node that checks the work, because a model is poor at verifying itself.
Loop: an agent triggered by time, a goal condition, or an event rather than by a human each time.
Harness: the modern agent runtime (Claude Code, Codex) providing bash, subagents, hooks, and workflow primitives.
Skill: a packaged SOP/instructions an agent invokes as context.
Output contract / schema: the defined shape a node must return, which becomes state passed to the next node.
Personal recommendations
1
Standing "verifier node" skill for fleet workflows
The author's recurring insistence that a model can't verify itself, so a verifier is its own node, and that missing testing is the top reason loops fail. He ships a reusable verifier setup skill.
System value
The fleet already splits DONE (machine-verifiable) from ACCEPT (human) on agentic tasks; a reusable verifier skill invoked as an explicit node would make the DONE gate a first-class, standardized step rather than per-task prose.
Proposed form
Skill (reusable), invoked as a node in fleet/orchestrate flows.
Target project
alexana-workspace (fleet-control)
2
Adopt explicit node/edge/state discipline for existing SOP skills
LLM-as-graph = SOP in a skill, made reliable by separating verifier/planner nodes, defining each node's input/output, and using code for deterministic steps.
System value
Skills like /yt, /sync, /stale already are graphs; naming their nodes/edges/state and separating verifier steps explicitly would make them more reliable and easier to reason about.
Proposed form
Reference/convention doc + a light retrofit of one existing skill as a pilot.
Target project
alexana-workspace (skills)
3
Standardize an append-only run-log state artifact per agentic task
The author's state pattern is one status markdown file plus an append-only lock/log from each run, so any agent can grasp current state fast.
System value
Maps directly onto the fleet's per-initiative build-journals; a standardized append-only run log per agentic task would give sub-agents a consistent, fast state read and reduce cross-run confusion.
The daily bad-design triage skill: pull candidates by heuristic, run deterministic script checks, fan out vision judges with an output schema, rank the worst, publish a list, feed an eval set.
System value
The same shape fits a daily lead-quality triage (PlanScout) or a daily site-QA sweep, turning a vague "keep an eye on X" into a reliable scheduled loop with a published list.
Proposed form
Skill + scripts + a scheduled trigger.
Target project
PlanScout or a chosen site (decide the surface first)
5
Per-node model routing + output schemas in the Workflow tool
ship-change.js declares phases and routes each to a specific model (opus for implement, sonnet for verify/PR), and every node returns a defined schema that becomes the next node's context.
System value
The fleet's Workflow orchestration already fans out; explicit per-node model routing (cheaper models on mechanical nodes, strong models on judge/plan nodes) plus schema output contracts would cut cost and tighten state passing.
An open-source dynamic-workflow implementation where each node can be Claude, Codex, or any agent library.
System value
If it cleanly runs mixed Claude/Codex nodes, it could be a portable code-as-graph layer for cross-agent fleet work; worth a read against the existing Workflow tool before adopting anything.
Proposed form
Research spike (verify repo name/URL first, per Claims to verify).
Target project
alexana-workspace (evaluation only)
Take this with you
Save the playbook to read later, or hand the raw notes to your favorite AI.
What's this?
The Markdown file (a .md file) is a plain-text copy of this whole playbook, written in the simple format AI chat tools read best. It keeps the headings, links, timestamps, and captions and drops all the page styling. Think of it as the raw notes behind this page, ready to hand to an assistant.
To use it, download the file and drag it into ChatGPT, Claude, or any AI chat (or just paste the text in), then ask for what you want: “Summarize this into a one-page cheat sheet,” “Turn these steps into a checklist I can follow,” or “Quiz me on the key ideas.” Because the file is already structured, the assistant works from the real content instead of guessing.
