The patient advocate
The most important part of a medical journey is seeing and feeling heard — and the system is not built to allow it. The doctor has forty-five minutes spread across you and a dozen other patients. You have a diagnosis you heard through a ringing in your ears, a prescription named in a language you don’t speak, lab results that arrive as a wall of acronyms, and a follow-up in six weeks. Sometimes neither you nor the doctor can synthesize the full story from the data and time available. And so every appointment starts to feel like an opportunity you cannot afford to waste.
That is why patient advocates exist. A human advocate is a second set of eyes and ears in the room — a second mind that recalls what was said three visits ago, connects the dots across scattered results, and goes home to research what the appointment left unexplained. Most people never get one. The question this post teaches: what does it take to build that second mind as an agent?
the anatomy of a second mind
Each of the advocate’s three duties maps to a specific piece of agent architecture:
Recall requires long-term memory. When
a session ends, the transcript is distilled into discrete tagged facts
([FACT] metoprolol 25mg twice daily), embedded as vectors, and stored
under the patient’s key; each new question pulls back the closest facts by
similarity. Nothing is re-asked. Connection falls out of accumulation:
a record that stacks can be read for trends — the prompt instructs the
agent that a creatinine of 1.4 means one thing alone and another as the
third rise in a row. Research is delegated to a subagent (MedScribe)
that fetches current, sourced clinical information — because dosing
claims from a model’s memory are guesses wearing lab coats.
the two jobs, worked through
The architecture serves exactly two patient-facing jobs. First, understanding your symptoms and diagnosis: told that a father was prescribed metoprolol after “a minor heart event,” the advocate explains what a beta-blocker does to his heart in plain speech, separates normal side effects (cold hands, mild fatigue) from emergency red flags (heart rate under 50, sudden swelling) — and leads with the one fact that can hurt him fastest: never stop the drug abruptly. Second, preparing for the follow-up: it drafts the exact questions Tuesday’s appointment deserves — what was the precise diagnosis? what is his ejection fraction? at what readings do we hold the dose and call? — so none of those forty-five shared minutes is wasted. Here it is in a cold-started session, from a real run:
The boundaries are load-bearing, written into the prompt as behavior:
- EMERGENCY OVERRIDE: if symptoms could indicate an emergency, the
FIRST sentence says push the call button / call 911.
- YOU PREPARE, THEY PRESCRIBE: never tell the user to start, stop, or
change a medication — hand them the exact question to bring to the
clinician who can.
- When the record is silent on something material, say so and ask —
never invent a remembered fact.A second mind points toward the doctor, never around them. Its output is a better conversation, not a competing opinion.
build it yourself
The complete system prompt — identity, memory doctrine, communication laws, research rules, safety boundaries, deployment notes — is yours: download the full prompt (markdown). It assumes only a persistent fact store, a search tool, and a date binding; the reference implementation runs on melchizedek’s long-term tier, and the repository link will be added here when it goes public. One non-negotiable: memory siloed per patient, deletable by the patient — a record this intimate belongs to the person it describes, or the agent shouldn’t exist.
Being heard, it turns out, has an architecture. It is someone who remembers what you said, connects what you couldn’t, and walks into the room already holding your questions. Most people never get that someone. Now you know how to build one.