Barnaby Robson

Artificial intelligence

Graph engineering: the shape of AI work

How jobs, dependencies, shared state, independent checks and human gates turn AI into a managed workflow.

In May I wrote that we are all going to have to become engineers. Once an AI agent can act, intelligence stops being the hardest problem. Control takes over: scope, sequence, evidence, permissions, checks and memory.

I now have a useful name for the next part of that education: graph engineering.

The idea follows a simple progression. A prompt sharpens the question. Context supplies the right material. A graph designs the work around the model: who does what, in which order, against which evidence, and where a human must intervene.

Prompt engineering shapes an instruction, context engineering supplies relevant material, and graph engineering designs the managed workflow. FIGURE 01 GRAPH ENGINEERING Three ways to improve AI work

The unit of improvement grows from an instruction, to a task, to a repeatable way of working.

This is the concept I was reaching for in that earlier essay. Skills, hooks, worktrees, reviewers and approval gates become much easier to understand when you see them as parts of a graph. Each part has a job. The connections carry work forward. Shared state lets the system remember what happened.

The workflow is the product

Most AI work still takes place in one long chat. The model interprets the question, chooses a research plan, gathers evidence, writes an answer and judges its own result. All those decisions disappear into one confident block of text.

One opaque chat is separated into planning, parallel research, challenge, synthesis and human approval. FIGURE 02 GRAPH ENGINEERING A workflow you can inspect

A graph exposes the jobs and hand-offs that a long chat hides.

A graph separates the roles. A planner breaks the question into parts. Specialist workers take different paths, often in parallel. A sceptic attacks weak evidence. A merger assembles what survives. A human approves the decision before it becomes expensive.

The final answer may still be a page of prose or a pull request. Its production is now inspectable. You can see which source supported a claim, which test failed, what the reviewer rejected and who authorised the last step.

The same model can perform several jobs. Separation still matters because each job receives its own instruction, context and output. A checker begins from the evidence and the acceptance criteria rather than inheriting the author’s confidence. This is the AI equivalent of keeping the maker and approver roles distinct.

A single AI model performs distinct roles through separate instructions, context and output files. FIGURE 03 GRAPH ENGINEERING One model can hold several bounded jobs

Role separation comes from the job boundary, even when every node uses the same model.

Graph engineering turns AI work into a managed system of jobs, dependencies, shared state, independent checks and human gates. It also leaves a trail that makes the next run smarter.

Jobs, arrows and state are the basic vocabulary

The useful definition is wonderfully plain:

  • Jobs are bounded pieces of work with a named output: research the customer, edit the code, test the page, challenge the recommendation.
  • Arrows express dependency and movement. They show what must finish first, what can run together, and what gets sent back around a loop.
  • State is the shared record of what the system knows so far: source notes, decisions, files, test results, approvals and failures.
Jobs are connected by dependency arrows while shared state runs underneath the workflow. FIGURE 04 GRAPH ENGINEERING The minimum graph grammar

Jobs do the work, arrows constrain its movement, and state gives every job a record it can inspect.

State is the part people often skip. Without it, a diagram can look clever while every worker starts from scratch. With it, the graph has continuity. One job can inspect what another produced, compare versions and resume after an interruption.

Each job writes an artefact into a persistent trail that the next job and the next run can inspect. FIGURE 05 GRAPH ENGINEERING State turns a run into memory

Named artefacts turn a run into memory. The trail can be read by the next job, the next session and the next model.

There are two related meanings of graph in AI. A knowledge graph connects things: a customer works at a company, that company uses a product, and a support issue concerns a feature owned by a team. An agent graph controls movement through work. The strongest systems can use both, but the agent graph is the immediately practical idea for anybody already using Claude Code, Codex or another agent.

A knowledge graph connects entities and meaning, while an agent graph directs the movement of work. FIGURE 06 GRAPH ENGINEERING Two graphs answer different questions

A knowledge graph explains how information connects. An agent graph directs how work should move.

Build backwards from the decision

You can build a useful graph without an orchestration framework. Start with a piece of work you already repeat and draw it on paper.

  1. Name the outcome and the person who can accept it.
  2. List the evidence that person would need in order to trust the result.
  3. Turn the work required to produce that evidence into bounded jobs.
  4. Draw the dependencies, including branches that can run in parallel and joins where their outputs meet.
  5. Put an independent check before any step where a plausible error becomes expensive, public or hard to reverse.
  6. Decide what each job must leave behind so the next job can continue from recorded state.
  7. Run the graph manually once. Automation earns its place after the structure produces better work.
A build decision moves from planning through four independent evidence lanes, challenge, synthesis and human approval. FIGURE 07 GRAPH ENGINEERING A decision graph in practice

Start with the decision and work backwards to the evidence needed to support it.

This backwards method exposes missing work quickly. If a recommendation has no evidence job feeding it, the gap is visible. If five researchers all depend on the same unanswered decision, the apparent parallelism disappears. If a human approval has no acceptance criteria, the gate becomes ceremonial.

Graph engineering progresses from a manual drawing, to a file trail, to orchestration only after the workflow proves itself. FIGURE 08 GRAPH ENGINEERING Draw the graph before you automate it

Automation comes third. A hand-drawn workflow and a dependable file trail are already useful graphs.

A graph earns its place when failure matters

A short email draft can live happily in one chat. Graphs become useful when work has several steps or sources, contains parallel paths, needs independent checks, carries risk, or ends in an approval.

A graph becomes useful as steps, sources, parallel paths, checks, risk and approvals accumulate. FIGURE 09 GRAPH ENGINEERING When a graph earns its place

The need for a graph rises with dependency, risk and the cost of being wrong.

Coding is an obvious example. A coding graph can plan the change, edit in an isolated worktree, review the diff, run tests, inspect the interface, hunt edge cases and stop at human approval for the pull request. The code-writing node is only one part of the system.

Consulting work has the same shape. A planner frames the question. Research paths cover the customer, market, competitors and economics. A sceptic looks for contradictory evidence. A synthesis job turns the surviving material into a recommendation. The decision-maker sees the evidence and the challenge before approving the answer.

Support, content and code workflows use separate worker and checker jobs before a human or downstream output. FIGURE 10 GRAPH ENGINEERING Three graphs worth stealing

The same grammar travels across support, content and code. The checker stays outside the job that made the thing.

I use one test: could a plausible mistake become costly, difficult to spot, or repeated at scale? A graph is usually worth drawing when the answer is yes.

The diamond is the useful first shape

The best first graph is a diamond. One question enters at the left. A planning job splits it into several paths. Those paths run independently. A sceptic checks the results, a merger joins them, and a human gate closes the decision.

One question splits into parallel evidence paths, then challenge and synthesis bring it back to one human decision. FIGURE 11 GRAPH ENGINEERING The diamond pattern

The diamond adds independent evidence paths, then brings them back through challenge and synthesis to one decision.

The diamond works because it adds diversity where evidence is gathered and discipline where judgement is made. It also stays small enough to run manually. Separate terminal sessions and a handful of files are enough. Each lane writes its own output, then the checker reads those files cold.

The pattern travels well. Customer support can classify an issue, inspect the account and search policy before drafting and checking a reply. Content work can research, form a thesis, draft, test specificity and then branch into titles and captions. Software work can move through planning, editing, review, tests and human release approval.

The checker should remain a separate job. Asking the author to score its own answer mostly measures confidence. Give the checker the original goal, the evidence and explicit acceptance criteria, then let it attack the result.

Wayfinder clears the decisions before the build

Large projects often begin in fog. The destination is visible while the route is still full of unresolved decisions. My Wayfinder skill treats that uncertainty as a graph in its own right.

Wayfinder records a destination, the decisions already made, the questions that can be specified now, the fog that will become clearer later, and the work ruled outside the effort. Each decision becomes a ticket sized for one focused session. Native blocking relationships reveal the frontier: the open questions that are ready to be worked because their prerequisites have closed.

This gives a long programme a shared map. Parallel research can proceed where the dependencies allow it, while human decisions stay human. Every resolved ticket adds a short pointer to the map and may expose the next question. The process ends when the route to the destination is clear enough to hand into execution.

Wayfinder is therefore a decision graph. It answers which questions must close, in what order, before the build can proceed with confidence. This prevents premature implementation from hardening an assumption that should have been examined first.

Closed decisions lead to an active frontier, blocked questions wait on dependencies, and fog clears on the route to a named destination. FIGURE 12 GRAPH ENGINEERING Wayfinder finds the next decision

Wayfinder keeps the active frontier small: work the decisions that are ready, record each ruling, and expose the next part of the route.

Compound Engineering runs the delivery graph

The Compound Engineering skills supply the next layer. Their familiar sequence is:

Brainstorm → Plan → Work → Review → Compound

ce-brainstorm decides what should be built and records the requirements. ce-plan works out how to build it. ce-work executes the plan, usually in an isolated worktree created by ce-worktree. ce-code-review inspects the diff through a separate review context, while ce-test-browser or ce-dogfood exercises the affected user journey. ce-compound records the solved problem and any useful project vocabulary so later work can begin with what was learned.

Seen as a graph, the skills become easier to combine. The nodes are named jobs. The arrows carry approved requirements, plans, diffs, test evidence and review findings. Git, issue trackers, test output and session notes provide state. User approval becomes a hard gate before broad edits, publication or deployment.

The loop matters as much as the forward path. A failed browser check returns to implementation. A review finding sends the change back for correction. Once the checks pass, compounding writes the lesson into the repository. The next agent can retrieve the reason behind a decision instead of rediscovering it inside a vanished chat.

Brainstorm, plan, isolated work, review, browser testing, human approval and compounding form a loop around shared state. FIGURE 13 GRAPH ENGINEERING Compound Engineering is a delivery graph

Compound Engineering is a delivery graph: separate jobs, visible evidence, feedback loops and a human gate before release.

My programme graph is a working record

I have started using this pattern for the blook programme, a large rework of my visual-production skills. Its Wayfinder map was absorbed into a programme graph once the major decisions were clear. Every open ticket appears as a node; standing rulings appear as completed nodes; dependencies determine what is ready, blocked or waiting at a gate.

The implementation is deliberately boring. YAML holds current state, a renderer produces the readable HTML page, and an append-only JSONL file preserves every transition. The current graph contains 18 tickets and 100 recorded transitions. Where a node declares its inputs and output, content fingerprints can warn that the output has become stale after a source changes.

That last feature matters. A project graph can lie beautifully if its status is typed by hand and never checked. Derived status and recorded transitions give the picture some teeth. I can open one page and see the programme’s shape, then inspect the underlying ticket or source file when I need the detail.

The graph also tells an agent where it may act. A ready node is available. A blocked node names its unmet dependency. A gate requires a person. The programme can survive a new session, a different model or a week away because its state lives in files rather than recollection.

The Wayfinder map feeds a YAML state file, which derives ticket status, renders an HTML view, records transitions and checks declared outputs for staleness. FIGURE 14 GRAPH ENGINEERING My blook programme graph is a live record

The blook programme keeps state in YAML, derives status, renders a readable view and records transitions so the picture remains accountable to its files.

Build the smallest graph that improves the work

Graph engineering can become its own form of procrastination. Huge diagrams create coordination costs and give ordinary work an impressive costume. The remedy is to begin with one workflow, one diamond and one expensive failure point.

Draw the jobs. Add only the dependencies that genuinely constrain them. Separate the worker from the checker. Place a human gate immediately before the costly action. Make every job leave a useful artefact behind. Then run the graph manually and watch where it breaks.

Only repeated, stable transitions deserve automation. A set of terminal lanes and markdown files is already a graph. The next level might use a repository and scripts. LangGraph, AutoGen GraphFlow, n8n or Make can arrive when persistence, branching, loops and external systems create a real need.

The residue is the compounding advantage. Each run leaves evidence, drafts, decisions, test results, review comments and provenance. That record becomes better context for the next run. Over time, the system develops memory around the work it performs.

A worker, an independent checker and a human gate create a compact loop whose artefacts make the next run smarter. FIGURE 15 GRAPH ENGINEERING The smallest graph that improves the work

The smallest useful graph separates making, checking and approval, then keeps the residue for the next run.

The durable gain comes from repeatability. Quality depends less on remembering a magical prompt and more on a system you can inspect, correct and reuse.

That is graph engineering in plain English. Design the work, preserve its state, separate makers from checkers, and keep humans at the gates where mistakes get expensive. The model can change next month. The shape of good work will last longer.