Autonomous agents are being pitched for workflows that should never run autonomously. The teams winning with agents in the enterprise are not the ones that gave them the most freedom – they are the ones that constrained them the hardest.

“Agentic AI” is currently the term doing the most work and carrying the least definition on enterprise roadmaps. The promise is seductive: give a model tools, a goal and the ability to plan, and it will handle multi-step work from start to finish. The demos genuinely are impressive. The production incidents are impressive too – just in the other direction: an agent that repeated a payment four times, or one that confidently “resolved” a ticket by inventing a refund policy.

We have shipped agent systems that run reliably, and we have stopped several that should never have left the whiteboard. The dividing line is not model capability. It is whether the task tolerates compounding errors.

The real problem: errors multiply across the steps

A single LLM call that is 95% reliable is useful. Chain ten such calls into an autonomous workflow where each depends on the previous one, and your end-to-end reliability is 0.95^10 – around 60%. Add tool calls that can fail, external systems with timeouts and a planner that can pick the wrong next step, and a “95% reliable” agent becomes a coin toss over a long enough chain.

That is the arithmetic most agent pitches skip. Autonomy multiplies errors; it does not absorb them. The question for any candidate workflow is therefore not “can an agent do this?” but “what happens when it does the wrong thing at step 6 – and who notices?”

A framework: classify by reversibility and chain length

Before you build, place the workflow on two axes:

• Reversibility – if the agent acts wrongly, can the action be undone cheaply? Drafting an email is reversible (you review it before sending). Issuing a refund, changing a production configuration or filing a regulatory report is not.
• Chain length – how many interdependent steps follow before an outcome becomes binding? More steps, more compounded errors.

That yields a clear deployment stance:

1. Short chain, reversible → full autonomy is fine. Triaging and tagging a ticket, drafting a summary, suggesting a categorisation. Let it run; a human catches the rare error further down the process.
2. Long chain, reversible → autonomy with checkpoints. Research-and-draft workflows: let the agent plan and execute, but put its plan and the intermediate results in front of a human for approval before the final reversible action happens.
3. Short chain, irreversible → human-confirmed action. The agent prepares everything, and a human confirms the irreversible step with a click. This is exactly where most of the actual “agentic” value sits in the enterprise.
4. Long chain, irreversible → do not build an autonomous agent. Break the task into supervised steps. The mathematics of compounding errors makes full autonomy negligent here – no matter how good the demo looked.

Most of the failed agent projects we get called in to rescue were trying to build quadrant four.

The architecture patterns that work

For the workflows that genuinely justify agents, three patterns separate reliable systems from fragile ones:

Constrain the action space

An agent with twenty tools and open-ended autonomy is a debugging nightmare and an attack surface. Give it the minimum set of tools, each with strict input validation, hard timeouts and idempotency, so that a retry does not double-charge or double-send. The agent must not be able to perform any action you have not explicitly and narrowly permitted.

Make the plan inspectable

The agent should produce an explicit plan before execution, logged and – for more sensitive work – submitted for approval. When something goes wrong, the question “what was it actually trying to do?” must be answerable from the trace, not guessed at. An agent you cannot inspect is an agent you cannot operate.

Bound the loop

Every agent loop needs a hard ceiling on steps, retries and cost. The classic failure is an agent stuck retrying a failing tool, burning tokens and time until somebody notices the bill. Cap the iterations, cap the cost per task, and escalate loudly to a human when the limit is hit.

A worked example: an onboarding agent

A financial services provider wanted to automate customer onboarding operations – collecting documents, validating them, checking sanctions lists, opening accounts. The vendor pitched a single autonomous agent that would do all of it. That is quadrant four: long chain, irreversible (account opening, compliance checks).

We rebuilt it as a supervised pipeline rather than an autonomous agent:

• One agent collects and validates documents (short chain, reversible) – fully automated.
• It prepares the sanctions/KYC check and presents the results with confidence scores – a compliance officer makes the decision (short chain, irreversible → human-confirmed).
• Account opening only runs after explicit approval, through idempotent, validated tool calls.

Outcome: onboarding handling time fell from around 95 to around 32 minutes of human work per customer (a 66% reduction), while every irreversible step kept a named accountable person. The fully automatic end-to-end runs the team had hoped for did not materialise at the compliance step – and that was the right result, not a shortfall. A fully autonomous version would have automated precisely the steps that must not be automated in a regulated business.

Most “agent” use cases are really workflow plus model

One clarifying question cuts through most of the agent hype: does this task genuinely require the model to decide what to do next, or does it merely need a model at a few fixed points in a known workflow? The overwhelming majority of enterprise “agent” use cases are the second kind – a deterministic process in which a model handles language understanding or text generation at particular points, while the control flow is fixed and known in advance. Calling that an agent is a category error that imports all of autonomy’s reliability problems without any of its benefits.

The difference in reliability is stark. A fixed workflow with model-backed steps fails predictably: if step three is 95% reliable, the workflow is 95% reliable at step three, and you know exactly where a check belongs. An autonomous agent that picks its own path compounds errors across every decision and fails in ways you cannot enumerate in advance – which makes it far harder to test, to monitor and to trust. Given the choice between “the model decides the steps” and “we decide the steps and the model executes them”, the latter is dramatically more reliable and the right default for any process whose shape you already understand.

Reserve real autonomy – where the model plans its own sequence – for the genuinely small set of tasks whose steps cannot be known in advance: open-ended research, exploratory data analysis, debugging where the next action depends on what the last one turned up. Even there: constrain hard and keep a human at the boundary of irreversibility. The discipline is to assume first that the task is a workflow, and to reach for autonomy only once you can give a concrete reason why the path cannot be fixed up front. Teams that start with “let’s build an agent” build fragile systems; teams that start with “what does the actual workflow look like?” build reliable ones – and add autonomy only where it is worth its risk.

Pitfalls

• Autonomy as the goal. Autonomy is a cost (less control, harder debugging), not a benefit. Use as little autonomy as the task allows.
• No idempotency. Retries without idempotent tools cause duplicate actions – the most common and most expensive agent incident.
• Unbounded loops. Without a ceiling on steps and cost, a stuck agent becomes a runaway bill.
• Hiding the plan. If you cannot see what the agent intended to do, you cannot run it in production.
• Skipping the eval set. Agents need scenario tests – including adversarial paths and failure paths – not just happy-path demos.

Decision checklist

1. Where does this workflow sit on the reversibility × chain length matrix?
2. What is the realistic end-to-end reliability given the number of dependent steps?
3. Which steps are irreversible, and does a named accountable person confirm them?
4. Is every tool idempotent, validated and bounded by timeouts?
5. Is the agent’s plan logged and, where necessary, approved before execution?
6. Are there hard ceilings on steps, retries and cost per task?
7. Do we have scenario evals covering failure paths and adversarial paths?

The gridz view

The organisations getting real value out of agents are unromantic about them: they use agents to prepare work and humans to own consequences, and they constrain the action space until the system is boring. “Boring in production” is the highest praise an agent system can earn. If a vendor wants to sell you a fully autonomous agent for an irreversible, multi-step process, the demo is the easy 20% – and the missing 80% is the part that gets you out of bed at 2 a.m. We design agent systems around the cost of an error: automate aggressively where mistakes are cheap and reversible, and keep a human on the trigger where they are not. If you would like to assess which of your workflows qualify, talk to us.