Everyone who knows how to keep civilization running is going to die.
We have a replacement program, although the recruits initially cannot hold up their own heads. They require years of supervision before we trust them with scissors. A few decades later, some of them will be performing heart surgery.
Somehow, civilization survives this arrangement. Often it even improves. People who were not alive when a discovery was made can begin their working lives knowing it. A doctor gets to start on the other side of mistakes that took centuries to understand.
We are so accustomed to this that we locate the achievement in the doctor. And becoming a doctor is an achievement. But put the same person in a world without textbooks, laboratories, instruments, or trained colleagues, and much of what we call their capability disappears. Intelligence is partly something we inherit from the world we enter.
That inheritance is more peculiar than a collection of facts. You can benefit from a discovery without remembering who made it or understanding the work that established it. Someone else's hard-won judgment has become the ordinary way you do things. What was once an insight now looks like equipment.
Unfortunately, mistakes travel by the same route.
A procedure can outlive the problem it was designed to solve. A distinction someone made under pressure can become a required field. People can spend years getting better at following a rule whose author would have changed it if they had seen what happened next.
Software gives this kind of inheritance extraordinary reach. It can arrange for a decision made years ago to be carried out thousands of times a day by people who never knew there had been a decision. We encounter it as the way the system works.
At Grata, the healthcare company I'm building, software carries much of the work. Three cases.
In the last two weeks of June, our recruiting system processed 117 applications from clinicians. It found clinicians in public provider data, sent each a personalized invitation, interviewed them, and scored their answers. During the rollout our team read every application alongside it and told it where it was wrong. By the end of August it had run 327 interviews and we had extended 109 offers.
It got very good at predicting whom we would hire.
Whom we should have hired is a different question, and nothing in the recruiting system can answer it. Answering it means following a clinician out of the interview and into the clinic: how she prescribes, how her patients do, what she did as distinct from what her patients brought with them. Then back to the interview, to ask which of the things we scored deserved their weight, and which questions we never asked.
We cannot do this yet. Most of the 49 clinicians we onboarded in July spent August in payer credentialing, which takes about two months. The evidence that would judge our interview is only starting to exist, and it will exist in supervision notes, in retention, in whether people come back for their second month of medication. None of that lives in the recruiting software. A model trained on our hiring decisions makes us more consistent with ourselves. Finding out whether we were right requires a clinic.
With claims, we get feedback sooner.
Our software now submits every initial claim without a person touching it. In August we collected 89.7 cents on the dollar. Some denials trace back to an eligibility check that missed a plan change, or a visit that needed an authorization nobody requested. The obvious thing to do with a denial is fix it and resubmit. We do. An agent is very good at this, and it is a large part of how we expect to pass 95 percent by October.
But look at what "fix and resubmit" leaves in place. The intake form that failed to ask the question is still the same form. Next month a different patient walks through it, the same denial comes back, and we rescue it again, faster and more cheaply than a person could. More work gets done. The mistake stays available for another round of excellent execution. If a denial changes what intake asks, the clinic has learned. If we only resubmit faster, the original mistake remains.
The October test is whether the same preventable denials recur less often.
Sometimes the booking funnel has something to tell the recruiting team.
1,618 people have completed a clinical intake asking Grata for insurance-reimbursed care in a state where we have no clinicians and no payer contracts. To the booking funnel, each is a failed conversion. To the people deciding where to recruit and which payers to call, they are the best map we have. They are why we spent August recruiting in Maryland, Colorado, and Washington rather than wherever a market study would have sent us. The same event is a failure in one part of the company and a plan in another. What differs is how far we let it travel.
Three cases, one shape. Software does a well-defined job: hire the clinician, collect the claim, book the appointment. The lesson has to reach the part of the company that can use it to change the work. It is possible to file every event correctly and still lose the lesson.
The usual story of progress runs from systems of record to systems of intelligence to systems of action, and action sounds like the destination. But acting is also how we discover where our understanding fails. If what happens afterward cannot change what we ask, record, and try next, we have built a very capable successor to our earlier assumptions.
This is the difficulty with buying healthcare software. With our prescribing software, we had to work within the changes our vendor supported. The recruiting tool ends at the offer. The billing tool ends at the remittance. The electronic health record, or EHR, ends at the signed note. Questions that cross those boundaries have to live somewhere, and in most clinics they live in people. Someone remembers what a clinician said in her interview when her charts start looking thin. Someone notices that the intakes arriving through a recovery app should change the plan for the next state. We call these people experienced, and they are. We also make the company depend on their remembering.
The tempting fix is to connect the software: put the records in one place, give an agent access to all of them, and let it find the relationships. For some questions that is enough, and we take those wins. But before any model can tell us which interview signals mattered, someone has to have written down how the clinician actually practiced, in enough detail to be useful a year later. If supervision notes say "doing well," there is nothing to retrieve. No system can recover an observation nobody made.
So answering a new question usually means changing the activity that produces the records. Ask something different in the next interview. Capture something different in supervision. Add a question to intake because a payer taught us to. We needed our software to let us make those changes.
We learned this the slow way. Until July, prescribing at Grata ran on a third-party EHR. It handled our existing prescribing workflow. When we wanted intake to change what the prescriber saw before the visit, there was no way to express it. When we wanted follow-up to depend on what happened during the visit, the visit ended at the signed note. We ended the contract and moved prescribing onto our own system, keeping DrFirst for the electronic transmission itself. Three engineers now run the consumer app, the clinic, the recruiting pipeline, the revenue cycle, and the partner infrastructure on one codebase.
That is the deeper reason we build so much ourselves, and it has little to do with cost. An intake, a schedule, and a clinical record decide what becomes visible, what can be attempted, and whether a discovery can change what happens next. We build while our understanding is still forming, because working on the tool is how we find out what the work should be.
A clinic on purchased software can outlearn one that wrote every line. Building gives us more freedom to preserve context, test our explanations, and change the work.
There is an uncomfortable consequence of this argument for a founder who likes building software. Our code carries an account of the world too. It encodes which questions we thought deserved answers, which outcomes we decided to count, and what we chose to ignore. Writing it ourselves gives those judgments excellent distribution. A mature vendor's product contains the accumulated experience of hundreds of practices, including the seemingly unnecessary step that turned out to prevent a mistake. Three engineers replacing it should expect to rediscover some of those reasons the hard way.
We did, within a month.
Our prescribing integration needs a seven-digit identifier for the destination pharmacy. A patient could select a real pharmacy by name and address while that identifier remained unknown to us. The place existed. The patient wanted it. Our record had a blank.
On August 5 we added a way to fill it. If exactly one pharmacy in our local directory matched the street, city, state, and ZIP code, the software attached its identifier to the selected location. An exact match, and only one of them. This sounds cautious.
But there was only one match in our directory. Two pharmacies can share an address, and the rule let a single coded entry lend its identifier to a different pharmacy without checking whether the name or phone number agreed. The number would be valid. The prescription would pass every technical check and transmit successfully. Success would not establish that it had gone where the patient intended.
The next day we added a second requirement: the name or phone had to corroborate the address. Without that evidence we kept the identifier and marked the result as unsuitable for prescribing.
Later that day, code review found that this correction did not do what it appeared to do. Another part of the software treated the presence of the number as permission to send the prescription. It never checked the warning. We had changed a flag. The rest of the system still acted on the number.
The final correction withheld an uncorroborated identifier altogether. A patient can still select the location, and when we cannot establish the routing identity, the prescriber chooses the destination in DrFirst. We added tests at the point where the earlier correction had failed. Code review caught the defect; we have no case of a prescription reaching the wrong pharmacy.
That correction accepted a cost. Some legitimate matches no longer resolve automatically, and a person sometimes makes a selection the software could have guessed correctly.
An empty field had looked like unfinished work. It turned out to be how the system represented what it did not know. The distinction we recovered is between retaining the place a patient selected and possessing enough evidence to route a prescription there. Those are different states of knowledge, and collapsing them made an uncertain match behave like an established fact. The rule, its reason, and a test of the failure it addresses now live in the code. The next engineer who sees a blank identifier can tell that it may be blank on purpose.
Medicine has always tried to carry knowledge beyond the person who first acquired it, through research, training, supervision, and protocol. The hard part is the return trip: investigate the observation, decide what it warrants, change the procedure or the software, check whether the change helped. Each step costs someone's attention, and attention is what a clinic runs out of first.
Agents lower that cost. One can trace what happened to the claim, or the patient, or the identifier, and assemble in minutes the context a person would spend an afternoon reconstructing. The pharmacy defect became visible only when review followed the meaning of a number from the place we inferred it to the place it authorized an action, and that is exactly the kind of tracing we can now ask for repeatedly. A coding agent can implement a correction once someone has decided what it should be. People still judge whether the explanation holds. Less of their attention goes to the path between discovery and change.
But the assignment matters more than the capability. An agent told to complete every pharmacy record would have shown its progress by reducing the number of blanks. Our discovery required us to accept some blanks. An agent can get better at the assigned job while destroying the evidence that the assignment is wrong. Experience has to be able to change the instructions under which the next agent works, and that requires the instructions to live somewhere we can revise.
Owning the systems lets us change the work. It lets a denial change intake, so that someone who joins next year benefits without learning why. It lets supervision change the interview. It lets a blank identifier stay blank, so the next prescriber gets a deliberate choice instead of a confident guess. The same agents that reconstruct missing context can make forgetting affordable: the same rescue tomorrow, at lower cost, indefinitely, if nothing upstream is allowed to move.
The advantage is accumulated judgment: a company that has revised its own procedures a few hundred times in response to what happened, and whose software asks, checks, and refuses different things than it did a year earlier. Even a model every competitor can call would perform better inside such a company. Anyone who finds evidence that our process is wrong needs a way to get it examined and changed, and evidence that complicates a convenient story deserves the same scrutiny as evidence that supports one. A rule must stay revisable after it becomes code, especially when revising it would mean admitting we built the wrong thing.
For patients, the payoff is inheriting more experience than the people in a single encounter could hold in their heads. A clinician's careful observation becomes useful to a clinician she will never meet. An obstacle understood in one part of the company stops surprising another. Someone asking for help meets an organization better prepared because of the people who asked before them.
Everyone at Grata is also going to die. Most will leave first. The engineer who caught the pharmacy defect will not be the one who meets the next one, and the clinician whose observation changes the interview may never learn that it did. Whatever we know about routing a prescription, reading a denial, or choosing a clinician has to survive our forgetting it. A company is a small civilization running the same replacement program, and ours is betting on the same thing: that the machinery can hold what the people learned, and that owning it gives the learning somewhere to go.
The next patient should inherit everything the last patient taught us.