Pass-Through vs Answer-On-Device: Who Computes Your Health Answer
Two designs showed up in health AI in 2026. One hands your agent the raw numbers and lets the model do the reading. One computes the answer on the phone and shows the working. The difference only becomes obvious the first time a number is wrong.
AI-assisted, human reviewed. How we use AI
Quick answer
A pass-through tool moves your data and stops: your agent receives samples and computes the answer itself. An answer-on-device app computes the number on the phone first, then a model only words it, and every answer carries a provenance card showing the samples, date range and computation. Both can be private. Only one of them lets you check the maths without re-running the model.
Two designs, one question
The question both designs are answering is simple: where does the computation happen? Everything else follows from that. If the computation happens inside the model, then the model's arithmetic is the product, and you audit it by asking again and hoping for the same answer. If the computation happens in a deterministic component, the model never touches the number, and the number is the same on every run.
That distinction is invisible in a demo. It shows up on the third question, when a trend flips sign between two identical prompts.
Pass-through: your agent does the reading
The pass-through pole is stated cleanly by Mibly, which says on its own site: "Mibly doesn't read your data. Your AI does." That is a real position, and it has real advantages. The tool stays small. There is no answer engine to audit and no scoring layer to argue with. Whatever agent you already pay for becomes the analyst, over whichever samples the tool hands over.
The cost sits in the same sentence. If your agent does the reading, your agent's reading is the answer. Nothing in the pipe checks whether a 7-day average was computed over 7 days, whether a gap quietly truncated the window, or whether a unit change was noticed. You find out by noticing something odd, which is the worst time to find out.
Answer-on-device: the phone computes, the model only words it
The other design puts the arithmetic on the device. In MetricBridge the iPhone computes the number before any model is involved, and there are four ways Ask can run: a deterministic guided mode with no model at all, Apple's on-device model, an optional downloaded model of about 400 MB, and Your Mac, where Ollama on your own Mac words the answer while the numbers still come from the iPhone. There are no API keys and no cloud AI in the path.
The point is not that a small model is smarter. It is that the model is not allowed to be the calculator. It receives facts that were already computed and writes a sentence around them.
What a provenance card looks like
Every computed answer renders as one card: the headline number in large type, an inline chart, and a tappable strip naming the samples, the date range and the computation behind it. From our own seeded 30-day series, one recorded card reads HRV 7-day average 49.6 ms, up 16.3% vs the prior 14 days, with the contributing samples listed. Re-run it and you get the same card, byte for byte (sha256 f2e87621). That is the property pass-through does not have: the answer is reproducible because the model was never the one doing the maths. The full method behind each computed number, including every window and threshold, is published on the methods page.
Baseline, not verdict. The card describes a change against your own recent data. It does not say a reading is good, bad or abnormal. The product's language is a deviation from your personal baseline, and that is all it claims to be.
The same phone also feeds your agent
This is where the comparison usually goes wrong. Answer-on-device is not the opposite of a pass-through pipe; it is the pipe plus a checked answer. MetricBridge exports all 194 metrics as clean JSON or CSV to a destination you choose, and the open-source MCP server exposes them to any MCP-aware agent as 18 tools, 16 read-only plus add_event and remove_event, which write only an events file beside the export, and 22 prompts. Nothing writes to Apple Health.
So the two halves are complementary in one product: the app gives you an answer you can audit without your agent, and the MCP server gives your agent the raw data when you want your agent to do the analysis instead. A pure pass-through tool can only ever offer the second half. A pure answers app without a bridge can only offer the first.
One question, two designs
Take a real question: "How is my HRV trending?"
- Pass-through: the tool hands your agent the HRV samples for the window you both agree on. The agent decides what "trending" means today, computes an average, picks a comparison window, and writes a sentence. Ask the same question in a fresh session and it may pick a different window.
- Answer-on-device: the phone computes the 7-day average and the change against the prior 14 days, the card shows both with the samples behind them, and the model words the result. Ask again and the number holds, because the number was never the model's to invent.
Neither is a trick. But only one of them survives being checked, and only one of them can tell you why it said 49.6 ms.
What each design is genuinely bad at
- Pass-through is bad at accountability. There is no artefact to inspect, so you cannot separate a data problem from a reasoning problem after the fact.
- Answer-on-device is bad at open-ended analysis. It answers what it was built to compute. If you want an unusual cut, an agent with loose tools will go further, which is exactly why the export and the MCP bridge exist alongside the answer engine.
- Both are bad at diagnosis, by design. Neither is a medical device, and neither should be asked to be. They describe your own data; they do not detect, treat or monitor a condition.
How to choose
Choose pass-through if you have a capable agent, you trust its arithmetic, and you only need a pipe. Choose answer-on-device if you want the number to be right before the model touches it, and a strip that shows exactly which samples produced it. Choose both if you can, because the interesting questions are the ones where a checked answer and an open agent disagree, and you can only have that argument if you own both sides.
Doing this yourself? MetricBridge computes answers on the iPhone with a provenance card on each one, and exports all 194 metrics to your own agent through the open-source MCP server (GitHub).
FAQ
What is a pass-through health tool?
A pass-through tool moves your data without interpreting it. Mibly states the idea plainly on its own site: "Mibly doesn't read your data. Your AI does." Your agent receives the selected samples and works out the answer itself, so the arithmetic happens in the model, not in a component you can inspect.
Does an answer-on-device app mean my health data never leaves the phone?
The answer is computed on the iPhone. Your health data never reaches us or a cloud AI. Two things are worth stating exactly: the iOS app reports install, trial-start and purchase events to Meta for ad attribution, never health data, and only if you allow tracking when iOS asks; and the open-source MCP server makes zero network calls, so an export goes only where you point it.
Can my agent still get the raw numbers if the app computes answers?
Yes. MetricBridge answers on the iPhone and also exports all 194 metrics as local JSON, and the open-source MCP server exposes 18 tools (16 read-only, plus add_event and remove_event, which write only an events file beside the export) over stdio. You get both halves: a computed answer you can audit in the app, and raw data your own agent can query.
Which design should I pick?
Pick pass-through if you already trust your agent and only want a pipe. Pick answer-on-device if you want the number to be correct before the model touches it, and a strip that shows which samples and date range produced it. If you want both, you need a product that computes on the phone and ships an MCP bridge.
An answer you can check, and a pipe your agent can use
Ask on the iPhone and read the working, or export all 194 metrics and let your own agent query them over MCP.
Where it goes: the app reads Apple Health read-only and writes JSON to a folder you pick. Your health data never reaches us or a cloud AI; the MCP server makes zero network calls. What you get: all 194 metrics, on-device Ask with a provenance card on every answer, the Weekly Brief, and the Mac and Apple Watch apps. Price: $24.99 one time after a 7-day free trial, not a subscription. Wellness, not medical advice.