Oh hell, I just went ahead and built the damn thing
I got tired of admiring the category from a tasteful distance, so I took the Family Health Agent thesis, turned the Claude Code prompts into a build order, and made a working prototype of the core loop.
This is a companion to From the Family Health Manager to the Family Health Agent: HealthVault 2030 and How to Build the Family Health Agent. The first post makes the category argument. The second one lays out the build logic, the product primitives, and the Claude Code prompts I’d use to get started. This one is what happened when I stopped theorizing quite so politely and actually made a prototype.
TL;DR: At a certain point, fuck the PRD and fuck the prompt deck. I wanted to know whether the Family Health Agent would actually cohere as software — not as a category claim, not as a deck, not as a nice abstract product sentence, but as a thing you could click on and feel. So I built a lightweight browser prototype of the core loop: household graph, delegate access, longitudinal care timeline, task engine, bounded actions, buyer KPIs, and audit log. It is very much a prototype. It does not connect to real provider, payer, or pharmacy rails. It is not secure. It is not compliant. Do not put real health information into it. But it does something more valuable at this stage: it makes the product logic tangible.
Prototype: Try the browser prototype here. It’s a lightweight browser demo of the core loop: household graph, delegated authority, longitudinal care timeline, task engine, bounded actions, buyer KPIs, and audit log. And, because the internet has trained all of us to do foolish things, let me be explicit: do not put any real healthcare information into this prototype. It is a concept vehicle, not a secure product.
Why I just went ahead and built it
After writing the first Family Health Agent essay and then the follow-up post on how to build it, I found myself in a slightly ridiculous situation. I had a category thesis I believed. I had a more serious product model than most people bother to sketch. I had a sequence of Claude Code prompts that, on paper at least, looked like a credible starting path. And yet the thing still lived at the level of elegant prose, which is a dangerous neighborhood for ideas like this because it is very easy to confuse “well argued” with “real.”
So I decided to cheat a little. Instead of polishing the abstraction endlessly, I wanted to see whether the Family Health Agent would survive contact with even a crude piece of software. Could I make the role feel tangible? Could I build something that made the Family Health Manager logic visible rather than merely discussable? Could I get to the point where someone clicked around for five minutes and said, “Oh — I see it now. This is not a synthetic doctor. This is a managerial system.”
That was the whole reason for building the prototype. Not to declare victory. Not to pretend the hard parts are solved. Not to sneak a toy into the world and call it a platform. Just to force the idea to become concrete enough that its strengths and weaknesses would start revealing themselves.
What I actually built
What I built is a lightweight browser prototype of the Family Health Agent’s core loop. It is not the whole product. It is not even close. But it is, I think, the right part to prototype first.
The prototype includes a Household Health Graph, a Delegation Ledger, a Longitudinal Care Timeline, a simple manager loop for detecting dropped or unresolved work, an Action Center for bounded actions, a buyer KPI panel, and an audit/activity log. In other words, it is a prototype of the managerial substrate, not a fake clinical brain in a lab coat.
That distinction matters. I did not try to make a smarter chatbot. I tried to make the role visible. The Family Health Agent, as argued in the first post, is not fundamentally about diagnosis. It is about remembering what was supposed to happen, noticing what did happen, spotting the gap, and managing the follow-through until the gap closes or a human needs to intervene. That is what the prototype tries to make feel real.
How the Claude prompts actually helped
The interesting thing about the Claude Code prompts from the previous post is that, if you take them seriously, they stop looking like speculative prompt theater and start looking like a build order. The prompts forced the same discipline the essays were trying to force conceptually: household first, delegated authority first, longitudinal state first, deterministic manager loop first. Not provider-patient-centric permissioning with family support bolted on later. Not a generic assistant waving vaguely in the direction of healthcare. A role-native managerial system.
So that is how I used them. I treated the prompt sequence as product scaffolding. The prompts gave me the hierarchy: start with the domain model, then the household and delegation layer, then the timeline, then the manager loop, then bounded actions, then buyer metrics. That sequence matters because it protects the build from collapsing back into the old industry defaults.
If I had started from a traditional provider-patient data model and then tried to “add family stuff,” I would have rebuilt the same philosophical mistake the first essay was trying to escape. The prompts prevented that. They kept the Family Health Manager insight inside the bones of the thing.
What the prototype does right now
The prototype is deliberately focused on the managerial loop. It lets you look at a household and its roles. It shows who the Family Health Manager is and who has delegated authority to do what. It keeps a timeline of health-related events. It runs a very simple version of the daily manager loop and shows what is open, what is waiting, and what has been resolved. It exposes a bounded action center rather than pretending the system can do everything. And it shows buyer-facing metrics, because if this thing is ever going to be funded by the institutions already paying for manual coordination, it has to explain the economics, not just the user experience.
That means the prototype already surfaces some of the right feelings. You can feel how the household becomes the operational unit. You can feel why delegate access is not a settings-page nuisance but a core data structure. You can feel how the timeline is not just a record of what happened, but a working memory of what should happen next. And you can feel, perhaps most importantly, that the “AI” part of the Family Health Agent is not the star of the show. The star of the show is the managerial system.
That is a useful result, because it confirms something I suspected in the essays: the product gets more convincing when you stop describing it as synthetic medical intelligence and start describing it as relentless, bounded, administratively competent follow-through.
What it very much does not do
This is the important part. The prototype does not connect to real provider systems. It does not connect to payer APIs. It does not connect to pharmacy rails. It does not perform real prior authorization. It does not move prescriptions across state lines. It does not authenticate against a health portal. It does not manage real PHI. It is not secure. It is not compliant. It is not production software. It is not even close.
It is also not trying to be a general-purpose medical assistant. It will not diagnose you. It will not prescribe anything. It will not become your synthetic Marcus Welby. That is not what I built, because that is not the category I am trying to make visible.
What I built is a role prototype. It demonstrates what it feels like when the Family Health Manager becomes software-assisted, when delegate access is built into the core data model, when the timeline becomes operational memory, and when dropped tasks become visible instead of silently rediscovered a week later by the most exhausted person in the household.
Again: do not put real healthcare data into it. This is a browser prototype for feeling the product loop, not a secure environment for actual care management.
What building it taught me
The first lesson is that the core insight holds up. Once you put even a crude interface around the Family Health Manager role, the old provider-patient-centric worldview starts to look obviously incomplete. The household really does feel like the right operating unit. Delegate access really does feel like core architecture rather than a feature. And the role really does feel managerial before it feels clinical.
The second lesson is that the product gets more interesting the less it pretends to be magical. The prototype is strongest where it is most modest: showing state, surfacing dropped work, routing bounded actions, and preserving authority. The parts that feel strongest are not the “AI” parts in the branding sense. They are the parts that let the system behave like the world’s most conscientious case manager with perfect memory and no capacity for administrative despair.
The third lesson is that the hard parts are exactly where we thought they would be. Not the surface. Not the copy. Not even the notion of the household graph. The hard parts are the rails, the permission model, the action boundaries, the event model, and the question of how much real managerial work you can do on top of partial and brittle infrastructure before you need deeper integration. In other words: the prototype makes the category more real, but it also makes Josh Mandel’s warnings more real.
Why the limitations are useful
One of the best things about prototyping a category this way is that the limitations are not embarrassing. They are clarifying.
Because the prototype is obviously incomplete, it forces the right questions. Where exactly does the delegated authority model need to be more rigorous? Which workflows should remain deterministic rather than LLM-driven? How should the action layer connect to portals, payer APIs, and pharmacy workflows without requiring the whole healthcare system to become elegant first? What is the right first wedge? Specialty therapy access? Post-discharge care? Medication continuity? Which buyer gets enough ROI fast enough to fund act one?
Those are all much better questions than “can AI help healthcare?” The prototype narrows the conversation from general excitement to product reality, which is exactly what you want a concept vehicle to do.
If you want to build one, you should build one too
One reason I wanted to post this is that I suspect we are entering a moment where it is no longer enough to wave at a category and admire it. The fastest way to understand whether an idea is real is to build enough of it that the awkward parts show up. The Family Health Agent now feels much more real to me than it did a week ago, not because I have solved it, but because I forced the logic into software and watched what survived.
So if the thesis resonates with you, build one. Seriously. Build one badly. Build one narrowly. Build one for specialty therapy access. Build one for post-discharge follow-up. Build one for medication continuity. But build it around the Family Health Manager role. Do not make the old mistake of designing around the institution and then pretending the household will somehow sort itself out later.
The category, if it exists, will not be proven by beautiful prose alone. It will be proven by software that can manage a hard, messy, indispensable role better than the system currently allows any human to manage it.
And that, I think, is where this stops being a nice essay idea and starts becoming a real one.