AI & Automation
Can an AI Agent Actually Run a Business Workflow?
Not a demo. A real, multi-step workflow with side effects — and what breaks when you let an agent own it.
A chatbot answering questions is not a workflow. A workflow has state, side effects, and a cost to getting it wrong. So I gave an agent one: triage an inbound lead, enrich it, decide if it's qualified, and either book a call or send a polite decline.
The parts of a real workflow
Every business workflow is the same three things wearing different clothes:
How it works
- TRIGGER (new lead)
- GATHER CONTEXT
- DECIDE
- TAKE ACTION
- RECORD OUTCOME
The interesting failures all live in decide and take action — the steps with consequences.
Giving it hands with MCP
The agent reaches real systems through tools. I exposed a CRM, an enrichment API, and a calendar over MCP, so the model calls typed functions instead of hallucinating REST calls.
Guardrails are not optional
The moment an agent can take actions with side effects, you need idempotency keys, spend limits, and a dry-run mode. An agent that can send email can send 1,000 emails.
What broke
- It double-booked once because the "create event" call wasn't idempotent.
- It over-qualified leads to be "helpful" until I gave it a scoring rubric.
- It handled the happy path perfectly and the ambiguous 15% poorly.
The honest verdict
Key takeaway
An agent can run the deterministic 85% of a workflow reliably today. The last 15% — ambiguity, judgment, edge cases — still needs a human, and the smart design is to route to one, not pretend the agent has it handled.
That "route to a human on low confidence" pattern turned out to be the whole trick. The agent isn't replacing the workflow owner — it's clearing their queue.