Blog

Why Agentic Automation Is Harder Than It Looks

Everyone sees the agent demo and thinks we're 2 weeks from production. we're not. the model is rarely the problem, it's everything around it.

Few things keep killing these projects - the data, and the process (approvals, gates, governance).

1. lack of good data

An agent can only act on what it can find, read and trust.. and most teams find out their data is way worse than they thought the day the agent starts using it.

1. Scattered - one decision needs CRM + spreadsheets + email + someone's head. Agents can't reconcile what it can't reach.
2. Inconsistent - same customer shows up 3 ways, "active" means one thing to sales and another to finance. Humans fix this on instinct, agents take it literally.
3. Stale - a person would double check an old record. the agent just runs with it.. at scale.
4. Tribal knowledge - this is a big one. why is this field blank? why does this exception exist? nobody wrote it down, so the agent guesses.
5. Access - permissions were built for people ("ask IT"), not a system account that needs read/write across 6 tools.

Bottom line : half the "automation" project turns into a data cleanup project nobody budgeted for.

2. lack of good process - approvals, gatekeeping, governance

In order to automate a workflow, you have to write down how it actually works, including who gets to say yes.. check if the org has that in place.

1. Approvals are habit, not policy - "run it by Dana if it's a big deal" works for people. The agent needs to know what big means, who Dana's backup is, and what happens when nobody answers.
2. Clear gates - what can the agent do on its own? what needs sign off? what's off limits? if we don't draw that line, it either sits in "suggest only" forever or moves too fast and we have an incident.
3. Who owns it? agent makes a bad call - is it the business owner, IT, the vendor? if no one owns the outcome, no one approves go-live.
4. Audit + exceptions - customer facing or regulated work needs a record of what the agent did and why, plus a path for edge cases. today that's mostly people remembering.
5. Governance shows up late - legal/security/compliance see it at launch, and the clock resets.

Automating a process that was never defined doesn't fix it.. it just makes the ambiguity run faster.

So, what do we do

Treat readiness as part of the project. steps are

Pick one narrow workflow - audit the data - write down the rules - draw the autonomy line - bring in legal/security on day 1 - run supervised - widen autonomy as error rates prove out.

Two questions to answer before we start..

1. which workflow first? needs a clear owner and a number we can measure.
2. what needs an approval? limits/thresholds??

The tech is one part.. the data and the decisions around it is where the real work is.

I kept this to data and process on purpose. Other things that bite, we can tackle these next..

1. Measuring quality - how do we know the agent is right? Need evals and a baseline before go-live, not after.
2. Cost - LLM spend adds up fast with lots of runs and retries. Need limits and a cost per task we can track.
3. Security - prompt injection, agents reading untrusted content, over-broad permissions.
4. Integrations - legacy systems, rate limits, APIs that don't expose what the agent needs.
5. Monitoring - when it fails at 2am, who finds out? Logging, alerts, rollback.
6. People - change management. Teams don't trust it, work around it, or worry about their jobs.
7. Model changes - vendor updates the model and behavior shifts. Need regression checks.
8. Privacy - what data goes to which vendor, data residency, customer consent.