The 9-Step Framework for Deploying Agentic AI in a Homeopathy Clinic

Here is the part nobody says to the founder of a homeopathy clinic out loud. Somewhere between a handful of patients and a full caseload, you stopped being the homeopath and became the operating system.

Every new intake, every remedy review that falls due, every "did we ever bill that consult", every patient wondering when their next appointment is waits on your attention, which means the whole clinic runs exactly as fast as one practitioner can read and remember.

This is the framework we use to take that job off the practitioner and give it to a system, without the risk that comes with letting software near patient records and clinical continuity. It is nine steps in three phases.

Four before you build anything, three to build it, and two to do the thing the whole exercise is for, which is to remove yourself from the middle of every case.

It is worth saying what this is not. It is not a new clinic booking package, and it is not "let AI take the case".

The case-taking, the prescribing, the clinical judgement all stay with your qualified homeopath, full stop. What changes is that the filing, the sorting, the chasing, the follow-up scheduling and the drafting stop landing on one desk, so a case never stalls because the practitioner was buried in admin the week a remedy review was due.

You quietly became the operating system

It happens slowly. In the early years you took the cases, filed the notes, made the follow-up calls and raised the invoices yourself because there was nobody else, and you were good at it, so the clinic grew.

Then it kept growing and the routing never left your head, because it was faster to just do it than to write it down. Now you are the one who notices a chronic case is due its remedy review, who remembers a patient still owes you their completed intake form, who realises a run of follow-up consults never made it onto an invoice.

None of that is written down anywhere. It lives in your attention, and in a clinic attention is the scarcest thing there is.

Three things follow, and every one of them costs the practice real money and, worse, costs patients their continuity of care.

• The clinic runs at memory speed. A practitioner spending two or three hours a day filing notes, chasing forms and trying to remember who is due a review is normal. That is not case-taking work. It is triage, done by the one person the patients actually came to see.
• Follow-ups happen because somebody remembered. Which is fine until the one busy week nobody did. A missed remedy review is a case that quietly stalls, a patient who drifts off, and a course of care that never got the chance to progress.
• Nothing survives your week off. A clinic where one practitioner is the router does not pause when that person is away. Notes pile up unfiled, follow-ups slip, consults go unbilled, and you find out when you get back.

The instinct is to fix this by hiring another practitioner or a receptionist. That works, and it also adds salary, supervision, and one more person who has to learn all the unwritten rules you were already the only keeper of.

You have not removed the bottleneck, you have given it a second head to depend on. The alternative is to write the routing down and let a system run the parts that never needed a clinician's brain in the first place.

That is what the next nine steps do.

For a homeopathy clinic, the patient experience is the marketing

One belief before the framework, because it decides how you read the rest of it. In a clinic, the patient experience is the marketing.

Not the website, not the logo. The follow-up that arrived when it was supposed to, the question answered the same day, the review booked before the patient had to think about it.

That is what gets a clinic referred to a friend, and it is produced almost entirely by the nine jobs we are about to automate.

This is why it belongs on a growth marketing site rather than in an IT catalogue. A follow-up that never happened is not an admin slip, it is a case that stalls and a patient who does not come back, which is churn you are about to pay for.

A consult delivered on a call and never billed is not a bookkeeping oversight, it is revenue you earned and then gave away. When the operating system is one tired practitioner, the patient experience frays in exactly the places a patient notices and a friend hears about.

Which brings up the trap most growing clinics fall into. They try to grow by taking on more new patients, into a practice whose care still runs entirely through the practitioner.

That does not produce growth. It produces missed follow-ups, longer waits and cases that never progress because nobody had the time to review them.

This is the capacity problem, and it is one of exactly three things almost every stuck clinic is stuck on. The other two are getting the right patients in and converting the enquiry into a first appointment, and I have written the full diagnostic in the 3A Machine.

So the goal of deploying agentic AI in a clinic is not "use AI to take the case". It is to build the capacity that lets you grow without continuity of care falling over.

Get the nine steps running and the same practitioner and the same team hold two or three times the caseload without a single remedy review slipping through. Fix capacity first, then go and win the patients.

The nine steps, in three phases

Here is the whole map on one page. Your clinic already runs all nine of these jobs today, whether or not anyone has ever named them.

The framework does not add work. It names the jobs, then decides one at a time whether a person does each one or a system does it.

Notice the shape. Four steps happen before anybody builds anything, and skipping them is the single most common reason a clinic's "let us try some AI" project quietly dies.

People buy the clever part first, point it at nothing in particular, and end up with a fast tool that does not know how the clinic actually runs. The order below is designed to stop that.

Step 1. Diagnose: find what is actually bleeding

You cannot fix what you have not counted, and most clinics have never counted this. So the first step is a leak audit, and its only job is to put a number on the money and the continuity already walking out of the practice.

Not a survey of how everyone feels. A count of losses.

In a homeopathy clinic the leaks are always in the same few places. Remedy reviews that fell due and slipped, and the cases that quietly stalled because the follow-up that would have moved them forward never got booked.

Consults that were delivered and never billed, and in a clinic this is almost always larger than the practitioner guesses, because follow-up calls, quick check-ins and "just seeing how you are getting on" rarely make it onto an invoice. Packages sold with a block of sessions, where the patient stopped coming with sessions still unused and money still owed against care never given.

The hours the team burns every week filing notes, typing up intake forms and chasing patients for the paperwork a case needs. And the quietest leak of all, patients who drifted away not because the care was wrong, but because nobody followed up and a clinic that did made them feel looked after.

Do it by case type, because the leaks are not spread evenly across the caseload. A chronic case is a series of reviews stretched over months, so it lapses quietly, one skipped follow-up at a time, and the loss is a whole course of care rather than a single missed visit.

The acute caseload leaks in a different way, fast and small, a run of short consults billed late or not at all. Constitutional cases sit somewhere between the two.

Break the audit down that way and you stop staring at one big blurry number and start seeing which part of the practice is actually bleeding and why.

Add it up honestly and the total is almost always bigger than expected, and concentrated in two or three places rather than spread evenly. That concentration is the gift.

It tells you exactly where to point the build first, and it becomes the before number you use, at the very end, to prove the system paid for itself.

Step 2. Shadow: follow one real case from intake to follow-up

Now you watch. Pick one live case, a new chronic case, an acute presentation, a constitutional case, and follow it end to end, from the first enquiry through case-taking to the first follow-up, writing down every single thing that happens to it and every decision anybody makes.

Not the tidy version in the procedures folder nobody opens. The real one.

This is where you discover the clinic does not run on the written process. It runs on a hundred unwritten rules that live in the practitioner's head and, more than anywhere else, in the appointment notes and the messages between visits.

Which parts of the intake have to be complete before a first appointment can even be booked. How the practitioner always structures the case-taking, and what is always missing when a patient fills the form in themselves.

When a case is due to be reviewed, and how long is too long to leave it. The case you never let close without a proper follow-up.

None of it is written down, all of it is load-bearing.

The excavation is the real work of this step. You read back through the notes and the follow-up messages and pull out the rules the clinic actually operates on, the ones that were never a decision, just a habit that turned out to be sound practice.

That messy, lived-in reality is what you are about to encode. Skip it and you will automate the fantasy version of the clinic, ship it, and watch the practitioner quietly go back to doing it their own way because the system does not know what they know.

And be honest about the fragility this surfaces: in most clinics the real operating manual is one experienced practitioner's memory, and it walks out of the door the day they cut back their hours.

Step 3. SOP: write the unwritten procedure down

Everything you excavated now becomes one written procedure. Plain language, step by step, in the order it really happens, with every rule and every exception stated.

This is the least glamorous step in the framework and it is the one that makes an agentic system possible, because a clinic assistant can only work a procedure that has actually been written.

For a new case it looks like a hard checklist, a case-taking checklist: the full intake, the presenting complaint, the history, the constitutional picture, the repertorisation, and a remedy plan with a follow-up already scheduled. The case does not count as ready until every one of those is on the record.

Written as a procedure, the messy reality becomes a gate a machine can enforce perfectly, every time, without a tired practitioner marking a case complete on a busy day when the follow-up was never actually booked. The same goes for onboarding a new patient, running a remedy review, or closing out a completed course of care.

Each becomes a written sequence rather than a thing your best clinician simply "knows".

Write it for a smart new team member on their first day, not for a machine. If a person could follow it without asking a single question, a system can run it.

If it still needs somebody to "just know", the procedure is not finished, and you are not ready to build. One line to be clear about: the checklist governs whether the admin around a case is complete.

What remedy to prescribe and how to read the case stays entirely with the qualified homeopath. The system enforces that the follow-up got booked, never what happens in it.

Step 4. Baseline: agree the numbers before you touch anything

The last step before the build, and it is thirty minutes that saves you a year of arguments. Write down the current numbers and get the practitioner to agree them.

How long it takes to file an intake form to the right case today. What share of remedy reviews actually happen on time.

How many consults are sitting delivered but unbilled right now. How many packages have unused sessions with an expiry approaching.

How fast the first reply to a patient enquiry goes out. Real numbers, honestly rounded, on the record.

You do this for one reason. In three months, when the system is running, memory rewrites history.

People forget how bad it was, decide it was "always basically fine", and start to wonder what they are paying for. The baseline is the receipt.

It is what lets the weekly proof report at the end say "filing an intake to the right case went from about twenty minutes by hand to about two" and have that land as a fact the practitioner agreed up front, rather than a vendor's claim.

It is also the moment to decide what "better" means for this clinic, so the build aims at a number and not a vibe. A practice bleeding on unbilled follow-up consults is not chasing the same win as one where cases keep stalling because reviews slip.

Name the number now. It is what everything you build next is pointed at.

Step 5. The command center: the whole clinic on one screen

Now you build, and the first thing you build is the place the practitioner looks. One screen that shows the whole clinic at a glance, in the order that matters, so nobody reconstructs the state of the practice from a diary, a billing app and a pile of paper notes every morning.

Build it on one spine, not twelve tools. This matters more than it sounds.

Every job in the audit is tempting to solve with its own separate app, one for booking, one for notes, one for reminders, one for invoices, and a year later you have a dozen subscriptions that do not talk to each other and a practitioner who is now the integration layer between them. Build the whole thing on one foundation, one place the data and the context live, and the next piece is nearly free because everything it needs already exists.

The centre of the screen is a patient radar: every live case, ranked not by name but by who is due a follow-up or about to lapse. The chronic case that is nine days past its remedy review sits at the top, in red, whether or not anybody asked.

Around it, the numbers a practitioner actually needs, the cases that need action today, how many follow-ups are overdue, how much delivered work is sitting unbilled, how many packages expire this month with sessions still inside them.

Then the follow-up clock. A clinic does not have one deadline, it has dozens running at once across every open case, and these are the reviews that decide whether a case progresses.

A single shared diary flattens them into a comforting average that hides the one about to lapse. The command center pulls them apart and shows each on its own, so the remedy review that is already overdue, the package about to expire with unused sessions, and the case review still comfortably ahead are three separate clocks, and the dangerous one is the one you see.

Beside the clocks, the money on the floor: every consult delivered, given, done, and never invoiced. In most clinics this is a genuinely uncomfortable number the first time it appears on a screen, because the work was already paid for in the practitioner's time and simply never got billed.

It was not a discount anyone decided to give. It was that raising the invoice was a small annoying job nobody owned, which is a fair description of most of what leaks in a clinic.

Sixteen patients, thousands of dollars of care, invisible until now.

Packages sit right next to it, because they leak the same way from the other end. A patient buys a block of sessions, comes for a few, then life gets in the way and the rest go unused.

The money is booked, the care was never given, and an expiry date is quietly ticking. The command center shows the packages expiring this month with sessions still inside, so a friendly reminder goes out while there is still time to use them, which is better for the patient and better for the clinic than a refund conversation later.

And the document wall. An established clinic is sitting on an enormous pile of case records, intake forms, consent forms, case notes, remedy logs and follow-up notes across folders nobody has fully mapped in years.

The command center reads that existing storage where it already lives, with no migration and no "please move every case file into our new system", and makes it navigable and countable, so any record is found in seconds instead of a frightened hunt through the cabinet while a patient waits on the phone. It even surfaces the quiet ones, like a consent form flagged for review in 41 days.

One design choice worth naming, because patients and regulators both care about it. The command center is owner-locked, and the team gets read-only logins scoped to what they need.

The practitioner sees the fees and the whole board. A receptionist sees the appointments and the forms, not the clinical detail they have no reason to open.

Nobody can quietly change a record they should only be reading, and the practitioner never loses the single honest view of the clinic the whole build exists to give them. In a setting holding sensitive health records, that scoping is not a nicety, it is the point.

Step 6. The procedure as data: the clinic's mind

The procedure you wrote in step 3 is a document, and a document just sits there. In step 6 you turn it into data the system can reason over: every rule, the case-taking checklist, the follow-up protocol, the remedy review cadence, and every good answer the clinic has ever given about how it runs, connected by meaning rather than filed in folders.

This is the clinic's mind, and it is what makes the clinic assistant in the next step sound like your practice instead of a generic model.

In practice it means anybody on the team can ask a plain question and get the clinic's own answer, not the internet's. What is our case-taking checklist for a new chronic case.

When is a remedy review due after a first prescription. What has to be complete before we book a first appointment.

The answer comes back grounded in the clinic's own written procedure, with the source it came from, so it is checkable rather than a confident guess. And it draws a hard line: it answers questions about how the clinic runs, never questions about what to prescribe, which is not its job and never will be.

The reason this matters more than it looks is drift. A general model, asked the same procedural question twice, will happily give two confident and slightly different answers, and in a clinic that is a liability, not a quirk.

Grounding every answer in the clinic's own written procedure kills it. The system is reading your rules and quoting them with the source, and when a protocol changes, when you decide the review cadence should be different, you change it in one place and every answer changes with it.

It is also where the case-taking checklist becomes enforceable rather than advisory, because the clinic assistant in the next step reads its gates from exactly here.

Step 7. The clinic assistant: filing and chasing that shows up on time

Now the part people picture when they hear "AI". An employee, not a chatbot, and the distinction is the whole thing.

A chatbot waits to be asked. An employee wakes on a timer, reads the live clinic, does its round, files the work, and flags what needs a human, whether or not anybody prompted it.

I have written the longer version in AI employees, not chatbots.

In a clinic it is a small crew of them, each with one job, all reading from the clinic's mind. A records controller that reads a photographed intake form or a signed consent, understands it, files it to the right case and starts the case-taking checklist.

A refusal fence that will not let a case be marked ready until that checklist is complete, all six items on the record. An invoice filler that drafts the bill for a delivered consult straight from the record of the visit.

A follow-up drafter that writes the personal message a patient is owed when their remedy review falls due, ready for a person to send. A talking agent that answers a patient's "when is my next appointment" in their own language, without pulling the practitioner off a case.

There is a quieter agent in this crew that practitioners never ask for and always end up valuing most: a critic. Before any piece of work reaches a human, a second agent grades it against the procedure.

Is the intake filed to the right case, is the checklist genuinely complete, does the draft follow-up say the right thing. Anything that fails goes back to be redone before you ever see it.

This is the line between AI you can run and AI you can trust in a setting where a mistake touches a patient's care.

An employee that can act is useful and it is also dangerous, so this step ships with four safety rules and they are not optional. They are the reason you can hand a system this much and sleep.

• It refuses out-of-procedure work. A case is not marked ready until the case-taking checklist is complete, all six items on the record. If an intake is missing a piece, or a request does not match the written procedure, the assistant declines and escalates rather than improvising. The refusal fence is a feature, not a failure, and it is what keeps a case from being closed before its follow-up is booked.
• Every file operation stays inside set boundaries, and deletes go to a recycle bin. It cannot reach outside the case folders it was given, and nothing it touches is ever gone. A form filed to the wrong case is always recoverable, which matters more, not less, when the files are health records.
• Every patient-facing message waits for a human yes. It drafts the follow-up, the reminder, the invoice, then stops. A person reads it and presses send. Anything that reaches a patient, touches their money or carries the clinic's name gets a human on it. The clinical judgement in any message is the practitioner's, always.
• Ambiguous figures and dates come back empty, never guessed. If it is not sure which case a form belongs to, or when a review is actually due, it says so and asks. A blank is safe. A confident wrong date on a patient's remedy review is how a system does real damage.

Step 8. Hand it to the team

The build is running. Now it stops being the practitioner's private tool and becomes how the team works, and the shift is subtle but total: people move from performing the admin to approving it.

The system does the first pass of everything and a person says yes, changes a line, or sends it back. Same team, far more patients cared for properly, and your qualified practitioner is left doing the case-taking and the clinical thinking that was always the actual job.

That handover is made of a few specific things. A follow-up drafter that writes the message a patient is owed when their review falls due, ready for a person to approve.

An activity wall so the practitioner can see what the system and the team did without asking. A change watcher that notices when a case stalls at the same stage for days, or a package is about to expire with sessions still inside.

And the piece everyone feels first: the morning brief.

At eight in the morning, before anyone opens anything, one message lands in order of what matters: here are the two cases overdue a remedy review, one of them a chronic case nine days past, here are the three packages about to expire with unused sessions and the reminders already drafted, here is the delivered work waiting to be invoiced across sixteen patients, here is the new case stuck two days without a follow-up. The team walks in already knowing the day instead of spending the first hour discovering it.

A word on the human side, because it decides whether any of this sticks. The word removal frightens a team, and if they think it means removing them, they will quietly starve the system of the knowledge it needs.

It does not mean that. It means removing the note-typing, the form-chasing, the frightened record hunts, and leaving people with the patient relationships and the care that were always the real work.

Say it out loud, early and often. A team that believes the system is on their side will feed it.

A team that fears it will fight it, and win.

Step 9. Removal is the whole point

Here is the step everyone gets wrong, and it is the reason the framework exists. Step 9 is not training.

It is removal. The goal was never to teach the practitioner to use a clever new tool.

It was to take the operating-system job out of the practitioner's head, so the clinic stops running at the speed of one person's memory.

You know you have reached it by a specific test: the practitioner can take a genuine week off and nothing lapses. Intakes still get filed.

Remedy reviews still get scheduled and the follow-up messages still go out on time. Consults still get invoiced.

Patients still get answered in their own language, the same day. Nothing waits for one person to come back and remember, because that person is no longer the thing the routing runs through.

They approve the exceptions from their phone, or they do not, and it holds either way. What they do not delegate, ever, is the case itself.

The system runs the clinic around the consult, never inside it.

And this is where the baseline earns its keep. Every Monday a proof report goes to the practitioner and says, in the numbers agreed at the start, what the system did this week.

Intakes filed in minutes instead of the afternoon. Every case contacted for its remedy review on time, so no case stalled unnoticed.

Zero consults left uninvoiced. It is not a dashboard somebody has to go and check.

It is the system reporting to the owner, unprompted, on whether it is still earning its keep.

And then the question that is really the point: what does the practitioner do with the attention they just got back. In every clinic the honest answer is the same, and it is why this belongs on a growth marketing site.

They go and do the work only they can do. Taking the cases properly, without one eye on the admin.

Building the reputation that brings the next patient through referral. The next hire, the next room.

Removal is not the end of the practitioner's involvement. It is the first time they get to actually be the clinician they trained to be, rather than the busiest administrator in the building.

What it costs to run

This is the question every practitioner asks within about ninety seconds, and the honest answer surprises people in the right direction. It is far less than they expect, and far more transparent, because the running cost is metered and shown like a utility bill rather than hidden inside a flat fee.

For a working system on a real clinic's volume, the AI usage runs on the order of a few dollars a day, and the hosting and database are a few tens of dollars a month, so the whole thing comes to roughly a hundred dollars a month to run. Your volume will differ, which is exactly why the meter is built in from day one and shown to the practitioner on day one.

No hidden meter, ever.

Now put that next to what it replaces, with round numbers you can redo with your own. Say the practitioner and the team lose two and a half hours a day to filing notes, chasing forms and remembering who is due a review, across twenty two working days.

That is fifty five hours a month. Value that time at even a modest fifty dollars an hour, low for a qualified clinician, and it is over two and a half thousand dollars a month of attention, against roughly a hundred to run the system that gives most of it back.

And that ignores the two biggest wins, because neither shows up as time saved: the case that stopped stalling because the review actually happened, and the follow-up consult that finally got billed. Those show up as revenue that did not leave, and as patients who stayed.

Where to start on Monday

Nobody builds all nine steps at once, and you should not try. This is a map, not a project plan, and the map is useful the moment you have it, because it tells you where you are and what the next single step is.

So do not start with the screen that impressed you most. Start with the step the audit said is bleeding worst.

If consults keep getting delivered and never billed, the money-on-the-floor wall and the invoice filler pay for the whole build in the first month. If cases keep stalling because reviews slip, start with the patient radar and the follow-up clock.

If the team is drowning in note-typing and form-chasing, start with the records controller. The full logic for choosing the first thing is in what to automate first in a service business, and the honest way to measure whether it worked is in true ROI versus reported ROAS.

One thing at a time. Diagnose, build the one piece that hurts most, put a human gate on anything irreversible or clinical, then the next piece, which will be cheaper than the first because it sits on the same spine.

That is the whole method. This same framework runs in an accounting firm, a law practice, a physio clinic and a construction consultancy, the labels on the screens change and the nine jobs do not, and the full walk-through of the general version is in the 9-step framework for deploying agentic AI.

The clinics that end up with a real system instead of a browser full of half-used tools all started the same way: one step too small to fail, aimed at a number they had already agreed was bleeding.