Table of Contents

When should you not use an AI agent? When the feature needs to give the same answer to the same question every time. An agent that plans its own steps is powerful in a conversation and a liability in a pipeline — because the very thing that makes it feel smart, deciding the order of operations at run time, also means it can decide differently next time.

If you’ve built with autonomous agents, you already know the good side: hand the agent a set of capabilities and it composes tasks you never explicitly coded. That’s the threshold of autonomy. This post is about the other direction — the moment you should take that autonomy back.

The question isn’t “agent or not.” It’s “how much autonomy, where.”

The framing that trips teams up is binary: should this be an agent or a hard-coded pipeline? Wrong question. Autonomy isn’t a switch, it’s a dial, and the real design work is deciding how far to turn it for each part of the system.

An agent planner — the part that decides which steps to run and in what order — is exactly where the dial matters. Give it full freedom and you get flexibility. You also get non-determinism: the same request can take a different path, skip a step, or combine things differently from one run to the next. In a chat that’s fine, even delightful. In a feature that has to be complete and reproducible, that freedom is the risk.

Where autonomy is a strength vs. where it’s a liability

The line is about what the task requires.

Conversational tasks — autonomy is a strength. “Pull together what you can about this account.” There’s no single correct execution path, the user is in the loop to judge the result, and variation between runs is acceptable, even useful. Let the agent plan.

Pipeline tasks — autonomy is a liability. “Return every record matching these conditions.” Now there is a correct answer, completeness matters, and the same input must produce the same output every time. An agent that decides the order — and might skip or reorder a step — introduces variance exactly where you can’t afford it. Here, the planner’s discretion buys you nothing and costs you reproducibility.

An agent’s autonomy is a strength in conversational tasks and a liability in pipeline tasks. When a feature has to return the same answer to the same question, the planner’s discretion is a risk, not a feature.

The fix: autonomy on the outside, determinism on the inside

You don’t have to choose “all agent” or “no agent.” You place the dial deliberately.

The move is this: don’t hand the agent a pile of small actions and let it improvise the sequence. Hand it one action — “do this whole job” — and implement the inside of that job as a fixed-order pipeline.

From the outside, the conversational layer still feels like an agent: the user talks to it naturally, it figures out intent, it calls the right capability. But when the request lands on a task that needs completeness and reproducibility, that capability isn’t an improvisation — it’s a single, deterministic pipeline that runs the same steps in the same order every time. Autonomy lives in the outer conversational layer; determinism lives in the inner execution layer.

The corollary: the LLM belongs only at the two ends

Look closely at that inner pipeline and you notice something about where the LLM actually sits.

In a well-shaped pipeline, the LLM appears at exactly two points: the entrance (turning the user’s natural-language request into a structured spec) and the exit (turning the structured result back into natural language). Everything in between — fetching, filtering, sorting, joining — is ordinary deterministic code. No model in the middle.

This has a consequence people underestimate: “understanding the query” is not something the AI just does for you — it’s something you have to build. And the thing you build isn’t mostly code. It’s a prompt: the piece that reliably converts a fluent human question into a structured spec (say, JSON) that the deterministic middle can execute. The code is plumbing around that prompt. So when someone says “the AI will figure out what the user wants,” the honest translation is: “we will write and maintain a prompt that turns intent into a spec, and wrap it in deterministic code.” That’s a build task, not a freebie.

How to decide, in practice

A short checklist for any feature where you’re tempted to reach for an agent:

• Is there one correct answer? If yes, lean deterministic. If the value is in exploration and variation, lean agent.
• Does completeness matter? If missing a result is a bug (not just a weaker answer), don’t let a planner decide whether to run that step.
• Must the same input give the same output? If reproducibility is a requirement — for audits, for trust, for testing — pin the execution order. A planner that varies its path can’t promise this.
• Is a human judging each result? If yes, variation is cheap and autonomy pays off. If the output feeds another system unattended, variation is expensive.

The pattern underneath all four: give autonomy where a wrong or varied answer is cheap to absorb, and pull it back where it isn’t. That’s the same reversibility logic that governs when to let an agent write vs. only read — you delegate what you can afford to have go sideways, and you gate what you can’t.

Takeaway

The mistake isn’t using agents. It’s letting an agent’s planner run the parts of your system that need to be complete and reproducible. Turn the dial deliberately: autonomy on the outside where a conversation lives, determinism on the inside where a pipeline has to give the same answer twice. Put the LLM at the entrance and the exit, keep the middle as boring deterministic code, and remember that “understanding the query” is a prompt you build — not magic the agent supplies. Use the agent for what it’s uniquely good at, and stop asking it to be reliable at the one thing its autonomy actively works against.

Related: this is the flip side of what makes an AI agent autonomous — that piece is about crossing the threshold into autonomy; this one is about knowing when to step back over it.