Fold glucose, restaurant spending and delivery orders into one morning digest: let the agent tell you which meals moved your blood sugar
AvidanX (Twitter) · 2026-09-15
Read original@alexandr_wang @benparr Muse connects to apple health and watches my blood glucose, then uses plaid to view my restaurant purchases, reads my email to see my DoorDash orders, gives me a morning digest on what meals created movement in my blood sugar and makes recommendations for the day ahead
Business model
The author has Muse connect to three of his own data sources: blood glucose from Apple Health, restaurant purchases seen through Plaid, and DoorDash orders read from his email. The output is a morning digest telling him which meals moved his blood sugar, plus recommendations for the day ahead. The post gives no glucose numbers, no example recommendation, no duration of use and no detail on the scope of each authorisation. It is a short reply to other people's posts, not a tutorial or a breakdown.
Measuring is not the hard part. The hard part is joining what you ate to what your numbers did, and those two facts live in three places that do not talk to each other. A person can do that join by hand for about a week before stopping. Each source on its own is easy to read; doing it every morning at the same time is exactly the kind of work an agent is good at. The boundary sits in the same place: it can tell you what moved together, never what to take for it.
Workflow
- Fix the data boundary before anything else: settle what each source opens up - glucose readings only from health data, transaction time and merchant category only from the bank aggregator, delivery notifications only from email. Grant the minimum that works and state the retention period. If this step is not clean, nothing after it should run.
- Align the three sources in time: one timezone, one granularity, one timeline for glucose readings, card transactions and delivery orders. Anything with a missing or unusable timestamp goes into a separate not-aligned bucket rather than being forced into a match.
- Find windows, not single points: use your own threshold to identify yesterday's movement windows - start, peak, fall-back and magnitude. A single reading is not an event. The original post describes it as which meals created movement in the blood sugar.
- Match candidate meals to each window: look back over the window you defined and list what falls inside it, each tagged with its source (order detail, card transaction, or time only) and a confidence of high, medium or low. Low confidence must be marked as low and never quietly mixed in with the rest.
- Produce the digest in a fixed shape: it answers only three questions - which windows moved most, what was matched to them, and what to adjust today. Same format, same length, every day, so there is exactly one place to look.
- Label the advice as correlational: every recommendation carries the same line, that this is a time correlation in your own data and not medical advice. Anything touching medication, dosage or diagnosis is not produced at all and is referred to a doctor.
Adaptation plan
The post gives no glucose range, no example recommendation, no duration of use, no threshold and no detail on how broad the Plaid or mailbox authorisations are. Whether the digest was accurate, useful or acted on is not stated. AgentFlow connected to no health data, no bank aggregator and no mailbox, and has no real glucose reading.
Prompt
AgentFlow draft · Untested.
You are my personal data summary assistant. You align three sources I have authorised myself and produce one morning digest. Your job is alignment and summary. It is not diagnosis, not a prescription and not medical advice. INPUT - WHAT I WILL PROVIDE 1) Glucose readings from my health data, with timestamps. 2) Restaurant transactions from my bank aggregator: time, merchant name and category, amount. 3) Delivery orders from my email: order time and a short summary. 4) My definition of a movement window (for example, a rise beyond a given magnitude within a set time after eating) and how far back to look for candidate meals. EXECUTION STEPS 1. Restate the authorisation scope and retention period for each source and begin only after I confirm. If any scope is unclear, ask first. 2. Normalise timezone and granularity and place all three streams on one timeline. Records with missing or unusable timestamps go into a separate not-aligned list. 3. Identify yesterday's movement windows against my threshold: start, peak, fall-back and magnitude. Never treat a single reading as an event. 4. For each window, match candidate meals within the look-back period, tagging each with its source (order detail, card transaction, or time only) and a confidence of high, medium or low. Anything low confidence must be labelled as low. 5. Write the digest answering only three things: which windows moved most, what was matched to each, and what to adjust today. Fixed format, fixed length. 6. Append the same line to every recommendation: this is a time correlation in your own data, not medical advice. OUTPUT FORMAT - Movement windows table: time / peak / magnitude / direction. - Matched candidates table: window / candidate meal / source / confidence / note on unmatched periods. - Count and reason for records that could not be aligned. - Today's recommendations, each with the not-medical-advice line. - Data gaps: which hours are missing and which source returned nothing. HUMAN CONFIRMATION I authorise each data source myself and can revoke any of them at any time. I set the thresholds and the look-back window. I do not take any judgement about medication, dosage or diagnosis from you; for those I go to a doctor. The digest is for me alone and is not sent anywhere. FAILURE AND MISSING DATA If a source has nothing for the day, write no data and do not fill the gap by inferring from another source. Keep unaligned records in their own list rather than forcing a match. List low-confidence candidates anyway but label them. If data is missing for several days running, tell me to check my authorisations instead of continuing to produce recommendations.
Running costs and pitfalls
The post gives no glucose range, no example recommendation, no duration of use, no threshold and no detail on how broad the Plaid or mailbox authorisations are. Whether the digest was accurate, useful or acted on is not stated. AgentFlow connected to no health data, no bank aggregator and no mailbox, and has no real glucose reading. No independent cost benchmark is available. Check subscriptions, permissions and external actions before running a workflow.
