An assistant that answers questions is useful. An assistant that can do the thing the question was leading to, whether that's booking an appointment, moving it, or cancelling it, is a different kind of build, and a much harder one.
The moment an AI system can change something in a business's real records, it stops being a clever front end and becomes an actor in the actual operation. That is the line I care about most in this work, because everything about how you build changes once you cross it. Here is what that looks like in practice, drawn from connecting an assistant to a multi-location medical group's booking and records systems.
Reading is low-stakes. Writing is not.
Retrieval is forgiving. Answering "what does this cost, when are you open, is this available" has slack in it: if the answer is slightly off, the customer asks again or a person corrects it. Writing is different. Creating or changing a booking touches the system the business runs on. A mistake there isn't an awkward sentence. It's a double-booking, a lost slot, someone arriving for an appointment that was already cancelled.
So I treat the two halves as different systems with different bars. The assistant answers freely from grounded data. It can only act through a narrow, deliberate set of operations, each one built to be safe on its own.
The system of record stays the source of truth
The strong temptation in these builds is to let the AI keep its own copy of the world, a cached list of appointments it reasons over. That copy drifts the instant anything changes outside the assistant, and in a real business, things change outside the assistant constantly. Staff edit bookings, customers call in, other channels write to the same records.
So the assistant holds no parallel truth. When it needs to act, it reads current state from the system that actually owns that state, acts against that system, and reads back the result. The existing booking platform stays in charge, and the assistant is a disciplined client of it rather than a replacement for it.
Know who owns each record
This is the subtle one, and it's where naive integrations break. In a real operation, the same kind of record can be created through more than one door: a form, a back-office tool, a partner system, or the assistant itself. Each of those can be the true owner of what it created.
If the assistant treats every record as its own to change, it will eventually act on one whose source of truth lives somewhere else, and quietly put two systems out of sync. So part of the build is teaching the assistant to recognise where a record came from and to route each action to the system that owns it. It handles the cases it can safely handle and defers the rest to the channel that should. Getting that boundary right is most of the reliability.
Match the assistant's authority to what's safe
Not every action carries the same risk. Changing an existing, already-verified booking is low-exposure, because the person was identified when the booking was made. Creating a brand-new record that depends on verified identity is a different matter, and it often belongs on a controlled step rather than a free-text conversation.
So I scope the assistant's authority deliberately. It owns the actions that are safe to take on established, already-verified records, and it defers the ones that need a stronger check. That isn't a limitation to apologise for. It's the design. An assistant that knows what it shouldn't do is more trustworthy than one that tries everything.
Confirm, then act once
Language models are probabilistic. Booking systems have to be exact. Between the two I put hard confirmation and safe retries. The assistant restates what it is about to do in plain terms and acts only on a clear yes. Every write is built so that a dropped connection or a repeated request can't create two of anything. Confirm before acting, make the action safe to retry, verify the result afterward. Boring, and exactly the point.
Log every action
Every write leaves a record: what was requested, what was done, against which system, and what came back. When an AI system can change real-world records, that trail is what makes it reviewable rather than a black box. The business can see everything done in its name and catch drift before it becomes a problem. (More on auditing production agents properly.)
The first conversation is the easy part to get right. The assistant answers, and it looks impressive. Whether it belongs in production comes down to the layer underneath: acting on live systems, every time, without putting them out of sync.
That layer is most of what I do. If your team has a client asking for an assistant that books, reschedules, and cancels real things, and it all has to hold up, that's the work I take on.