From a chat that writes for you to an assistant that does the work

For the last few years, using AI at work has meant a chat window. You paste in a GP letter and get a summary. You ask it to word a difficult email, or to turn your notes into a letter. It is good at this, and most small firms I meet use it this way every day. It also leaves the job exactly where it was: the summary still has to go in the file and the email still has to be sent, by you.

Something different has started to happen, in large organisations first. The same text box is being connected to the calendar, the mailbox, the documents and the accounts, and given permission to act. You no longer ask it to write something you will then go and do yourself. You tell it what you need, it does the work, and you confirm. The chat window knows things; the assistant can do them. That is the shift, and the rest of this piece is about what it changes in a small firm.

Adviser, then operator

The first few years were the adviser years. The AI was a very well read colleague in a side window. You brought it text and it gave you better text back. Nothing it produced went anywhere on its own, and in a strange way that was the comfort of it. It could be brilliant and it could be wrong, and either way nothing happened until you copied the result somewhere.

The operator is different in kind. It has the same ability to read and write, and on top of that it has hands: it can look up a client, create a record, put an appointment in the diary, send an email, raise an invoice. You describe the outcome and it works out the steps. “Book her in for Thursday and let her know” is one sentence to you and four actions to it. The judgement about whether to do it stays with you; the doing moves to the assistant. Any firm whose day is a run of small, repeated tasks across the same few tools is a candidate, and that describes most small firms.

A Monday, twice

Here is a morning in a small assessment practice, the sort we build for. A referral has come in as a PDF. Two clients still have not returned a questionnaire. One session has to move to Thursday. It is the 28th and nobody has started the month’s invoices.

With the chat window, each of those gets a helpful answer. What the PDF says. A decent chasing email. A reminder of what to check before you move a session. Then you type it all in, across four tools and four windows, and the morning is gone.

With the assistant connected to those tools, the same requests simply happen. “Register this referral” creates the case and the client folder from the document, and lists what the form left out. “Who needs following up?” comes back from the live record rather than from whoever remembers. “Move Tuesday’s session to Thursday at 2pm” shifts the event, refreshes the meeting link and puts the email to the client in front of you. “Invoice every client for September” reads each case’s unbilled items and drafts the invoices in the accounts package. In the practice we run, that last one takes about five minutes. It used to take most of a day, though I should say we never timed the old way properly, so treat that as memory rather than measurement.

Why it stayed a chat window for so long

The chat tools were never the problem. They read and write well, and they got better every few months. What they could not do was reach. A small firm already pays for the pieces: a calendar, email, somewhere documents live, an accounts package, and usually a spreadsheet that has quietly become the system of record because it was there first. The AI sat in a browser tab next to all of that and could touch none of it.

So a person did the joining up by hand. One plain request implies four or five actions in four or five places, and the person is the only thing that moves between them. The assistant takes that joining-up over. It sits in the middle with access to each tool and turns “book her for Thursday” into the calendar event, the email, the note on the case and the billing row, together, because they belong together.

It works more like glue than like a new app: the tools stay where they are, and the typing between them goes away.

Why I was nervous about letting it act, and what settled it

An assistant that can send email and raise invoices is a different animal from one that just talks, and for a while I did not want to build one. A wrong summary wastes a minute. A wrong email to the wrong person is a complaint, or worse. What makes it safe is the set of rules around it, and most of them turned out to be rules a good practice manager already follows by hand.

Reading costs nothing; writing is confirmed. A summary or the overdue list is answered straight away. Anything that changes a record, sends a message, moves an appointment or raises an invoice shows up first as a preview: the actual email, the actual invoice, or the before and after of a record change. A person confirms it or bins it, and one confirmation sends it.

It is all on the record. Each confirmed action is logged with who confirmed it and when, which is the standard referrers and auditors already expect. It can only write where the case allows: emails go to the addresses that belong to that case. If the record changes under a preview before you press confirm, the preview refuses rather than guessing. Deleting anything for good needs an administrator and a typed confirmation, which is deliberately annoying.

And the data does not move. It stays in the systems the firm already runs and administers. The text the assistant drafts passes through the model provider under commercial terms that rule out training on it, with a processing agreement signed before anything goes live. It is the discipline of a careful practice manager, written down so that it still holds on a busy Thursday.

Two brief examples: one person, then one practice

The smallest version of this is mine. For some months I have run my own admin through an assistant I call Hermes. It lives on a small server, so it does not stop when I shut the laptop, and I talk to it from my phone, typed or spoken. It has my calendars, my mailboxes and my documents. Once a day it goes through the inboxes and tells me what actually needs an answer; it drafts replies and sends them when I say so. One rule I added early and have not regretted: a job that runs on a timer is never allowed to send anything.

Cassie is the same idea with more people in it and more at stake. It runs a vocational rehabilitation practice today. The team does most of the day through conversation: register this referral, who needs chasing, move the session, write the invitation letter with live dates, invoice everyone for September. There are around seventy actions available, roughly two-thirds of them read-only, and every one that changes something shows a card first. The spreadsheet that used to be the system of record is gone. The thirteen email templates someone used to pick and fill in by hand now go out at the right stage of the case, previewed first. Month-end invoicing for the whole practice is the five minutes I mentioned. The practice belongs to my co-founder, which is why every feature was argued over by the person who has to use it, sometimes at length.

The part of Cassie I would point to first is how it does things the same way every time. The model does not improvise an email or an invoice from scratch. For each thing the practice does, we prepared a tool: a fixed procedure that takes a few named inputs, checks them, and performs exactly one action in exactly one way. “Invoice this client for September” means the model picks the invoicing tool and fills in the client and the month; the tool then reads the unbilled items, applies the agreed rates and drafts the invoice the way it always does. The model’s job is to understand what was asked and choose the right tool with the right inputs. The tool’s job is to be boring and do the same thing every time. Keeping the clever part away from the part that must not vary is what lets us trust the assistant with real work.

The next step for Cassie is voice, and it is close. You will say it out loud, on the way between appointments, and the practice will understand and do it. That is the version of this I find hardest to argue with: you talk to your firm, and your firm gets on with it.

Those are the figures we have. We do not publish hours saved, because we have not measured them, and I am wary of numbers that arrive before the measuring does.

Why this is now a small-firm thing

Big organisations are building their operating systems on top engineering teams: assistants wired into their own systems, and people whose whole job is to look after them. A small firm, meanwhile, is still looking for the statement that was definitely in the inbox last week. The parts that make the rest possible have become ordinary in the last year or two: models that can read a scanned form, calendars and mailboxes with proper interfaces, accounts packages that will accept a draft invoice from outside. What was left was the joining-up, built around the way one practice actually works rather than the way a product manager imagines a thousand of them work.

There is a plain money reason too. A small firm cannot afford a human assistant, so the owner has always been the assistant as well, in the evenings. The AI one costs £100 to £200 a month in API usage, in our experience, and that is the whole bill for an assistant that handles the bookings, the letters and the invoices. The large firm could already pay for the person. The small firm could not, which is why I think this fits the small firm better than anyone it was first built for.

That is the part we do. It starts with a two-hour audit: where an assistant could take the work on in your firm, where a person has to stay in the loop, what your current tools already do, and what order to do it in. The report is yours whatever you decide, and “change nothing” is a real answer we give. If we build, each phase has a price and an outcome before you commit, and your records stay where they are.

If your week is mostly the emails, the bookings, the forms and the invoices, you have already seen what the chat window can do for it. The next step is a twenty-minute call, and it has two questions in it: what are you using, and what do you pay for it a month?

Pawel Dobrzynski is mgctech’s CTO. He built Cassie and runs the audits himself.