The health agent that remembers

Most connected health products collect a great deal and use almost none of it.

A typical patient in one of these systems wears a ring, syncs a watch, uses a therapy device, logs how they feel, and reads articles in an app. That is five systems with no shared view of the person. The device knows about sessions. The wearable knows about sleep. The content library knows nothing about anybody. Support has a spreadsheet.

The obvious move is to put a language model in front of it. That produces two failures, and in health both are fatal. The first is amnesia: an assistant that starts every conversation from zero, asking a patient to re-explain their knee for the fourth time. The second is improvisation: an assistant that generates health advice out of model weights that nobody reviewed and nobody can audit.

So the system needs two properties that pull against each other. It has to remember a person accurately over months, which means retention. And it has to only say things a clinician approved, which means constrained generation. Nearly all of the interesting architecture sits in holding both at once.

Here is the shape that works, built from four layers: a wearable aggregation API for ingest, Google Cloud as the platform and boundary, Mastra as the reasoning layer, and Sanity as the knowledge layer.

Ingest: one integration instead of twelve

Building direct integrations with Oura, Garmin, Fitbit, Apple Health, Withings and the rest is a permanent tax. Each has its own auth model, its own schema, its own rate limits, and its own habit of changing them. It is real work and it is not your differentiator.

Terra sits in front of all of it. One API, normalised schemas across several hundred providers, and webhook delivery that pushes data to you when a user syncs rather than making you poll. It carries HIPAA and GDPR posture and SOC 2 Type II, which matters less for the certificate than for the data processing agreement you can actually put in front of a hospital procurement team.

The build versus buy call

Every engineering team we meet can build this. That is never the question. A competent developer will have an OAuth flow running against one wearable API in a week, and it will work.

The question is what the thing costs to keep alive for five years, and whether that cost buys you anything a customer will pay for.

The rule we apply, in health and everywhere else: if it is not your core business, buy it. Core means the thing customers choose you for and competitors cannot copy easily. Everything else is plumbing, and plumbing should be rented from someone who amortises its maintenance across hundreds of customers.

Build when the capability is the product, when you need behaviour no vendor offers, when vendor economics break at your scale, or when the dependency is genuinely existential. Buy when the domain shifts underneath you constantly, when the compliance paperwork comes bundled, and when parity with a commodity is the ceiling of your ambition.

Wearable ingestion fails every build test. A dozen providers, each with its own auth model, schema, rate limits and deprecation schedule, all changing independently and none of them coordinating with you. The best possible outcome of building it yourself is that your data pipeline works as well as one you could have bought. No patient has ever chosen a health product because it had a nicer Garmin connector.

The honest counterweight: buying is not free. You inherit the vendor's outages, their roadmap, their pricing changes, and their view of what a sleep stage is. So make the purchase reversible. Keep every raw payload, own your normalised schema rather than adopting theirs wholesale, and keep the vendor behind an interface you control. Do that and switching providers is one adapter rewritten over a fortnight, not a pipeline rebuilt over two quarters. The reversibility is the real deliverable of a build versus buy decision, more than the decision itself.

Three things to get right underneath it

Ingest is event sourced, not a write. Webhooks fire when the user syncs, not when the event happened. Data arrives late, out of order, and duplicated. Store the raw payload first, normalise second. When you inevitably change your normalisation logic in month seven, you replay instead of losing history.

Every metric is an observation with provenance. Source device, measurement time, sync time, and confidence. A sleep score from a ring and a sleep score inferred from phone accelerometer data are not the same fact, and the agent needs to know which one it is holding before it says anything confident about recovery.

Design for absence. Someone forgets to charge their ring for four days. The system must distinguish "no data" from "no activity." That single distinction prevents an entire category of embarrassing coaching, and it is surprisingly easy to skip.

Platform: making the boundary real

Google Cloud is doing unglamorous work here, and the unglamorous work is the point.

Region is pinned for data residency. Customer-managed encryption keys mean the keys sit under your control rather than the platform's. A VPC Service Controls perimeter means health data cannot be exported outside it even by a misconfigured service. Credentials live in Secret Manager. Every component runs under its own service account with least privilege, so a compromised ingestion worker cannot read the identity store.

Two decisions matter more than the rest.

Split identity from measurements. Names, emails, addresses and payment details live in one small, tightly scoped service. Measurements, sessions and agent memory live elsewhere, keyed by a pseudonymous ID. Analytics, dashboards and the agent's retrieval index all run against the pseudonymous side. Most of the system never learns who anyone is.

Have exactly one egress path to the model provider. Everything that leaves for inference goes through one gateway that enforces redaction, classifies the payload, applies the retention policy and writes the audit record. If you cannot point at the single file where that happens, you do not have a boundary, you have an intention.

Then build deletion as a feature rather than a support ticket. A GDPR erasure request across a pipeline like this touches raw webhook payloads, normalised tables, vector embeddings, agent memory, traces and logs. Build that cascade in the first month. Retrofitting it means hunting personal data through an embedding index you created ten months earlier, which is exactly as bad as it sounds.

Reasoning: what Mastra is for

Mastra is a TypeScript agent framework, which means the agent lives in the same repository, the same type system and the same deploy pipeline as the product. For a small team that alone is worth a lot. What it gives you beyond that is memory, tools, workflows, evaluations and tracing as primitives rather than as things you write yourself and get subtly wrong.

Tools are the security boundary. The agent never receives a database connection. It receives typed tools, and each tool takes the authenticated user's identifier from the execution context, never from the model's output. The model cannot request another patient's sleep data because the parameter does not exist. That is a small design decision with an outsized safety payoff, and it converts prompt injection from a data breach into a failed tool call.

Workflows carry anything with consequences. Mastra workflows suspend and resume, which is precisely the shape of human review. The agent drafts an adjusted plan, the workflow suspends, a clinician approves it from a queue, the workflow resumes and the message goes out. The agent handles the ninety percent of the relationship that is logistics, nudging and explanation. A human signs the part that is advice.

Trace everything, evaluate continuously. In consumer software you ship and watch the metrics. In health you need to answer "why did it say that" about one specific conversation from eight months ago. Every run records the retrieved context, the content versions used and the tool calls made. Scope adherence and refusal behaviour get their own eval suites, because guardrails that are not tested are decoration.

Guardrails on the way in and the way out

Tool scoping solves authorisation. It does nothing about what arrives in the message box, and in a health product the message box is open to anyone with an account and a bad idea.

Mastra handles this with input and output processors: a composable pipeline that runs before a message reaches the model and before a response reaches the user. The value of the pattern is that safety logic sits outside agent logic. Your prompts stay about coaching, and the security controls are separately testable units.

The built-ins that earn their place in a health build:

UnicodeNormalizer strips control characters and collapses whitespace. Deeply unglamorous, and it removes an entire class of obfuscation where instructions hide in invisible characters.

PromptInjectionDetector classifies injection, jailbreak and system-override attempts against a confidence threshold, then either blocks the message or rewrites it to neutralise the attack while keeping the legitimate intent. Rewrite is often the better strategy in a consumer health app, where a blocked message reads as the product being broken.

ModerationProcessor screens incoming messages for hate and harassment before the model is invoked.

PIIDetector runs on both input and output and can detect or redact personal data on the way through. Useful when free-text symptom notes carry names, addresses and other people's details into something you are about to embed and store for years.

SystemPromptScrubber on the output side, so the agent's instructions and its clinical rules never leak back to a curious user.

Four operational points matter more than the list itself.

Order is security, then safety, then privacy. Injection detection first, moderation second, PII redaction last. Redact first and you may destroy the exact text the injection detector needed to see.

A message blocked at the input stage never reaches the model, and nothing from it is written to memory. In a system carrying long-lived per-patient memory, that is the property that actually matters. A poisoned message that gets through is not one bad answer. It is a false belief the agent holds about a patient for the next nine months, quietly shaping every response.

These processors are LLM calls, so they cost latency on every turn. Use a small, fast classification model rather than your primary one, and run the independent block-only guardrails in parallel rather than in sequence. Guardrails that add three seconds to every reply get switched off by the third sprint.

Decide failure posture deliberately. Security fails closed: if the injection detector errors, block. Moderation is a policy choice, and health inverts the usual default. The messages most likely to trip a moderation filter are often the ones a human most needs to see, so route them to a person rather than silently dropping them.

Memory: what the agent is allowed to remember

This is the part that makes the thing feel like a coach rather than a search box, and it is where the privacy thinking has to be sharpest.

Mastra separates memory into layers, and the separation turns out to be clinically useful. Working memory is a compact structured record kept current across every conversation: goals, schedule, constraints, contraindications, current protocol, communication preferences, what the person has already tried and disliked. It is resource-scoped, so it follows the person across threads and devices instead of resetting each session. Semantic recall retrieves relevant past exchanges by meaning, so a comment in March about stairs bothering a left knee surfaces in September when the person asks about a training plan, without either party having to remember it. Observational memory compresses long history into a dense log so the context window stays small while the record stays long.

Three rules we would apply to any health build on top of that:

Keep three registers separate. What the person said, what a device measured, and what the agent inferred. Inference must never be silently promoted to fact. A memory entry reading "reports knee pain on stairs, self-reported, 12 March" is safe. An entry reading "has patellofemoral pain syndrome" is a diagnosis the system is not permitted to make, and once it is in memory the agent will treat it as ground truth forever.

Memory is visible and editable by the patient. They can open it, read the same text the agent reads, correct it and delete lines. Part of that is GDPR. The larger part is trust. Very little damages a health product faster than someone discovering the system has been quietly holding a wrong belief about their body.

Memory expires. Preferences persist. Symptoms do not. Anything clinical carries a review date, after which the agent asks rather than assumes. "You mentioned your knee back in March, is that still an issue?" is better product and safer behaviour than a nine month old assumption applied with total confidence.

Memory is personal health data and carries every rule that implies: inside the perimeter, encrypted, in the deletion cascade, out of the logs.

Knowledge: reviewed content, not improvisation

Sanity is where the actual health content lives, and this layer is the one teams most often skip.

An agent that generates health guidance from model weights is not shippable. An agent that retrieves from a library your clinical reviewers wrote and approved, then phrases it for this specific person's situation, is. The distinction is the entire product.

Model content as structured types rather than blobs. Protocol, condition, contraindication, exercise, escalation trigger, each with fields the agent can reason over. Then a contraindication check is a field lookup rather than a hope that the warning appears somewhere in the prose.

The editorial workflow becomes the clinical control. Draft, review, approve, publish is a governance gate you get for free from a CMS, and it maps exactly onto clinical sign-off. Only published documents are indexed for retrieval. A reviewer unpublishing a document removes it from the agent's mouth on the next sync, in minutes, without a deploy.

Version everything and cite it. Every agent response records the document IDs and versions behind it. A year later you can reconstruct precisely why the system said what it said, instead of shrugging at a model.

The rule underneath all of it: the agent decides what is relevant and how to phrase it. It does not decide what is true.

Using external sources without letting the internet write health advice

Coaching content goes stale. New research appears, guidelines get updated, seasons change, the product changes.

The loop that keeps content current without opening a hole: scheduled jobs pull from external sources, an agent drafts summaries with sources attached, those land as drafts in the CMS, a clinical reviewer approves or rejects, and only then do they become published, versioned, retrievable documents. External input reaches a patient only after a human has signed it.

Separately, the agent can read real-time context that is not advice: weather before suggesting an outdoor session, the person's calendar before proposing a schedule, local season, adherence over the last fortnight, whether a device firmware update changed something. Facts about the world and about the person, never claims about their health.

Clinical boundaries, which are a separate problem

Processors stop attacks. They do not stop a well-meaning agent from quietly practising medicine. That is a different control layer.

Scope is written into the system prompt and then verified by evals, because a guardrail that is not tested is a hope.

Red flag detection routes to a human immediately. Chest pain, neurological symptoms, anything acute. The agent's job there is to recognise, hand off fast, and say plainly that it is doing so.

No diagnosis, no prescription-only recommendations, no dosage changes, no interpretation of clinical test results.

And the regulatory posture is set by intended use, not by data source. A platform showing sleep quality for general wellness is not a medical device. A platform using the same data to guide a treatment decision may well be. Write the intended-use statement before writing the code, because it determines what class of system you are building and how much of the above is optional.

If you are starting this

Do the boundary work first. It is three weeks at the beginning and three months in the middle.

Aggregate wearable data through one provider. Twelve integrations is a maintenance program, not a feature.

Choose a runtime that gives you memory, tools and human-in-the-loop workflows as primitives, and keep it in the same language as your product.

Put your knowledge in a CMS with a review workflow before you have content worth reviewing. The workflow is the compliance story.

Ship the escalation path before you ship the coaching.

An agent that remembers accurately and stays inside approved content beats one that improvises brilliantly. Both look impressive in a demo. Only one is still running after a year of real patients.

Working on something like this

devspace places senior engineers and AI specialists directly into product teams building connected health systems. We do not run your delivery from the outside. Our people join your team, work in your stack, and leave you with something your engineers can own.

If you are building health infrastructure and want to compare notes on any of this, we are easy to reach.