Autonomy Is Not the Bug

I keep coming across practitioners arguing that the answer to runaway agents is to kill autonomy entirely. One wrote it up succinctly last week: a multi-agent loop that worked beautifully in demo got stuck in a recursive Planner-Executor loop three days into production. $200 in API credits burned in two hours, midnight alert, conclusion: "autonomy is a bug, not a feature."

I think he's onto something real, though I'd land somewhere different on the fix.

The false dichotomy I keep noticing in these "agent reliability" discussions is autonomous versus deterministic, pick one. As if the only way to avoid the 3am Slack ping is to rip out the agent and ship a plain DAG.

The pain is real, and the numbers say so. Gartner forecasts that more than 40% of agentic AI projects will be cancelled by 2027, mostly because teams hit the same wall he did.

That said, Cursor runs agents in production. Claude Code runs agents in production. Anthropic Skills triggers autonomous tool calls on millions of sessions. None of those are deterministic workflows. What they have, and what most setups skip, is eval-gated promotion and automatic rollback.

I think it helps to look at this as three camps, not two.

Camp 1 — Full autonomous, no gates. AutoGPT-era. This is the failure mode that bit him, and it bites most of us at some point. Fast to demo, brutal in production.

Camp 2 — Full deterministic, hard pipelines. Temporal, n8n, classic DAGs. Reliable, auditable, predictable. You also lose the adaptive reasoning that made you want an agent in the first place.

Camp 3 — Eval-gated agentic. The agent stays autonomous, but every new version gets shipped behind a champion/challenger split: 90% of traffic on the current champion, 10% on the challenger, an LLM judge scoring each interaction on safety, relevance, tool accuracy. Promote on improvement, rollback on regression. Users notice nothing.

This is the camp I've been building in for the last six months with Récif, so take what follows with that disclosure: I'm biased toward this approach because I ship it. The reason I keep coming back to it is that the tradeoff feels honest. You keep the adaptive behavior of agents, and you treat agent failure as normal production traffic instead of a bug. It's the same discipline web infra teams use for canary deploys at Cloudflare — ship the new version to 10% of traffic, watch it, promote or rollback. Apply that same loop to agent behavior.

So before you pivot your whole stack to deterministic workflows, ask three things about your most expensive agent in production:

1. If it ships a regression tomorrow, how do you detect it before your users do? 2. What's the rollback mechanism, and who can trigger it without a code deploy? 3. What percentage of traffic is hitting the unproven version right now?

If you can't answer all three yet, you're probably closer to Camp 1 than you think. That's where the $200 midnight bills tend to come from.

I don't think killing the agents is the move. I do think they need the same operational discipline we'd give any other production service.