AI agents, eighteen months in

Eighteen months after the 2024 agentic wave broke, vendor demos still emphasize broad autonomous workflows. A safer engineering starting point is narrower: bounded tasks, explicit stopping conditions, hard token and wall-clock limits, and a kill switch a human can reach. That is an editorial risk posture, not a claim about how every production deployment looks.

This piece compares four agentic stacks (LangGraph, OpenAI Assistants v2, Anthropic's computer use, and Microsoft Autogen) through their documented architecture and intended control surfaces. The recommendations below are hypotheses to validate against your own workload. For high-stakes work, the default recommendation is human approval until an evaluation demonstrates acceptable failure and recovery behavior.

Agent-loop reliability depends on both the underlying model and the framework around it. A framework shapes topology, observability, and recovery, but it cannot guarantee planning quality across tool calls. Treat model choice as a separate test: run candidate models on the same traces, tool schemas, and stop conditions, then compare task success, tool errors, latency, and cost. The broader capability question is covered in the Opus review; this article does not declare one model a universal agent winner.

What you should use each framework for

The four frameworks are not direct substitutes for each other. Each one has a different design point and a different cost-of-error profile. The right framework for you is the one whose design point matches the workload you are about to put on it.

LangGraph: explicit topology, production-readiness

LangGraph's design point is that the LLM doesn't decide the topology of the loop; you do. The agent is a graph of nodes (each node is either an LLM call, a tool call, or a deterministic function) and the edges between them are explicit. The framework gives you the control surface that lets you keep the loop bounded.

That design makes LangGraph a candidate when production work needs explicit states, transitions, and recovery paths. Validate the fit with a small evaluation: inject a tool timeout, a malformed result, and a repeated action; then confirm that the trace explains the failure and that the graph reaches a safe terminal state. If an agent touches money, customer data, or anything expensive to get wrong, evaluate those controls before comparing convenience.

The likely trade is development effort: explicit graphs can require more application code than a managed loop. Measure that rather than assume it. Time a small implementation in each candidate, then include debugging and recovery work in the comparison.

OpenAI Assistants v2: fast prototype, slower debug

The current production iteration of OpenAI's Assistants API is higher-level than LangGraph. You describe the tools and the instructions; the platform handles the loop. It's the closest thing in the space to "just describe what you want."

The hypothesis to test is prototype speed versus debugging control. Build the same narrow tool-calling task in Assistants v2 and the alternative under consideration. Record implementation time, then inject an incorrect tool result and compare how quickly each trace reveals the cause and supports recovery. Choose from those results; do not assume a prototype framework must be the production framework.

Anthropic's computer use: a different kind of agent

Anthropic's computer use is a different category. Instead of calling APIs, the agent sees a virtual screen, moves the mouse, types, and reads the result. That covers tasks with no API surface: a desktop application, a website with no clean programmatic interface, or a vendor product that keeps its functions behind the UI.

Computer use is a candidate when a workflow has no usable API, but UI drift is an important failure hypothesis. Test it by changing labels, moving controls, introducing a modal, and varying viewport size. Measure completion, unsafe clicks, recovery, and human interventions. If an API path exists, run the same cases through it and compare maintenance burden rather than assuming either path wins.

Microsoft Autogen: the multi-agent trap

Autogen's pitch is multi-agent. Instead of one agent doing everything, it lets you compose specialist agents that collaborate. The editorial risk hypothesis is that each handoff creates another place for state, intent, or tool results to drift. That is not a universal result: it is something to measure.

Call it the Frankenstein test. Implement a single-agent baseline and a multi-agent decomposition against the same held-out tasks. Score final task success, incorrect handoffs, tool calls, latency, cost, and recovery after an injected failure. Keep the multi-agent design only if it improves a metric that matters without crossing your safety and cost limits.

The distance between a demo that dazzles and a deployment you'd trust unattended is the whole problem. Closing it is the next two years of work.

Where to evaluate agents first

A new managed option belongs in the evaluation. OpenAI announced Presence on July 22, 2026: a service that packages voice and chat agents with policies, approved actions, evaluations, escalation, and deployment support. It is not a framework or self-serve API, so compare it against a build path on operating burden, change control, and total cost—not against a token price alone.

Start with categories whose errors are bounded and easy to detect. The following are candidate workloads, not a claim that an agent is automatically trustworthy in them.

The first candidate is high-volume, low-stakes classification or routing. Build a labeled holdout set, define the maximum acceptable error rate by class, and include the cost of human review and retries. Ship only if the measured total cost and error profile beat the existing workflow.

The second candidate is tightly-scoped tool calling: one tool, one decision, and a clear stopping condition. Search documentation, look up a customer record, or fetch weather data. Test argument validity, permission boundaries, timeout recovery, and whether the agent stops after the expected call.

The third candidate is human-in-the-loop assistance. The agent prepares an action and a human approves or rejects it. Measure reviewer time, acceptance rate, escaped errors, and whether the approval screen exposes enough evidence for a real decision. The coding-assistants shootout discusses products that use this pattern.

1. Mar 2024 LangChain Agents

   First broadly-used framework. Tool-calling templates that hid the loop.

2. Aug 2024 LangGraph

   Explicit graph topology and inspectable transitions.

3. Sep 2024 OpenAI Assistants v2

   Higher-level API. Faster to prototype, harder to debug.

4. Oct 2024 Anthropic computer use

   Agent that sees a screen and uses a mouse and keyboard.

5. 2025 Multi-agent everywhere

   Autogen and related designs. Benchmark against one-agent baselines.

Where the evaluation bar should be highest

Long-horizon planning. As a task requires more dependent tool calls, evaluate whether errors compound and whether the agent can recover from a wrong intermediate state. Create cases with delayed consequences, missing tool results, and conflicting evidence; do not infer production reliability from a short benchmark alone. The measurement problem is discussed in why the benchmarks stopped telling you anything.

High-stakes autonomous action. When a wrong action costs money, trust, or safety, define severity-specific limits rather than borrowing an average success rate from a low-stakes task. Keep human approval wherever one harmful action could escape downstream review.

Open-ended exploration. Tasks without a clear stopping condition need explicit budgets and termination tests. Deliberately give the agent an unsatisfiable goal and verify that token, retry, tool-call, time, and spend caps stop the loop safely.

What to build, if you're building

For a developer who wants to try this, begin with one agent, one task, and hard caps. Treat LangGraph and the candidate models you can access as options to evaluate, not predetermined winners. Establish a single-agent baseline that meets your reliability target before testing whether a second agent adds enough value to justify its coordination cost.

Our editorial hypothesis is that near-term value will come from carefully bounded systems rather than a fixed timetable for replacing broad categories of knowledge work. That forecast is uncertain. Reliability, recovery, and tool design are the variables to track. The prompt-engineering piece covers how to turn prompt choices inside the loop into testable variants.

Frameworks and models will keep changing. A useful hypothesis is that wider scope creates more failure paths; test it by expanding one dimension at a time and plotting success, recovery, latency, and cost. Keep the narrowest scope that satisfies the product need.