Discovering and Delivering an AI Agent for a Healthcare Workflow

The Client: The Longevity Practice

The Longevity Practice is a private preventive medicine practice based in Berlin, Germany, specialized in 360° preventive medicine, hormonal health, and metabolic, cardiovascular, and sleep optimization.

The practice delivers evidence-based, Doctor-led care built on a simple premise: patients should be able to measure their health and walk away with a clear, personalized plan for what to do next, rather than wait for the healthcare system to treat disease once it appears. Its model pairs early, precise diagnostics (20+ screenings for early risk detection) with in-depth consultations and a sustainable coaching approach.

‍

The Product Problem: A High-Trust Workflow Was Being Slowed Down by Manual Production

Every patient journey at The Longevity Practice ends in a personalized health report. It is the deliverable the 360° Longevity Check builds toward, and the Doctor presents it to the patient in the follow-up consultation.

Creating the report took 3 to 4 hours per patient. Much of that time was not clinical judgment; it was production work: moving AI-generated content into a PowerPoint template, checking every value against the labs, and making sure the final report was polished enough for a patient consultation. In one early conversation, the Doctor described working until midnight because three reports had to go out that day.

The product opportunity was not simply to make report creation faster. In a medical context, speed only matters if the Doctor can still trust the output. Product People was brought in as AI and agents consultants to help automate the workflow end to end: from raw patient diagnostics to a patient-ready deck, while protecting the clinical accuracy the practice’s reputation rests on.

🖋️ In a medical practice, AI implementation must satisfy GDPR's strictest tier: health data is a "special category" under Article 9 and requires a lawful basis for processing under Article 6. Every design decision in this mission was made with that constraint in place.

‍

Discovery: Understanding the Workflow Before Choosing the Automation Point

Product People was already onboarded on this client from a previous mission, so we moved straight into discovery with the Doctor. In a working session, she walked us through the report workflow end to end: how she uses Gemini, what the final report looks like, and where the hours actually went.

The workflow had three main stages:

1. Diagnostics and source material: Each patient begins with the 360° Longevity Check: a ~5-hour assessment spanning 20+ screenings across multiple diagnostic devices, including comprehensive blood and biomarker panels, VO2max and functional fitness testing, imaging, cognitive screening, and in-depth health-history questionnaires.‍
2. AI-assisted drafting: To preserve patient data anonymity, screenshots of the patient data are taken, along with any relevant patient history, and put into a Gemini chat. A specific prompt curated by the Doctor generates the report in a predefined structure: a fixed seven-health-risk framework with an executive summary, per-risk biomarkers and interventions, then lifestyle guidance and a phased action plan. The Doctor manually adds details not in the screenshots, such as the patient's gender and age.‍
3. Manual production and validation: The Doctor converses with Gemini over several iterations to make the report patient-ready, then moves the content by hand into a predefined PowerPoint template, appends the identified test results (labs, EKG) as a separate section so identifiable data stays out of the AI-generated content, and exports the final deck as a PDF for the follow-up consultation.

💡 The Longevity Practice uses an EU-hosted, enterprise-grade Gemini subscription so that patient and practice data is stored and processed entirely within the EU under a signed Data Processing Agreement, and is never used to train Google's models. This is the tier required to handle health data under GDPR; consumer Gemini plans don't provide these guarantees.

💡 Why PowerPoint, not Google Slides: we deliver the report as a PowerPoint file rather than Google Slides so the patient's data is never stored in the cloud. The report can be transferred directly to the patient's device or printed if they wish.

‍

Discovery surfaced three product risks:

1. The workflow was too time-consuming: Each report took 3 to 4 hours, and most of that time was spent on mechanical transfer, formatting, and checking.‍
2. Manual error risk was too high: Copy-pasting medical content by hand is error-prone. In a medical context, an error carries a high cost, so the Doctor compensated by double- and triple-checking everything.‍
3. The AI output was not reliably controllable: Gemini did not always follow the prompt instructions over time, and sometimes changed the report structure. There was also a low but real risk of data hallucination, with serious downstream consequences: wrong findings and wrong recommendations. The only validation was the Doctor eyeballing the report against the labs, and her only lever for improvement was adjusting the prompt.

The riskiest assumption was clear: if an AI reads patient labs from screenshots, every extracted value has to be right. Everything downstream, including findings, recommendations, and action plans, depends on those values. That is where we invested first.

‍

Product Decisions

Product Decision 1: Own the Workflow End to End Instead of Automating Only Formatting

Problem

The most visible pain was the time spent moving content into PowerPoint, but automating only that step would have made a possibly flawed report prettier. The underlying product risk was bigger: hallucination, drift from instructions, and lack of reliable validation during generation.

Decision

We moved from a Gemini-assisted manual workflow to an end-to-end Claude pipeline. The goal was to make the workflow measurable and controllable, not just faster.

The pipeline was broken into discrete steps, each with clear inputs and outputs:

1. Patient creation: Sets up a new patient in a fixed structure so the Doctor provides inputs in the right format, and can add extra context like family history that the labs would not capture.‍
2. Data extraction: Pulls everything from screenshots and notes into one consolidated file for the next steps, so the model is not holding raw images in context and losing fidelity.‍
3. Report generation: Builds the markdown report from extracted inputs, lab references, and clinical rules. Claude writes each section to fixed-length limits so nothing overflows or breaks the slides.‍
4. PowerPoint generation: Converts the markdown into a faithful deck.

Privacy stayed by design throughout: anonymized screenshot inputs, patient names never entering the AI artifacts, and local, GDPR-safe processing so identifiable patient data never reaches the model or the generated report.

Product Decision 2: Treat Trust as a Product Requirement, Not a QA Afterthought

Problem

In a medical report, a hallucinated value can create serious downstream risk. The existing safety net was the Doctor manually checking the entire report. If the system was going to save time, it had to catch errors before the Doctor reviewed the output.

Decision

We wrapped generation in automated evals that check:

• every cited data point traces back to the extracted source
• clinical rules were followed
• writing rules were followed, including the shape and length needed to fit the slides
• nothing was changed or hallucinated when the markdown became a deck

A final eval confirms the PowerPoint faithfully reflects the markdown report. The pipeline also surfaces critical open questions for the Doctor to tighten the diagnosis and next steps.

We deliberately chose not to use AI for safety-critical grading. Every safety-critical eval is a deterministic Python check rather than one model grading another:

1. Using AI to grade AI means the evaluator shares the same failure modes as the thing it is checking, so it can hallucinate too. A deterministic check that a value appears verbatim in the source cannot hallucinate.
2. The checks add no token cost or latency to a run.
3. We reserve LLM-as-judge only for subjective qualities like tone.

Product Decision 3: Turn Expert Feedback into Durable System Rules

Problem

In the previous Gemini workflow, the system had no durable way to improve from the Doctor's feedback. Her only lever was adjusting the prompt, and the same issues could keep coming back.

Decision

We worked in short loops. We shared real PowerPoint outputs with the Doctor, and her feedback drove the build.

Some feedback was visual, focused on the deck. Much of it was clinical and editorial judgment: what the focus section of a health risk should cover versus what belongs in the explanation section, and which biomarkers are relevant enough to appear for a given risk.

Each piece of feedback was encoded as a rule the pipeline enforces and checks on every run, so a fixed issue stays fixed.

We then made this self-serve. The Doctor can update the lab reference values and clinical rules herself, and those changes propagate everywhere they are used across the pipeline. It is built so an update cannot silently break a downstream check and give false confidence.

Product Decision 4: Keep the System Fast and Sustainable Enough to Use

Problem

As the pipeline matured, some steps were slow. A tool the Doctor has to wait on loses the time it is meant to save, and runaway token usage would make it unsustainable to run per patient.

Decision

We instrumented every step to track token cost and runtime, debugged the bottlenecks, and right-sized the model per step:

• Haiku for light tasks like patient setup
• Sonnet for heavy clinical work like extraction and drafting
• Deterministic code where no model was needed, such as building the deck

The result runs reliably within the Doctor's real-world tolerance and clear of usage limits, without compromising clinical quality.

‍

Scope Decisions: What We Deliberately Did Not Build

Two scope decisions mattered as much as what we shipped.

1. We did not redesign the report format

The PowerPoint report was already in active use with patients. Rethinking how results are presented would have been a much bigger discussion involving patient comprehension and the clinical framing of the consultation.

That was not where the immediate pain was. We kept the format patients already knew and automated the path to it.

2. We did not build a self-learning system

We considered a system that adjusts itself from the Doctor's feedback and decided against it for a medical product.

Instead, the Doctor updates the lab reference values and clinical rules directly, and the pipeline enforces them deterministically on every run. She gets control and predictability; a self-tuning system would have given her neither.

‍

Additional Product Decisions

Backup route for existing Gemini reports

If a report already exists in Gemini, the pipeline can still consume it and produce the PowerPoint. It does not carry the same evals and quality guarantees as the full pipeline, but it covers that case without extra work for the Doctor.

Zero-touch distribution

We built on the surface the Doctor already uses, Claude CoWork, and packaged the solution as a plugin distributed through a private marketplace. Improvements and fixes reach her automatically, versioned and with safe rollback, all managed by us with zero involvement from her.

‍

PM Takeaways

• The highest-value automation point was not the most visible pain point. Formatting was painful, but the bigger product risk was trust in the generated medical content.
• Trust had to be designed into the workflow. For this use case, accuracy and traceability were not quality improvements; they were requirements for adoption.
• Expert feedback became product infrastructure. The Doctor's clinical and editorial feedback was not just applied once; it was turned into reusable rules and checks.
• Scope control protected adoption. We kept the existing PowerPoint format, avoided a self-learning system, and focused on the workflow changes that solved the immediate pain without taking control away from the Doctor.

‍

Outcomes

We achieved the following in 1 month:

💡 25-33% faster personalized medical report creation per patient. It now takes 1 hour less per report; the clinic saves ~1 week each quarter and ~1 month per year of the Doctor's time. The number comes from the Doctor herself, who runs the pipeline on her own patients and reported the savings after using it in practice.

💡 Zero data extraction errors; every data point traced back to its sources, enforced by evals.

💡 Professional-looking report: zero layout failures; no text overflow or broken shapes, enforced by evals.

💡 The reclaimed time goes back into the practice. The hours the Doctor used to spend copy-pasting and cross-checking now go into working with more patients. Report preparation is back to being a clinical task instead of a production task.

Note that this was possible because Product People was already onboarded on this client from a previous mission, and because of the small size of the private practice chain. In a normal scenario, we'd need 3 months at a minimum.