A graph of agents is a diagram. Running it is an operating system.

Draw it on a whiteboard and graph engineering looks solved. A researcher node fans out to three search nodes, they fan back into a writer node, a reviewer node checks the draft and routes it back on failure. Clean boxes, clean arrows, everyone nods. Then you try to run it on Monday, and the diagram quietly turns into you: copying the researcher’s output into the writer’s prompt, remembering which draft the reviewer already rejected, holding the state that the arrows only pretended to carry. The graph was never the hard part. Running one without becoming its wiring is.

Graph engineering is how you run many agent loops as one governed system, and you run it on an AI operating system, a system of record every loop reads and writes, a system of intelligence that reasons over it, and a system of action that executes, not on a folder of agents glued together by hand. This post is about that gap: why the diagram is free, why the runtime is the whole game, and why running graph engineering is an operating-system problem, not a drawing problem.

The graph is the right idea

Start by giving the idea its due, because it is real. A year ago the unit of work was the prompt. Then Boris Cherny described his own job in a line that spread fast: “I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.” A loop is one agent’s outer cycle, discover, plan, execute, verify, repeat, with the agent driving the cycle instead of a human clicking each step. Then in July, Peter Steinberger posted the joke that named the next layer, “Are we still talking loops or did we shift to graphs yet?”, and the framing settled into a stack: a prompt shapes one call, a harness is the code around the model, a loop is one agent’s cycle, and a graph is the org of those loops, specialist nodes joined by edges that route, fan out, fan in, and veto. It is cumulative, not a replacement: a graph is full of nodes, a good node is a well-run loop, a good loop needs a real harness. That much is sound, and the mechanics, node, edge, shared state, a verifier node that is a different agent from the producer, are worth building on.

But notice what the diagram assumes and never provides. Every arrow assumes a piece of state moves from one node to the next and arrives intact. Every “fan back in” assumes something merges the parallel results without losing half of them. Every “route back on failure” assumes a memory of what already failed. The boxes are the easy 20 percent. The state that flows between them, and the thing that holds it, is the other 80 percent, and it is not on the whiteboard.

The naive way to run it: glue the agents together

So how do teams run a graph today. The honest answer, for most, is by hand. You open Claude Code in one place, Codex in another, a chat assistant in a third, maybe a background worker somewhere, and you wire them together yourself: the output of one becomes the prompt you paste into the next, and your own attention is the shared state that keeps the whole thing coherent. It works for a demo. It is a graph the way a row of people passing notes is a network.

It fails for one structural reason, and it is the same reason every time: there is no shared system of record. Each agent keeps its own context, so nothing but you knows the whole state of the work. The moment the graph has more than a couple of nodes, you are the wire, copying context between tools, reconciling their disagreements, remembering what each one already did, exactly the clipboard problem that shows up the instant you try to orchestrate agents by hand. And because nothing holds the record, nothing can audit it: when a node claims it finished, there is no shared ledger to check the claim against, so “done” is a message you trust instead of a fact you can verify.

The frameworks that do give you a graph runtime, LangGraph, Google’s Agent Development Kit, Microsoft’s AutoGen graph flow, are real and they predate the buzzword, which the skeptics were right to point out. They hand you nodes, edges, conditional routing, even durable execution that resumes after a crash. What they do not hand you is your company’s system of record. They run the graph; they do not hold the truth the graph is supposed to operate on. That is the difference between an orchestration library and an operating system, and it is the difference that decides whether the graph runs your company or just runs a script.

What actually runs a graph: the three layers

Here is the part the diagram leaves out, and it is the whole answer to “how do you run graph engineering.” You run it on three layers, and an AI operating system is the thing that gives you all three at once.

The first is a system of record: one place the whole graph reads state from and writes results to. This is what turns the arrows from wishful thinking into plumbing, because the state does not travel node-to-node in someone’s memory, it lives in the record and every node reads and writes the same copy. The second is a system of intelligence: the graph of loops itself, reasoning over that record, the specialist nodes deciding what to do next. The third is a system of action: the execution layer that carries out those decisions against real systems and writes the outcome back into the record it started from, so the loop actually closes instead of stopping at a recommendation a human still has to carry out. Those three layers are the architecture the AI era is converging on, and graph engineering is what you do on top of them once you have them.

Run a graph on those three layers and the failure modes of the hand-wired version disappear. State stops leaking because there is one record. Coordination stops living in your head because it lives in the record every node shares. And “done” stops being a message you trust, because the record holds an audit trail and a verifier node that the producing loop cannot rewrite grades the work against ground truth. The graph is still the design. The operating system is what makes the design a thing that runs.

Why ApolloSpace AI treats this as an OS problem

This is the bet behind ApolloSpace AI, stated plainly: graph engineering is not a diagram you buy, it is an operating system you run your company’s work on. Apollo is built so your agents are nodes in one graph on a shared system of record, the loops reason over that record as a system of intelligence, and a system of action executes and writes the result back, with the grounding wired in from the start, anchors that read real outcomes, rules the loops are forbidden to tune, and a human gate that lives outside the optimization rather than as a step inside it. You do not assemble that from a folder of separate agents, any more than you assemble an operating system by opening five apps at once. The OS is the thing that was missing under the graph the whole time.

That framing also keeps us honest about the cost, because an operating system is a bigger commitment than a library. You give up the freedom to swap in a different best-of-breed tool for every node, in exchange for the three layers staying inside one boundary where the loop can actually close and be audited. For a weekend script, that trade is not worth it, wire two agents together by hand and move on. For a company that wants its work to run as a system instead of a pile of tabs, it is the only trade that ends with a graph that runs itself instead of a graph that runs you.

The turn: the diagram is free, the OS is the moat

Anyone can draw the graph. The boxes and arrows are already a commodity, the frameworks ship them, and a competitor can copy your diagram off a slide in an afternoon. What they cannot copy off the slide is the operating system underneath it: the system of record your loops are wired to, the grounding that keeps them touching reality, the audit trail that makes “done” a fact. That is not on the whiteboard, and it is the entire difference between a graph of agents that looks impressive in a demo and one that quietly runs your operations on a Tuesday while you are doing something else.

So the answer to “did we shift from loops to graphs yet” is yes, and it is also the wrong question. The shift that matters is not from loops to graphs. It is from a diagram of agents to an operating system that runs them, from you being the wire to a system of record being the wire, from a graph you coordinate by hand to a graph that coordinates itself because everything it needs lives in one grounded place.

---

ApolloSpace AI is that operating system: your agent loops as one governed graph, running on a system of record, a system of intelligence, and a system of action, so the graph you draw is the graph that actually runs, grounded and audited, instead of a diagram you hold together by hand. If you want to run graph engineering instead of drawing it, join the early access list.