A guide to graph engineering for people who don't code

A developer published a guide arguing that "graph engineering" — the practice of structuring AI agent tasks as parallel graphs rather than sequential lists — is a real technique roughly two and a half years old, while the name itself is only about six weeks old and largely a joke. The guide claims that recent tooling lets users describe a job, have Claude generate an execution plan, and review the order of operations before any tokens are spent, removing the need to write orchestration scripts. It also warns that two configuration settings can silently break a graph setup and offers a free GitHub repository for experimentation.

Watch an AI agent work through a list sometime. Say you’ve asked it to check what six competitors changed on their pricing pages. It reads the first one. Writes a note. Reads the second. Writes a note. Reads the third. Sixteen minutes later you have six notes. Here’s the thing: not one of those six checks needed anything from the check before it. Competitor two’s pricing page has no idea competitor one exists. Those six jobs ran one after another for exactly one reason — that’s the order you typed them in. Sixteen minutes should have been three. I assumed for a long time that this was just what using an agent felt like. You give it a list, it works the list, you wait. Then I started drawing my own work out as boxes and arrows, and found that most of the waiting in it was for nothing. Not a model problem. A shape problem — and the shape was one I’d drawn by accident, by typing things in an order. That drawing has a name now, and the name has been unbearable for about six weeks. If you’ve been anywhere near AI in the last six weeks, you’ve watched “graph engineering” arrive. It got coined in a twelve-word joke post at half past midnight, had a manifesto four hours later, and had paid courses two days after that. You’ve probably also seen the other half of the timeline: the guy who built LangGraph publicly saying he doesn’t really know what graph engineering is and it seems to just be his own product, and a very good argument about whether a million lines of AI-written code can be reviewed by anyone at all. So you’re a little interested and a little suspicious. That’s the correct amount of both. I was there too. Here’s what I found underneath it. The technique is real and it’s two and a half years old. The name is six weeks old and mostly a joke. And the tooling — the part nobody’s written about — shipped seven weeks before the name did, and it changed who this is for. Because the version of this you’ve read about involves writing an orchestration script. That’s what every explainer teaches, and it’s why you bounced. You don’t write the script anymore. You describe the job, Claude writes the plan, and you get a screen showing you exactly what’s about to run and in what order, before a single token gets spent. Then you approve it, or you don’t. Reading a plan and asking why one thing is waiting on another — you’ve done that a hundred times. That’s the whole skill. Six weeks ago I wrote that three loops was the ceiling, because three is more than most people can watch. That still holds. What I got wrong was calling them three separate things. Three loops touching the same file in the same week aren’t three loops. They’re a graph nobody drew. It’s a bit fiddly to set up — two settings will break it silently and neither one gives you an error. I found them the slow way. Here’s exactly how you can skip that: What you’ll have by the end: - A test you can run tonight that finds the wasted waiting in whatever process you run today. Costs nothing, takes ten minutes, needs no tools. - Your first graph running , every screen shown, including the two settings that break it. - Nine copy-paste prompts for work you already do — research briefs, number checks, feedback piles, contract folders. - The five graphs you’ll want to build and shouldn’t , and what to do instead. Two things this won’t do. It won’t make you an engineer — you won’t write a line of code and I’m not going to pretend you should want to. And it won’t make your judgment better. A graph buys width, nothing else, and almost all the disappointment in this space comes from people who wanted the other thing. It’s also long, and you won’t have it running perfectly in one sitting. That’s not the goal. The goal is one job of yours, running wide, by Friday. Download the free github repo here to start playing with graphs: https://github.com/johnmoneyman1000x/graph-engineering https://github.com/johnmoneyman1000x/graph-engineering First, what a graph actually is Skip this if you already know. It’s four bullets. - A node is one job. One agent, one task, one thing in, one thing out. Research one competitor. Check one claim. Read one file. - An edge is a dependency. It means this job needs what that job produced. It only exists when something real travels along it. - State is the shared notes. What’s been found, what’s been decided. Every node reads it. Every node can write to it — which is where graphs go wrong. - A loop is a graph with one node pointing at itself. You already run three. This isn’t a new discipline; it’s the one from last month, drawn wider. That’s the whole vocabulary. Two quick disambiguations, because both will waste your time if you search: Not a knowledge graph. Half of what you’ll find searching “graph engineering” is about Neo4j and GraphRAG — modelling your documents as connected entities. Real field, different field, same word. If you land on a page about entity relationships, back out. Not an org chart of AI employees. Nobody’s assigning headcount. The boxes are jobs, and they exist for the length of one run. One paragraph of history, because you’ll be asked. The name was coined on 18 July 2026, in a twelve-word post by Peter Steinberger asking whether we were still talking loops or had moved to graphs. Four and a half hours later Hamel Husain published Loop Engineering Is Dead. Enter Graph Engineering — and then, seven minutes after publishing, posted that if he saw it on his timeline he’d personally be afraid to click it. The underlying pattern is two and a half years old. The tooling shipped seven weeks before the name did. It’s a real technique with a joke for a title, and both halves of that are worth knowing. A loop is a graph pointing at itself. You already run three. That’s not a new field, that’s Tuesday. The test to run tonight, before you touch anything Do this before you install, configure or pay for anything. It’s free and it’s the highest-value ten minutes in the article. Take one process you run regularly. Writing a weekly update, prepping for a client call, researching a decision. Write out the steps in the order you actually do them. Now go step by step and ask one question: Does this step read the result of the step before it? If yes, the arrow is real. Keep the order. If no, there’s no arrow — and the waiting is time you’re paying for and not using. Here’s what it looks like on something that actually costs you money. Churn doubled last month. You need to know why before the board call on Thursday. So you work it the way anyone would: 1. Pull the cancellation reasons from the last sixty days 2. Read the support tickets from every account that left 3. Check whether their usage dropped before they cancelled, or only after 4. Check what changed on your side — pricing, onboarding, a release, a bug 5. Write up what happened Four investigations, then a conclusion. It feels like a sequence because you’d type it as one. It isn’t. The cancellation reasons don’t need the support tickets. The usage data doesn’t need either of them. The release log doesn’t need any of the three. Four jobs that never read each other’s results, feeding one job that needs all four. Run them in order and it’s most of a day, and you’re reading the fourth one at six in the evening with a tired brain. But speed isn’t actually the point here, and this is the part I’d underline. The answer to a churn question is almost never in one of those four. It’s in the overlap between two of them — usage dropped three weeks before they cancelled, and the release log says you shipped a new onboarding flow exactly three weeks before that. You cannot see an overlap you’re reading sequentially. By the time you get to the release log you’ve half-forgotten the shape of the usage data. Run the four at once and they land in front of you together. That’s not a faster version of the same work. It’s a different quality of answer. Same shape, other jobs: - Deciding whether to raise prices — what competitors charge, what your own customers said about value, what your usage data says about who’d actually leave. Three jobs, no arrows between them. - Diligence on a senior hire — references, work samples, and the market rate for the role. None of the three needs the others. Most people do them over two weeks anyway. - A customer asking for something custom — what it costs to build, who else has asked for it, what your contract already commits you to. Three independent questions and one decision. Do this tonight. You’ll find two or three fake arrows in the first process you draw. That’s the entire skill this article is about, and you already have it now. Everything below is how to make a machine act on it. Setting up your first graph What you need - Claude Code, v2.1.248 or later. Run claude --version to check. - A folder. Any folder. Not a code repo — a plain folder is fine. - About twenty minutes for the first one. Two things that will silently break this Both cost me time. Neither produces an error message 1. On the Pro plan, this feature ships turned off. You’ll type your prompt, nothing will happen, and there’ll be no error. Open /config , find the Dynamic workflows row, turn it on. That row is the only place it’s mentioned anywhere. 2. Don’t start Claude Code in your home directory. Trust acceptance isn’t saved to disk there, so the permission prompt comes back every single launch and no setting fixes it. Start in a subfolder instead. Set the size dial before your first run Also in /config : Dynamic workflow size , which defaults to medium . Set it to small — that’s fewer than five agents — before your first real run. This is the single best habit in the whole article. Your first attempt costs you a rounding error instead of an afternoon, and you can widen it once you’ve seen what it does. Warm up on the one that’s already built Before building anything, run this: /deep-research what are the three biggest complaints about your competitor That’s a bundled graph. It fans searches across several angles, cross-checks what it finds, votes on each claim, and returns a cited report with the claims that didn’t survive filtered out. One command. You get to watch the machinery before you’re responsible for any of it. Cost nothing, learn the shape, then build your own. Building one, every screen What we’re building: a competitor brief that tries to kill itself. One agent per competitor, working only from that company’s own pages. Then a separate reviewer whose entire job is to delete any claim it can’t quote verbatim. What lands is a brief plus a kill list of everything that didn’t survive. I picked this one because it needs no code, nothing gets sent anywhere so it’s safe to run while you’re learning, and the artifact it produces — the kill list — shows the graph removing work rather than generating more of it. Step 1 — Write the prompt Here’s what goes in. Not a template with brackets — this is the actual text, minus your competitor names. ultracode: research how our four named competitors position themselves on pricing <Competitor 1, competitor 2, competitor 3, competitor 4. Use one agent per competitor, working only from their own public pages. Then hand every claim to a separate reviewer agent whose only job is to try to kill it: any claim without a direct quote from the page it came from gets deleted, not softened. Give me one brief, under 800 words, every surviving claim with the URL it came from, and a short list at the end of what got killed and why. Don't summarize anything you couldn't quote. Steal the anatomy, not just the prompt. Four jobs in one paragraph: - Names the source and restricts it — their own pages, not the open web - States the format and the size — one brief, under 800 words - Carries the judgment instruction — delete, don’t soften - Carries the guardrail — don’t summarise anything you couldn’t quote Every prompt in this article does those four things. Yours should too. As you type, the trigger keyword lights up with a purple shimmer. If a tutorial tells you to type the word “workflow,” it predates 1 June 2026. The keyword was renamed. Asking in plain language still works. Step 2 — Read the plan before you approve it Press enter. You get an approval screen showing the phase list — for this build, something like Research · Review · Assemble — and four options: Yes, run it , Yes, and don’t ask again , View raw script , No . Stop here. This screen is the whole skill. Forty seconds of reading tells you how many agents are about to run, in what order, and what waits on what. It’s the only moment where fixing the shape is free. After you approve, there’s no intervening. Read it the way you’d read a plan from someone new on your team: - Does the order make sense? - Is anything waiting on something it doesn’t need? That’s your fake arrow, in the wild. - Is anything missing? If it’s wrong, press No and rewrite the prompt. That costs you nothing. Approving a bad shape costs you the whole run. Step 3 — Look at the script once Pick View raw script . You’ll see plain JavaScript. You don’t need to write any of it. But look once, because three words make it readable: - parallel — these run at the same time - phase — a stage of the work - agent — one worker That’s enough to check whether the machine understood you. ⟦📸 4 — the script, with a parallel block visible.⟧ Step 4 — Approve, then keep working Approve and keep typing. A progress line appears under your input box. Down-arrow focuses it, Enter expands it. Permission prompts are the one thing that stalls a run. If an agent needs a tool you haven’t allowed, it waits — quietly. Set your allow rules before a long run or you’ll come back to a graph that’s been sitting on its hands. Step 5 — Open the control panel Run /workflows . You get the list of runs. Drill in and you see each phase with its agent count, token total, and elapsed time. Along the bottom, the whole control surface in about eight characters: p and x are the two that matter emotionally. You can pause this. You can stop it. Knowing that before you start changes how it feels to start. Step 6 — Read one agent’s work Drill into a phase, then into a single agent. You see its prompt, its recent tool calls, and its result. This screen is the answer to the hardest question anyone will ask you about this: how do you review work from six agents when you couldn’t have produced any of it yourself? You open one and read it. Not all six — one, then another, spot-checked. The way you’d read two pages of a contract closely instead of skimming forty. https://claude.ai/code/artifact/ca8b4b95-660f-4d60-b03c-8e821f1bfd24 https://claude.ai/code/artifact/ca8b4b95-660f-4d60-b03c-8e821f1bfd24 If you stop an agent with x , that counts as a failure — and when you relaunch, every agent that started after it runs again, including ones that finished. Stopping is cheap. Relaunching after stopping isn’t. Step 7 — Save it, and it becomes one command Back in /workflows , select the run and press s . Tab toggles where it saves: your project folder, or your home directory. Enter saves. It now runs as /your-name and shows up in autocomplete. That’s the compounding part. The first run costs you twenty minutes. Every run after that costs you one command. Hand-edit that saved script later and you need to reload before it takes. And if you put anything but plain text values in the header block, the command silently disappears from autocomplete with no error. Nine graphs to copy and paste These are jobs you already do. Every one runs on a folder or the open web — no code, no repo. Each card has the pain, the prompt, and the gate — the thing that decides whether output survives. Gates are the difference between a graph and an expensive summary. ⟦JOHN — run each one and link the real output. A card with a link is evidence; without one it’s a recipe. If you only have time for four, publish four.⟧ 1. The research brief that kills its own claims For: any decision with money behind it. The prompt from the walkthrough above. Fan out one researcher per competitor, then a reviewer that deletes anything it can’t quote. Gate: string presence. Every surviving claim contains text that appears verbatim on the page it cites. Why this gate works and “check this for errors” doesn’t: models are bad at finding flaws and fine at fixing them once you point at one. So don’t ask a reviewer to look for problems. Ask it whether one specific string exists on one specific page. Yes or no. 2. Reconcile every number before you send it For: investor updates, board decks, monthly reports. ultracode: I'm sending the monthly update. Take the draft in update.md and the exports in /numbers. Run one agent per source file to pull the figures it owns, then a separate agent that reads only the draft and lists every numeral in it. Then a third that matches the two lists. Tell me every number in my prose that doesn't resolve to something in the exports, and every export figure I left out. Don't rewrite my sentences. Just give me the mismatches, as a table. Gate: numeral reconciliation. Every number in the prose resolves to the source pack, or it gets flagged. Note the shape: many readers, one writer. Only the last agent produces anything. That’s the pattern Cognition landed on after running their coding agent in production for a year — and it’s the reversal of their own earlier advice. Writes stay single-threaded; the extra agents contribute intelligence, not actions. 3. Fifty pieces of feedback, without deciding anything For: interview transcripts, survey responses, support tickets, sales call notes. ultracode: read every transcript in /interviews. Use one agent per file so nothing gets skimmed. Group what you find into themes, but a theme only counts if you can show me three or more quotes that appear word for word in the files, from three or more different accounts. Then a separate agent deletes any theme that contains a recommendation — I want what people said, not what you think we should do. Give me the surviving themes with their quotes and the filenames. Gate: substring match plus a distinct-account count, plus a hard reject on any theme containing a recommendation. Honest limit: this returns fewer themes than a single-prompt summary. Noticeably fewer. And the ones it drops are disproportionately the ones you liked — the elegant sweeping theme that turned out to rest on one enthusiastic customer. That’s the gate working. It will not feel like the gate working. 4. Four positions, four objections For: positioning, pricing, naming, any call where you need options rather than an answer. ultracode: I need positioning for the new tier. Have four agents each draft a one-paragraph position from a different angle — price, speed, who it's for, what it replaces — working independently so they don't read each other. Then one agent that lists, for each draft, the single strongest objection a skeptical buyer would raise. Give me the four paragraphs and the four objections side by side. Don't pick a winner. I'll pick. Gate: none, and I’m labelling it rather than hiding it. There’s no objective check on a positioning paragraph. This is a filter, not a gate. It may surface an objection you missed. It will never tell you the position is right. It earns a slot because it does something a loop genuinely can’t: four drafts written in real isolation. Inside one conversation, every draft has read the last one and they converge. Here they don’t. 5. The document pile For: contracts, policies, RFP responses, a folder of PDFs somebody dumped on you. ultracode: read every document in /contracts. One agent per file. For each one, tell me only: the renewal date, the notice period, and whether there's an auto-renew clause — quoting the exact sentence you got each answer from. If a document doesn't say, write "not stated" rather than guessing. Then one agent that puts it all in one table sorted by renewal date, and flags anything renewing in the next 90 days. Gate: quote-or-null. Every field is either backed by a quoted sentence or explicitly marked as absent. No inference. Swap the three fields for whatever you actually need. This is the highest-leverage prompt in the article for anyone with a folder they’ve been avoiding. 6. What the top pages cover, and what they skip For: writers, marketers, anyone with a content calendar. ultracode: I want to write about topic . Run three jobs at once: one lists what the top-ranking pages actually cover, section by section; one collects the real questions people ask about this, with where you found each one; one finds what the top pages all skip. Then merge into an outline where every section says which of the three it came from. Don't write the draft. Gate: provenance. Every outline section names its source job. Anything that came from nowhere is the model improvising, and you can see it. Honest limit: this gets you an outline nobody else has. It does not get you a draft worth publishing. Different job. 7. Meeting notes into decisions and actions For: anyone who runs meetings and loses what happened in them. ultracode: read the transcript in /meeting.txt. Run two agents that don't see each other's work: one extracts only decisions that were actually made, one extracts only action items with an owner named out loud. Both must quote the line the item came from. Then a third agent that checks every extracted item against the transcript and deletes anything where the quote doesn't appear verbatim, or where a decision was later reversed in the same transcript. Give me two lists. Gate: verbatim presence, plus a reversal check. The reversal check is the part worth stealing. Half of what goes wrong in meeting summaries is an action item that got cancelled twenty minutes later and nobody noticed. 8. The vendor or candidate comparison For: buying anything, hiring anyone, choosing between options. ultracode: compare option A , option B and option C on price, what's included at each tier, and what their own docs say about limits. One agent per option, working only from their own site and docs. Then one agent that builds a comparison table and marks every cell either "stated" with the URL, or "not published" — never inferred. Then one that lists what none of them publish, because that's usually the thing that matters. Gate: stated-or-not-published. No cell gets filled in from inference. The last agent is the good one. What all three vendors decline to publish is a finding, and it’s the one a single-prompt comparison always smooths over. 9. The weekly scan, saved and re-run For: keeping tabs on anything — a market, a competitor set, a regulation. ultracode: check these five sources for anything new in the last seven days about topic . One agent per source. Then one agent that drops anything already in scan-history.md, and one that ranks what's left by whether it changes a decision we've already made. Give me under 300 words, newest first, with links. Append everything you kept to scan-history.md. Gate: dedupe against history, plus a relevance rank. Run it once, then press s and save it. Now it’s one command every Monday morning. This is the one that compounds — everything else in this list is a job you do sometimes; this is a job you do forever. What broke when I ran these A worker returned nothing and the report still looked complete. This is the one to fear. Not the run that stops — the run that finishes, looks finished, and quietly ran on two-thirds of the data. The fix: at the merge step, ask it to count its inputs against the number expected and flag the gap. Two jobs that looked independent weren’t. Both writing to the same file, neither knowing. They looked independent because their prompts never mentioned each other. The fix: any two jobs that write to the same place need an arrow between them, not parallelism. The final step choked. Too many results poured into one summarizing step at once. The fix: summarize in batches, then combine the summaries. Never pour the whole pile into one node. The five graphs you’ll want to build and shouldn’t 1. The one where every step needs the last step’s answer. That’s a loop. Loops are fine. Forcing a graph onto sequential work makes it slower and worse — in one controlled study, every multi-agent variant tested degraded sequential reasoning tasks by 39 to 70 percent. Instead: keep the loop. 2. The one with a review gate in the middle. You’ll want “check with me before phase three.” There isn’t one. No mid-run input at all. Instead: run phase two as its own workflow, look at it, then run phase three. 3. The one with a node that sends something. Email, calendar invite, CRM record, Slack message. When a run fails partway and you relaunch, every agent that started after the failure runs again — including ones that already succeeded. Your send fires twice. Instead: draft it in the graph, send it yourself. 4. The panel of critics. Four agents scoring your work, one aggregating. It feels rigorous. But they share a base model and the same context, so they agree with each other, and you get impeccable structure around a wrong answer. There’s a mechanism: judges inflate anything labelled as their own, and the effect largely vanishes under blind evaluation. Instead: don’t tell the reviewer whose draft it is. 5. The forty-agent overnight run. There’s a warning line that fires above 25 agents or 1.5 million projected tokens. It is advisory only — it does not pause anything and it does not limit anything. It tells you, and then it keeps going. Instead: small until a run has earned medium . And the one that isn’t about graphs. If you build any of these and it doesn’t beat one good prompt, delete it. That’s the whole test. A graph that can’t beat a prompt is theatre, and this space is full of theatre right now — the name is six weeks old and there were paid courses for it within forty-eight hours. Including me. I’m writing a tutorial about a named discipline inside a newsletter economy. So here’s my own version, plainly: the useful part of this article is maybe half its length. The rest is what you need in order to know when not to use the useful half. What this actually costs Short version, because the honest answer is short. There is no published number for what a graph run costs. Not from the vendor, not from anyone. I looked, and three independent research passes looked. The figures that circulate — the 4× and 15× multiples you’ll see quoted everywhere — are both measured against chat , not against a single agent, and nearly every article in this space drops that baseline and reports the second number as the single-versus-multi cost. It isn’t. What the vendor’s own later testing says: 3 to 10× a single agent, for equivalent work. And in one of their own experiments, agents specialised by role spent more tokens coordinating than doing the work. So do this instead of trusting anyone’s multiplier, mine included: 1. /config workflowSizeGuideline=small 2. Run /usage . Write the number down. 3. Run your graph on a slice — two competitors, not eight. One folder, not the whole drive. 4. Run /usage again. Now you have your number, for your work, and you never have to wonder again. It takes four minutes. The rule that survives all of it, and it’s the vendor’s own: a graph is worth it when the value of the task is high enough to pay for the extra tokens. Most tasks aren’t. That’s not a criticism of the technique; it’s the technique’s own instruction manual. Start here, this week Start copying prompts from this github repo https://github.com/johnmoneyman1000x/graph-engineering to start creating loops. Tonight, ten minutes. Write out one process you run regularly. Ask, at every step, whether it reads the result of the step before it. Cross out the arrows that don’t carry anything. That’s your graph, and it cost you nothing. Tomorrow, twenty minutes. Turn on dynamic workflows in /config , set the size to small , and run /deep-research on a real question. Watch it fan out. Read one agent’s work. This week, one hour. Take number 5 from the list above — the document pile — and point it at a folder you’ve been avoiding. That’s the one where people go quiet for a minute when the table comes back. Then save it. Press s . Now it’s a command, and the next twelve times cost you nothing but the tokens. One last thing, and it’s the only rule from this article I’d put on a wall: don’t ask a node to find the flaw. Ask it to check one specific named thing, and never tell it whose draft it is. Every gate in the nine prompts above is that sentence, applied. The rest is just drawing boxes and deleting the arrows that were never there. Go find your fake arrows. — John P.S. Send this to the person on your team with six research tabs open on a Tuesday morning, working through them one at a time. They don’t need a new discipline. They need to notice that four of those tabs were never waiting on each other.