I’ve spent two articles arguing that the auditable structure around an agent graph matters more than the engine that executes it. I’d be doing you a disservice by leaving it there. Here is what the approach costs, and where I think it’s the wrong call.
Somebody wrote the checklists. The quality gate on one of our deliverables is a roughly 150-checkpoint audit rolled up into seven categories. Another deliverable carries its own, shorter one. Those weren’t generated. They were written by people who knew what a bad workbook looks like, and they are the reason the gate catches anything at all. The architecture is not what produces quality here. The checklist is, and the architecture is what makes sure the checklist gets run. If you adopt the structure and skip that work, you have a pipeline with a decorative QA node and a false sense of coverage, which is worse than having neither.
The back-edge means rework is budgeted, not exceptional. Designing a reject path that routes backward is an admission that a meaningful fraction of runs will fail QA. That is the correct admission, but it also means your delivery estimates have to carry it, and that is a conversation with whoever owns the engagement margin, not just an architecture decision.
Two write paths to one store is a real and vicious failure mode. We hit this one. An operator console’s save-tools were connected concurrently with a pipeline run. The agent had two plausible ways to write the same record, picked the wrong one, and orphaned a version mid-write. The fix was two guards: verify the write reached a terminal state, then read it back and confirm. The general problem is that multi-agent tool namespaces collide, and I don’t think anybody has a good answer for it yet. If you connect an admin surface and an execution surface to the same model at the same time, you have this bug and you don’t know it.
And a human executes the graph. There is no orchestrator process. The operator is the scheduler. That caps throughput at exactly the rate a person can invoke nodes, and I’m not going to dress it up as a feature. For the work we do it has never been the binding constraint. But “it isn’t our bottleneck” is a claim about our workload, not a defense of the design.
Which brings me to where this recommendation is wrong, because the trade is throughput against auditability and it genuinely goes the other way for a lot of work.
The strongest counter-evidence is the April 2026 finding I cited in the first article, and it deserves more than a footnote. In-context prompting beat LangGraph orchestration in all fifteen comparisons the authors ran under their primary judge, p<0.005: failure rates of 11.5% versus 24% on travel workflows, 0.5% versus 9% on one conversational set, 5% versus 17% on insurance. An independent replication under a second judge favours in-context in eleven of the fifteen, with none favouring orchestration. Their conclusion for procedural tasks is that orchestration is “not just unnecessary but actively harmful.” One figure in that paper cuts my way and one cuts against me, and I’d rather print both. The orchestrated system consumed 1.2 to 1.7 times more LLM calls on routing overhead at decision nodes, so it pays latency at every hub. It was also the cheaper of the two, at five to seventeen cents a conversation against eight to twenty-two, because the full procedure in the prompt costs more tokens than the routing calls save.I think the finding is correct within its scope, and its scope is large: high-volume, low-consequence, repetitive work where no sign-off is required. Support triage, enrichment, classification, content operations. Nobody is going to ask why a record got tagged the way it did eight months ago, and if they do, the answer doesn’t carry liability. Run the engine, take the throughput, and every human gate you insert is pure drag.
Professional-services delivery sits in the opposite corner: low volume, high consequence, mandatory sign-off, and a six-month lookback that arrives whether you prepared for it or not. A wrong number in a client deliverable is an exposure, and it gets priced like one. Buying throughput you structurally cannot use, at the cost of auditability you are required to have, is a bad trade, and it is the trade that “adopt a graph framework” quietly recommends.
There’s a market signal worth sitting with here. Gartner predicted in June 2025 that more than 40% of agentic AI projects will be canceled by the end of 2027, on escalating costs, unclear business value, and inadequate risk controls. Two of those three are governance problems, not capability problems. And of the thousands of vendors selling agentic AI, Gartner’s assessment was that roughly 130 were legitimate. The failure mode in this market is not that the agents can’t do the work. It’s that nobody can demonstrate the work was done correctly.
So the honest version of my recommendation is conditional. If your output is a decision someone signs their name to, build the contract and skip the engine until volume forces your hand, and price the checklist work, because that’s the part that actually catches things. If your output is a tagged record in a queue, do the opposite, and don’t let anyone sell you a governance layer you’ll never be asked to produce.
The failure I’d most want to prevent is the middle: an organization that buys the runtime because the architecture diagram looked rigorous, skips the checklists because they’re unglamorous, and ends up with a fast pipeline whose output nobody can verify and whose failures nobody can reconstruct. That’s not an improvement on the autonomous loop. It’s the same problem with better diagrams.