One AI Agent Is Not a Strategy

You have a quote for one agent in front of you. The scope is clear, the price is defensible against the problem it addresses, and the only real question left is whether one is enough. Sometimes it is, and a section below says when. Most of the time the answer turns on something the quote does not itemise.

The agent is the small part of the first build

Whatever the quote calls it, a first agent is five pieces of work, and the agent logic is the cheapest of them.

• Context. What the agent needs to know to be useful, where that lives today, how current it has to be, and what happens when two systems disagree.
• Permissions. What it may read, what it may write, and which actions require a person. Set per action rather than granted once to the agent as a whole.
• Approval design. Which steps need a named human, how that sign-off is captured, and what the record looks like afterwards.
• Integration. Getting into and back out of the systems that hold the truth, including the failure cases: the write that half succeeded, the record that was locked, the duplicate created at three in the morning.
• Measurement. A baseline captured before anything changes, so somebody can say afterwards whether it moved.

Buying one agent means paying for all five, scoped to one task. That is why a first agent looks expensive relative to what it visibly does, and why the second one does not have to.

One agent rebuilds its context every time it runs

An agent with no prepared context layer starts each run from nothing. It reads the records it can reach and reconstructs the account position from whatever activity it finds, at a cost that scales with the size of the account rather than the size of the task. Two further consequences follow, and neither shows up in a demonstration, because a demonstration uses a chosen example on clean data.

It is inconsistent. Two runs against the same account can assemble different pictures, because the reconstruction depends on what was reachable and recent at that moment. Somebody then adjudicates between them, which is work you did not have before.

It cannot be inspected. When the output is wrong, the input no longer exists in any fixed form, so the diagnosis is a re-run and a guess. A prepared context layer, built once against your records on a schedule, gives the agent and the person the same account position to work from.

The second agent is the test of whether the first was built properly

A first agent always works in the sitting where it is shown to you. The honest test arrives when you want a second one in a different workflow.

A foundation designed properly is one the second agent can inherit: the context layer, the permission model, the approval and audit design, the integrations and the measurement method. What is left is its own logic, its own evaluation and its own adoption work, which is a smaller build than the first. If instead it needs its own connectors, its own copy of your data and its own way of recording who approved what, the first one was a point solution, and you find that out at the moment you were hoping for leverage.

Four questions worth asking before you sign for the first agent, whoever is quoting:

• Where does this agent get its context, and can a different agent use the same source without rebuilding it?
• How is authority recorded per action, and does that model extend to workflows beyond this one?
• What is the baseline, who captures it, and when?
• When the person who built this moves on, what documents exist, and who is named as the owner?

Ask them of any supplier, us included. The measure afterwards is equally blunt: how much of the second build was new, and how much it inherited. Nothing else tells you as clearly what you bought the first time.

Three tools means three copies of your data and three sets of rules

The other route to the same disappointment is buying three point solutions from three vendors over eighteen months. Each arrives with its own connector into your CRM, its own extract of your data, its own idea of what a customer record means, and its own rules about what it may write back.

That is not three times the capability. Your customer is described three different ways, reconciliation lands on somebody who chose none of the tools, and nobody is accountable for the whole. Work removed at task level reappears as coordination, which is harder to see and harder to cost.

When one agent is genuinely the right purchase

Often enough that we say it on first calls. Buy the single agent when most of the following hold.

• The job is bounded. One kind of input, one destination, a rule set that does not change from week to week.
• It needs no shared context. Everything required is in the document or message in front of it, not in the history of the account.
• Errors are contained and correctable. A mistake is visible quickly and reversible cheaply, and nothing customer-facing goes out unattended.
• Nothing you report to the board depends on it. If a number in a board pack moves because of it, you need the measurement layer, and that is no longer a single-tool purchase.
• There is no second one planned this year. If two more are already on the list, you are buying the foundation eventually, and buying it after three point solutions costs more than buying it first.

For a UK builders' merchant we have built an order-entry agent on OpenAI's GPT-5.6, now in staging, that reads incoming orders and writes them into their system. The hire they had budgeted at £20,000 a year was not made. That is the shape of work a single agent does well: a defined input, a defined destination, and a rule set that holds.

We build single agents, and where that is what your situation calls for we will say so rather than sell you a programme you do not need. Put a named owner on it and capture a baseline anyway. Both cost nothing and make the next decision evidence rather than opinion.

The value compounds in the shared layer, not in the agent count

Where a second and third workflow are coming, the arithmetic inverts. Each additional agent works from the same prepared context, so it starts from the same account position rather than its own reconstruction. A change to the permission model applies everywhere at once. Results are comparable across workflows because the baseline method is the same, which is the difference between knowing the work is paying and believing it is.

Agent count is the wrong scoreboard. Two agents in daily use, with named owners and a measured baseline, are worth more than six that were demonstrated once.

That is the structure behind AI Accelerator, a 12-month programme delivered one department at a time. The first wave establishes the context and detection foundation, each quarter brings one new department onto AI while earlier departments keep running, and a standard wave activates two production agents in that department. Two, not ten, because the constraint is what a department can absorb and evidence, not what can be built. The client commits one quarter at a time, and pricing starts from £10,000 per month.

Where the approval boundary sits, whichever you buy

This does not change with the size of the purchase, and a single-tool purchase is where it most often goes undefined. Every action an agent can take is classified on a ladder before release. Autonomy is granted per action, not per agent, so the same agent may read and draft freely while being hard-blocked from sending anything to a customer.

For many workflows the correct steady state is draft or recommend, permanently, and that is a finished design rather than a cautious first version of one. Higher autonomy is earned through evaluation results and operating evidence, and human accountability for the workflow is never removed. If the quote you are holding does not say where each action sits on that ladder, resolve that before you argue about price.

Further reading on the build-or-buy question itself: custom agents compared with off-the-shelf tools.

The next step

If you are holding a quote for one agent, the decision is not really about that agent. It is whether the workflow behind it is the only one you will want to change, and whether the foundation it needs exists yet.

The AI and Data Readiness Assessment answers both. The output is a ranked list of candidate workflows, where your data and permissions stand, the action and approval map, and a straight recommendation: one build, a programme, or not yet. Fixed scope, no obligation, and the third of those three is a real answer rather than a polite way of declining the work.

Book a diagnostic. If the answer is a programme rather than a build, how a department-by-department rollout is sequenced sets out the order.