Graph Engineering: How I’m Wiring My AI Loops Into an Organization

Boris Cherny, the engineer who built Claude Code at Anthropic, said the thing that reorganized how I think about my own work: “I don’t prompt Claude anymore. I have loops that are running. They’re the ones that are prompting Claude and figuring out what to do.”

That one line became a whole vocabulary this summer. Addy Osmani, an engineering lead at Google Chrome, wrote it up as loop engineering — you stop writing prompts and start building the system that writes the prompts. Then, almost as fast, the conversation jumped a level. Peter Steinberger, the developer who built PSPDFKit, posted the question that named the next thing: “Are we still talking loops, or did we shift to graphs yet?” And so graph engineering arrived.

I’ll be honest about the discourse: a good chunk of it is people racing to plant a flag on a new term, and some of the “you must adopt this framework” energy is just marketing. I’m not writing to sell you a methodology. I’m writing because the framing genuinely changed how I run my own small operation — a company of one with a lot of loops — and I want to show you my actual thinking so far. This is a work in progress. It will change. But here’s where I’ve landed on graph engineering, and how I’m using it to build.

The shift: your operation is a graph, not a to-do list

A loop is a single automated thing that fires on a clock: a script that drafts your welcome email when someone subscribes, a job that refreshes a dashboard every morning. Loop engineering is the craft of making one of those run well without you. It’s real, and it’s a leap.

But once you have a handful of loops, you notice they don’t know about each other. Each one is an island with a timer. You’re still the ferry between them — carrying the output of one over to become the input of the next. The insight of graph engineering is to stop thinking in isolated loops and start seeing the whole operation as a directed graph. Loops are just nodes that happen to fire on a clock. The leverage isn’t in the nodes. It’s in the edges — the handoffs between them.

The five words the whole practice runs on

This is the vocabulary I keep coming back to. Five words. If you get these clear, everything else is bookkeeping.

• Node — anything that does work or holds state: an automated routine, a skill, a database, a dashboard, a client — and you.
• Edge — a handoff. The output of one node arriving as valid input to the next without you reformatting it. An edge is only real when the artifact is typed and lands in a known place — a database row, a folder, a channel, a draft in your outbox. “I’ll paste it over” is not an edge; that’s you being the ferry.
• Trigger — what fires a node. There’s a ladder, from most to least dependent on you: you → you-on-a-schedule → an event → a clock. Most of the work is promoting triggers up that ladder.
• Gate — a quality check, treated as its own node. The place you look, judge, and approve. Gates are where your taste lives; almost everything else can be handed off.
• State — the graph’s memory. If a node’s output isn’t written down somewhere the next node can read, the graph forgets it — and you become the memory. That’s the failure mode to design out.

The map most of us are actually running: hub-and-spoke

When I drew my own operation honestly, nearly every edge passed through me. I was doing three jobs at once:

1. The router — deciding what goes where. This recording becomes that document; this spreadsheet becomes that dashboard.
2. The trigger — most things happened because I remembered to make them happen.
3. The gate — the quality judgment on everything.

Only the third one is a good use of a human. Routing and remembering are transport and clockwork — exactly what the graph should absorb. That reframing is the whole game: keep yourself on the gates; get yourself off the wires.

The practice: four moves, one edge at a time

I don’t try to automate the whole operation at once. I promote one edge a week. Each time, it’s the same four moves.

1. Name the contract what goes in, what comes out

For every node, I write down three things: the input artifact, the output artifact and where it lands, and the “done-when.” A node without a contract can’t have a reliable edge, because the next node has no idea what to expect. I keep all of these in one plain registry file — the single source of truth for what runs.

A contract, not a script — the output lands somewhere known (my outbox), so the next node — me — can just look.

2. Type the artifact make it land where the next node already looks

The reason a good edge feels like magic is that the output shows up exactly where the next node is already looking. My morning summary works because it reads precisely what the overnight refresh writes — same shape, same place. No translation step. If two nodes disagree about the shape of the thing passing between them, you are the translation step, forever.

3. Promote the trigger move it up the ladder

This is the heart of it. Every node starts life fired by you. The work is walking it up one rung at a time — and you almost never need to jump straight to the end.

The trigger ladder. Graph engineering is mostly the patient work of moving edges rightward — one per week, never all at once.

4. Keep yourself on the gate, off the wire the non-negotiable

Every promotion should reduce how much routing and remembering you do, and preserve your judgment. You’re not automating yourself out of the work — you’re automating yourself out of the transport so you can spend your attention on the calls only you can make. And when a gate proves boring — when you approve it “yes” every single time — that is data. Demote it to a spot-check. Don’t stand guard over a door nobody’s trying to walk through.

How you know it’s working

Vibes aren’t enough; I try to actually watch a few numbers. You don’t need a dashboard for this — just an honest count.

Why I’m building it this way: the graph is the org design

Here’s the part I find genuinely exciting, and the reason I’m doing this now rather than “someday.” An org chart is just a graph of who hands what to whom. If I build my operation as an explicit graph today — contracts, typed artifacts, gates — then the organization is already designed, whether or not I ever grow it.

The arc I’m walking, roughly, is four steps:

1. Instrument. You can’t engineer a graph you can’t see. Write down every loop and its contract first.
2. Promote triggers. One edge up the ladder each week. Mornings should start from a proposed list, not a blank page.
3. Group into pods. Bundle related loops into functions — delivery, growth, the back office — each with a weekly review that reports only the exceptions. You read five summaries, not twenty raw outputs.
4. Run on exceptions. The default day becomes gates, real relationships, and the handful of things that actually need a human. Everything routine flows through the graph.

And if I ever do bring someone on — a person or a more capable agent — they don’t inherit a task list. They inherit a pod: its loops are their tools on day one, and the contracts are their job description. Growth stops being “invent a bunch of new process” and becomes “hand off a subgraph.” Which means I can defer the hiring decision without deferring the org design. The design is the graph, and the graph exists now.

This will change — and that’s the point

I want to be clear that this is a snapshot of my thinking, not a finished doctrine. The terms are six weeks old. Half of what I just wrote I’ll probably revise once I’ve promoted a few more edges and watched what breaks. But the core has already earned its place in how I work: the human belongs on the gates, not on the wires. The loops do the transport and the clockwork and the first drafts; the judgment stays with me. That’s not a defensive crouch against automation — it’s the most optimistic version of it I know. Build the graph. Stay in the loop.

— Joe