02 · Intelligent Agents
Agents that ship, and the six that quietly died in staging
Five frameworks, one long-running workflow, and the only question that separates a demo from a product: what happens on step fourteen?
In January a fintech showed me an agent that reconciled merchant disputes end to end. It was genuinely impressive for about four minutes, which is roughly how long the happy path takes. I asked them to run the case where the merchant portal returns a 302 redirect to a login page. The agent read the login HTML, decided it was the dispute record, hallucinated a resolution, and wrote it to their ledger. Nobody in the room had seen that before, because nobody had tested step fourteen.
That is my whole thesis on agents in 2026. The model is no longer the bottleneck. Tool-calling reliability on single calls now sits comfortably above 95 per cent for frontier models. But an agent that takes twenty steps at 97 per cent per-step reliability completes about 54 per cent of the time. The engineering discipline that gets you from 54 to 96 is not prompting. It is state management, idempotency, timeouts, schemas and human checkpoints — the same boring things that make distributed systems work.
The five frameworks, honestly
LangGraph is where I’d start for anything stateful and long-running. You model the agent as an explicit graph with typed state, and you get durable checkpointing, time-travel replay and interrupt-for-human-approval as first-class features. The cost is a genuine learning curve — expect a week before your team is fluent — and a certain amount of ceremony for simple flows. LangGraph itself is open source (MIT); the managed Platform tier is where the invoice appears, and pricing at filing starts on a free developer tier with paid plans in the low tens of dollars per seat plus usage.
The OpenAI Agents SDK is the fastest path from zero to a working multi-agent handoff. Sessions, handoffs and guardrails are pleasant abstractions, tracing is built in, and the Python API is small enough to read in an afternoon. It is model-agnostic in principle via a Chat Completions-compatible adapter, but the ergonomics clearly assume you are staying inside one vendor. I use it for prototypes and internal tools; I have not yet put it under a customer-facing SLA.
CrewAI sells role-based crews — researcher, writer, critic — and demos beautifully. In production I found the role metaphor gets in the way: you end up fighting the abstraction to express “call this API, check the status code, retry twice, then escalate”. Fine for content pipelines and research summarisation. I would not run a payments workflow through it.
Google’s Agent Development Kit is the most opinionated of the five and the best documented for deployment. If you are already on Vertex AI, the path from local dev to a managed Agent Engine runtime is short and the evaluation tooling is respectable. Off Google Cloud, the value drops sharply.
Pydantic AI is my quiet favourite for teams who already write typed Python. Everything is a validated schema, dependency injection is clean, and it does not try to own your architecture. It gives you less — no built-in durable execution — which is exactly why some teams like it.
MCP changed the integration maths
The Model Context Protocol has done more for practical agent deployment in eighteen months than any model release. Instead of writing bespoke tool adapters per framework, you stand up an MCP server once and every compliant client can use it. I have watched integration estimates fall from three weeks to four days on the strength of that alone.
The caveat is security, and it is not theoretical. An MCP server is a remote capability grant. If a tool returns attacker-controlled text and your agent treats tool output as instructions, you have a prompt-injection path straight into your systems. Treat every tool return as untrusted input, scope tokens per-tool rather than per-agent, log every invocation with arguments, and require human approval for anything that writes to money, identity or production infrastructure.
What separated the shipped from the shelved
Across the eleven deployments reviewed this quarter, five agents reached production and six did not. The five that shipped shared four habits. They constrained scope savagely — one workflow, one department, one clearly reversible action. They ran on durable execution, so a crash at step fourteen resumed at step fourteen rather than restarting a £0.40 run from scratch. They had a human approval gate on any irreversible step, with a target of removing it only after 500 clean runs. And they had an eval set of real historical cases with graded outcomes, run in CI on every prompt change.
The six that died mostly failed on the same thing: unbounded scope. “An agent for operations” is not a project, it is a wish. The other recurring killer was cost surprise — one team’s research agent averaged 340,000 tokens per run because a search tool returned raw HTML, and at flagship rates that is roughly £2 a query for something a junior analyst would do for less.
My advice, unchanged since October: build the workflow as a deterministic pipeline first, then replace the specific steps that genuinely need judgement with a model call. Most of what is sold as an agent is a state machine with three interesting nodes. Ship the state machine.
Framework documentation checked 6 March 2026. See modelcontextprotocol.io for the MCP specification. Disagree? Write to the desk.
Next in this issue: Services-as-software: when you buy the outcome, not the seat →