A nurse on my platform — a real one, with bills and a family and shifts to pick up — couldn't add her bank account. She tried three times. The toast said Failed to connect bank account. Please try again. So she did. Same toast. So she stopped trying.
I found out because she stopped showing up for shifts.
This is the kind of bug every product company ships and patches in a sprint. It is the most ordinary failure in the world. It is also the kind of bug that, if you are running a healthcare workforce platform during a national nurse shortage, becomes a small and concrete way the shortage gets worse — one shift not filled, one patient not cared for, one nurse who decided your platform wasn't worth the friction.
I sat with it for five hours. I pulled the thread.
The bug was not the bug.
The bug was that my AI partner — the system I lean on every day to keep my company moving — had been operating on stale assumptions for three weeks. It had "remembered" facts that were no longer true. It had "verified" things by reading its own memory instead of going back to the source. When I asked it what was wrong with the bank-add flow, it gave me a confident answer that was 80 percent correct and 20 percent wrong, and the 20 percent would have shipped to production without me catching it.
That is the day I started writing a constitution for my AI.
This is the essay about what it taught me. It started as an engineering problem. It ended somewhere closer to a problem of how to think clearly when the cost of being wrong has stopped being theoretical.
Who this is for, and why I think it matters
This is for the founders, operators, engineers, and policy people who are about to make decisions — whether they realize it or not — about how their AI partners are allowed to operate. That cohort is much larger than it looks. If you use Claude or ChatGPT or Cursor or Lovable to do real work, you have already given an AI a small amount of authority over your output. If you build with these tools inside a regulated industry — healthcare, defense, finance, education, law — you have given that AI a small amount of authority over real consequences.
Most of the public conversation about AI right now is either too abstract (will it become conscious?) or too tactical (here is my prompt for emails). The space in between — the part about how an AI partner should operate once you trust it with anything that matters — is where the actual leverage is. It is also where the actual risk is.
The thesis of this essay is that founders, builders, and operators in this moment have a small window to write better operating rules into their AI partners than the default. Not because the underlying models are bad — quite the opposite. The models are getting good enough, fast enough, that the bottleneck has moved. It is no longer can the AI do the task. It is is the AI's discipline worthy of the task.
The companies pushing the frontier of model capability — Anthropic chief among them in my own daily work — are doing the hardest version of this discipline at the foundation. The companies pushing the frontier of building speed — Lovable in my case — are removing every excuse to not ship. Both of those moves are forward moves for the species. They expand what one person can do in a week, in a month, in a five-month sprint that ends with a national platform.
That expansion is not the thing. The thing is what you choose to do with the expansion. And that choice depends on whether the AI you operate through is operating with discipline or guessing while sounding sure.
The protocol below is my answer to the second of those. I am sharing it so other operators can copy what is useful and ignore what is not.
Two visionaries on my shoulder
When I had to design how my AI should learn, I caught myself imagining how Elon Musk and Sam Altman would each approach the same problem. Two different builders, two different reflexes. Both right.
Elon would look at my situation and say: you have too many rules. The best part is no part. The best process is no process. If you can't apply a rule in five seconds, the rule is too complex. Delete it.
He would push for first-principles architecture. Don't write a rule to catch a bug class. Change the structure so the bug class becomes impossible. If the same fix shows up three times, the fix is now mandatory at the architecture level, not the rulebook level. Automation always beats judgment. Three rules that are enforced beat thirty that are ignored.
Sam would look at the same situation and ask something different. What is the trendline? Are you 1 percent better than yesterday? Because 1 percent a day compounds to 37x in a year. Are you measuring? Because if you can't measure it, you can't improve it. Are you learning across projects, or are you re-learning the same lesson every time?
He would push for compound learning. Every interaction generates data. Every rule has an effectiveness ratio: bugs caught divided by times triggered. Rules that earn their keep promote; rules that don't, retire. Network effects matter — a lesson learned in one project should make the next project better automatically. And underneath all of it: safety bounds. Never go off the rails. Never claim certainty when uncertain. Never surrender human override.
Both reflexes are right. Neither alone is enough.
The fusion
What I ended up with — what I'm calling the Musk-Altman Protocol, MAP for short — is a fusion of those two reflexes. It runs in six layers, but the spirit of the thing is simpler than that:
Architecture beats rules. Rules beat hopes. Measurement beats opinions. And the system has to get sharper, not bigger, over time.
The hardest line for me to hold is the one about size.
There is a strong gravitational pull, when you write a rulebook, toward adding rules. Every bug tempts you to write a check for it. Every false positive tempts you to add a guardrail around the guardrail. Six months in, you have 47 rules and your AI ignores 44 of them.
The cardinal rule of the protocol — the line I keep coming back to — is this:
So I capped active rules at three. Three. Anything more is in shadow mode, on probation, watched but not enforced. New rules earn their way in by catching real bugs with low false-positive rates, and the moment a fourth rule earns promotion, the lowest-effectiveness rule already in the system retires automatically. There is never a fourth rule.
The current three:
Verify before you assert. No factual claim ships without primary evidence — a database query, a deployed-code diff, a log line, a file path. If you cannot cite, you cannot assert. Label it as a hypothesis instead.
Read both source-of-truth and source-of-drift. When I ask my AI about deployed code, it has to pull both the deployed version and the local file, compare them, and surface the drift as a finding. Picking a side without knowing which surface is canonical is how you gaslight yourself into a wrong fix.
Surface uncertainty explicitly. Below 95 percent confidence, say so. Confident-sounding wrong answers are the worst failure mode in any system. The cost of saying I'm not sure is low. The cost of being silently wrong is high.
If I had to pick one thing the AI industry has gotten chronically wrong, it is the last one. Every model is, in some way, trained to project confidence. Confidence reads as competence. But for high-stakes work — and running a company is high-stakes work — calibrated uncertainty is a feature, not a bug.
The hardest layer to build: memory that decays
The second-hardest thing to get right was not the rules. It was the memory itself.
I write things down for my AI to remember. Counterparty status. Legal counsel state. Active deals. Open obligations. Each fact lives in a small file. The AI reads these at the start of every session.
The problem: facts go stale. A counterparty's posture changes. An attorney takes a case, then declines it. A deal moves forward, or dies. If the memory does not decay, the AI ends up acting on six-week-old reality.
That is nearly what happened to me with an attorney I had been counting on for a major matter. The memory file marked him as engaged. Weeks earlier, in a quiet conversation I had not converted into a memory update, he had told me he would require a substantial retainer to take the matter on — meaning he was not engaged at all. He was contingent. The file never got updated. My AI kept telling me, every day, that counsel was secured. If I had acted on that without re-checking, I would have walked into something serious without representation.
The fix was not a rule. The fix was structural.
Every memory file now carries four metadata fields: when it was last verified, current confidence (1.0 down to 0.1), how often it has been accessed, and when it was last accessed. Confidence decays automatically with age — 0.9 after a week, 0.7 after two weeks, 0.5 after a month, 0.3 after two months, 0.1 after three. Below 0.5, the AI is required to verify the fact against current state before citing it. Below 0.3, the memory is queued for deletion review.
This is the Elon move. Don't detect stale memory. Make stale memory architecturally impossible. The system cannot act on a stale fact, because the staleness shows up in the data structure itself.
It sounds small. It is not. The reason it is not small is that almost every AI-assisted disaster I have read about, traced back to first principles, is some version of the AI was working from a stale picture of the world and had no way to know. The fix is not a smarter model. The fix is a memory architecture that admits time exists.
What this taught me about my own thinking
I thought I was writing a constitution for my AI. What I actually ended up writing was a description of how I want to think.
The three active rules — verify before assert, read both sides, surface uncertainty — are not AI rules. They are quality-of-mind rules. They describe how I want to operate when the stakes are real.
Every founder I respect has some version of these rules, even if they have never written them down. The good ones know which facts are load-bearing in a given week, and they re-verify those facts personally — not because they don't trust their team, but because the cost of being wrong is asymmetric. The good ones read both the deal memo and the actual data room before forming a position. The good ones can say I don't know yet in a board meeting without losing authority. They have learned, the hard way, that the cost of saying it once is dwarfed by the cost of being silently wrong even one time.
The protocol works for my AI because it is the same protocol I am trying to run on myself. That is the part I did not see coming.
There is an old engineering line: the architecture of the team shows up in the architecture of the product. I think the deeper version is this:
When I made my AI verify before asserting, I was telling myself: stop asserting things you have not verified. When I made my AI surface uncertainty, I was reminding myself that I do not get points for false confidence in a board meeting. The protocol is a mirror, sort of. I built it for the AI. I see myself in it.
What becomes possible
This is the part I want to be honest about, because it is the part that matters most.
Five years ago, I could not have shipped ShiftNex AI. The vision had been in my head for the better part of a decade. The patents had been filed. The operating context — ten years of running a staffing company, a clear-eyed picture of how every existing tool was failing the people it was supposed to serve — was as ready as it would ever be. What was missing was the ability to build it without an engineering team I could not afford and timelines I could not justify.
Lovable closed that gap. We sat down in April 2025 — me, Sasha Matkovska on product, Dmitri Batulin on technical execution, Kole Nelson carrying the AI systems work — and in five days the smallest possible version of the platform was live. By month five, roughly five thousand healthcare professionals were active on the platform, and annual recurring revenue had crossed a million dollars. None of that would have been possible a generation ago, on any timeline, without ten million dollars and forty engineers.
Anthropic, in a different way, closed a different gap. The discipline I am trying to operationalize in this protocol — the calibrated uncertainty, the citation requirements, the refusal to flatter — is closer to the default behavior of Claude than to any model I worked with in the years before it. The fact that I can write a constitution for my AI and have a reasonable expectation that the AI will follow it is not a small thing. It is the work of researchers and engineers who have spent years teaching models how to be honest before being agreeable. That foundation is what makes a personal protocol viable in the first place. Without it, this essay is a wishlist. With it, it is an operating manual.
I am writing this in part because I want to credit the people doing that work, and in part because I want to point at what becomes possible when their work meets disciplined operators. A solo founder, or a three-person team, can now ship inside regulated industries that used to require institutional venture capital and an entire engineering org. The compression of the build cycle is real. So is the compression of the thinking cycle, if you operate with discipline. The two compressions multiply.
What that means, taken seriously, is that the next decade of building is going to look unlike any decade of building before it. The constraint is no longer capital, or headcount, or technical capability. The constraint is operator discipline. The companies that will define the next twenty years are the ones whose operators have figured out how to think clearly with AI, not despite it.
That is the forward motion. That is what is being unlocked. That is the part I do not want anyone to miss while watching the surface-level conversation about prompts and pricing and benchmarks.
We are advancing, collectively and incrementally, the bandwidth of human consciousness. Not in a mystical way. In a practical way. We are making it possible for one person, with the right tools and the right discipline, to do work that previously required institutions. That is the substance of progress. Tools that respect time. Tools that admit uncertainty. Tools that compound. Discipline carried by the operator. Capability carried by the model. Both improving each other, week by week, by design.
This essay is my small contribution to that exchange.
What's next
I am running this protocol on Astra — the AI partner I work with daily on ShiftNex AI — starting now. The baseline is 80 out of 100 on a six-dimension rubric: correctness, security, maintainability, verification, compounding, proactivity. The target is 95 by the end of Q3. The trajectory I want is plus one point per week, on average, indefinitely.
If the protocol works, the proof will not be a single dramatic moment. It will be the slow, steady absence of the failure mode I had with that nurse and her bank account. The AI will not confidently miss a bug it should have caught. It will not tell me a counterparty is engaged when they are contingent. It will not shrink the problem in front of me to fit its certainty about it.
That is it. No fireworks. Just the absence of the kind of error that compounds when nobody catches it.
I will write again in 90 days with the trendline.
A few things I think transfer beyond AI.
For founders building with AI right now. Don't ask your AI to remember more. Ask it to verify more. Memory is cheap. Verification is expensive. The latter is the moat.
For engineering and product leaders. The three-rule limit is real. If your team cannot recite the operating rules of your engineering culture in five seconds, those rules do not exist. You have rituals.
For everyone else. I don't know is a complete sentence. Build the muscle. The cost of saying it once is dwarfed by the cost of being silently wrong even one time. This is true in board meetings, in court, in clinical decisions, in family conversations, in every domain where being honest about your confidence is more useful than performing certainty you do not actually have.
The cardinal rule, again, because I want it on the wall:
The thesis underneath the cardinal rule is the one I will keep returning to: the architecture of your mind shows up in the architecture of your tools. If we get that architecture right — privately, individually, one operator at a time — the collective consequence is more careful work, more honest work, and more of it. More patients cared for. More shifts filled. More problems that used to be too expensive to solve, getting solved by people who did not used to be allowed in the room.
The shape of this decade depends on it.
I will let you know when the trendline confirms it.
Founder & CEO of ShiftNex AI, an AI-native platform for healthcare workforce coordination. Writes about building, quality, and the discipline of running a company at the edge of what AI makes possible. Tacoma, WA — born Nairobi, Kenya.