Building an AI agent people will let near their business
Every CRM sold to a small business asks the same thing: type it all in. Enter the customer, enter the job, update the stage, log the call. Do that faithfully and the software becomes useful.
Nobody does it faithfully. The shop is already at capacity. The thing that is scarce is attention, and a CRM asks for more of it. So the system rots, and the business goes back to what actually works, which is a whiteboard and one person who remembers everything.
I spent a year building software for a sign manufacturer, and that was the wall I kept hitting. Not "can the software do this". It could. The question was whether anyone would change how they work in order to let it.
Do the work, leave the record
The way out was to stop asking people to keep records and have the system do the work instead, leaving the record behind as a by-product.
So it reads the accounting system and the file store the business already had. An enquiry arrives, it gets picked up. A quote needs chasing, it gets chased. A job needs booking, it goes in the calendar. The record exists because the work happened, not because somebody typed it up afterwards.
That solves adoption. It creates a much harder problem.
The hard problem is not capability
Nobody hands their livelihood to something they cannot predict. If the software can email a customer, then one bad email is not a bug report, it is a lost account and a very awkward phone call. The owner has to believe it will not do something stupid while they are on a roof somewhere with no signal.
Capability was never the constraint. Trust was. Almost everything interesting in the design is there to make an autonomous system legible to the person carrying the risk.
One path, so there is always a record
Every workflow follows the same five steps. Queue the thing that needs doing. Retrieve what is known about it. Verify that what was retrieved is actually true. Route it, either to an action or to a person. Then resolve it, or escalate it to a human.
The point is not the steps. The point is that because there is only one path, every automated decision leaves the same shaped trace, and you can go back afterwards and see what it knew and why it did what it did. A system that makes decisions you cannot reconstruct is one you will eventually switch off, and you will be right to.
Two kinds of write, and the difference matters
Anything done to the business or to a customer is proposed rather than executed. Creating a job, moving a stage, booking a fitting, sending a quote, chasing somebody. Each one goes through a ledger where it is logged, attributed, and undoable.
The owner's own controls are different. Pausing the system, approving a queued decision, changing the settings. Those deliberately do not go through the ledger.
That distinction took me a while to see, and it comes down to three things. There is no honest way to record "the owner changed their mind" as an action taken against a customer. Approving a queued decision is the human judgement the ledger was waiting for, so queueing it for approval is a loop that never terminates. And most importantly, Pause is the kill switch. Routing the kill switch through the machinery it switches off is a circular dependency with an obvious failure mode. Stop everything has to work when everything else is broken.
A dial, not a switch
Autonomy is not one setting. Per capability, the owner chooses whether the system does it and tells them, or asks first and waits.
New capabilities start on ask. As the owner watches a few go through and finds nothing surprising, they move it to do. Trust gets earned in the direction it is actually given in real life, one thing at a time, and it can be taken back the same way.
Rails the system cannot argue with
Separately from the dial there are constraints it simply cannot cross. Customers who must never be contacted. A quote value above which a person always decides. Quiet hours. Tone.
These are not prompts. A prompt is a request. A rail is enforced outside the model, because the whole point is that it holds on the day the model would otherwise do something reasonable-looking and wrong.
Everything ships switched off
Every capability that touches a customer or touches money ships to production disabled, behind a flag that fails closed. Absent means off. Malformed means off. Only an exact, deliberate value means on, and turning one on is the owner's decision, never mine.
That sounds overcautious until the first time you deploy on a Friday.
What the numbers say about the design
The system has sixty-one tools. Forty-two of them only read. Eleven write through the ledger where they can be undone. Eight are the owner's own controls.
That split is the whole argument in one line. Most of what an agent should be able to do is look. The things that change the world are few, deliberate, logged and reversible. And the switches that stop it belong to the person whose business it is.
The product decision I got wrong first
I built it agent-first. The home screen told you what the AI had done. It was the most interesting thing about the product and I wanted it visible.
It was the wrong call. A sign shop does not think in terms of what the assistant did today. It thinks about the week. What is going out, what is late, who is fitting what on Thursday.
So the calendar became the product and the agent went quiet underneath it. The work it does shows up as jobs moving, quotes going out, dates filling in. It stopped narrating and started working. That change did more for adoption than any capability I added.
What I would tell you
If you are deploying AI into a business that does not have engineers, the interesting problems are not model problems. They are: what happens when it is wrong, who finds out, how fast can it be stopped, and can the person carrying the risk see enough to keep trusting it.
Get those right and the capability takes care of itself. Get them wrong and it does not matter how good the model is, because it will be switched off inside a fortnight.