A team is building an agent that plans and executes multi-step tasks. What architectural bounds must exist, and what usually goes wrong?

The bounds that must exist

• A step budget and a wall-clock budget, enforced outside the agent. An agent that can loop will loop, and the cost of an unbounded loop is real money.
• A cost budget per task, checked between steps, with a defined behaviour on exhaustion — stop and report, not silently continue with a cheaper model.
• Tool authorisation against the initiating user's permissions, evaluated outside the model. If the user cannot perform an action, the agent must not be able to either, regardless of what it was persuaded to attempt.
• Irreversible actions gated by explicit confirmation, described to the user in the application's words rather than the model's.
• Idempotency on every tool that has a side effect, since agents retry and re-plan and will call the same tool twice.
• A terminal state for every path, including "gave up", which must be visible rather than appearing as a hang.

What usually goes wrong

• No observability into the reasoning. When an agent produces a wrong outcome, the question is which step went wrong, and without a recorded trace of every step, tool call, input and output it is unanswerable.
• Compounding error. Each step's small error rate multiplies over a long chain, so a ten-step task with 95% per-step reliability succeeds about 60% of the time. The answer is usually fewer steps, not a better model — and decomposing a task into a deterministic workflow with model steps at specific points is far more reliable than an open-ended agent.
• Non-determinism making testing hard, which is intrinsic and is managed by evaluating on outcomes over a set of tasks rather than on exact behaviour.
• Cost that is invisible until the invoice, because a task's cost depends on how many steps it took.

The framing that produces better systems

Use an agent where the sequence genuinely cannot be predetermined, and a workflow everywhere else. Most tasks presented as agent problems are workflows with one or two steps requiring judgement, and implementing them as workflows makes them faster, cheaper, testable and debuggable.

The agent framing is frequently a design choice made before the problem was understood, and it is expensive to unwind.