The line you draw before a voice agent answers

Arbol answers the phone at clinics. A patient calls, an agent picks up, understands what they need, and books it into the practice system that is already there. Same agent on WhatsApp, which is where a lot of patients would rather be anyway. It runs in twelve markets now, eight of them in Spanish.

The hardest decision in building it was not the voice pipeline, the latency budget, or the EHR integration. It was deciding what the agent does when someone describes a symptom.

The failure mode that matters

Every other failure in this product is recoverable. A misheard name gets corrected at the desk. A double-booked slot gets a phone call. A dropped call gets called back.

One failure is not recoverable, and it is this: someone calls, starts describing chest pain, and the agent — helpful, fluent, confident — engages with it.

It does not have to give bad advice. It only has to sound like the conversation is being handled. That is enough for someone to wait instead of going to an emergency room.

So the boundary is in the product, not the terms of service

Arbol does not do diagnosis and does not do triage. Not “is not intended for”, not “should not be relied upon for” — it does not do it. The agent recognises symptom description as a category and hands off. It does not soften, it does not summarise, it does not offer a maybe.

Writing that boundary into a disclaimer would have been much easier and would have protected the company just as well legally. It would not have protected the patient at all, because nobody calling a clinic in distress has read the terms of service.

An agent that answers a phone in healthcare has to be unambiguous about what it will not attempt. The honest description of Arbol is: it moves appointments, it does not practise medicine.

What that constraint bought

Refusing the clinical surface made everything else sharper.

The product is now front-office operations, entirely. Know who to call. Call them. Book the slot, confirm it, backfill the waitlist, recover the no-show. Then prove all of it happened, with the recording, the transcript and the outcome.

That last verb turned out to be the one that matters. Every market has a version of it: Colombia’s Modelo de Gestión de Tiempos de Espera, adopted in Resolución 2117 de 2025, makes waiting times a public quality indicator. The US has HIPAA and the FCC’s disclosure and consent rules for AI voice. The UK has the NHS. An automated system that cannot produce evidence of what it said to a patient is a liability in every one of them.

That is a well-bounded problem with a clear owner, a clear metric, and regulators who keep making it more unavoidable. It is a much better business than a vague “AI for health”.

The second decision: no migration

Arbol writes into the EHR the clinic already runs.

The tempting version of this product owns the calendar. Your own scheduling model, your own source of truth, clean data, no integration work. Every demo goes beautifully.

Then a real clinic tries it, and the front desk now has two calendars that disagree by lunchtime. Nobody wins that fight. The receptionist keeps using the system she has used for nine years, and your beautiful calendar becomes a stale mirror of it.

So: no migration, no parallel calendar, no “just export your data first”. Arbol books into what is already there. It is slower to build against every EHR one at a time, and it is the only version of this that survives contact with an actual front desk.

The pattern

Both decisions are the same decision made twice. The product is defined by what it hands back: the clinical conversation to a human, the source of truth to the system that already owns it.

A narrow tool that does one thing all the way through is more useful than a broad one that does several things up to the point where it gets uncomfortable.