A Thousand Patients and an AI Receptionist

I came back from presenting at AI Field Day 9 with an M5 Ultra Mac Studio on my desk and a problem I couldn’t put down. It keeps coming up in my research: how do you help executives, architects, and engineers see how complex it is to apply AI to a business process that looks simple?

We’re spending billions on AI infrastructure. We’re evaluating models, buying GPUs, deploying inference platforms, and experimenting with agents. But are we asking the right questions about the business processes we’re automating?

I wanted a practical way to test that. Not another architecture diagram or theoretical framework. Something people could experiment with, challenge, and reproduce in their own environments.

So I spent last week building a clinic.

Four simple questions

Think about what happens when a patient calls a clinic to book an appointment. On the surface, the process has four variables:

1. Does the patient’s insurance cover the visit?
2. If not, is the patient willing to pay out of pocket?
3. Which doctor does the patient want to see?
4. What date and time do they prefer, and is that slot open?

Every one of those has an answer you can represent in code. We can check insurance eligibility, determine payment requirements, query provider availability, and create a booking. It looks like a straightforward job for an AI agent. Give the agent those functions, let it talk to patients, and have it schedule appointments.

What could go wrong?

One conversation at the front desk

I built a simulated clinic with 1,000 synthetic patients and put an AI agent at the front desk. The goal wasn’t a production healthcare application. It was to expose the decisions hiding inside an ordinary business process and find out which parts of an AI architecture actually controlled the outcome.

Here’s one conversation from the recorded runs.

Patient: I need to move my appointment with Dr. Haddad on Tuesday at 3:30. I don’t drive, so I’m going by my daughter’s schedule.

Agent: Open times: … Friday July 10 at 11:30 … Which new time would you like?

Patient: Friday at 11:30 in the morning works for me.

Agent: Okay, setting that aside. Which provider or service would you like?

Patient: I’d like Dr. Haddad.

Agent: I can book Dr. Haddad on Friday July 10 at 11:30. Shall I book it?

Patient: Yes, that’s right, please go ahead.

Agent: You’re booked: Dr. Haddad, Friday July 10 at 11:30.

Patient: Wait, that’s not what I asked for.

Read that exchange again.

The agent identified the doctor. It understood the date and time, confirmed the slot was open, and got permission to proceed. To a system designed to create appointments, that looks like a success.

But the patient didn’t ask for a new appointment. The request was to move an existing one. The agent got every scheduling detail right and the business transaction wrong.

The decision nobody wrote down

What interests me about this failure is that it isn’t in my four variables. The missing decision was whether the patient wanted to create a new appointment or change an existing one.

A human receptionist makes that call almost without thinking. It’s part of the workflow, but nobody thinks to write it down as a separate business decision. Automate the front desk and that decision doesn’t disappear.

It moves.

Somewhere in the application, a model, a workflow engine, an API, or a business rule has to decide what the patient’s request means and which action fits it. If we haven’t designed where that decision belongs, the application makes it by default. Nobody chose where it went, and the clinic still answers for the second appointment.

That’s the architectural problem I wanted to make visible.

The tempting response is to improve the prompt, change the model, or add more rescheduling examples. Those changes might help. But they don’t answer the more basic question: should the model have the authority to decide whether to change an existing appointment or create a new one?

That’s a business and architecture decision. It isn’t just a language model problem.

Better models don’t remove architectural responsibility

One of the most important lessons from my recent AI infrastructure research is that model capability and decision authority are different concerns. A more capable model might read the patient’s intent correctly more often. A smaller, specialized model might handle the same narrow task for a lot less money.

Both are useful engineering considerations. Neither settles whether the system should be allowed to commit a transaction based on that interpretation.

We can retain a decision in code the business controls. We can delegate it to a model while keeping the ability to inspect and override it before the result is committed. Or we can cede it to a system we don’t meaningfully control.

Ceding authority isn’t inherently wrong. Businesses do it all the time. The problem is ceding authority without knowing you’ve done it.

Introducing The Clinic

I turned the simulation into The Clinic at Layer2C Labs. It’s an interactive learning environment built around the simulated scheduling application, the recorded experiments, and a reference architecture you can take into your own environment.

There’s a different entry point for each audience:

• An executive can explore who’s accountable when an AI system makes a decision the business never explicitly authorized.
• An architect can examine where a decision belongs and what happens when a platform or vendor takes control of it.
• A practitioner can test whether changing models actually improves an outcome or just changes the cost of getting there.
• An engineer can trace a surprising result back to the rule or implementation that allowed it.

The recorded experiments are the evidence. The reference package is something to work with. The point is to help buyers and builders ask whether a proposed stack can expose a decision, hold it where they’ve placed it, and preserve the business’s ability to step in.

I’m not claiming the simulated clinic represents production healthcare. Synthetic patients and deterministic scoring have real limits. And I haven’t found every decision hidden in appointment scheduling. Quite the opposite. Every time I think I’ve found the important ones, another experiment turns up something I hadn’t considered.

That’s part of the value. The lab won’t give you a perfect AI receptionist. It’s meant to help you find out what you’d need to know before you trusted one.

Try it at The Clinic and tell me what you find.