Use the least autonomous pattern that does the job

Agents are the headline of the moment. Every vendor deck has them, and every leadership team is being asked what its agent strategy is. It’s a fair question, but it tends to skip a more useful one: what is the simplest thing that would solve this problem in this journey?

In my experience, most of the value available today comes from patterns well short of full autonomy. More autonomy is not more maturity. It is more cost: more controls, more testing, more monitoring and more trust needed from the people who work alongside it. So it should be earned, use case by use case.

Five patterns cover most of the opportunity

You don’t need a new architecture for every use case. Five patterns, reused, cover most of what organisations are trying to do. The names are plain English; the industry terms are in brackets.

1. Assistant (copilot)

A person provides context, asks for the work and reviews the result. Choose it when a person directs the work and checks every output, for example drafting a proposal from a brief. Around the model: approved access, clear instructions and human review.

2. Knowledge assistant (retrieval-augmented generation, or RAG)

The system finds the relevant company information before it answers. Choose it when the answer depends on current company knowledge, for example answering a service question using today’s policy. Around the model: search, owned sources, permissions, citations and freshness. If nobody owns the policy documents, the assistant will confidently quote last year’s.

3. AI-enabled workflow (agentic workflow)

A defined process uses AI at particular steps, with rules and approvals around it. Choose it when the process is defined, repeated and rule-bound, for example reading an enquiry, extracting requirements, checking completeness and preparing a quote. Around the model: integrations, business rules, validation, approvals and an exception queue for the cases it can’t handle.

4. Bounded agent (AI agent with guardrails)

The AI chooses which permitted tools and steps to use to reach a defined goal. Choose it when the path varies case by case across several systems, for example investigating a delayed order and preparing a resolution. Around the model: restricted authority, stopping conditions, a record of where each task has got to, and a log of every action.

5. Prediction and optimisation (predictive and prescriptive analytics)

Models estimate what will happen; rules or optimisation choose what to do about it. Choose it when the decision is a forecast, a score or an optimisation, for example forecasting demand and recommending replenishment. Around the model: historical data, an agreed objective, operational constraints and monitoring for drift. Pricing insight of this kind delivered £6.5m of additional annual revenue in a food services business I worked with, and none of it needed a chatbot.

One journey, several patterns

The patterns become clearer when you walk a single journey. Take a typical B2B order, from first enquiry to delivery:

• A salesperson uses an assistant to draft the proposal, and edits it before it goes out.
• An account manager uses a knowledge assistant to answer a question about warranty terms, with the source shown.
• Incoming enquiries pass through an AI-enabled workflow that extracts the requirements, checks for anything missing and prepares a draft quote for approval.
• When an order is late, a bounded agent checks the warehouse, carrier and order systems and proposes a resolution for a colleague to confirm.
• Behind the scenes, prediction and optimisation forecasts demand so the stock is there in the first place.

Five different patterns in one journey, each chosen for the step in front of it. That is the point: the pattern follows the moment in the journey, not the other way round.

Autonomy is a cost. Make every use case earn it.

Why start low

• It’s easier to test. You can check an assistant’s outputs against a sample. Testing every route an agent might take is far harder.
• It’s easier to explain. Colleagues adopt what they understand. A tool that drafts and lets them decide is an easy yes; one that acts on their behalf needs more trust.
• It’s cheaper to run and to fix. Fewer moving parts, fewer integrations, fewer ways to fail quietly.
• You can always move up. An assistant that proves its accuracy can become a workflow. A workflow with clean exception data can become a bounded agent. Going the other way after an incident is much more painful.

The first question

Before choosing any pattern, ask whether a tool you already pay for can do the job. Many organisations have licences that are barely used. Use what you have, then configure it, and only then build. It is the least exciting answer and very often the right one.