Agents do not fix bad processes. They expose them.
Agents are the thing in every keynote right now, for a real reason: they work better than the previous generation of AI deployments did, and the numbers are starting to show it. Google Cloud's most recent enterprise study found that 52% of executives report their organizations are actively using AI agents, and agentic early adopters are reporting higher ROI than the average AI deployment. At the same time, Deloitte finds that nearly three in four companies expect to be using agentic AI at scale within two years — but only one in five has mature governance for autonomous AI agents today.
The gap between deployment and governance is where the next set of AI failures will happen — and they will not look like the chatbot failures of the last cycle. They will be more expensive.
The difference between a workflow and an agent
A chatbot answers a question. A workflow is a sequence of steps a team executes, sometimes with software and sometimes with a person. An agent is a workflow that runs without a person in the loop for the routine cases.
The category jump matters. A chatbot that gets a question wrong wastes someone's time. An agent that gets a workflow wrong sends an email, files a ticket, refunds a customer, updates a record, or closes a contract before anyone notices. The blast radius is different. So is the governance requirement.
Agents need clearer boundaries than chatbots
The same vagueness that made chatbots tolerable makes agents dangerous.
A chatbot's failure mode is usually a wrong or unhelpful answer. The cost is annoyance. An agent's failure mode is an action — and actions have downstream effects. If the action is "send a draft for a human to approve," the cost is contained. If the action is "execute the workflow end to end," the cost depends entirely on what the workflow does.
The companies deploying agents safely are the ones who have answered, explicitly and in writing, four questions for each agent before it goes live.
- What can the agent do? What set of actions is in scope? What systems can it touch? What customer-facing actions can it take?
- What can it not do? What is explicitly off-limits, even if the model thinks it should? Refunds above a limit. Contract changes. External communications. Anything irreversible.
- Who approves risky actions? What is the human-in-the-loop path for the actions that fall between routine and forbidden? Who gets paged, on what signal?
- How is quality evaluated? On what real cases is the agent's performance measured? How often? By whom? What happens when it drifts?
If those four questions do not have written answers, the agent is not ready to go to production. It is a demo.
Agents into messy processes accelerate the mess
The seductive promise of agents is that they will fix a slow or broken process by running it autonomously. That promise is usually wrong. If a process is unclear today, an agent makes the lack of clarity scale: the inconsistencies humans were quietly papering over now happen faster, in more places, with less visibility.
The processes worth agentifying first are not the messy ones. They are the boring, well-defined, repetitive ones — the ones where the workflow is documented and the failure modes are known. Agents are good at running these reliably. They are not good at finishing the design work the workflow never had.
If you cannot describe the current process in writing — who does it, what triggers each step, what makes it succeed or fail — you cannot agentify it. You can deploy something that looks like an agent. It will create work, not eliminate it.
A practical agent-readiness checklist
Before deploying any agent, we walk through five things with the team that owns the workflow.
- The workflow is documented end to end, including failure paths.
- The agent's scope is defined in writing — what it can and cannot do.
- There is a human approval path for the cases that are not routine.
- There is an evaluation loop running on real production cases.
- There is a rollback plan, and someone on call when the agent misbehaves.
If those five things are not in place, the conversation is not "what model should we use." It is "we should not deploy an agent here yet."
Do not start with autonomy. Start with the workflow, then decide how much autonomy it can safely absorb.