Graph engineering: running real work step-by-step

Another month, another term. This one earns it.

Prompt engineering. Context engineering. Vibe coding. Every few weeks the timeline produces a new phrase, and the honest first reaction to most of them is to wonder whether anything new was actually described. Graph engineering is the current one, and we think it is worth keeping.

Here is the framing we find clearest. Prompt engineering is how you ask better. Context engineering is what you feed the model. Graph engineering is how you design the work around the model, so the whole thing stops living inside one enormous chat window.

The problem with one big answer

Ask a model whether you should build your startup idea and you get something confident: market size, a few competitors, a go-to-market sketch. It feels like research. Slow down and notice what happened. One model, in one pass, decided what mattered, gathered the evidence, interpreted it, wrote the recommendation, and rated its own confidence. That is a lot of weight on a single blob of text, especially if the answer is going to consume the next two years of your life.

The graph version splits that work into jobs connected by arrows, which is all a graph is. A planner breaks the question into angles. Separate researchers take customers, competitors, and distribution at the same time, because none of them depends on the others. A skeptic tries to kill the weakest findings. A merge step turns what survives into a one-page recommendation. Then a human approves it before anyone acts.

A lot of AI research fails for one boring reason: the model writing the answer is also the model grading it.

Two things people mean by "graph"

Most of the confusion around the term comes from conflating two ideas:

• Knowledge graphs describe how information connects: this customer belongs to this company, which uses this product, which is owned by this team. Useful when plain retrieval keeps returning paragraphs that look similar to the question but miss the relationship that actually answers it. Microsoft's GraphRAG is the well-known implementation.

• Agent graphs describe how work moves: who plans, who researches in parallel, who checks, who merges, where the human signs off.

Agent graphs are the ones you can adopt this week without touching your data infrastructure. Mature systems eventually want both.

When it is worth the trouble

Not every task needs this. Brainstorming ten product names does not. Summarising an email does not. The rule we use is narrow and practical: reach for a graph when the work has several steps, some of which can run at the same time, and the output needs checking before it matters.

That covers more than people expect. Support triage becomes classify, pull account context, search policy, draft, review for tone and risk, then escalate anything involving refunds or angry customers. A coding workflow becomes plan, edit, review the diff, run tests, probe edge cases, then a human approves the pull request. In both cases the model writing the output is one node among several, and the leverage sits in everything around it.

Draw it before you automate it

The common mistake is reaching for a framework on day one. Run the first version by hand. Open Excalidraw, write the final outcome at the top, list the jobs a good human team would do, and draw arrows only where one job genuinely depends on another. Then run each job in its own lane, manually.

Level two is a repo where every step writes a file: plan.md, customers.md, competitors.md, review.md, recommendation.md. Slower than full automation, but it leaves a paper trail you can inspect, diff, and reuse. Only then does orchestration earn its keep: LangGraph for state, checkpoints and human-in-the-loop approvals, AutoGen for branching and loops, n8n or Make when the graph has to touch Slack, email and your CRM.

Automating a workflow you do not understand produces mediocre work faster. That is the whole warning.

How we think about this at Birdhouse

This maps closely to how we build. A few principles we keep coming back to:

• Bigger graphs are not better graphs. Five agents confidently repeating the same wrong idea is worse than one careful pass. Aim for the smallest graph that measurably improves the output.

• Checking is its own job. An adversarial reviewer with no stake in the draft catches what the author cannot. Never let the writer grade the writing.

• Put the human gate where mistakes are expensive. An internal memo needs a light touch. Production data, customer-facing emails and deploys do not.

• Design for the paper trail. Every run should leave evidence, drafts and decisions behind. The graph produces the work, and the artefacts make the next run smarter.

That last point is the compounding one. The output of a good workflow is not just this week's recommendation, it is an accumulating record of what your team has already investigated and decided. Tools like Claude Code make the file-per-step version cheap enough that there is no reason to skip it.

Pick one workflow you already run weekly. Write the final output in a single sentence. List the jobs, draw the arrows, run the independent ones in parallel, add a skeptic, and approve the last step yourself. That is your first graph, and it is the point where you stop prompting AI and start managing it.