Guide

Choosing agent complexity: why bigger is not safer

Published 19 September 2026

When you are specifying an agent and you honestly cannot tell whether the job is simple or complex, which way should you round? The instinct is to round up, because a bigger loop feels like headroom and headroom feels like safety. That instinct is wrong, because the two failure modes are not symmetric.

The tier framework below is ours. It came out of building the spec generator behind this site, and it is not an industry standard: nobody has an agreed definition of a moderate complexity agent that you can go and look up.

A complexity tier is a leash, not a quality dial

The common misunderstanding is that a higher complexity tier makes an agent better at hard things. It does not. In our engine the tier mostly sets one number: the iteration ceiling written into the agent's reasoning loop. For multi-agent systems the equivalent is a round ceiling used as a circuit breaker.

Tier Agent MAX_ITERATIONS Multi-agent round ceiling
Simple 5 10
Moderate 10 25
Complex 25 50

That is the mechanic that matters here. The tier is not adding reasoning ability, tools or context. You are choosing a leash length.

Keep that separate from stop conditions. Those are the halt predicates that should actually end a run: the goal is met, the input was invalid, the human declined. The ceiling sits behind them as a circuit breaker for the case where none of them fire. If your agent routinely ends because it hit the ceiling, the ceiling is not too low. Your stop conditions are missing.

Round down, because only one of the two failures is loud

The rule from our classifier is blunt: when torn on complexity, choose the simpler level. Under-provisioning fails loudly and cheaply: the agent stops short and the trace shows where it ran out of room. Over-provisioning fails quietly: the output usually looks fine and the cost turns up on a bill rather than in a stack trace.

Take under-provisioning first. You gave the agent the simple tier's five iterations and the job needed more. It stops short. The output is visibly incomplete, the run was cheap, and the trace shows exactly where it ran out of room. The fix is one number, and you find it on the first real test.

Now over-provisioning. You gave it the complex tier's twenty-five iterations for a job that needed a handful. It does not stop at a handful, because a model will usually find something else plausible to try: re-checking work that was already correct, calling tools it did not need, second-guessing a good answer into a worse one. The damage is spread thinly across a long run. No single moment went wrong, the output usually looks fine, and the cost turns up on a bill rather than in a stack trace. Anthropic's engineering post on building effective agents states the general version of this: "The autonomous nature of agents means higher costs, and the potential for compounding errors."

Demonstrably is the load-bearing word

Anthropic puts the general rule this way: "When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed." The test they attach matters more: complexity should be added only when it demonstrably improves outcomes. A tier you raised because you felt unsure has demonstrated nothing.

That post is often summarised as an argument against agents. It is not. It lays out a ladder from a single optimised call, through workflows, to agents, and it is explicit that agents suit open-ended problems where you cannot predict the number of steps in advance or hardcode a fixed path. Rounding down is not a rule to stay simple forever. It is a rule for what to do when the evidence runs out.

Harrison Chase draws a near identical ladder independently at LangChain, mapped to solutions rather than to agents specifically: low complexity calls for a no-code agent, medium for a no-code workflow, and only high complexity for a workflow written in code. Two competing companies landing on the same shape, simple by default, complexity earned, is a stronger signal than either post alone.

So the practical test is: name the observable that would make the loop need a sixth pass. If you can name it, say a search that can legitimately return nothing and needs a broadened retry, then you have evidence, and evidence beats the default. If the only reason you want a higher ceiling is that the task feels big, that is ambiguity, and ambiguity rounds down.

Autonomy: when torn, keep the gate

The sibling rule is harsher. When torn on autonomy, choose the more supervised level, because a needless approval gate is annoying while a missing one can take an irreversible action.

Wrong in the supervised direction, a person clicks approve on something that did not need approving. That is friction: visible in every run and removable in one edit once you have watched the agent behave. Wrong in the autonomous direction, the agent sends, deletes, pays or publishes, and there is no undo.

This is why guardrails in our engine are written as "Never X because Y" rather than as bare prohibitions, and why, when a human gate is required, they must forbid the gated action without a recorded approval. One of the engine's own examples reads: "Never send/delete/pay/publish without a recorded approval because the action cannot be undone." The approval has to be recorded, which makes its absence a checkable condition rather than something you hope the model respected.

Memory: when torn, choose the simpler kind

Third rule, same shape. When torn on memory, choose the simpler kind: none before in-session before persistent.

Memory is state that outlives the moment, which is what makes the wrong call expensive. Too little memory fails in front of you: the agent forgets, asks the same thing twice, and someone complains the same day. Too much fails behind you. Weeks later it acts confidently on something that has since become false, or carries a fact from one run into another where it does not belong.

One rule, three times

Decision When torn, choose Because the wrong call costs
Complexity tier The simpler tier Stopping short is loud and cheap. A loop that wanders is quiet and billed.
Autonomy level The more supervised level A needless gate is annoying. A missing one can act irreversibly.
Memory type The simpler kind Forgetting is visible. Remembering something stale is not.

Each of these is a tie-breaker that only fires when the signals are genuinely ambiguous. If the description says the route branches on outcomes, or that the agent must resume tomorrow where it left off, follow the signals.

A spec raised on evidence also has a readable history: you know which run forced each increase. A spec that started at the top has none, and nobody will ever be confident enough to bring it down.

Where this fits if you use Bespoke Prompting

These three defaults are written into the classifier that reads your description: complexity, autonomy level and memory type each carry a stated bias toward the safer side of a tie, and the tier that wins lands in the spec's reasoning loop as MAX_ITERATIONS. If it comes out tighter than the job needs, that is one number to raise after you have watched a real run.

Sources

The complexity, autonomy and memory tier framework described above is not from an external source. It reflects this site's own product design.

Suggested internal links