What an AI agent can automate in a business (and what it shouldn't)

Your team answers the same request five times a day. Support answers it, sales answers it again, ops retypes the same thing into a spreadsheet. Nobody's doing bad work — the work is just repeated.

This is the pattern I use when a business wants to automate, but doesn't want to hand the company over to a machine. One agent, one workflow, a human at the end of it.

The cost is repetition, not effort

When I look at where a team loses time, it is rarely a hard problem. It is the same request answered by three different people, in three different formats, with the same information typed out each time. That is the part worth automating first, because the input is predictable and the output is easy to check.

One agent, pointed at the inbox

The first build is deliberately small. One agent sits on the inbox. It reads the request. It pulls the account from the CRM. Then it drafts a reply in your tone — not a template — and it stops and waits.

That last step matters more than the drafting. The agent is not allowed to send. A person reads the draft, approves it, and only then does it go out. The drafting is the automation; the decision stays with the team.

The same pattern covers the boring rest

Once the inbox agent runs reliably, the identical shape — read, look up, draft, wait — applies to the repetitive work around it:

• Triage. Urgent requests jump the queue instead of sitting behind whatever arrived first.
• Follow-ups. Nothing sits for a week because someone forgot to circle back.
• CRM notes. The record gets updated in the same pass, so the account history is right the first time.
• Status reports. Written before the meeting, from the same source data, not from memory.

None of these are clever. They are the tasks that annoy the most people, done in the same loop with the same approval step.

What it doesn't do

This is the part I make explicit before anything ships. The agent does not set pricing. It does not promise dates. It does not argue with a customer. Anything that commits the business still goes through a person — every time, not as a fallback when confidence is low.

That boundary is what makes the automation usable. You are not asking anyone to trust a draft; you are asking them to review one.

When it's wrong: show the source, log the action

It will get things wrong. Pretending otherwise is how these projects die in week three.

So every draft shows where it got the answer — which record, which field, which thread. Every action gets logged. And when it is wrong, you fix it once, and it stops repeating that mistake. A correction is an edit to the system, not a one-off patch in a chat window.

Start with one workflow, not the whole business

We don't start with your whole business. We pick one workflow — the one that annoys the most people — and we build for that. Two weeks later, it runs. You read the drafts, reject what's wrong, and it learns from your edits.

That's the whole method: one agent, one inbox, a draft that cites itself, and a person who approves anything that commits the business.

If answering the same question twice a day sounds familiar, you can book a call and we'll pick the first workflow together.

Quick recap

• The cost is repetition: the same request answered five times a day.
• Start with one agent on the inbox: read the request, pull the CRM account, draft in your tone, stop and wait.
• The same loop covers triage, follow-ups, CRM notes and status reports.
• It doesn't set pricing, promise dates or argue with customers — commitments go through a person.
• Every draft shows its source, every action is logged, and a fix is made once.
• Pick the workflow that annoys the most people; two weeks later it runs, with you reading the drafts.