Scope beats autonomy: a contrarian take on AI agents

Open-ended agent autonomy is a brilliant demo and a poor production strategy. The agent that plans, browses, and improvises its way to an answer is thrilling to watch once and miserable to operate a thousand times. What holds up in production is the opposite: an agent scoped to one bounded task, with tools that are explicit about what they touch and failure modes you designed on purpose. Scope beats autonomy, and it is not close.

Why does autonomy lose in production?

Autonomy trades predictability for range. An agent that can do anything will, eventually, try to do anything, and the long tail of “anything” is where you get the production incidents: the unbounded loop, the destructive write nobody reviewed, the confident wrong action taken three steps deep where no human was watching.

The demo hides this because a demo is a single curated run. Production is the thousandth run on inputs you never tested. The same property that makes an autonomous agent impressive on stage (it decides for itself) is the property that makes it impossible to reason about when it fails at 2am. You cannot debug a system whose behaviour you cannot enumerate.

What does a scoped agent look like?

A scoped agent is built around three deliberate constraints:

• One real bounded task. Not “handle support” but “draft a reply to a billing question and attach the relevant invoice”. The boundary is the feature, not a limitation.
• Explicit tool definitions. Each tool states exactly what it reads and what it writes. A tool that only reads cannot surprise you. A tool that writes says so loudly, and you scope its blast radius before you ship it.
• Predictable failure modes. When the agent is unsure, it stops and asks rather than improvising. A boring, legible failure beats a creative, silent one every time.

The result reads as unremarkable, and that is the point. Boring agents are the ones you can put on a roadmap, observe, and trust.

How do you build for scope instead of autonomy?

Start from the task, not the model. Write the bounded job in one sentence, then enumerate every tool it needs and nothing more. Make each tool definition honest about its side effects so a reviewer can see the surface at a glance. Add a hard stop for the unsure case and a log line for every action, because an agent you cannot observe is an agent you cannot trust.

This is the design philosophy behind the agentic systems I build for teams: explicit tools, narrow surfaces, legible behaviour. It is also why so many ambitious pilots never reach production, a pattern I cover in why AI pilots stall before production.

Autonomy is the feature you reach for last, after scope, observability, and predictable failure are already in place. Demos reward the reverse order. Production does not.