71% of small businesses use AI. Almost none of it is allowed to do anything.

A couple of surveys doing the rounds this month put small business AI adoption at 71.4%, with 78.6% of those users reporting lower costs or better efficiency. Read that quickly and it looks like a solved problem.

The interesting part is what they are using it for. Almost all of it is advice.

Draft me an email. Summarise this call. What should I say to this client. Which of these two options is better. All useful, all genuinely faster than doing it cold, and all of it ends the same way: the AI finishes talking, and then you go and do the work.

That is the actual state of AI in most small businesses. You have hired an extremely capable advisor, given it no access to a single one of your systems, no memory of your business, and no ability to touch anything. Then you take its advice and do the job yourself, the same as before, slightly quicker.

Advice is not capacity

There is a hard ceiling on what advice can do for you.

If the AI drafts a client email in fifteen seconds and you spend the next ten minutes finding the right thread, checking what you promised last month, sending it, logging what happened, and updating the job, you have improved fifteen seconds of an eleven minute task. That is the shape of most AI use right now, and it is why the efficiency numbers feel smaller in practice than they look in a survey.

The work was never the writing. The work is everything around the writing.

So the question worth asking is not "am I using AI". It is: when the AI finishes its answer, who does the job? If the answer is you, every time, then you have bought advice. Advice is worth having. It is not capacity.

Two things are missing, and both are needed

To move from advice to action, you need two things, and neither of them is a better model. Everyone has access to roughly the same models now.

One system that knows everything. A single place holding the real state of the business: the clients, the jobs, the history, the hours, what has already been built and what was promised. Not five apps each holding a slice. Not a chat history. One system, with the boring stuff written down properly.

Agents that are allowed to act in it. An agent is not a mystical thing. It is AI that has been given access to your systems, permission to write to them, and rules about when it must stop and ask you. That is the whole definition. Access, permission, rules.

Either one alone gets you very little. An agent with no shared context is a stranger who has to be briefed from scratch every time, which is precisely what using a chat window feels like. A single source of truth with no agents is a database you still have to type into by hand.

Put them together and the AI stops being a consultant and starts being a colleague.

To be clear about the human part

None of this means stepping out of the loop. I am in the loop constantly, and deliberately so.

What changes is which loop. I am no longer in the loop for the copying, the looking up, the retyping, the remembering to log it. I am in the loop for the decisions, which is where I was actually useful.

Every agent I run stops and asks before it writes anything. That is a design rule, not a limitation I have not got round to fixing yet. An agent that writes silently gets one thing wrong and then gets switched off forever, and rightly so. An agent that proposes, shows its reasoning, and waits for a yes earns more trust every week and ends up being allowed to do more.

What this looks like in practice

Four real examples from my own business, since abstract descriptions of agents are worthless.

A client email becomes a logged, tracked job

Before: a client emails about a piece of work. I read it, work out which of their live jobs it refers to, open the system, find that job, paste in what they said, update the status, and then reply. One of those five steps involves thinking.

Now an agent reads the inbox, filters out the newsletters and the automated noise, and for each real email resolves the sender against the client records. It then pulls that client's open jobs, reads the email against them, and tells me which job it thinks this belongs to, why it thinks that, and how confident it is.

I say yes. That is my entire contribution.

On yes, it writes the update against the right job, in both plain text and HTML because the downstream email template needs one and the interface needs the other, sets the status to client responded, labels the email as processed so it never gets triaged twice, and the support channel picks it up automatically from there. I still write the actual reply myself, because that has judgement in it.

The AI is no cleverer than the one in your browser tab. It just has somewhere to look things up and somewhere to write them down.

A meeting becomes a scope of work

A client call happens. The transcript arrives. An agent reads it alongside the client's context file, which is the running record of who they are, what we have already built for them, what broke last time and what they keep asking for.

That context is the difference between a useful draft and a plausible one. Without it you get a scope that proposes something we delivered eight months ago. With it, the draft knows that already exists and scopes the extension instead.

It produces a draft scope of work and a technical specification, then claims the next project reference number in the central system before either document is saved.

That last step exists because of a mistake. A number was written into a document before it had been claimed centrally, someone else claimed it in the meantime, and that project now carries two different reference numbers in two different places, permanently, because reference numbers cannot be reclaimed once they are consumed. It is a small, stupid, entirely avoidable problem, and it is exactly the kind of thing that happens when two systems both think they are in charge. The fix was a rule the agent follows without being reminded: claim the number first, then write the document.

Hours meet budgets

I moved my time tracking off Toggl in July. Nothing was wrong with Toggl. It tracked time accurately for years. It simply had no idea what a client, a project or a budget was.

Toggl knew the hours. My project system knew the budget. The only place those two facts ever met was my head.

Now the hours live in the same system as the clients, the jobs and the project scopes, and an agent creates the entries from a plain text file I jot lines into during the day, after showing me the full list to confirm. Burn against each project calculates itself. A support hours block dropping below two hours flags itself for renewal instead of quietly running dry and turning into an awkward email.

The technically interesting part is what joining them up revealed. Every entry has to link to exactly one of the client's hours block or the project scope, never both, because approved hours for a scoped project are already deducted from that client's block by a rollup:

Hours Remaining =
    Hours Purchased
  - Hours Used            (frozen opening balance, no history imported)
  - Scoped Approved Hrs   (rollup from linked project scopes)
  - Hours Logged          (rollup from time entries)

An entry linked to both would bill the same hour against a client twice, in two places, both looking perfectly reasonable.

That bug could not exist while the tools were separate, because separate tools never meet. It appeared the moment they did. This is worth sitting with: joining your systems up does not create these problems, it reveals the ones your disconnection was hiding from you. Being unable to see a contradiction is not the same as not having one.

The business answers its own questions

The client facing version of the same idea. Instead of a team where four people hold different bits of how things are done in their heads, the knowledge lives in one place, written down, and an agent with read access to the live data answers from it.

Someone asks what the process is for a particular kind of job, or what was agreed with a particular customer, and they get an answer from the company's own facts rather than from a colleague's memory or the general internet. Onboarding gets shorter. The same question stops being asked six times.

This one is less about speed and more about a business that stops depending on who happens to be available that day.

What you can take from this

If you want to find the gap in your own setup, three questions get you most of the way.

When my AI finishes answering, who does the job? If it is always you, you have an advisor. Everything past that point is capacity you have not claimed yet.

Where do I type the same information twice? Every duplicate entry is a join that should be automatic, and it names the two systems that ought to be talking.

What do I currently only know in my head? Hours against budget, in my case. That is not a knowledge problem, it is an architecture problem, and no amount of clever prompting fixes it.

Then start with the boring half. Get one system holding the truth before you go anywhere near agents. An agent pointed at scattered, half-recorded, contradictory data will produce scattered, half-recorded, contradictory work, faster than you could have produced it yourself. The tidying is unglamorous and it is most of the value.

After that, pick one job you do by hand every week and let something act on it, with a confirmation step in front. Not the whole business. One job.

That is the thing we are building at AI-First, and it is a genuinely different proposition to buying five tools. Adoption was the easy half and 71% of us have done it. The half that pays is joining it up and then letting it do something.