Expanding the context window (and the team)

A few years ago at a Pomelo offsite, Dr. Isabelle Von Kohorn, our Chief Medical Officer, said something that stuck with me:

The goal is getting the relevant data, at the right time, surfaced to the right clinician, to enable the right intervention.

At the time, we had our foundational telehealth infrastructure in place: chat, visits, tasks, and documentation. But the pieces were disconnected and relied on either static automations or significant clinical time to get close to that goal. Now, we clearly see the path to achieving it sustainably.

The problem we kept running into

A pregnant patient texts at 11 p.m.: "I have a headache again, and my feet look puffy."

The on-call clinician can make the right call on what to do next. But only if they have the right context right now: gestational age, recent blood pressure trends, labs, risk factors, what was discussed at the last visit, and current interventions.

In most healthcare settings (including ours, back at the time of the offsite), that context is scattered. Clinicians do what the system forces them to do in order to get the information they need: chart review, note spelunking, inbox archaeology. Fifteen minutes pass before the full picture is assembled, instead of spending time actually caring for the patient.

Taking inspiration from LLMs, you could think of this as a “context” problem. And once you see it, you see it everywhere in healthcare.

From reactive to continuous

Most AI tools in healthcare today operate on a request-response model: you ask a question, and it gives an answer. It is a transactional, "stateless" interaction.

But patient care is inherently "stateful." A patient isn’t a collection of isolated queries; they are a continuous narrative. To support this, we are building a system that maintains a persistent, continuously up-to-date view of the patient. That context includes:

• Patient state: medical history, concerns, what’s important to them
• Task state: pending or complete clinical action items
• Protocol state: which protocols may be relevant based on patient history
• Narrative state: patient preferences and nuances from prior conversations with clinical staff, collected with appropriate consent and privacy safeguards

Instead of forcing a human to assemble context every time, the system does it by default. It then presents a clinician with relevant context and a draft summary for their review, which they can accept, modify, or override. 

Every patient interaction starts with a clear vision of what matters. 

What that looks like in practice

Today, when a patient reaches out, our system pulls signals from across the platform (history, recent labs, care plan state, outstanding follow-ups, risk factors, protocol applicability) and organizes them around the specific interaction.

The heterogeneous nature of this data poses many  interesting challenges. Each piece of context has different semantics, update frequencies, and reliability profiles: structured vitals alongside free-text notes, scheduled tasks alongside ad-hoc messages. Protocol applicability can hinge on many variables like gestational age, postpartum status, trends, and comorbidities, so the system evaluates these in real time and surfaces relevant protocols for clinician review, helping to reduce cognitive load on the clinician.

The goal is the smallest set of relevant data, framed for the task at hand. Then we turn context into recommendations: presenting potential next steps aligned with care pathways and organizing information by recency and clinical context.

The feedback from clinicians: it feels like having a colleague who already reviewed the chart, organized the relevant information, and prepared a starting point for their review.

So when that patient texts at 11 p.m. about headaches and puffy feet, the on-call clinician doesn't spend fifteen minutes assembling context. They open the conversation and immediately see: 32 weeks gestational age, elevated blood pressure noted in her last visit, hypertension noted in her history, and that she had headaches and swelling with her first pregnancy. As little as a few minutes from notification to informed clinical decision. The rest of the time goes where it should: actually helping the patient.

With persistent context, new capabilities unlock. The system can flag when a patient mentioning breastfeeding trouble may benefit from a lactation specialist, or when certain symptom patterns may warrant structured intake instead of chat. We're building toward a platform that helps clinicians route patients to appropriate care modality, not just the right information.

Why Pomelo

With our Series C, we're doubling down on what AI enables us to build: a fundamentally better way for our clinicians to deliver care. Our goal is to build AI native products that extend what our clinicians can do and deliver incredible longitudinal care. We also want to expand this intelligent, proactive care to encompass all of women’s health, including midlife.

We're in an unusual position to do this. Most companies attempting AI in healthcare are either a) building on top of someone else's EHR, limited by what that system exposes or b) starting from scratch, years away from the data density to validate anything.

We have an integrated stack we built from the ground up, an in-house clinical team using it every day, real patient interactions at scale, and the ability to ship validated changes into production clinical workflows within hours. When clinicians surface a gap during real care delivery, we can address it at the right layer and measure impact quickly.

Our engineers and clinicians are on the same team. Literally.

Come build with us

The problems we’re solving are genuinely hard, but the impact is immediate. You ship something, clinicians use it that day, and you hear directly whether it helped them better care for patients. That feedback loop changes how you think about building.

The people who thrive here care about both craft and context. You're sitting with the care team, understanding why a workflow breaks, then fixing it at the right layer. Sometimes that's the model, the data pipeline, or the web app. We own outcomes and problems, not just the code.

If you’re interested in this kind of ownership at scale, we’d love to talk.

‍

Explore careers at Pomelo