The short answer: treat an AI assistant that books for a patient as a scheduling clerk with no authority of its own. Let it request routine, administrative bookings through a channel you control, ask it for the minimum information needed to find the patient and a slot, and never treat the booking as final until the patient confirms on a channel you have already verified, such as the phone number or portal account on file. Anything that looks clinical, urgent or outside a routine booking goes to a person. Log every step, including who the agent said it was acting for.

That is the operational pattern this guide walks through, whether the assistant is ChatGPT, Claude, Gemini or one of the newer personal agents. Lorikeet publishes this guide and sells an AI concierge for telehealth and healthtech support, including B2A, which lets a patient's AI agent reach the same concierge your patients use, under the same guardrails, identity verification and action policies. We have tried to keep the playbook useful whichever tools you run. One caveat up front: this is about operations, not legal or clinical advice. Where HIPAA comes up, we quote how HHS describes the rules and you should confirm your own policy with counsel.

Key takeaways

• An AI assistant acting for a patient is a channel, not a new kind of patient. It gets no more authority than the patient already has.

• Separate two questions: who is the agent, and who is the patient it says it acts for. Verify the patient, not the agent's say-so.

• Ask for the minimum needed to find the record and a slot. Do not volunteer chart details to the agent.

• Routine bookings, reschedules and cancellations can be automated. New-patient intake with clinical questions, urgent symptoms and anything needing triage go to people.

• Hold the slot as pending until the patient confirms on a verified channel, then mark it booked.

• Keep an audit trail that records the agent, the patient, what was asked, what was shared and what was booked.

Why this is a front desk problem now

Consumer AI assistants have moved from answering questions to doing errands. Patients ask them to find a GP appointment, move a telehealth consult or book a follow-up, and the assistant then tries your website, your phone line, your chat widget or your booking page. Some arrive through a browser and look like a person. Some call. Some hit whatever public endpoint they can find.

The conventional advice is to block them and tell patients to book themselves. That holds for about a week. The patient who asked their assistant to book does not experience a blocked bot. They experience your practice as hard to deal with, and the assistant keeps trying through the phone line, where it is harder to spot. Our view, set out in what B2A means for support teams, is that the safer path is to give agents a front door you control, with rules you wrote, rather than leaving them to find the side doors.

Scheduling is also the natural place to start because it is administrative. HL7's FHIR Appointment resource, the standard many health IT systems use for bookings, notes that appointments "can be considered as Administrative only", while the encounter that follows is expected to carry the clinical implications. That gives you a clean line: the agent can help with the booking, and the care stays with your clinicians.

Identity and authority: who is the agent acting for?

Every agent request contains two claims. The first is about the agent itself: which product it is, who runs it, whether it is the same agent that contacted you yesterday. The second is about the patient: this is Jane Citizen, date of birth such and such, and she wants a Tuesday appointment. Most failed designs collapse these into one. They see a polite, well-formatted request and treat it as the patient.

Keep them apart. Identifying the agent tells you how to handle the traffic: rate limits, labelling, logging. It tells you nothing about whether the patient asked for this. The web standards world has a vocabulary for exactly this split. OAuth's token exchange specification, RFC 8693, defines an "act" (actor) claim that expresses "that delegation has occurred" and identifies the acting party, separately from the subject the token is about. You may never issue tokens to patient agents, but the model is the right one: the patient is the subject, the agent is the actor, and authority flows from the patient.

HIPAA has its own version of the second question. HHS explains that the Privacy Rule requires a covered entity to treat a "personal representative" the same as the individual, where a personal representative is someone with legal authority to make health care decisions for the individual, and that the scope of access follows the scope of that authority (HHS guidance on personal representatives). HHS also notes that a power of attorney that does not cover health care decisions does not authorise the holder to exercise the individual's rights (HHS FAQ 224). An AI assistant is software, not a person with legal authority, so do not assume it fits that category. Separately, the Privacy Rule's verification requirements at 45 CFR 164.514(h) require a covered entity to verify the identity of a person requesting protected health information, and their authority to have access, if that identity or authority is not known. How those rules apply to an agent booking on a patient's behalf is a question for your counsel. Operationally, the safe default is simple: verify the patient through a channel you trust, and treat the agent as a messenger.

Minimum necessary: what to ask for and what to share

HHS describes the minimum necessary standard as requiring covered entities to make reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose (HHS minimum necessary FAQs). HHS also notes the standard does not apply to some disclosures, including disclosures to the individual. Again, confirm with counsel how that applies when an agent sits between you and the patient. The operating habits below are sensible either way.

On the way in, ask only for what you need to find the record and the slot: name, date of birth or another matching detail, the appointment type and preferred times. Do not ask the agent for the reason for visit in clinical detail. If a booking type requires a clinical question, that booking is not one the agent should complete.

On the way out, share only what the booking needs: available times, the location or video link arrangement, preparation that applies to everyone booking that appointment type, and the confirmation step. Do not read back what is already on the chart, do not confirm whether a named person is a patient before they are verified, and do not include clinician notes, results or medication details in anything the agent receives.

What an AI assistant can book, and what needs a human

Write the list down before an agent ever reaches you. The table below is a starting point. Your practice types, payer rules and state law will change the details.

The urgent row matters most. An AI assistant may relay "she has chest pain, can you fit her in this week?" as if it were a scheduling preference. Your system must treat the words, not the format. No AI in the booking path should triage. It should recognise that the request has left administrative territory, stop, and hand to a person using the escalation path your clinical team has approved.

Confirmation on a verified channel

This is the control that does most of the work. The agent can propose a booking. Only the patient can confirm it, and only through a channel you already trust: an SMS to the number on file, a message in your patient portal, or an email to the verified address. Never confirm through the agent's own channel, because that only proves the agent agrees with itself.

FHIR already models this. The Appointment resource's status values include proposed, pending and booked. Use them literally: an agent request creates a pending hold, the patient's confirmation moves it to booked, and an unconfirmed hold expires and releases the slot. That one rule handles a wrong patient match, a mistaken request and a misbehaving agent, because none of them can finish the booking without the real patient.

It also handles volume. Personal agents can be persistent. Expiring holds stop a single agent from tying up a clinic's diary, and rate limits per agent keep a polling assistant from flooding your queue. For more on the identity side, see our guide to verifying identity when an AI agent contacts support.

The audit trail

When something goes wrong, someone will ask who booked this, on whose instruction, and what was shared. Your log should answer that without a forensic project. Record, for every agent interaction: the agent identifier and channel, the patient it claimed to act for, how the patient was matched and verified, every field requested and every field returned, the proposed slot, the confirmation event and channel, and any escalation with its reason. Keep agent traffic labelled so you can report on it separately from human patients. That label is also how you will find out which assistants your patients actually use.

Platforms and approaches worth considering

There is no single product category for this yet. These are the realistic options, and many practices will combine two of them.

1. Lorikeet: an AI concierge that serves patient agents

Lorikeet is an AI customer support platform for regulated businesses, including telehealth and healthtech. With Lorikeet B2A, a business deploys a concierge adapted to personal agent traffic. Agents that support WebMCP, a proposed web standard, call tools on your website, and every other agent calls a public endpoint. The agent talks to the same concierge that serves your patients across chat, email and voice, with the same knowledge, workflows and actions behind it. Agents get no more authority than the patient has: the same guardrails, identity verification and action policies apply, and they see only what a patient would see. Custom guardrails can escalate on defined triggers, and when one fires you can see the blocked response, the explanation and the affected tickets. In telehealth, Lorikeet is configured to resolve administrative tickets and stop at the clinical line, handing clinical questions to a licensed provider with the conversation attached.

2. A standards-based scheduling API

If your EHR or practice management system exposes scheduling through FHIR, you can build an agent-facing booking flow on the Appointment resource and its proposed, pending and booked statuses. This gives you precise control and a clean data model. The cost is that you build and maintain the agent-facing layer yourself: matching, confirmation messaging, rate limits, escalation and logging.

3. Hand the patient a booking link

The lightest approach. When an agent asks to book, reply with your public availability and send the patient a self-scheduling link on their verified channel. The agent never books anything; the patient taps the link and finishes. It is safe and cheap, and it leaves the patient doing the last step, which some will see as the friction they hired the assistant to avoid.

4. Route agents to your scheduling team

Treat agent requests as a queue for people, who call or message the patient on the number on file. This is the most conservative option and the slowest. It suits low volumes, complex specialties, or the period while you decide what to automate.

Checklist: before you let agents book

1. Decide the channel agents should use, and publish it where agents look, so they stop guessing at your phone line.

2. Label agent traffic on every channel and set rate limits per agent.

3. Write the bookable list: appointment types an agent may request, and the ones it may not.

4. Define the minimum matching fields, and the fields the agent will never receive.

5. Make every agent booking pending until the patient confirms on a verified channel; set a hold expiry.

6. Write urgent-language triggers with your clinical team, and the exact escalation path and wording.

7. Agree with counsel how personal representative, verification and minimum necessary rules apply to your agent channel.

8. Log agent, patient, verification method, fields requested and returned, slot, confirmation and escalations.

9. Test with scripted agent requests, including a wrong-patient match and a request that mentions symptoms, before going live.

10. Review agent traffic monthly: volume, confirmation rate, expired holds and escalations.

If you are also thinking about what happens after hours, our guide to after-hours patient messaging covers the same verified-channel pattern for SMS, and personal AI agents and HIPAA covers the wider set of decisions for healthcare support teams.

Getting started

Start with one appointment type, such as routine follow-ups for existing patients, and one rule: nothing an agent requests is booked until the patient confirms it on a verified channel. Run that for a month, read the logs, and widen the list only when the confirmation and escalation data say it is safe.

If you want to see how a concierge handles agent traffic with these controls, you can get a demo or start a 30-day free trial and have Coach, Lorikeet's setup agent, help you build and test one.