Graph Engineering: Building AI Workflows That Can Recover

Gartner published a prediction in June 2025 that has been quoted so often it has almost lost its sting: more than 40% of agentic AI projects will be cancelled by the end of 2027, with escalating costs, unclear business value and inadequate risk controls given as the reasons. It came from a poll of 3,412 executives, and it is a forecast rather than a measurement, which is worth remembering whenever you see it in a headline (Gartner, 2025).

Forbes revisited the figure earlier this month and drew out something sharper. The problem is described there as a capability-deployment verification gap, where pilots that demonstrate beautifully quietly fall over in production because integration, data access and accountability were never designed in the first place (Forbes, 2026). Gartner also flagged that of the thousands of vendors claiming agentic capability, only around 130 were building something that deserved the label, which is how the industry ended up with a term for the rest of it: agent washing.

Read that carefully, because none of it is a story about weak models. What keeps failing is the structure around them, and the shift we want to talk about this week is one of the more useful answers anyone has offered to that problem.

What Loop Engineering Actually Is

In case you are new here, allow us to explain. A prompt loop is the simplest way to build an AI workflow, and almost everyone starts there. You give a model a task, it proposes an action, something executes that action, the result gets fed back in, and the loop runs again until the model decides it is finished. Call the model, run the tools, repeat.

Nothing is wrong with that for a bounded job. Classify an email, draft a reply, extract three fields from a PDF, retry a request that timed out. The loop is fast to build, easy to demonstrate, and perfectly adequate when the whole task lives inside one system and nobody needs to sign anything off.

The trouble starts when the work grows up. A retry can repeat an unsafe action rather than repair it, so an agent that failed halfway through issuing a credit note might helpfully issue a second one. A long, sprawling context can bury the source of a bad decision so deeply that nobody can reconstruct why the system did what it did. A human reviewer has no obvious moment to step in, because a loop does not really have moments; it has one continuous churn. And an interrupted run may have no idea what it has already changed in the real world before it stopped.

Those four failures have something in common. None of them are the model being wrong. They are all the workflow having no shape.

So What Is Graph Engineering?

Graph engineering is a practical name for designing the workflow as states and transitions rather than as one open-ended loop. Each node has exactly one job. Each edge states plainly what is allowed to happen next. The result is that the normal flow, the approval flow, the exception flow and the rollback path are all visible on paper before the system is ever given access to a production environment.

The tooling has been moving this way for a while. LangGraph, one of the more widely used orchestration frameworks, is built on precisely this abstraction, and its documentation describes the central benefits as durable execution, persistence and human-in-the-loop oversight, meaning agents that survive failures, resume from where they left off, and pause at defined points so a person can inspect or modify the state before the run continues (LangChain, 2026). The human-in-the-loop documentation goes further and makes the approval policy explicit per tool: a file write or a SQL execution can be configured to interrupt and wait for a decision, while a read-only lookup runs straight through (LangChain, 2026).

A workflow that can be paused at a named point and resumed hours later is a very different operational object from a loop that either finishes or dies.

An Honest Note on the Counter-Argument

We should be straight with you here, because the strongest case against graph engineering comes from a source we respect and we would rather you heard it from us.

Anthropic's own engineering guidance recommends finding the simplest solution possible and only increasing complexity when it is needed, and it observes that the most successful implementations the company has seen were building with simple, composable patterns rather than complex frameworks (Anthropic, 2024). The architectural analysis of Claude Code published by researchers at MBZUAI's VILA Lab and University College London makes the same point structurally: Claude Code deliberately does not impose explicit planning graphs on the model's reasoning, and the paper names rule-based orchestration of the LangGraph variety as a genuinely different design family, one that chooses scaffolding where Claude Code chooses a minimal harness with rich operational infrastructure around it (Liu et al., 2026).

That paper is also the origin of a number doing the rounds at the moment, so it is worth handling with care. The widely repeated claim that 1.6% of Claude Code's codebase is AI decision logic and 98.4% is operational infrastructure appears in the paper, but the paper attributes it to community analysis of the extracted source rather than presenting it as its own measurement. Almost every secondary write-up drops that qualifier. Treat it as a useful illustration of how thin the reasoning layer is, and not as a hard finding.

So the honest position is this. A graph is the right answer when the work crosses systems, involves money or customers, and needs an approval trail. A loop is the right answer for a bounded, reversible task with one owner. Choosing the heavier structure for a job that does not need it is its own kind of failure.

A Useful First Graph

Here is what a first graph looks like for a real business workflow. Six states, in order:

1. Receive the request, and identify its source and its owner.
2. Retrieve only the approved evidence needed for this specific decision, and nothing beyond it.
3. Prepare a recommendation with a confidence level and references back to the sources used.
4. Route any material action to a named human approver.
5. Execute the approved action and write an audit record of what happened.
6. Escalate ambiguous or failed cases to a person rather than guessing.

Notice how ordinary that looks. It reads like a process map any operations manager could have drawn twenty years ago, which is rather the point. The discipline is not exotic. What is new is applying it to a technology most teams are currently deploying as an open-ended conversation and hoping for the best.

The Question That Changes Your Operating Meeting

Here is where the commercial value shows up, and it is subtler than it first appears.

When a prompt loop misbehaves, the only question your team can really ask is “did the agent work?” That question has no useful answer. It cannot be tested, it cannot be assigned to anyone, and it produces meetings where everybody agrees the AI is a bit unreliable and nobody knows what to do on Monday.

A graph replaces that with four questions that each have a real answer. Which transition failed? What evidence was available at that point? Who could have approved it? What should happen next? Those are testable system properties. They can be measured, owned and fixed.

There is a second benefit that matters if you are the one signing the invoice. A workflow with a visible boundary is far easier to price and to accept, because both sides can see exactly where the automation starts and stops. Vague scope is where AI projects go to die, and a graph is a scope document that happens to also be the architecture.

Where Governance Should Actually Live

We have written before about agentic governance, and the argument holds here with one important refinement. Governance that sits in a policy document, disconnected from what the system does at runtime, is decoration. It should instead be attached to the specific transitions that create exposure.

A payment instruction, a client communication, a data export, a change to production configuration: each of these is an edge in the graph, and each should require explicit authority before the workflow crosses it. Low-risk preparation can stay automated, because there is genuinely no reason for a person to approve the retrieval of a document the agent is already allowed to read. Material decisions should remain attributable to a named human being.

There is good evidence for putting the control on the edge rather than on every action. Anthropic's analysis of its own permission system found that users approve approximately 93% of permission prompts, and longitudinal data shows auto-approve rates climbing from around 20% in a user's first fifty sessions to over 40% by session 750 (Liu et al., 2026, citing Anthropic). Approval fatigue is real and measurable. Ask a person to confirm everything and they will confirm everything, including the one thing that mattered. Draw the boundary carefully instead, let the agent work freely inside it, and reserve human attention for the transitions that genuinely carry risk.

“Agents must be able to work autonomously; their independent operation is exactly what makes them valuable. But humans should retain control over how their goals are pursued.”

— Anthropic, framework for safe agents, cited in Liu et al., 2026

The Regulatory Picture Has Just Moved

If you were planning around 2 August 2026, the ground shifted this summer and it is worth being precise about what changed.

The EU's Digital Omnibus on AI was formally adopted by the European Parliament on 16 June 2026 and by the Council on 29 June 2026, with entry into force in July. The headline effect is that high-risk obligations for stand-alone Annex III systems, covering areas such as employment, education, credit scoring, critical infrastructure and law enforcement, are deferred from 2 August 2026 to 2 December 2027. AI embedded in products already regulated under Annex I moves to 2 August 2028 (Freshfields, 2026; Gibson Dunn, 2026).

Do not read that as a reprieve from the substance. The Article 50 transparency obligations were not deferred and still apply from 2 August 2026, with a three-month grace period to 2 December 2026 for systems already on the market (Jones Walker, 2026). The deferral happened because national authorities and harmonised technical standards were not ready, rather than because the requirements were abandoned. Article 14's human oversight requirement, that a person can understand what a high-risk system is doing, interpret its output and stop it when needed, is still coming, and a workflow with no defined intervention points cannot honestly claim any of it. The NIST AI Risk Management Framework takes the same view from the other side of the Atlantic, treating trustworthiness as something designed across the full lifecycle rather than certified at the end (NIST, 2023).

Eighteen extra months is a decent runway. It is a poor reason to stop building.

What Graph Engineering Does Not Claim

A graph does not make model outputs correct. It will not stop a model hallucinating a supplier name or misreading an ambiguous invoice. What it does is make the workflow easier to inspect, test, pause and recover. The model still needs proper evaluation against representative examples from your actual business, including the awkward ones, and people still need real authority over material exceptions.

The graph should also be small enough that an operator can read it. If you cannot explain your workflow as a sequence of states, authorities and exception routes, it is too complex to be given broad autonomy, and the right response is to split it into smaller workflows with explicit handoffs between them.

One more caution worth naming. Layered controls can share failure modes. Security researchers documented that Claude Code's own permission checks fall back to a single generic approval prompt when a shell command contains more than fifty subcommands, because per-subcommand parsing was freezing the interface (Liu et al., 2026, citing Adversa). Defence in depth only works when the layers fail independently, so test that assumption rather than trusting it.

What This Looks Like in Your Industry

Manufacturing

Maintenance and quality workflows are full of natural transitions. An agent can gather machine alerts, prior work orders and manual references into a ranked triage brief, and that whole path can be automated. The edge where a work order gets created, scheduled or closed is where a maintenance lead approves, and no state in the graph should hold authority over machine settings.

Logistics

Exception management is the obvious first graph. Delayed shipment signals, carrier updates, order priority and customer commitments all flow into a prepared exception queue with recommended actions. The transitions that touch a carrier, a customer, a credit or a service-level commitment stay gated by a coordinator, and every one of those decisions leaves an audit record.

Retail

Product data exceptions, duplicate listings and incomplete supplier records are ideal preparation work. The graph handles the finding and the drafting. Publication, pricing and any regulated product claim sit behind an approval edge owned by a merchandising or compliance lead, because those are the transitions where a mistake becomes public and expensive.

Real Estate

Enquiry classification, document readiness checks and broker briefings can run automatically. Anything touching eligibility, pricing advice or a client record change is a material transition and belongs to a licensed human. The audit trail matters here more than in most sectors, because when someone asks why they were quoted what they were quoted, “the model decided” is not an answer anybody accepts.

Where to Start on Monday

Choose one recurring workflow with clear inputs, a known decision owner and a limited cost of failure. Map the current handoffs before you automate anything, because you cannot draw a graph of a process nobody has written down.

Then document the work in plain operational terms, and do it before you choose a framework. What triggers this workflow? Which facts is it allowed to use? Which actions are prohibited outright? Who owns the decision? What is the safe fallback if a tool or a model fails? Answering those five questions forces a team to design the business control first, which is the correct order and almost never the order it happens in.

After that, automate the preparation and the routing, and leave the actions alone. Anything that changes a customer record, sends a message or moves money comes last, once the earlier states have proved themselves against real cases. The OWASP Top 10 for Agentic Applications is a sensible checklist to run the design against before you connect anything live (OWASP, 2026).

How U4RIA Designs Recoverable Workflows

At U4RIA we do not hand a business an open-ended chatbot and wish it luck. We build execution infrastructure, which means the workflow gets designed as states and transitions before anything is connected to a live system.

In practice that means diagnosing one repetitive, high-value process, mapping the systems and the decision owners, and defining the exact outcome we are going to measure. From there we design the graph itself: what each node does, what each edge permits, where the human approval gates sit, and what the rollback path looks like when a step fails. We test it against normal cases, edge cases and deliberately adversarial ones before it is trusted with anything irreversible, and we instrument it so that failures are attributable to a transition rather than to a vague sense that the AI is playing up.

This is also how a business climbs our AI Maturity Ladder without falling off it. Tool enablement and workflow customisation are useful early wins. Bespoke workflow intelligence and a genuinely AI-native operating layer are only safe once the workflow has a shape you can inspect.

The industry story of the autonomous employee who simply gets on with it makes for a good demonstration and a poor operating model. The better version is quieter and considerably more valuable: an AI workflow your team can read, pause, explain and recover.

At U4RIA, we believe AI is a tool to help humans, not replace them. Like what we're about? See what your business is truly capable of. Experience U4RIA.