Query two years of WHOOP and blood-lab data
This is v2 of health-lakehouse-agent. Task: This is v2 of health-lakehouse-agent. In v1 I built a lakehouse on Databricks for two years of WHOOP biometrics and my blood-lab PDFs, then put a Genie agent on top of it. In v2 I replaced Genie with a small Claude agent querying the same tables, built a 30-question eval to measure both, and used the eval to test a claim I made in v1. The short version: the eval turned up two date bugs in my v1 gold table. Every agent got those questions wrong, Genie and Claude Opus included. Fixing the data took Claude Sonnet from 47% to 90% correct, and Genie from 47% to 67%. Sonnet on the fixed data beats Opus on the buggy data (53%) at about a quarter of the cost per question. Part 1: The Databricks build (v1) Part 2: Swapping Genie for Claude Part 3: The eval Part 4: What the eval found Part 5: Results Tradeoffs · Caveats · What I'd build next · Running it Part 1: The Databricks build (v1) Solving for a unified biometric and biomarker experience As a biometrics and biomarker tracker, I have been searching for a way to aggregate unstructured lab PDFs and 2+ years of biometrics data. Running experiments and viewing how my biometrics and biomarkers change is challenging when the data isn't stored in one place and when I'm flipping through multiple views of data (recovery scores, sleep, workout performance) on Whoop. To solve for this, I explored Databricks' Unity Catalog to store lab and biometrics data and found that the lakehouse architecture allowed me to easily upload 10,000+ rows of biometrics data across multiple years. I also used AI/BI dashboards to display all of my biometrics data across months. I used Agent Bricks to extract my lab data from unstructured PDFs, stored this structured data in Delta Lake, and built an agent with Genie that let me query for one experiment and view results across Whoop and my lab PDFs. With the agent, I can explore relationships between experiments and biomarker data. Uploading to Unity Catalog I requested an export of my Whoop biometrics data and uploaded it to Unity Catalog. Since a Unity Catalog volume is a governed folder managing underlying S3 data, I can read this data into notebooks, Genie Code, Lakeflow pipelines, and SQL queries. This flexibility let me create Delta Lake tables and eventually build the agent to query against different data formats. Whoop metrics as AI/BI dashboards with Genie Code With the help of Genie Code, I built bronze, silver, and gold tables of biometrics data. The bronze data gave me room to make errors down the line, since all of it is recoverable. Decisions about malformed data are made in the silver tables, and the gold data is shaped for consumption. With this one semantic layer, I built AI/BI dashboards. I was able to view my workout data side by side with my sleep and recovery data for the first time, and see how my Zone 2 workouts affected my recovery scores and sleep metrics across weeks and months. All three layers are Delta tables, so DESCRIBE HISTORY shows every operation that produced them, including every step Genie Code took on my behalf. Agent Bricks to extract unstructured data Since my bloodwork lived in unstructured PDFs in my email, I pointed Agent Bricks' Information Extraction Agent at the Unity Catalog volume holding them and described the fields I wanted: test name, result, unit, reference range, collection date. In the past I've had to preprocess data and use OCR or rely on vision multimodal LLMs, but I was surprised at the accuracy of the extraction. The Genie agent I built a Genie agent pointed at gold_daily_metrics, then taught it my vocabulary through its instructions: recovery means a 0–100 score, HRV is in milliseconds, lab results are sparse point-in-time events while wearable metrics are daily, and abnormal means a range flag rather than a numeric bound. At the end of v1 I wrote: Genie generates SQL against whatever tables I gave it, so its accuracy is a property of the semantic layer, not the model. Every time an answer was incorrect, the fix was one layer down, in the data or the instructions, never in the question I asked. I believed that, but I hadn't measured it. Genie manages its model and doesn't expose it, so I couldn't swap it out, see its SQL across a batch of questions, or score it. v2 is about measuring that claim. Part 2: Swapping Genie for Claude I kept the v1 Databricks tables exactly as they were and replaced only the agent.; tools: Claude. Human role: The original post does not say how a person stayed involved.; limitations: The evaluation relies on a small sample of 30 questions and one run per configuration, making minor score differences potentially noisy. The judge is a Claude model grading Claude outputs, introducing potential bias despite manual review. The prompt fix requires every query to correctly apply local-date logic, whereas the data fix resolves issues for all consumers. Source reliability is high for technical details but limited to a personal health tracking use case..
Tools
Published on Agent Work Atlas:
Overview
This is v2 of health-lakehouse-agent.
Workflow
This is v2 of health-lakehouse-agent. In v1 I built a lakehouse on Databricks for two years of WHOOP biometrics and my blood-lab PDFs, then put a Genie agent on top of it. In v2 I replaced Genie with a small Claude agent querying the same tables, built a 30-question eval to measure both, and used the eval to test a claim I made in v1. The short version: the eval turned up two date bugs in my v1 gold table. Every agent got those questions wrong, Genie and Claude Opus included. Fixing the data took Claude Sonnet from 47% to 90% correct, and Genie from 47% to 67%. Sonnet on the fixed data beats Opus on the buggy data (53%) at about a quarter of the cost per question. Part 1: The Databricks build (v1) Part 2: Swapping Genie for Claude Part 3: The eval Part 4: What the eval found Part 5: Results Tradeoffs · Caveats · What I'd build next · Running it Part 1: The Databricks build (v1) Solving for a unified biometric and biomarker experience As a biometrics and biomarker tracker, I have been searching for a way to aggregate unstructured lab PDFs and 2+ years of biometrics data. Running experiments and viewing how my biometrics and biomarkers change is challenging when the data isn't stored in one place and when I'm flipping through multiple views of data (recovery scores, sleep, workout performance) on Whoop. To solve for this, I explored Databricks' Unity Catalog to store lab and biometrics data and found that the lakehouse architecture allowed me to easily upload 10,000+ rows of biometrics data across multiple years. I also used AI/BI dashboards to display all of my biometrics data across months. I used Agent Bricks to extract my lab data from unstructured PDFs, stored this structured data in Delta Lake, and built an agent with Genie that let me query for one experiment and view results across Whoop and my lab PDFs. With the agent, I can explore relationships between experiments and biomarker data. Uploading to Unity Catalog I requested an export of my Whoop biometrics data and uploaded it to Unity Catalog. Since a Unity Catalog volume is a governed folder managing underlying S3 data, I can read this data into notebooks, Genie Code, Lakeflow pipelines, and SQL queries. This flexibility let me create Delta Lake tables and eventually build the agent to query against different data formats. Whoop metrics as AI/BI dashboards with Genie Code With the help of Genie Code, I built bronze, silver, and gold tables of biometrics data. The bronze data gave me room to make errors down the line, since all of it is recoverable. Decisions about malformed data are made in the silver tables, and the gold data is shaped for consumption. With this one semantic layer, I built AI/BI dashboards. I was able to view my workout data side by side with my sleep and recovery data for the first time, and see how my Zone 2 workouts affected my recovery scores and sleep metrics across weeks and months. All three layers are Delta tables, so DESCRIBE HISTORY shows every operation that produced them, including every step Genie Code took on my behalf. Agent Bricks to extract unstructured data Since my bloodwork lived in unstructured PDFs in my email, I pointed Agent Bricks' Information Extraction Agent at the Unity Catalog volume holding them and described the fields I wanted: test name, result, unit, reference range, collection date. In the past I've had to preprocess data and use OCR or rely on vision multimodal LLMs, but I was surprised at the accuracy of the extraction. The Genie agent I built a Genie agent pointed at gold_daily_metrics, then taught it my vocabulary through its instructions: recovery means a 0–100 score, HRV is in milliseconds, lab results are sparse point-in-time events while wearable metrics are daily, and abnormal means a range flag rather than a numeric bound. At the end of v1 I wrote: Genie generates SQL against whatever tables I gave it, so its accuracy is a property of the semantic layer, not the model. Every time an answer was incorrect, the fix was one layer down, in the data or the instructions, never in the question I asked. I believed that, but I hadn't measured it. Genie manages its model and doesn't expose it, so I couldn't swap it out, see its SQL across a batch of questions, or score it. v2 is about measuring that claim. Part 2: Swapping Genie for Claude I kept the v1 Databricks tables exactly as they were and replaced only the agent.
Reported result
Fixing the data improved Claude Sonnet's accuracy from 47% to 90% and Genie's from 47% to 67%. Sonnet on corrected data outperformed Opus on buggy data (53%) at approximately one-quarter the cost per question. The data fix proved more effective than prompt engineering, reducing latency by 25% and cost by 20% compared to the prompt-only fix. No specific business ROI was reported, only technical performance metrics.
Human role
The original post does not say how a person stayed involved.
Limitations
The evaluation relies on a small sample of 30 questions and one run per configuration, making minor score differences potentially noisy. The judge is a Claude model grading Claude outputs, introducing potential bias despite manual review. The prompt fix requires every query to correctly apply local-date logic, whereas the data fix resolves issues for all consumers. Source reliability is high for technical details but limited to a personal health tracking use case.
Try it
I need to replicate the health-lakehouse-agent v2 evaluation workflow. First, set up a Databricks environment with [replaceable: WHOOP biometrics CSVs] and [replaceable: blood-lab PDFs]. Use Agent Bricks to extract lab data into Delta Lake tables. Build a bronze-silver-gold data pipeline, ensuring the gold table handles timezone conversions correctly to avoid UTC/local date bugs. Create a 30-question eval set covering lookups, aggregations, and unanswerable queries. Implement a Claude agent using the Databricks MCP SQL server with read-only permissions. Run the eval against both the original and corrected data views. Compare accuracy, cost, and latency for Claude Sonnet and Genie. Before finalizing, manually verify 5 reference answers and review judge outputs for bias. Output a report detailing accuracy improvements from data fixes vs. prompt engineering. If data is missing, ask for specific file formats and timezone settings.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.