Most of the value of AI agents in a business is not in the impressive demo. It's in the inbox nobody wants to triage, the booking request that arrives at midnight, the support ticket that's the same question for the fortieth time. These are manual workflows with clear rules, high volume and low tolerance for mistakes. That combination is exactly where agents should go first, and exactly where they're most often introduced badly.
Here's what I've come to believe after building a few of these for small businesses.
Classify before you generate
The safest first agent is one that reads and decides, not one that writes. An email classifier that routes messages to the right person, tags urgency, and extracts the two fields the team needs is boring and transformative. It fails safe: a wrong label is a minor annoyance. A wrong reply sent to a customer is a fire.
Start with classification, extraction and routing. Add generation only once the classifier has earned trust, and even then draft first, send later.
Thresholds and a human fallback
Every decision the agent makes comes with a confidence. Below a threshold, the item goes to a person with the agent's best guess attached. Above it, the agent acts. The threshold starts high and comes down as the logs show it can.
This does two things. It keeps error rates where the business can live with them. And it turns the human queue into a training set: every override is a labelled example of where the agent was wrong.
Bookings: the agent is a form filler with judgement
A booking request in an email or a chat is unstructured. The booking system wants structured input: date, time, party size, service, contact. The agent's job is to fill that form from the message, ask for what's missing, and check availability through the real booking API. It should never invent a slot.
The pattern is a state machine with an agent inside it. The states are: collect details, confirm availability, hold the slot, confirm with the customer, book. The agent moves between states by calling tools. It does not get to skip states. When the customer says something the agent can't parse, the conversation goes to a person with the partially filled form attached.
Customer support: answer from sources, or don't answer
A support agent that answers from its own knowledge will confidently tell customers about refund policies you don't have. The rule I use is simple: every answer must quote a passage from the company's own documents, and the passage is shown alongside the answer. If retrieval finds nothing relevant, the agent says so and hands off. No source, no answer.
This makes the agent only as good as the documentation, which sounds like a limitation and is actually the point. It turns "improve the bot" into "improve the docs", which is work the team can do without an engineer.
Log everything, show it to the team
Each action the agent takes is logged with the input, the decision, the confidence and the sources. The team can see it in the same tool they already use. This is not for debugging, though it helps with that. It's for trust. People accept an automated colleague much faster when they can see its reasoning and correct it.
Where it goes wrong
- Automating the messy process as-is. If the manual workflow has three exceptions for every rule, the agent inherits them. Fix the process first, then automate the fixed process.
- Measuring the wrong thing. "Tickets handled by the bot" goes up when the bot handles tickets badly. Measure resolution without human touch, and customer follow-ups after an agent reply.
- No off switch. Every agent needs a kill switch a non-engineer can press, and a routing rule that sends everything to humans when it's pressed.
- Skipping the boring integration. The agent is fifteen percent of the work. Reading from the inbox, writing to the CRM, calling the booking API, handling auth and retries is the rest.
A sequence that works
- Pick one workflow with volume and clear rules.
- Ship a classifier with a human fallback and a high threshold.
- Watch the overrides for two weeks. Lower the threshold where the logs justify it.
- Add extraction and routing. Then drafts. Then, if the numbers say so, sends.
- Keep the kill switch and the logs forever.
The agent that saves a small team ten hours a week rarely looks impressive. It looks like an inbox that sorts itself and a calendar that fills in correctly. That's the goal.