Don't automate shit: Not everything should be left to agentic AI

Walk past any tech conference in 2025 or 2026 and you'll hear the same mantra, repeated with enough conviction to pass for gospel: "We're AI-first now." Suddenly, every company is an AI company: every workflow is a prompt chain, every human process is a candidate for automation, and the workforce is now a mix of real people and agentic AI.

However, there's a quiet disaster unfolding in plain sight, one that no one wants to talk about because saying it out loud sounds like you're not on the AI train:

Some organisations are automating shit.

Not literally, I hope (unless you're in the waste treatment business), but in this context we're talking about automating broken processes. Processes with unnecessary bureaucracy, redundant approvals, and workflows that exist purely to protect someone's ego. Or processes that used to work back when it was created but wasn't maintained to scale with the business nor to adopt new methods or techniques as technology evolves.

So when you hand these broken processes to an agentic AI system, you don't get efficiency. You get automated shit. Even worse, these broken processes are now fast, scalable, and although a single model call is cheap, over time it sneaks up on you. Run a broken process a few hundred thousand times a month and you've simply industrialised your old problems.

Why everyone is automating right now (and why it's not entirely irrational)

Let's be fair first - the push toward AI-driven automation isn't just hype. There are legitimate reasons organisations are taking it into serious consideration:

Token costs justify efficiency gains when there's something to gain: Although the initial cost of training an LLM and maintaining agent orchestration is expensive (not to mention continuously running it), the payback can be real if that same process legitimately takes 20 human hours per week and AI reduces it to 1, the ROI speaks for itself. Companies need to show boards that those token costs are converting into savings. This creates pressure to find more processes to automate, which eventually means automating things that don't need automating just to feed the business case.

Competitive FOMO is a genuine motivator: When your competitor says they've replaced their customer support with an AI agent that resolves 80% of tickets without human intervention, that feels like a threat even if you know their process was broken before. The fear isn't rational, but the pressure is real.

There are processes worth automating: We work with clients all the time identifying processes in this bucket: the ones that are worth automating. Things like reconciling invoices that could be auto matched, reading 7-years of Zendesk tickets to then categorising them to make it easier for analysis and finding potential pain points, or reducing the amount of time front line agents search for information whilst the customer is on the phone are very legitimate processes that could be automated. These are legitimate wins because they are repetitive, rules-based, high-volume tasks where AI genuinely outperforms humans on speed and consistency.

Agentic AI in the right environment is really a game changer: When your senior leadership announces that they're bought everyone licences to enterprise-grade AI and ask you to show the benefits, you take that hammer every process start looking like a nail. In the case for some departments and roles, it is a game changer because they've never got access to something that is not only accessible but easy to implement. However, the problem is not access not ease to implement: its applying it to the right problem to fix and making sure the process was right to be automated to begin with.

What happens when you automate before you optimise

Three things will start to happen:

First, the problems scale: A broken approval process that delays decisions by four days now "delays" decisions in 40 minutes. You've sped up a problem without solving it. The decisions are still being blocked, only at higher velocity. Now you're making the wrong calls faster and questioning them less because "the AI handled it."

Second, debugging becomes harder: When a human-mediated process breaks, you can trace it to a decision point and generally you can ask someone why they did something and uncover intent. When an AI agent mediates that same broken process, the failure modes compound across layers of orchestration, tool calling, and context windows. You don't know why it's producing bad output because even the engineers who built the automation and sequence can't fully explain what a 128k-token chain-of-thought is doing in step seven.

Third, you create institutional blindness. Once a process is automated, it becomes invisible, like a black box. People stop thinking about the steps because the machine handles them. The redundancy that was quietly bleeding efficiency gets entombed in an agent workflow and nobody asks questions for six months until someone has to explain why customer satisfaction dropped after we "optimised" our onboarding flow with AI. When you open the box, it is filled with skills, recipes and rules within harnesses that no one really understands.

So what do you do instead? Three moves before building an agent

Move 1: Eliminate before you automate

This is the radical one that will get pushback from stakeholders who are emotionally invested in their processes. But hear this out: the most cost-effective automation is the one you never build.

There are hundreds of processes running inside organisations right now (including yours) that serve no measurable business outcome. They exist because someone created them years ago to solve a problem that either went away, was solved another way, or was never actually a problem in the first place.

Examples abound - let's play Non-Value Add Automation Bingo:

• Weekly status reports that are written on Fridays and deleted before they're opened
  

• Multi-stage approval workflows for where people are questioning why they're approving something they're not across.
  

• Customer satisfaction surveys sent to everyone who interacted with support (sometimes when they STILL HAVE AN OPEN SUPPORT CASE)
  

• Chatbots that is slapped on top of FAQ and customers rage click through them to get to an actual human to talk to.
  

There are plenty more but you see it often in many organisations - no one wants to rip that band-aid off. Just ask the question if it doesn't add any value to the customer, doesn't add any value for employees and it is not a mandatory regulatory thing that is required for compliance, then why are we doing it?

Move 2: Question every step before automating any step

Before you spend a single token on automation, draw the process on a whiteboard. Then ask three uncomfortable questions for every single step:

Does this step need to exist? Not "Can this be automated?", but "Should this step even exist?". Many processes survive purely through social momentum. No one designed them this way. They evolved like sedimentary rock: layer upon layer of "we should probably check with someone" accumulating until what was once a simple decision became a cross-functional committee.

If it must exist, can it be simpler? Stripping complexity before introducing AI is cheaper than introducing AI to manage complexity. Every additional step in an automated chain compounds error rates and token costs exponentially, not linearly. Multiply this by many other processes going through the same process and you've added to the compounding problem.

If it's simple and necessary, is AI the right tool? Not everything needs an agentic system. Some processes need better software, some need policy changes, and some just need someone to stop interfering. Before reaching for an LLM-powered agent, ask whether a script, a rule-based system, or a well-designed form would solve the problem without any token costs at all.

Move 3: When you do automate, design for value, not velocity

Here's where agentic AI earns its keep. Once you've questioned, simplified, and eliminated, now what's left is determining if it is genuinely worth automating.

Assess them against these 3 criteria:

They're frequent enough to matter: You don't need to automate something that happens twice a month for one person. But invoice reconciliation across 800 transactions per week? Customer-support routing across 4,000 tickets daily? Document summarisation for a team of 20 researchers who each process 15 papers per day? These are processes that are frequent enough that it matters.

They have measurable quality gates: The output of the automation must be verifiable either by human review at rates, or by rule-based validation that catches AI hallucinations before they reach a customer. Speed means nothing without quality controls baked into the design. If you automate a process where errors are silently compounding, you'll only discover it when someone complains about the outcome months later.

They produce defensible ROI: You should be able to model what these token costs will actually save you over 12 months. Factor in agent development time, maintenance overhead (remember that models update, APIs change, prompts drift), error-correction labour, and the cost of monitoring that someone needs to do because "set-and-forget" automation is a fantasy when you're dealing with non-deterministic systems.

A note on culture: the people who designed the broken process aren't stupid

Before this becomes another "process improvement" sermon where readers nod cynically while thinking about ways their team will never comply with yet another initiative, it's worth saying this plainly: most broken processes weren't designed by incompetent people. They were designed by rational people responding to real events: a compliance failure that required an approval step, a customer complaint that led to an extra handoff, a near-miss with data privacy that added a review checkpoint.

The process was good once. It became bad because the world changed and nobody revisited it.

Your job isn't to blame anyone. It's to be brave enough to say: "Things have moved on. Let's look at this again." That conversation will be harder than any prompt engineering exercise. And it will pay off more too, because you might end up automating 30% of what you planned to and achieving 80% of the results with 1/3rd of the token costs.

The bottom line

Agentic AI is not wrong. Automating processes that have value, streamlined, quality-controlled, purpose-driven workflows, is one of the most defensible uses of the technology in existence right now.

But automating something before you understand whether it's worth doing is how you spend thousand (if not millions) of dollars and discover at the end of the year that your organisation runs on faster version of the same mistakes, minus any capacity for human judgment when things go sideways.

Don't automate shit, fix the process first. And when there's something genuinely valuable left, then you can bring in the agents. Let them earn their keep.