Do You Need an Agent Framework? Start With Plain Code

State of the field as of 2026-09-18.

Octomind ran LangChain's agent abstractions in production for more than twelve months, from early 2023 to mid-2024. When they pulled it out, Fabian Both, their Staff Deep Learning Engineer, wrote down the reason in a sentence that should worry anyone about to pick an orchestration layer: the framework "does not provide a method for externally observing an agent's state, resulting in us reducing the scope of our implementation to fit into the limited functionality available to LangChain Agents."

Read that again. They did not hit a bug. They did not lose a benchmark. They shipped a smaller product than they intended, for a year, because the topology they picked on day one could not show them what their own agent was doing. The bill for an orchestration decision does not arrive as an outage. It arrives as the features you quietly stopped trying to build.

This is the decision this article resolves.

Orchestration topology: the one decision this article answers

This article answers a single question: what orchestration topology should a production AI agent use in 2026, and when should you change it?

Explicitly out of scope, each of which deserves its own treatment: retrieval strategy, evaluation and regression gating, telemetry schema, serving and latency, containment and guardrails. Those are separate decisions with separate defaults. Mixing them into one article produces a survey nobody can act on.

Two further topologies are out of scope rather than absent. Event-driven and actor-mesh designs, where control flow lives in a message bus and there is no orchestrator process at all, are an integration choice made by the platform a company already runs rather than by the team building the agent. Agent-to-agent federation across organizations (A2A reached 1.0 in January 2026) is an interop protocol, not a topology for a single system.

The recommendation below is a snapshot. Three of the eight options did not exist eighteen months ago, and the hosted tier has already had two predecessor products deprecated out from under its users.

The default: plain code plus your provider's SDK

Start with a loop you wrote, calling your model provider's SDK directly. Add an orchestration framework at the point where your control flow has to outlive the process that started it.

That is the whole recommendation. If you are skimming for the answer, you now have it.

The second half matters as much as the first. This is not an argument that frameworks are bad, and it is not the familiar "you don't need a framework" post. It is a claim about ordering: the loop is the cheap part, you should write it yourself first, and the thing that should eventually move you off plain code is durability, not complexity.

Why plain code is the right default in 2026

The model providers themselves tell you to start here

Anthropic's own engineering guidance has said so since December 2024, and the page still says it in 2026: "We suggest that developers start by using LLM APIs directly: many patterns can be implemented in a few lines of code. If you do use a framework, ensure you understand the underlying code. Incorrect assumptions about what's under the hood are a common source of customer error."

OpenAI ships an agent framework and still documents when not to use it. The Agents SDK docs carry an explicit section telling you to call the Responses API directly when "you want to own the loop, tool dispatch, and state handling yourself." Both vendors have a commercial interest in you adopting their higher-level product. Both tell you to start lower.

What changed: the provider SDKs absorbed the agent loop

This is what changed between 2024 and 2026. Most "do you need a framework" arguments are still missing it. Capabilities that used to justify reaching for a framework now ship inside the provider SDK:

• The tool-calling loop. Anthropic's Tool Runner "handles the agentic loop, error wrapping, and type safety," with max_iterations, an iterable interface, and mid-loop takeover of message history. It is available in the Python, TypeScript, C#, Go, Java, PHP and Ruby SDKs.
• Tool schema generation. The @beta_tool decorator "inspects the function arguments and docstring to derive the JSON schema for you." OpenAI's equivalent does Pydantic-powered validation.
• Context compaction. Anthropic's server-side compaction is documented as "the recommended strategy," handling context management "without client-side summarization code," with a configurable trigger defaulting to 150k input tokens.
• Long-running execution. OpenAI's background mode removes the request-timeout ceiling.

Thorsten Ball, who works on Sourcegraph's Amp, built a working code-editing agent in under 400 lines of Go using only the Anthropic SDK. His summary: "It's an LLM, a loop, and enough tokens." His caveat in the same paragraph is the honest part, and this article will come back to it: "The rest, the stuff that makes Amp so addictive and impressive? Elbow grease."

The framework vendors concede the point

Harrison Chase, LangChain's CEO, wrote in April 2025 that agentic systems "all benefit from the same set of helpful features, which can be provided by a framework, or built from scratch," and asked directly: "do you really need an agentic framework? If your application does not require all of these features, and/or if you want to build them yourself, then you may not need one."

That is the vendor of the thing you would be skipping, telling you the loop is not the hard part. He is right, and it cuts both ways, which the alternatives section takes seriously.

Why Thoughtworks downgraded LangGraph in 2026

Thoughtworks moved LangGraph out of Adopt in April 2026, a rare reversal of their own prior call. The trajectory reads Trial (April 2025), Adopt (November 2025), Trial (April 2026). Be precise about what that means, because it is weaker than "downgraded" sounds and the argument is better for saying so. Trial is Thoughtworks' second-highest ring: they still recommend it for real projects. What they withdrew is its standing as the default, which is this article's exact claim and no more. Their stated reasoning:

"the LangGraph architecture - which treats every multi-agent system as stateful graphs with a global shared state - is not always the best approach... Instead of starting with a rigid graph and a massive shared state, this approach favors simple agents communicating through code execution, with graph structures added later when needed... we no longer see it as the default choice for building every agentic system."

"Graph structures added later when needed" is the same ordering claim this article makes, from an assessor with no product to sell. Be precise about what they are recommending as the starting point, though: "communicating through code execution" is a variant of the hand-written loop, where the model writes programs rather than tool-call JSON. That is a topology in its own right and it gets its own section below.

Agent orchestration framework comparison: seven alternatives, and why each lost

Each of these is a real choice a competent engineer brings to the meeting. Each gets its strongest case before its limitation.

Workflow graph (LangGraph-style)

The case for it. Explicit control flow, conditional branching, and checkpointing as a first-class construct rather than something you bolt on. PostgresSaver is boring, known technology, and resume-at-step-N comes free with it. Human-in-the-loop is a supported primitive, not an improvisation. LangGraph reached 1.0 on 2025-10-22 with a stated commitment to no breaking changes until 2.0, and is at 1.2.11 as of 2026-08-11. This is not a toy position. LangChain's own writeup of who runs it in production names Klarna (an assistant serving 85 million users), Uber (agent-driven unit-test generation for large-scale code migration), LinkedIn (a multi-agent natural-language-to-SQL bot) and Replit (multi-agent with human-in-the-loop at scale). That is the vendor's own list, which is exactly what the steelman rule asks for - a maintainer's framing of what the tool is for - and it is worth saying out loud that this article declines vendor adoption metrics elsewhere, for the hosted harnesses. Named customers with described workloads are checkable; a headline adoption count is not, so there is none here. Replit is the sharpest case for this article, because human approval inside a running agent at that scale is exactly the condition the deviation table hands to a framework. If your control flow genuinely is a graph with branches and rejoins, writing that by hand is real work you can avoid - and there is a real argument that agents need a runtime rather than a loop once that shape sets.

Why it is not the default. Deal with the obvious objection first. The Octomind story in the opening is about LangChain in 2024, and LangGraph exists in large part because of that class of complaint - too much abstraction, too little control over the loop and the state. Citing it as evidence against LangGraph today would be arguing against the Next.js App Router with a 2019 create-react-app postmortem. What survives the redesign is narrower and still real: a graph is a commitment to a control-flow shape, and you make it at the point when you know least about what that shape should be. LangChain's own 1.0 announcement concedes the shape of the complaint: "we've heard consistent feedback: LangChain's abstractions were sometimes too heavy, the package surface area had grown unwieldy, and developers wanted more control over the agent loop..." A graph is the right structure once you know the shape of your control flow. On day one you do not, and committing to one early is how you end up reducing scope to fit it.

Single-threaded agent loop

The case for it. This is Cognition's stated production position, published 2025-06-12. Context stays continuous, so no subagent ever acts on a partial view, and there are no conflicting decisions to reconcile because only one actor decides. Their two principles are worth stating directly: share full agent traces rather than individual messages, and actions carry implicit decisions, so conflicting decisions carry bad results. For any workload involving mutation, this is the safe shape.

Why it is not the default. It is not really a competing topology so much as a constraint that survives into the default. Plain code written the obvious way is already single-threaded. Where Cognition goes further is in extending it: when context overflows, they introduce a dedicated compression model, and they state they fine-tuned a smaller model specifically for this. That is a meaningful engineering investment most teams will not make, and server-side compaction now covers much of the same ground without it.

Multi-agent orchestrator-worker

The case for it. Anthropic's multi-agent research system outperformed single-agent Opus 4 by 90.2% on their internal research eval - with an Opus 4 lead directing Sonnet 4 subagents, which is also why the token economics land where they do. Their token analysis is the more interesting number: token usage alone explains 80% of performance variance on BrowseComp, and token usage plus tool calls plus model choice explains 95%. When the information genuinely exceeds a single context window, fan-out is not a preference, it is the only thing that works. Anthropic names the fit precisely: heavy parallelization, information exceeding one context window, many complex tools. Width matters as much as depth here - an unbounded fan-out is its own failure mode.

Why it is not the default. Anthropic rules it out themselves, on two grounds: domains that need shared context or carry many dependencies between agents, and - for coding specifically - parallelizability, since "most coding tasks involve fewer truly parallelizable tasks than research." The economics are severe, and the number most often quoted is the wrong one. Anthropic's 15x figure is multi-agent measured against chat. Measured against a single agent - the comparison you are actually making - their own January 2026 guidance puts it at 3-10x: "multi-agent implementations typically use 3-10x more tokens than single-agent approaches for equivalent tasks." That is still expensive, and it buys less than teams expect. Anthropic describes their own: teams "invest months building elaborate multi-agent architectures only to discover that improved prompting on a single agent achieved equivalent results." Nor does it buy speed - "the primary benefit of parallelization is thoroughness, not speed," and multi-agent systems "often take longer overall." And the independent evidence is unkind. Beyond the Leaderboard (arXiv:2607.05775, July 2026), synthesising 27 papers across 19 benchmarks, found that additional scaffolding does not consistently improve reliability, alongside two findings that matter here: failures compound nonlinearly with task length, and strong sub-task performance does not translate to end-to-end success. Paying 3-10x for a reliability improvement that does not reliably arrive is the single most expensive way to get this decision wrong.

Durable execution engine (Temporal, Restate, DBOS, Inngest)

The case for it. This is the only category built for the exact condition this article names. Temporal is the exemplar below because it has the clearest public evidence; Restate and DBOS are lighter-weight alternatives, with DBOS running in-process against Postgres rather than as a separate cluster, and Inngest sits closer to managed event-driven workflows. A workflow graph's checkpointer durably stores state; a durable execution engine makes the control flow itself replayable. Something outside a graph still has to notice the process died and restart it. Here that is the runtime's job. Temporal's own framing is the clearest statement of what you get: "code the happy path, and Temporal does the error handling for you," so that when "your app crashes when it's just about done with a long-running task," you "restart it, and Temporal will see to it that it picks up where it left off, saving you compute and token costs." You can even fix the bug and resume workflows that are already running.

This is not a future bet. The OpenAI Agents SDK integration with Temporal reached General Availability on 2026-03-23 - generally available on the snapshot date, while every hosted option below is still beta. Grid Dynamics published a named account of replacing LangGraph, Redis and their own hand-rolled retry logic with it, citing race conditions, stale state and agents that got stuck with nothing reporting it. Note where that account sits: on Temporal's blog, as is the maintainer framing above. Weigh it accordingly.

Why it is not the default. It is a second runtime and a second mental model. Workflow code must be deterministic, so model calls and tool calls move into activities and you learn where that boundary falls by crossing it wrongly at least once. Replay semantics are a discipline, not a library you import. Below a certain cost of failure, none of that is worth carrying - which is the same reason it is not the default and precisely the reason it wins once the cost of failure crosses your threshold.

Code mode (the model writes the program)

The case for it. Instead of emitting tool-call JSON that your loop dispatches, the model writes a program that calls the tools, and a sandbox runs it. Intermediate results never enter the context window at all. Anthropic's own worked example of a Drive-to-Salesforce workflow drops from roughly 150,000 tokens to roughly 2,000 by taking this route; Cloudflare shipped the TypeScript equivalent as Code Mode. It attacks the same token cost that multi-agent fan-out pays for, from the opposite direction: rather than buying more context windows, it stops filling the one you have.

It also has the strongest endorsement in this article. When Thoughtworks withdrew LangGraph's default status, the alternative they named was "simple agents communicating through code execution, with graph structures added later when needed." That is this topology, and it is why their demotion is quoted above.

Why it is not the default. It requires a code-execution sandbox with an egress policy, which is the containment problem this article explicitly scoped out - and it is not free, either operationally or in risk. Debuggability moves into generated code, which is harder to inspect than a tool-call trace. It is also the newest option here, with the least production evidence behind it.

Lab-hosted harness (Anthropic Managed Agents, OpenAI Agents API)

The case for it. This is the strongest steelman in the set, and it comes from Anthropic's own engineering post of 2026-04-08: "Harnesses encode assumptions that go stale as models improve." Their example is concrete and dated. Claude Sonnet 4.5 would wrap up tasks prematurely as it approached its context limit, so they added context resets to the harness. On Claude Opus 4.5 "the behavior was gone. The resets had become dead weight." A hosted harness is maintained against model changes you do not control.

The security work is real and specific too. They document git tokens wired into the sandbox's local remote so push and pull work "without the agent ever handling the token itself," and MCP OAuth tokens held in a vault outside the sandbox behind a proxy, so "the harness is never made aware of any credentials." A team self-hosting builds that or accepts the prompt-injection-to-credential-exfiltration path.

Why it is not the default. Two hard reasons.

First, compliance, and it is binary. Anthropic states Managed Agents "is not currently eligible for Zero Data Retention or HIPAA Business Associate Agreement (BAA) coverage." OpenAI's Agents API has no ZDR and is US-only, and adds the detail teams get wrong: "Choosing a self-hosted sandbox does not make the Agents API ZDR-eligible." The hybrid buys you execution locality, not data-flow isolation. Tool inputs and outputs still cross the vendor's control plane.

Second, product longevity, and this is documented rather than speculative. OpenAI has now retired two hosted agent-orchestration products and launched a third: the Assistants API shut down 2026-08-26, Agent Builder was deprecated 2026-06-03 with shutdown set for 2026-11-30 (roughly seven months from launch to deprecation notice), and the Agents API entered public beta 2026-09-10. Both labs' current offerings are beta, which sits outside OpenAI's own six-month notice commitment for GA models.

Note what is not a reason: cost. Anthropic's own worked example puts the $0.08 session-hour runtime fee at 11.3% of a $0.705 session, and OpenAI charges nothing for the harness itself. Anyone rejecting a managed harness on cost grounds has picked the wrong argument.

Cloud-hosted your-code runtime (Bedrock AgentCore, Google Agent Platform)

The case for it. These host your agent, not their loop, and that difference carries all the way through. AWS Bedrock AgentCore reached GA on 2025-10-13, positioned for "any framework, model, or protocol." Its runtime-instances tier only reached GA on 2026-08-10, five weeks before this snapshot. Google's Agent Platform runs LangGraph, ADK, LlamaIndex and AG2, and its compliance matrix is the decisive fact: VPC Service Controls, CMEK, data residency at rest and HIPAA across Runtime, Sessions, Memory Bank and Code Execution. If you need both hosting and a HIPAA BAA, this is the documented answer, and it is the reason the compliance objection does not cut against hosted runtimes generally - only against the labs' own harnesses.

Why it is not the default. You still operate a runtime, still shape your agent to its deployment model, and still take infrastructure lock-in even while keeping the model swappable. Microsoft's position is harder to read, though not for pricing reasons - Foundry charges nothing for the agent service itself, the same model OpenAI uses. The signal worth watching there sits underneath it: AutoGen and Semantic Kernel both went to maintenance when Microsoft Agent Framework 1.0 shipped in April 2026, so the framework layer consolidated while the hosting layer was still settling. This is a good destination, not a starting point.

When to deviate from plain code and add a framework

Every condition below is checkable against your own system without interpretation. Each names the alternative that wins and why.

Look at what every row in that table has in common, because this is the part no single source states. Each condition is about something crossing a boundary: a process boundary, a session boundary, a person boundary, or the edge of the context window. Only one of them - specialization - is about the agent being complicated, and it is the weakest row in the table. The field argues loudly about complexity - how many agents, how many tools, how many steps - and then, when practitioners write down what actually forced their hand, they describe durability and inspection every time. That gap between what the discourse argues about and what the decisions turn on is the most useful thing in this article, and it is why the advice is "write the loop first" rather than "estimate your complexity up front." You cannot estimate complexity before you have built the thing. You can answer "must this survive a crash?" on day one.

Note what is absent: no row mentions tool count or step count. Every credible source draws this line at durability and multi-party inspection. The "switch after 3 tools" and "switch after 5 steps" thresholds that circulate are, on inspection, generated content with no shipped system behind them. If you want one sentence to carry away: plain code holds while the control flow is one process, one maintainer's head, and a run you can afford to restart from zero.

Multi-agent fan-out: the write-conflict mistake and the fix

The most expensive version of this mistake is not choosing plain code over a framework. It is fanning out to subagents on work that mutates shared state. Here is the pattern, and the fix.

Wrong: parallel subagents that write

import asyncioimport anthropicclient = anthropic.AsyncAnthropic()MODULES = ["auth", "billing", "notifications"]async def refactor_module(module: str, shared_helpers: dict[str, str]) -> None:    """Each subagent decides a helper name and writes it. Independently."""    prompt = (        f"Refactor the {module} module. Extract the repeated retry logic "        f"into a shared helper and tell me the helper name you chose."    )    response = await client.messages.create(        model="claude-sonnet-5",        max_tokens=1024,        messages=[{"role": "user", "content": prompt}],    )    # Three subagents, three independent decisions, one shared namespace.    shared_helpers[module] = response.content[0].text.strip()async def main() -> None:    shared_helpers: dict[str, str] = {}    await asyncio.gather(        *(refactor_module(m, shared_helpers) for m in MODULES)    )    print(shared_helpers)

What this example demonstrates is structural, and you can see it without running anything: there is no step in that control flow where the three names are reconciled. asyncio.gather fans out, each coroutine writes its own key, and main prints the result. No reconciliation step exists to be reviewed, tested, or fixed later. Nothing crashes, and no exception is raised, because nothing here is an error in the ordinary sense. Each subagent does its job correctly given what it can see, which is nothing about the other two.

This is Cognition's principle in concrete form. The actions carried implicit decisions, the decisions conflicted, and the conflict surfaced as three near-duplicate helpers that a human now has to reconcile. Scale that to a refactor across thirty modules and the reconciliation costs more than the refactor saved.

Right: fan out on reads, single-thread on writes

import asyncioimport anthropicclient = anthropic.AsyncAnthropic()MODULES = ["auth", "billing", "notifications"]async def analyse_module(module: str) -> dict[str, str]:    """Read-only. Safe to run in parallel - no decision is committed here."""    prompt = (        f"Analyse the {module} module. Describe the repeated retry logic "        f"you find. Do not propose names. Report findings only."    )    response = await client.messages.create(        model="claude-sonnet-5",        max_tokens=1024,        messages=[{"role": "user", "content": prompt}],    )    return {"module": module, "findings": response.content[0].text}async def main() -> None:    # Fan out: analysis is read-only, so parallelism is free and safe.    findings = await asyncio.gather(*(analyse_module(m) for m in MODULES))    # Single-thread: one actor sees every finding and makes one decision.    combined = "\n\n".join(        f"## {f['module']}\n{f['findings']}" for f in findings    )    decision = await client.messages.create(        model="claude-sonnet-5",        max_tokens=2048,        messages=[{            "role": "user",            "content": (                "Here are retry-logic findings from three modules:\n\n"                f"{combined}\n\n"                "Choose ONE helper name and one signature for all three. "                "Then give the per-module edits that use it."            ),        }],    )    print(decision.content[0].text)

The parallelism survives, because analysis is genuinely independent. The decision does not fan out, because it is one decision. This read/write line is my synthesis, and it is worth being exact about that. Cognition's stated principles are about sharing full traces and about actions carrying implicit decisions; the read/write split appears in their post as a description of how Claude Code actually uses subagents, which are usually asked to answer a question rather than write code. Anthropic's concession is that domains with many inter-agent dependencies are a bad fit, and a shared namespace is exactly such a dependency. The rule is what falls out when you hold both statements at once.

Notice how little machinery either version needs. No framework appears in the fix. The correction was structural, not a tooling upgrade.

Where plain code stops: the human-approval boundary

The fix above is still plain code, because nothing in it has to survive the process. Change one requirement and that stops being true:

# The same work, but a human has to approve the plan before any edit lands.# The approval may arrive in ten seconds or tomorrow morning.## propose_plan, wait_for_human_approval and apply_edits are elided - none of# them is the interesting part. analyse_module is the one defined above.async def main() -> None:    findings = await asyncio.gather(*(analyse_module(m) for m in MODULES))    plan = await propose_plan(findings)    approved = await wait_for_human_approval(plan)  # <- the boundary    if not approved:        return    await apply_edits(plan)

wait_for_human_approval is where plain code stops being the right answer. Not because the code is hard to write - it is a poll or a webhook - but because the process holding findings and plan in memory now has to still exist when the answer comes back. If it does not, you rebuild that state from nothing, and you are writing a checkpointer. If the work that was in flight has to restart too, you are writing a durable execution engine.

That is the whole deviation rule in one line of code. Everything above the boundary is a loop you should write yourself. The first requirement that reaches below it is the one that buys a framework.

Decision flowchart: choosing an orchestration topology

flowchart TD
    A[New agent workload] --> B{Must control flow<br/>outlive the process?}
    B -->|No| C{Writes with<br/>dependencies?}
    B -->|Yes| D{Need HIPAA BAA<br/>or ZDR?}
    C -->|Yes| E[Plain code,<br/>single-threaded]
    C -->|No| F{Any of Anthropic's<br/>3 conditions AND<br/>value &gt; 3-10x tokens?}
    F -->|No| E
    F -->|Yes| G[Fan out on reads,<br/>single-thread writes]
    D -->|Yes| H[Gemini Enterprise<br/>Agent Platform]
    D -->|No| I{Somewhere to<br/>persist state?}
    I -->|Yes| J[Durable execution<br/>or workflow graph]
    I -->|No| K[Lab-hosted harness<br/>note: beta, no ZDR]

    style A fill:#4A90E2,color:#FFFFFF
    style E fill:#6BCF7F,color:#2C2C2A
    style G fill:#6BCF7F,color:#2C2C2A
    style J fill:#98D8C8,color:#2C2C2A
    style H fill:#98D8C8,color:#2C2C2A
    style K fill:#FFD93D,color:#2C2C2A
    style B fill:#7B68EE,color:#FFFFFF
    style C fill:#7B68EE,color:#FFFFFF
    style D fill:#7B68EE,color:#FFFFFF
    style F fill:#7B68EE,color:#FFFFFF
    style I fill:#7B68EE,color:#FFFFFF

Pre-adoption checklist: should you add an agent framework

Run this before you add an orchestration dependency:

• Can I name the specific thing the framework does that my loop does not? If the answer is "structure," that is not a reason yet.
• Does my control flow need to survive the process dying? If no, plain code still holds. If yes, ask the sharper version: do I need the state to survive, or the control flow? A checkpointer covers the first; only a durable execution engine covers the second.
• Will a human approval arrive after the process that requested it has exited?
• Will someone other than me need to replay a run they did not execute?
• If I am fanning out: are the subtasks genuinely read-only? If any of them writes to shared state, collapse the writes to one actor.
• If I am fanning out: does one of Anthropic's three conditions hold - context pollution, genuine parallelism, specialization - and does task value exceed roughly 3-10x my single-agent token cost?
• Do I need ZDR or a HIPAA BAA? If yes, the lab harnesses are out, and self-hosting their sandbox does not change that.
• Am I running more than one model provider now, or within the horizon I am designing for?
• Have I checked the deprecation record of anything hosted I am about to depend on?

What would move the default off plain code

Each of these would move the default itself, not just add a deviation row. Each names something to watch.

• Provider SDK loop primitives reaching stability. Anthropic's Tool Runner and compaction are beta, gated behind dated beta headers. If they go GA, the default gets stronger and the framework tier narrows further. Watch the Claude platform changelog.
• A lab harness reaching GA with ZDR and a HIPAA BAA. That single change removes the hardest blocker and moves a large regulated segment. Watch both labs' compliance documentation, not their launch posts.
• An open standard at the orchestration layer. MCP standardised tools; the sandbox layer is already commoditised across a shared partner list. The agent loop and its state are the one layer with no standard, which is precisely why they lock you in. Watch the MCP specification repository.
• Per-token cost falling faster than task value rises. Anthropic's own argument is that multi-agent wins because it spends more tokens. If the 3-10x penalty stops mattering, fan-out becomes the default for far more workloads. gpt-5.6-luna is already $0.20/$1.20 per MTok.
• Post-training coupling to harness shape. If models are increasingly trained against specific harnesses, the line moves per model release rather than per framework release. Watch whether lab-published evals start reporting harness alongside model.
• Thoughtworks moving LangGraph back to Adopt. They downgraded it in April 2026 on a stated architectural argument. A reversal would be evidence the graph-first objection had been answered.

One honest caveat about the evidence base. The public record contains named, dated accounts of teams removing a framework - Octomind, and Armin Ronacher reversing an SDK abstraction decision - and I could find no account of a team regretting plain code as such. The nearest counter-example is Grid Dynamics, who tore out LangGraph and Redis along with their own hand-built orchestration and retry logic, citing race conditions, stale state, and agents that got stuck with nothing reporting it. It is not a clean counter-example - they were running a framework too, and the writeup sits on a vendor's blog - but it is the closest thing that exists and you should weigh it. That the literature leans one way may say more about who writes engineering blog posts than about which decision fails more often.

References

• Anthropic. (2024, December 19; revised 2026). Building effective agents. https://www.anthropic.com/engineering/building-effective-agents
• Anthropic. (2025, June 13). How we built our multi-agent research system. https://www.anthropic.com/engineering/multi-agent-research-system
• Anthropic. (2026, January 23). Building multi-agent systems: When and how to use them. https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them
• Davis, C. (2025, July 30; GA update 2026, March 23). Production-ready agents with the OpenAI Agents SDK + Temporal. https://temporal.io/blog/announcing-openai-agents-sdk-integration
• Mezhensky, D., Larko, D., & Steinberg, E. (2025, September 29). From prototype to production-ready agentic AI solution: A use case from Grid Dynamics. Temporal. https://temporal.io/blog/prototype-to-prod-ready-agentic-ai-grid-dynamics
• Anthropic. (2025). Code execution with MCP. https://www.anthropic.com/engineering/code-execution-with-mcp
• Cloudflare. (2025). Code Mode. https://blog.cloudflare.com/code-mode/
• Martin, L., Cemaj, G., & Cohen, M. (2026, April 8). Scaling Managed Agents: Decoupling the brain from the hands. Anthropic Engineering. https://www.anthropic.com/engineering/managed-agents
• Anthropic. Tool runner (SDK). Claude Platform Docs. https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-runner
• Anthropic. Compaction. Claude Platform Docs. https://platform.claude.com/docs/en/build-with-claude/compaction
• Anthropic. Claude Managed Agents overview. https://platform.claude.com/docs/en/managed-agents/overview
• Yan, W. (2025, June 12). Don't Build Multi-Agents. Cognition. https://cognition.ai/blog/dont-build-multi-agents
• Both, F. (2024, June). Why we no longer use LangChain for building our AI agents. Octomind. https://web.archive.org/web/2024/https://octomind.dev/blog/why-we-no-longer-use-langchain-for-building-our-ai-agents
• Ball, T. (2025, April 15). How to build an agent. Amp. https://ampcode.com/how-to-build-an-agent
• Chase, H. (2025, April 20). How to think about agent frameworks. LangChain Blog. https://blog.langchain.com/how-to-think-about-agent-frameworks/
• LangChain Team. (2025, October 22). LangChain and LangGraph reach v1.0. https://blog.langchain.com/langchain-langgraph-1dot0/
• Thoughtworks. (2026, April). LangGraph (moved out of Adopt). Technology Radar. https://www.thoughtworks.com/radar/languages-and-frameworks/langgraph
• Albayaydh, W., Zhao, R., & Flechais, I. (2026, July 7). Beyond the Leaderboard: A Synthesis of Tool-Use, Planning, and Reasoning Failures in Large Language Model Agents. arXiv:2607.05775. https://arxiv.org/abs/2607.05775
• OpenAI. Agents SDK documentation. https://openai.github.io/openai-agents-python/
• OpenAI. Agents API overview. https://developers.openai.com/api/docs/guides/agents-api/overview
• OpenAI. Deprecations. https://developers.openai.com/api/docs/deprecations
• Amazon Web Services. (2025, October 13). Amazon Bedrock AgentCore is now generally available. https://aws.amazon.com/about-aws/whats-new/2025/10/amazon-bedrock-agentcore-available
• Google Cloud. Scale your agents - Gemini Enterprise Agent Platform. https://docs.cloud.google.com/vertex-ai/generative-ai/docs/agent-engine/pricing
• Ronacher, A. (2025, November 21). Agent design is still hard. https://lucumr.pocoo.org/2025/11/21/agents-are-hard/
• Horthy, D. (2025). 12-Factor Agents. HumanLayer. https://github.com/humanlayer/12-factor-agents

Related Articles

Agentic AI

• Multi-Agent Pipeline Orchestration and Failure Propagation: Designing for Blast Radius
• LangGraph Reducers Are a Concurrency Policy
• What Three Audits Found in My Own LangGraph Book
• Multi-Agent Topology Patterns: Every Topology Has a Tear Point