The industry made a correction in late 2025, and it was the right one.
Autonomous agent loops, meaning an LLM with tools running until it decides it’s done, turned out to be unreliable in production in a specific and boring way. They drift. They lose the objective somewhere around turn fourteen, chase a tangent, and return something plausible that isn’t what anyone asked for. Salesforce’s Phil Mui named it in October 2025: agent “drop-off,” or goal drift, where agents lose track of their primary objectives when users ask tangential questions. His team’s answer was guided determinism: externalize the reasoning into design-time graphs so that context is never lost. LangChain had made a version of the same argument twenty months earlier, shipping LangGraph in January 2024 on the observation that the simple agent loop “offloads pretty much ALL of the decision making and reasoning ability to the LLM,” and that in production “often times more control is needed.
The diagnosis holds up under measurement, and the numbers are worse than the discourse suggests. In July 2026 the SWE-Milestone team published the cleanest illustration I’ve seen: Claude Sonnet 4.6 scored 93.2% on scikit-learn milestones evaluated independently, and 21.1% on the same milestones evaluated continuously, where the agent inherits its own prior damage instead of starting from a clean snapshot. Same model, same tasks, same execution engine. Only the structural context changed. Their conclusion is worth quoting: the ceiling “is not caused by agents forgetting how to code, but by their inability to prevent regressions from accumulating.
So: we agree with the diagnosis. We think the industry drew the wrong lesson from it.
The lesson everyone drew was adopt a graph framework, and by early 2026 everyone had one to sell you. Microsoft shipped Agent Framework in October 2025, merging Semantic Kernel and AutoGen, and reached 1.0 in April 2026 with “functional and graph-based workflows that connect agents and functions through explicit execution paths.” Mastra hit 1.0 in January 2026 on a graph-based workflow engine. LangGraph reached 1.0 in October 2025. OpenAI shipped Agent Builder at DevDay 2025: a drag-and-drop node canvas with guardrails, versioning, and inline evals.
Then something happened in June that should give the convergence story pause. OpenAI deprecated Agent Builder on June 3rd. It shuts down on November 30th, and the migration guidance points customers back to the code-first Agents SDK. The company with more usage data on agent orchestration than anyone built the visual graph runtime, shipped it, watched what people did with it, and is switching it off inside fourteen months. I don’t think that’s a story about a bad product. I think it’s a story about which half of an agent graph was actually load-bearing.
Be fair to the other side of that, because a Salesforce-literate reader will be. In the same six months, Microsoft’s Agent Framework reached 1.0 with graph workflows, Google’s ADK moved to a graph-based workflow runtime, and Salesforce took deterministic orchestration in Agent Broker from beta in April to general availability in June, complete with the visual authoring canvas OpenAI was in the middle of retiring. Convergence did not crack. It consolidated, and one vendor left the canvas business. That is still the fact worth sitting with: five companies shipped the engine, and the one with the clearest view of how the engine actually gets used decided the canvas was not the part worth maintaining.
We’ve shipped three client engagements built on explicit graph structure. Slide3 runs that work under a framework we call CDQ, for Context, Data, Questions: map the decisions a function actually makes, derive the questions those decisions depend on, and score every question against data the business already trusts, before deciding what to build. I went back through four of our repositories this month expecting to write up how CDQ, agents and skills fit together, and found that what we’d actually built,without using the term once, was agentic graphs. Read against what the frameworks shipped in 2026, the lesson I’d argue for is narrower and more uncomfortable than “adopt a framework”: the executable runtime is the least valuable part of an agent graph, and in regulated professional-services work it is frequently a liability.
Before going further, a disambiguation, because “agent graph” is doing double duty in the discourse and the two meanings get conflated constantly. An orchestration graph is about control flow: nodes are discrete units of work, edges are dependencies and transitions, state passes along the edges. It answers what runs next, and with what. A memory graph is about knowledge structure: nodes are entities, edges are typed relations, and the whole value is multi-hop traversal. It answers what is connected to what.Both are real, they solve different problems, and they fail differently. This series is mostly about the first. The last article is about the second, and about a trap in it we are currently sitting in ourselves.
Now the concession, which I’d rather make myself than have made for me. We are not claiming that graph structure makes agents more accurate. The best available evidence says the opposite. An April 2026 study found that in-context prompting beat LangGraph orchestration in all fifteen comparisons it ran under its primary judge, p<0.005, with failure rates of 11.5% versus 24% on one workflow set and 0.5% versus 9% on another. An independent replication under a second judge holds the direction at eleven of fifteen, none of them favouring orchestration. The orchestrated version also burned 1.2 to 1.7 times more LLM calls on routing overhead, though at a slightly lower dollar cost per conversation, because the full procedure in the prompt costs more tokens than the routing calls save. The authors’ phrasing is blunt: for procedural tasks the orchestration architecture is “not just unnecessary but actively harmful.
Read that carefully, because it is narrower than it looks. It measures task quality and failure rate on procedural conversational work. It says nothing about whether a partner can read the pipeline, whether you can explain why a number changed six months after delivery, or whether a miswired step is detectable before it executes. That is the ground we’re actually arguing on, and conceding the accuracy point is what makes the governance argument worth anything.
Here’s the shape of the thing we actually run. One engagement’s analytical pipeline decomposes into eight nodes, executed in sequence, with a per-domain subgraph in the middle that fans out and fans back in. Another runs six. Both terminate in a quality gate. Neither has a scheduler, a DAG executor, or a framework. The graph is declared in YAML, validated in CI, and executed by a human operator invoking each node in turn.
That sounds like the primitive version of what LangGraph gives you for free. It’s a different set of trade-offs, and on three specific dimensions it’s strictly better for the work we do: edges declared as data and validated before runtime, gates typed by severity and expressed in the tool surface rather than the prompt, and state versioned with a ledger that survives the run. Those three are the subject of the next article, and all three are available to you today, in any stack, with no framework adoption and no runtime.
Get them, and the execution engine is an implementation detail you can add later when volume justifies it. Get the engine without them, and you’ve bought a faster way to produce work that nobody can check.