The companies before Grata have an advantage we cannot acquire by hiring better engineers. They have treated more patients.
They have seen more ways for someone to disappear between asking for help and receiving it. Their clinicians have encountered situations ours have not. Somewhere in their procedures are precautions whose reasons took years to discover. Some of that knowledge has been published. Much of it belongs to people who work there.
They have also established things a new company can use. Patients will receive addiction care virtually. Clinicians can deliver it. Insurers will pay for it. In January 2025, Bicycle Health announced that it had reached operating profitability while growing revenue, after serving more than 40,000 patients since its founding. A company starting today owes something to the people who made those questions less uncertain.
Being late, by itself, is a considerable disadvantage. The interesting question is whether something has changed about the company it is possible to build.
A clinic pays to do its work. It also pays to change how its work is done.
The first cost is visible: recruiting, credentialing, scheduling, documentation, billing, coordination. More patients generate more of it. Software can absorb some of that growth, and agents can take on work that previously required a person to interpret a document or follow a sequence across several systems. A clinic should be able to treat more people without adding administrative staff at the same rate.
The second cost is harder to see. Someone notices that a procedure is causing trouble. They have to establish what happened, understand why the procedure exists, decide what should replace it, get the affected people and systems to change, and check whether the replacement helped. The cost includes every hour spent finding context, every other project displaced, and every consequence of changing something that was doing a useful job nobody remembered.
This cost determines how much of the clinic's experience it can afford to use.
Consider an intake question that repeatedly produces an answer the billing team has to clarify. Calling the patient takes a few minutes. Fixing the question may require changing the form, the clinical workflow that uses the answer, and the billing rules that interpret it. Keeping the calls can be a reasonable decision even when everyone agrees the question is badly designed. A small recurring expense survives because removing it is a project.
Now make the calls cheaper with an agent. The immediate economics improve. The case for fixing the question may get weaker.
That is an uncomfortable possibility for anyone expecting AI adoption to make organizations more intelligent. A company can become very efficient at accommodating its own mistakes. If the cost of correction stays high while the cost of coping falls, more of what is wrong becomes affordable to leave alone.
The opportunity I see is to lower the cost of correction too.
An agent can reconstruct the sequence that produced a denial, find the other cases with the same pattern, and trace the rule through the software that applied it. A coding agent can help implement and test a proposed change. People still have to decide whether the explanation holds and what evidence would establish that the change worked. But less of their attention has to go toward assembling the question and moving the answer into production.
This could change which improvements are worth attempting. A correction that would never have justified a project can become part of an ordinary week's work. Over time, the institution could retain more of what it learns in its questions, checks, defaults, and decisions. The next person benefits without having to discover the lesson again.
There is a condition: the things that need to change have to be within reach.
Until July, prescribing at Grata ran on a third-party EHR. When we wanted information from intake to change what a prescriber saw before a visit, and the visit to change what happened in follow-up, we ran into the boundaries of that product. We moved prescribing onto our own system, keeping DrFirst for electronic transmission. Three engineers now support the consumer app, clinic, recruiting pipeline, revenue cycle, and partner infrastructure.
The headcount tells us something about what a small team can now maintain. It does not establish that we make better decisions. What matters is that a discovery in one part of the company can lead us to change another part, including the activity that produces the evidence in the first place. We can ask a different question at intake because of what happens in a visit. We can change what supervision records because we want to know whether our interview selected the right clinician.
That is a more demanding ambition than putting all the records in one place. It asks the organization to revise its account of what is worth recording.
I have written about why these loops are difficult to combine after the fact. The difficulty also helps explain why the timing of a company's formation might matter.
An established company is deciding whether to replace a working arrangement. A new company is deciding what arrangement to make. Those are different investments, even when the people making them agree about the future.
The established company has people who know how to keep its current systems running. Their workarounds contain real knowledge. Replacing those systems means recovering that knowledge and preserving the business while the replacement is tested. The new company has less to migrate, but also less experience to keep it from making a foolish choice. One pays for continuity. The other pays for ignorance.
There is a useful precedent in Paul David's account of factory electrification. Individual electric motors made new factory layouts possible, with benefits extending beyond the cost of power. Existing factories still embodied useful investments in the old arrangement. Replacing them did not become economical merely because a better design could be imagined. New construction offered an opportunity to organize production differently from the beginning.
The analogy suggests an opportunity for a new clinic, but grants it no permanent exemption. Every system we build at Grata becomes something we rely on. Every successful workaround acquires a defender. Soon enough, we will have our own excellent reasons to leave things as they are.
We have already had to correct assumptions in software we had just written. In one prescribing integration, we learned that a missing pharmacy identifier could represent uncertainty we needed to preserve. The correction required the software to do less automatically and sometimes ask a person to choose. I describe it in the machinery of inheritance, because it is an example of knowledge becoming a constraint on future action. It is also a reminder of how quickly a new company can manufacture the assumptions it will later need to undo.
Starting later gives us some freedom in how we organize the work. We will spend that freedom as we grow. The only way it becomes a lasting advantage is if we use it to make the company easier to correct after it has become harder to change.
That means preserving the reason for a rule alongside the rule. It means making room for evidence that contradicts a successful process. It means checking whether a change improved what happens to patients, even when the software is behaving exactly as instructed. A procedure that once prevented a mistake must remain open to revision when circumstances change.
Older companies can do all of this. They can use the same agents and have more experience to examine. Their relationships and clinical knowledge may make them better at it. Our bet is that we can make investigation and revision part of the ordinary work of the company early enough that growth does not turn them into exceptional events.
If we succeed, access to the same model will not produce the same institution. A model working inside Grata would encounter questions we learned to ask, distinctions we learned to preserve, and instructions revised because of what happened when we followed the previous ones. That context has to be earned through operating a clinic. It becomes useful only when the next decision draws on it.
There is no shortcut through the clinical evidence. Faster software development cannot tell us today how a patient will be doing in six months. It can help us collect the right observations, find the relevant history, and act sooner once the evidence warrants a change. The time between an experience and a justified correction is where we hope to gain ground.
The test will be whether fewer patients encounter problems we have already understood. Whether a new state starts with procedures improved by the states before it. Whether a clinician can benefit from an observation made by a colleague she has never met. Falling administrative cost would be one result. So would knowing when an additional question or a slower decision is worth the expense.
The companies before us made it possible to start with fewer unanswered questions about virtual addiction care. We get to build with that evidence, and with tools that make more of the organization available for revision. That is the opportunity in starting now.
Eventually we will be an older company too.
The advantage worth building is one we can still have then.