Visit

Visit has been running for close to a decade. That is long enough to accumulate two things at once: years of real patient message history that is genuinely valuable, and a large surface of features that were built for a workflow nobody follows any more.

The instinct with a system this old is to rewrite it. The instinct is usually wrong, because the parts that look like cruft are often the parts holding up an edge case somebody depends on.

I start by separating what is used from what is merely present. Not what the documentation claims, and not what the feature list says — what actually gets touched. That question has an empirical answer, and it is worth getting before writing any new code.

Then the rule is simple: keep what matters, drop what does not. Years of patient message history matters and migrates. A settings screen nobody has opened does not.

The new version is AI-first rather than AI-assisted. An AI concierge handles the conversation, and a human can take it over at any point. The takeover path is the hard part and the part that has to be right: the handoff has to preserve full context, and the patient should not have to repeat themselves because the system changed who was answering.

Bolting a model onto an existing messaging product gets you a suggestion box. Designing for it from the start changes what the system is: the default responder is the model, escalation to a person is a first-class state, and the interface a staff member uses is built for supervising conversations rather than typing all of them.

That is a different product, and it was not reachable by adding a feature to the old one.