Skip to content
StrategyJuly 2, 2026 · 8 min

The things we tell clients not to automate

Four patterns that look like perfect agent candidates and are not. We have lost projects over each of them.

Written by Subash, Project Lead

Week one of every ai247 engagement ends with a written go / no-go. Roughly one in six comes back as no-go, or as a substantially smaller yes than the client asked for.

Here are the four patterns that most often trigger it. Each has cost us money.

1. The process nobody can describe

The tell is simple. Ask three people who do the work to explain the rule, and you get three answers, all of them starting with "well, it depends."

That is not a documentation gap you can close in a workshop. It usually means the work is judgement being performed under the costume of a process, and the judgement lives in experience nobody has ever had to externalise. An agent can encode a rule. It cannot encode a rule that does not exist yet.

The right first project here is not an agent. It is writing the rule down, with the people who hold it, and seeing whether it survives a month of use. Sometimes a client does that and comes back. Sometimes writing it down turns out to be the whole win.

2. The high-stakes, low-volume decision

Automation pays on volume. Risk accrues on stakes. When a task is low-volume and high-consequence, the arithmetic goes the wrong way: you spend the full build cost and the full guardrail cost on a handful of decisions a month, each of which needs a human review anyway.

A useful sanity check: if every output needs a human to approve it, and the volume is low enough that approving is not the bottleneck, the agent is saving the cheap part and leaving the expensive part.

We sometimes build these anyway — but as assistive tooling that prepares the decision, priced accordingly, and explicitly not sold as automation.

3. The workflow that is about to change

If the function is being reorganised next quarter, if the CRM migration is scheduled, if the team lead is leaving — build later. An agent is wired into the systems and the shape of the work as they are on the day it ships. A reorganisation does not adjust it, it invalidates it.

This one is easy to miss because clients rarely mention it. It surfaces in the function map when somebody says "though that will all be different after the migration." That sentence is worth stopping the meeting for.

4. The problem that is really a data problem

Perhaps the most common of the four. The request is for an agent that answers questions from a knowledge base that is out of date, or reconciles records in a system where the records are wrong.

An agent over bad data produces confident bad answers, faster and at greater volume than the humans were producing them. It makes the problem harder to see, not easier.

The honest answer is that the first project is a data project, and it is less exciting and more valuable. We will say that even though it is not work we are selling.

What this costs us

We lose roughly one in six projects at the go/no-go, and we shrink the scope of quite a few more. Commercially, that is not nothing.

What it buys is that when we do say yes, the client can take it seriously. Every agency says they will tell you the truth. The only evidence that means anything is having done it while the money was on the table.

Write the guardrails before the capability

Read next
Engineering

Know what you need, or don't. We can help either way.

Already sure you want an agent, or a web, mobile or 3D product? We can scope it on the call. Still figuring it out? That's fine. AI is new, and we'll tell you honestly what's realistic. Chances are we've already worked with a company like yours, or a direct competitor, so we're not guessing.

Engagements start at $3,000. Typically live in under a month.