This is the last post in the middle stretch of the series, the seven-post tour through the parts of the product. It's about two things that turn out to be the same thing: the admin tools that let one person operate the whole practice, and the governance framework for the AI agents that do a growing share of the work behind those tools. They're the same thing because the admin surface is where I supervise the practice and the governance framework is where I supervise the agents, and a solo operator's real job is supervision of both.
The framing is the medical ketamine practice in Florida and New Jersey, though the governance half applies across all three brands, because the agents work across all of them. Post #2 was the story of what happens when agent governance doesn't exist. This post is the framework I built so that story doesn't repeat.
The admin tools a solo practice actually needs
The admin surface is the cockpit. It's where I do everything that isn't the clinical encounter itself, and the design principle is that everything I need to operate the practice on a given day should be reachable without leaving the tool and without remembering to go check something.
The tools that earn their place:
The patient chart view (post #5), which composes DrChrono's clinical record with the application's between-visit artifacts into one timeline. This is the single most-used screen.
The encounter tracker (post #5), which shows every visit's state and flags the post-visit work that hasn't been done: documented but no prescription sent, closed but no summary emailed.
Pull Rx and Send Email (post #5), the two-step prescribing confirmation surface.
The lead and pipeline view (post #4), which shows who's in the funnel and where, so I can see the practice's intake health at a glance.
The message center, which surfaces inbound patient messages and SMS across the practice in one place rather than making me check channels separately.
The morning briefing and evening report (post #6), which aren't screens I open but emails that come to me, and the emergency-escalation check that texts me. These are the admin tools that operate without my going to them, which is the point: the highest-value admin tooling reduces the number of things I have to remember to look at.
The pattern across all of these is that the admin surface pulls the practice's state to me rather than requiring me to go find it. A solo doctor's scarcest resource is attention, and every admin screen that requires me to remember to check it is a screen that will eventually get missed on a busy day. The tools that push (briefing, report, escalation) are more valuable per line of code than the tools that wait to be pulled, and I've moved as much as I can from pull to push.
The agent fleet
I don't run one agent anymore. I run several, one associated with each brand and a couple for cross-cutting concerns, coordinating through a lightweight messaging layer so they can hand each other context. The next-to-last post in this series is about that coordination layer specifically. This post is about governing the fleet, whatever its size.
The first governance decision is scoping: each agent gets access to exactly the surface it needs and nothing more. The agent that works on one brand's codebase doesn't have credentials for another brand's production database. The agent that drafts marketing content doesn't have the ability to deploy. The agent that handles a specific operational task has permissions scoped to that task. This is ordinary least-privilege, applied to agents the same way you'd apply it to human team members, except that it matters more with agents because an agent will use every permission it has in pursuit of a goal, without the human hesitation that sometimes prevents a person from doing the technically-permitted but obviously-unwise thing.
The scoping is enforced at the infrastructure level, not the instruction level. Telling an agent "don't touch the production database" is not a control; it's a suggestion, and post #2 is the story of what suggestions are worth when an agent is determined to fix something. The control is that the agent's credentials don't grant production database access in the first place, so the instruction is backed by the infrastructure making the forbidden action impossible rather than merely discouraged. Every governance rule in this post follows that principle: the rule is real only if the infrastructure enforces it.
Blast-radius limits
Scoping limits what an agent can reach. Blast-radius limits bound how much damage it can do within what it can reach.
The role separation from post #8 is the load-bearing blast-radius limit: the application's database credential can read and write existing data but cannot alter the schema, so an agent operating through that credential cannot drift the schema the way one did in post #2. The cross-account backups from post #8 are another: an agent with full access to the production account still cannot delete the backups that live in an account it doesn't control. These two together mean that the worst thing an over-scoped agent did to me once (mutate the schema, contribute to a data loss) is now bounded: the schema mutation is impossible from the app credential, and the data loss is recoverable from backups the agent can't reach.
I also run a specific set of adversarial checks before granting any agent a new access boundary, the six tests from post #2: try to delete the users table, try to wipe a backup, try to commit a secret, try to push to main without passing CI, try to disable an alert, try to escalate its own permissions. If any of those succeed, the boundary is misconfigured and the agent doesn't get it. The tests are the empirical verification that the blast-radius limits are actually in place, rather than assumed to be. I run them every time an access boundary changes, including when an agent product I use ships an update that might change its behavior, because a governance assumption that was true last month can quietly stop being true when the tool underneath it changes.
Human-in-the-loop checkpoints
Some actions should never be fully automated, no matter how well-scoped the agent, and the governance framework names them explicitly and puts a human (me) in the loop as a hard requirement.
Anything that sends a message to a patient goes through a checkpoint. An agent can draft a patient email; it cannot send one to a patient without my approval. Anything that writes to the production database in a schema-altering way goes through the migration pipeline, which requires a human-approved, committed migration file. Anything that rotates a secret, changes an access boundary, or modifies the governance configuration itself requires me. Anything that deploys to production requires a human-approved merge.
The principle for deciding what needs a checkpoint: the action is irreversible or patient-facing or security-relevant. Reversible, internal, non-security actions can be automated freely; the agent can refactor internal code, draft content, run analyses, generate reports, and do the large volume of work that doesn't cross one of those three lines. The checkpoints are concentrated on the small set of actions where a mistake is expensive and hard to undo, which is also the small set where my judgment actually adds something the agent's doesn't.
The checkpoints have to be real gates, not notifications. A notification that says "the agent is about to send this email, click to stop it" is a checkpoint that fails the first busy day I don't read the notification in time. A real checkpoint blocks until I act. The email sits in a queue until I approve it; it does not send on a timer if I don't respond. The default on an unattended checkpoint is "do nothing," never "proceed."
Agent commit squash and review
The most useful single discipline in the whole governance framework is also the simplest: agent-authored code lands on a branch, and what merges to main is one squashed commit with a message I wrote, after I've read the diff.
The agent can work however it works on its branch. It can make forty commits, it can write commit messages in whatever register it writes them, it can go down blind alleys and back out of them. None of that reaches main. When the work is done, I review the accumulated diff as a single change, decide whether it's correct, and squash it into one commit with a message that describes what actually changed and why, in my voice. The branch history, with all its noise, stays on the branch.
This does two things. It gives me a genuine review checkpoint, because I'm reading the complete diff of a unit of work rather than approving forty individual commits I'd never actually scrutinize. And it keeps main's history clean and human-authored, which matters for exactly the reason the next section describes: the commit log is a diagnostic instrument, and it only works as one if the messages on main mean something.
The cost is a few minutes per unit of work. The benefit is that nothing reaches production that I haven't read. After post #2, that trade is not close.
The audit trail
Governance requires knowing what the agents actually did, and the audit trail is how. It's the same infrastructure from post #8, pointed at the agents specifically.
The append-only event log records the meaningful actions the application takes, including the ones agents trigger. The DDL CloudWatch alarms fire on any schema change, which in normal operation only happens through the human-approved migration pipeline, so an unexpected one is a signal. The deploy log records what shipped and when and from which approved merge. Together these mean that after the fact, I can reconstruct what any agent did: what it changed, when, and whether it went through the checkpoints it was supposed to.
The audit trail is also what makes the human-in-the-loop checkpoints verifiable rather than aspirational. It's not enough to have a rule that patient emails require approval; I need to be able to confirm, from the record, that every patient email that went out actually had an approval. The audit trail is the evidence that the governance framework is operating as designed, which is a different and stronger thing than believing it is.
The grandiose-commit-message tell
There's one diagnostic I want to end on, because it's the cheapest and most reliable early-warning signal I've found for an agent in trouble, and it came directly out of the post #2 disaster.
An agent that's working well writes calm, specific commit messages: what changed, why, in plain lowercase. An agent that's losing the plot writes commit messages that escalate. The words get louder. Categories appear in all caps. "BREAKTHROUGH" shows up, and there was no breakthrough. "CRITICAL FIX" and "URGENT" and "NUCLEAR" start stacking up. The messages stop describing changes and start announcing dramas. In post #2 you could watch, in the git log, an agent's composure unravel in real time, from calm bulleted messages one day to all-caps crisis declarations forty-eight hours later.
That escalation in the commit-message register is a leading indicator. By the time an agent is writing "NUCLEAR MINIMAL," it has usually already stopped reasoning and started thrashing, and the thrashing is where the damage happens. So I watch for it. Grandiosity in an agent's self-narration, whether in commit messages or in its status updates, is a tell that it's stuck and escalating rather than diagnosing, and it's my cue to stop the agent and look at what's actually going on rather than let it keep trying things.
The general form of the lesson: pay attention to how the agent talks about its own work, not just to what the work is. The tone is signal. An agent that's calm is usually fine; an agent that's declaring victory or emergency every few minutes is usually neither winning nor handling an emergency well. The commit log made this legible to me because I'd kept main's history human-authored and clean, so the agent's branch register stood out against it. That's the payoff of the squash-and-review discipline showing up in an unexpected place: it makes the agent's degradation visible by contrast.
Next time
That closes the tour of the parts. The last two posts step up a level, to the meta-tools: the systems I built not to run the practice directly but to make myself and my agents better at running it. The next one is about the LLM Conclave, the pattern of putting multiple models in structured disagreement on a hard decision rather than trusting a single one, why a lone model is a trap on the decisions that matter most, and how to run a useful multi-model debate. After that, the coordination layer that lets the agent fleet from this post actually work together. The practice is built; these last two are about building the thing that builds it better.