# Agent or a single call: how much autonomy you actually need

> When one model call is enough, when a fixed chain of steps is better, when you really need an agent, and what its freedom costs you.

Published: 2026-04-14 · Source: https://subxcat.com/articles/agent-or-single-call · Author: SUBXCAT

"Agent" now gets stamped on anything that calls a model more than once. That makes it easy to think of agents as the next level up from "just a request," something to aspire to. In practice it's a different tool with a price that isn't obvious at first.

Let's go through three levels in order of increasing freedom.

## A single call

Data and an instruction go in, an answer comes out. Classify a request, pull fields from a document, shorten text, translate, suggest a headline. A surprisingly large share of real tasks lives here.

The benefits are plain: predictable cost, predictable latency, easy to test, easy to see what went wrong. If a task is solved by one call with a good prompt and maybe a couple of examples, don't complicate it.

## A chain of steps

When one call isn't enough, the next step isn't an agent but a fixed pipeline where your code sets the order:

- the model classifies the request;
- based on the class, code decides which data to fetch;
- a second call writes the answer from that data;
- a third checks the answer against a checklist.

Each step can be tested separately, each has a clear input and output, and the cost is still known up front: so many steps, so many tokens. When something breaks, you can see which step. Most tasks people want to hand to an agent fit neatly into a chain like this with a branch or two.

## An agent

An agent is when the model decides the order of steps: it has a set of tools, picks which to call, looks at the result and decides what to do next until it considers the job done.

That's justified when the path to a solution genuinely can't be laid out in advance:

- research, where the next step depends on what the previous one found;
- work on code, where you read files, run tests, fix and check again;
- tasks with many tools, where there are too many combinations for hand-written branches.

## The cost of autonomy

You pay for flexibility in several currencies at once.

**Cost and time become unpredictable.** One task takes three steps, a similar one takes thirty. Each step resends a growing context. Without a ceiling on steps and tokens per task, an agent can loop and diligently work until the budget runs out.

**Errors compound.** If each step is less than perfectly reliable, a long chain of decisions is noticeably less reliable than any single step. A wrong conclusion at step three carries through to the end.

**Testing gets harder.** The same input can take different paths. You end up checking behavior rather than an answer: did it reach the goal, did it do anything extra, what did it spend.

**The attack surface grows.** An agent with tools that reads external data is exactly the setup where prompt injection turns from an embarrassment into an action.

## If you do need an agent

- **A narrow toolset**: only what this task requires, with the specific user's permissions.
- **Hard limits**: steps, tokens and time per task. When exceeded, stop with a clear message, not a silent failure.
- **Confirmation for anything irreversible**: whatever sends, deletes or pays needs a human yes.
- **A full log**: every tool call with arguments and result. Without it, an incident review is guesswork.
- **A comparison with the simple version**: run the same tasks through a chain without an agent. If the results are comparable, take the chain.

## How to choose

Start with a single call. If it falls short, add steps in code. When the branches multiply until the code becomes a maze, and the path really depends on intermediate results, that's when an agent makes sense. Move up one level only when the current one hits its ceiling, not because agents are in fashion.

SUBXCAT can review your agent setup and point out which parts would run more reliably and cheaply as a plain chain.