Healthcare agents with patient context

Patient context is some of the most consequential and most scattered information there is. A patient's medication history sits in one system, their past interactions in another, their stated preferences perhaps nowhere durable at all. An agent meant to help with patient care inherits that fragmentation, and on top of it forgets everything between sessions, so it greets a returning patient as a stranger.

The model can reason about clinical context perfectly well when it has the context in front of it. The difficulty is holding that context per patient, keeping it current, keeping it strictly separated from every other patient, and being able to account for what the agent knew and when. This page is about the infrastructure that makes a healthcare agent traceable, isolated, and able to remember.

A note on scope before going further: this page is about the data infrastructure underneath a healthcare agent, not about clinical decision-making, regulatory clearance, or what any given deployment must do to meet its obligations. Those depend on your jurisdiction, your use case, and your own compliance review.

The problem

A patient's relevant history rarely lives in one place. It's spread across record systems, prior conversations, intake forms, and clinicians' notes. An agent without persistent memory adds to the fragmentation rather than resolving it, because each session starts cold and whatever it learned last time is gone. The patient ends up repeating their medication list, their history, their preferences, to the thing that's supposed to already know them.

Trying to hold it all in the prompt has the usual ceiling. A patient with any real history produces more context than a context window can carry, so something gets dropped, and dropping clinical context at random is not acceptable. Storing raw conversation logs gives persistence without the understanding that matters here: an agent needs to know that a medication was discontinued, not merely that it was once mentioned alongside a later contradiction. Keeping the picture current as medications change and conditions evolve is precisely the entity resolution problem, and getting it wrong is memory drift with real stakes.

Two constraints sit above all of this in a healthcare setting. One patient's data must never leak into another's, so isolation can't be a convention you hope holds; it has to be structural. And you need to be able to reconstruct what the agent knew and when, because "why did the agent say that" is a question that will be asked and must be answerable.

What Exabase unlocks

With per-patient memory, structural isolation, and an audit trail underneath, the agent becomes something you can actually account for.

A returning patient is recognised. The agent holds their medication history, their past interactions, the preferences they've stated, scoped entirely to them. It doesn't ask them to recite their medications again, and it doesn't confuse them with anyone else, because their context lives in an environment that contains only their data.

When something changes, the picture updates rather than accumulating contradictions. A discontinued medication is treated as discontinued, a resolved condition as resolved, so the agent reasons from the patient's current state rather than an average of everything ever recorded. That accuracy is the whole game when the subject is care.

And every memory carries a timestamped history of when it was created and modified, so the question of what the agent knew at the moment it acted has an answer you can point to rather than guess at. The compliance and audit trails use case covers that accountability layer in more depth.

How it works

Three primitives carry a healthcare agent, with Bases doing unusually heavy lifting because isolation matters so much here.

Bases

A Base is a fully isolated environment with its own memory, storage, and search index. For a healthcare agent you create one Base per patient, so each patient's data lives in a sealed space that contains nothing else. Isolation is structural rather than a filter you remember to apply: a memory operation scoped to a patient's Base can only ever see that patient's memories. You get this from a single API call instead of building and auditing your own partitioning scheme, which removes an entire category of cross-contamination risk. Exabase encrypts data at rest using AES-256, and the per-Base boundary is the mechanism that keeps one patient's information from ever surfacing in another's session.

Memory

Exabase Memory, scoped to each patient's Base, holds the durable picture: medication history, past interactions, stated preferences, relevant history. You send in the interactions and Exabase extracts what's worth keeping. The contradiction handling is what makes it safe to rely on, since a changed medication supersedes the prior one rather than sitting beside it. Every memory is timestamped on creation and modification, which is what turns the memory store into something auditable rather than merely persistent. This is the distinction a memory layer draws that a log of past chats cannot.

Resources

Resources, also scoped per patient, hold the documents: intake forms, prior notes, uploaded records, anything written that belongs to that patient. Stored as Resources they're indexed for Deep Search, so the agent can find the relevant passage in a patient's own documents by meaning rather than by keyword. If those documents arrive as PDFs or scans, Extract turns them into clean, searchable text first.

Example architecture

The structure is simple, which in a setting like this is a feature in itself.

One Base per patient. Hold the Base ID against the patient record. Every operation for that patient, memory and documents alike, is scoped to their Base and can touch nothing outside it.

As interactions happen, send them to Memory within that patient's Base for extraction, and store their documents as Resources in the same Base. Documents arriving as PDFs or scans go through Extract first.

On each session, the agent retrieves memory scoped to that patient for their current context, and runs a Deep Search across their documents when it needs something specific. Both are confined to the patient's Base.

Each patient's data flows into and out of their own sealed Base. There is no shared pool where one patient's context could surface in another's session, and every memory carries the timestamps that make the agent's knowledge auditable after the fact.

What compounds over time

The longer an agent works with a patient, the more complete and current its picture of them becomes, and because the memory self-organises, that accumulation stays accurate rather than turning into a tangle of stale and contradictory notes. A patient the agent has seen across many interactions is one it understands in context, not one it has to reassemble from scattered records each time.

The accountability compounds too. Because every memory is timestamped from the moment it's created, the audit trail builds itself as the agent works, rather than being something you bolt on afterwards and hope is complete. Reliable, current context also reduces the chance of the agent acting on outdated information, the failure mode that matters most in care, and that reliability improves as the memory matures rather than degrading the way a manually maintained record tends to.

Who's building this

Teams building patient-facing assistants, care-coordination tools, intake and triage agents, and clinical support tools, anywhere an agent handles individual patients' context and must keep it isolated, current, and accountable.

Because the isolation pattern here is the same one that underpins any per-tenant system, the multi-tenant SaaS use case is worth reading alongside this for the general shape, and the compliance and audit trails use case covers the accountability side.

Get started

Start with the getting started guide, then about Bases and creating Bases to see how per-patient isolation is set up. Memory scoping shows how memory is confined to a Base, and there's a free tier to build against. As with any healthcare deployment, run your own compliance and regulatory review before going to production.

FAQs

How is one patient's data kept separate from another's?

Through Bases. Each patient gets a fully isolated environment, and any memory or search operation scoped to a patient's Base can only see that Base's data. The separation is structural rather than a filter applied at query time, which removes the main route by which cross-contamination happens.

Can I reconstruct what the agent knew at a given point?

Yes. Every memory carries creation and modification timestamps, so you can determine what context the agent held when it acted. The compliance and audit trails use case covers this accountability layer in more detail.

How does it handle a discontinued medication or a resolved condition?

The change supersedes the prior state through entity resolution. A discontinued medication is treated as discontinued rather than coexisting with the earlier record, so the agent reasons from the patient's current state.

Is patient data encrypted?

Data is encrypted at rest using AES-256. Beyond encryption and the per-Base isolation described above, the specific controls your deployment needs depend on your jurisdiction and use case, which is a matter for your own compliance review.

Can the agent read uploaded records and intake forms?

Yes. Store them as Resources in the patient's Base and they're indexed for Deep Search. If they arrive as PDFs or scans, Extract converts them into searchable text first.

Does Exabase make clinical decisions or give medical advice?

No. Exabase is data infrastructure: memory, isolation, storage, and search. What the agent does with that context, and whether a given use is clinically and legally appropriate, is determined by you and your compliance review, not by Exabase.