Processes You Should Not Hand to an AI Agent

What not to automate with an AI agent comes down to six red flags. Do not hand a process to an agent when one wrong action is expensive or cannot be undone, when nobody owns the result, when the data it would act on is unreliable, when you cannot say what success looks like, when the agent cannot reach the systems through proper access, or when the judgement is the valuable part of the work.

Four of those flags mean "not yet": fix the gap and the process may become a good candidate. Two mean "not alone": split the process so the agent does the preparation and a person makes the call. Below is how to spot each flag and what to build instead.

What not to automate: the six red flags at a glance

An AI agent is software that decides its own next step and acts in your systems: it reads, looks things up, updates records, sends messages. That is what makes it useful, and it is also why the bar for handing it a process is higher than for a fixed workflow. Anthropic's engineers, in Building effective agents, put the trade plainly: "The autonomous nature of agents means higher costs, and the potential for compounding errors." They also say agents fit tasks that "have clear success criteria" and "enable feedback loops". Most of the red flags below are those conditions turned around.

This post is about whole processes and whether an agent should run them. If your question is narrower (should this one step use a model at all?), when not to use AI covers exact rules, low volume and decisions about people. And if you want to rate a process rather than just look for blockers, the automation scorecard turns the same ideas into eight scored checks.

1. High-risk actions where one mistake is final

If one wrong run costs real money, reaches customers or cannot be reversed, do not let an agent take that action on its own. Payments, refunds above a set amount, deleting records, an email to your whole list, a price change on a live shop: each is cheap to get right and expensive to get wrong.

Website work has its own versions. A robots.txt file with two lines, User-agent: * and Disallow: /, tells crawlers to stay off the entire site; Google's own robots.txt documentation uses exactly that pair as its example of blocking all crawlers (AdsBot aside, which has to be named separately). Bulk redirect changes, canonical tags and noindex rules are in the same class. An agent "tidying up" any of them can undo months of work in one run, and nobody notices until the traffic report.

The problem is compounding. A person who makes a mistake usually stops at the first odd result. An agent acting on a wrong assumption can repeat it across every record it touches before anyone looks.

Instead: let the agent propose and a person approve. OWASP lists this as a core mitigation for excessive agency in LLM applications: "Utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken." Put hard limits in code as well (a maximum refund per call, no deletes, a cap on recipients), so a confused agent cannot talk its way past them. Our post on human-in-the-loop AI covers how to design that approval step so people actually read it.

2. Nobody owns the outcome

If you cannot name the person who answers for the process when it goes wrong, it is not ready for an agent. This flag is the one teams skip most often, because it does not look like a technical problem.

It shows up in processes that sit between teams. Partner invoices touch finance, operations and whoever manages the partner. Lead routing touches marketing and sales. Everyone does a bit, so nobody has decided what "correct" means, who reviews the exceptions, or who is allowed to change the rules. Put an agent on that and every error becomes a meeting about whose problem it is.

Risk frameworks treat this as basic. NIST's AI Risk Management Framework asks, under GOVERN 2.1, that "roles and responsibilities and lines of communication related to mapping, measuring, and managing AI risks are documented and are clear to individuals and teams throughout the organization." You do not need a formal framework for a small automation, but you do need the same answers.

Instead: before anyone builds, write down six answers: who owns the outcome, who reviews errors, who can change the rules, who can switch the agent off, what the success measure is, and who exceptions escalate to. If you cannot fill a field, settle it first. That conversation often fixes the manual process too.

3. The data is poor

If you would not trust the records yourself, do not let an agent act on them. An agent working from a CRM with duplicate contacts, stale deal stages and three spellings of the same company will produce confident, well-formatted wrong actions: the follow-up goes to the wrong person, the report counts the same client twice, the "inactive" customer gets a win-back email the week after renewing.

Signs to look for:

• People keep their own spreadsheet because they do not trust the system.
• The same fact (a price, an address, a status) lives in two places and they disagree.
• Key fields are free text where they should be a fixed list.

Instead: pick one system of record for each fact, clean it, and fix the input forms so it stays clean. A useful first automation here is a read-only one: a weekly job that flags duplicates, empty required fields and records that contradict each other, for a person to fix. It improves the data and teaches you where it breaks, with no risk of acting on it. Once the data holds up, the original process may be a good candidate.

4. There is no measurable outcome

If you cannot say which number should change, you cannot tell whether the agent works, and neither can anyone deciding whether to keep paying for it. "Make our content better", "help sales be more proactive" and "improve customer experience" are aims, not outcomes an agent can be tested against.

This is a common way agent projects die. Gartner predicted in June 2025 that over 40% of agentic AI projects will be cancelled by the end of 2027, citing "escalating costs, unclear business value or inadequate risk controls". Unclear value is the one you can fix before you start.

From the search side, watch out for volume pretending to be an outcome. "Publish more pages" is easy to measure and easy to automate, and it is the wrong target. Google's spam policies name "using generative AI tools or other similar tools to generate many pages without adding value for users" as an example of scaled content abuse. The outcome you want is pages that rank and convert, and that needs editorial judgement (see flag 6).

Instead: choose one or two measures before building, such as time from request to done, error rate, response time, or the share of outputs a person had to rewrite. Then measure the process by hand for two to four weeks to get a baseline. If you cannot find a measure that matters, that is a sign the process is not worth automating at all.

5. The agent has no proper access to the systems

If the only way into a system is a shared login, a screen to click through or a person's personal account, the agent should not run that process yet. An agent is only as safe as the access you give it, and broad access is the usual shortcut.

OWASP names the three roots of excessive agency as excessive functionality, excessive permissions and excessive autonomy, and its advice on permissions is direct: "Limit the permissions that LLM extensions are granted to other systems to the minimum necessary." An agent logged in with an admin password can do everything that admin can, including what it was never meant to do. It also leaves an audit trail that says the admin did it.

Check three things before you plan the agent:

1. Is there an API for the actions the process needs, not just for reading?
2. Can access be scoped to those actions, ideally per task and with an expiry?
3. Do actions show up in a log as the agent, separately from people?

As an example of what scoped access looks like in practice, the assistant in TeamOS gets a temporary key per request that is read-only while it proposes changes and has task scope only when it applies them, so payroll and member management stay out of its reach.

Instead: build the integration before the agent. Sometimes that is a small internal endpoint that exposes exactly three actions with proper permissions. That work is usually the bigger part of the job anyway, and it is what our API and workflow integration work covers.

6. The judgement is the job

If the valuable part of a process is the decision itself, keep the decision with a person and automate around it. Strategy, pricing a big deal, negotiating a renewal, handling an upset key client, choosing which topics to publish and which to drop: an agent can produce an answer for any of these, but the answer is not what you are paying for. The reasoning, the context nobody wrote down, and the accountability are.

It is worth being specific, because "requires judgement" is easy to claim for any process. A process is judgement-heavy when two experienced people would reasonably decide differently, when the right answer depends on context outside the systems (a relationship, a plan not yet announced, a feeling about a client), and when the person deciding has to stand behind it afterwards. Hiring and credit decisions add legal duties on top. Those are covered in when not to use AI.

What to do instead: automate around the decision

For the two "not alone" flags, the answer is rarely "do nothing". Split the process into steps and give each step to whoever is best at it: rules and API calls for the mechanical parts, an agent for gathering and drafting, a person for the decision.

Three examples:

• Content plan. Code pulls search and analytics data; an agent clusters topics and drafts briefs; an editor chooses what to publish; code schedules and reports. The editor's time goes into the decision, not the spreadsheet.
• Refund over the limit. A rule catches the request; an agent summarises the case and the customer's history; a person approves or declines; code pays and logs it.
• Contract renewal. A date triggers it; an agent prepares a usage recap and draft terms; the account owner negotiates; the CRM is updated.

This is the same pattern as approval above a threshold. In GrowthDesk, an operations app we built, each deal has a target and a ceiling, and deals that go past the ceiling need approval. The software handles the routine cases and routes the rest to a person.

For the four "not yet" flags, the fix comes before the agent:

Deciding which processes to hand over

Run the six questions over your list of candidate processes before you talk to anyone about building. A process with no red flags is a good candidate. A process with one or two "not yet" flags is usually a good candidate after a few weeks of groundwork, and that groundwork tends to help the manual process too. A process where the judgement is the job stays with a person, with an agent doing the preparation around them.

If you would like a second pair of eyes on the list, a discovery and scoping session maps how each process really runs and marks every step as rule, agent, person or "fix first". When a process passes, our AI automation service builds it with the access limits, approval steps and logging it needs.