Graph Engineering: structure and control for bigger outcomes

What it is

The same territory as loop engineering, further along.

Instead of one agent working through a task from end to end, the work is given an explicit shape. Named steps. Defined routes between them. Work that runs in parallel where it can. Specific points where a person approves before anything continues. State that carries between steps and survives a failure.

The two are not separate decisions either. LangChain, who build one of the leading tools for this, point out that a loop is simply a directed, cyclic graph, and describe graph engineering as the latest name for a well established approach. So it helps to treat them as one capability area with two levels of structure.

What the structure buys

Four things, and they map onto things you probably already care about.

Parallel work. Steps that do not depend on each other run at the same time rather than in a queue. For anything with real volume, this is the difference between overnight and next week.

Approval points. Because the steps are named, you can put a person at a specific one. Not a general instruction to review things, but a defined gate the work cannot pass without a decision from someone with the authority to make it.

Recoverability. State that survives a failure means a long piece of work does not restart from the beginning when something breaks in the middle. It is the difference between a system you trust with a large job and one you only trust with small ones.

Auditability. This is often the one that matters most, and it is why regulated clients ask for it without necessarily using the vocabulary. When something goes wrong, you can point at the step where it went wrong. Not "the AI got it wrong" but "the check at stage four passed something it should have caught, here is the record." For anything you might have to explain to a regulator, a client or a board, that is often worth more than the speed.

When it is not warranted

Structure has a real cost. It takes longer to build, it is harder to change, and somebody has to maintain it. That cost is worth paying when the work is complex, high volume, or sensitive, and not worth paying because the approach is interesting.

Imposing it on something that was one straight line leaves you with elaborate architecture wrapped around a task that needed a checklist.

Anthropic's standing advice on agent design is to start with the simplest thing that works and add structure only when it earns its place. That is good advice for buying as well as building.

What to do with this

You are not going to specify a graph. What you can do is recognise when a piece of work has the characteristics that justify one, and ask directly.

The signals are straightforward. Does this run at volume? Does it touch anything regulated, financial or personal? Would you need to explain to somebody outside the business exactly what happened? Does part of it need a human decision in the middle rather than a review at the end?

If the answer to two or more of those is yes, ask your build partner which level of structure the work warrants and why. A strong answer will cover where the approval points sit and what happens when a step fails.

That is the whole series. Seven terms, and underneath them the same job it has always been: clear opportunities, clear inputs, clear outputs.

If you think you need help building these capabilities, applying them to the problems that matter, and getting real value from AI in your business, get in touch. We are always happy to talk about how we work with our clients to get there.

Part of the series that starts with The jargon is complicated. The capabilities underneath are simple.