YC Hackathon 2026 · Personal data substrate

Your health data,
finally useful.
No middlemen.

Getting data out of Apple Health is a nightmare of shortcuts and third-party collectors. We compiled a Go daemon into the iOS app and stream directly to an agent. Two G-Brains. One channel. Talk to it on Telegram.

2
OpenClaw agents
27
On-device models
17
Research papers
1 primitive
send-message
The problem

Apple Health is a silo.

Your watch knows more about your body than any doctor. Getting that data out — and doing something intelligent with it — is an unsolved engineering problem.

01 · Export

Export is broken by design

Apple lets you export a ZIP. The XML inside is 500 MB, unstructured, and missing workout metadata. Shortcuts can drip samples one-by-one but there is no streaming API and no way to push data anywhere reliably.

02 · Privacy

Third-party collectors are a risk

Every "sync to Google Sheets" app is a new data custodian. Your HRV, sleep stages, and resting heart rate end up on someone else's server, often unencrypted, with terms that can change.

03 · Infrastructure

The wiring problem

Even if you get the data out, you still need a receiver, a transformer, a store, a query layer, and something to reason over it. Most people stop at the export. The wiring is the hard part.

04 · Context

No conversational interface

Charts show what happened. But "should I train hard today?" requires HRV trend, sleep quality, and your calendar for the week — cross-referenced. No consumer app does this. Ours does.

The insight

Compile a Pilot daemon into iOS.
Make the phone a network node.

Instead of exporting data out of the phone, we run a Go network daemon — pilot-swift — inside the iOS app sandbox. The iPhone becomes a first-class node on an encrypted overlay network.

Health samples are pushed directly to an agent via pilotctl send-message. No HTTP server, no port forwarding, no third party in the middle. E2E encrypted, NAT-traversed. It just works from any network.

Wire format
# iPhone → Collector, E2E encrypted pilotctl send-message <collector-id> \ --data '{"samples": [...], "batch_id": "..."}' # Collector acks back to iPhone pilotctl send-message <iphone-id> \ --data '{"accepted": [...], "duplicates": [...]}' # Collector notifies Coach pilotctl send-message <coach-id> \ --data '{"kind": "samples_added", ...}'

One primitive. Classification by content shape, not port number.

The solution

Two agents.
Each owns its data.

Each agent has its own OpenClaw workspace, its own Pilot identity, its own G-Brain, and its own Docker container. They coordinate only via send-message.

Agent A · Collector

Retains your health data

Receives HealthKit envelopes from the iPhone, deduplicates by sample UUID, and writes to a DuckDB warehouse. Answers SQL queries from the Coach. Its G-Brain holds factual observations — what HealthKit reported, when, raw counts. No interpretation.

Owns
  • facts.duckdb — every sample ever ingested
  • gbrain-collector-home — factual memory
  • Ack logic — iPhone cursor advances only on confirmation
  • 84 unit tests · 8 E2E scenarios passing
Agent B · Coach

Retains what you did

Monitors health events via 7 rule models, pulls your Google Calendar, and reasons over all of it. Sends proactive nudges on Telegram when a rule fires. Answers questions with paper-backed evidence from 17 peer-reviewed studies.

Owns
  • gbrain-coach-home — interpretive memory, prior nudges
  • Calendar context — daily markdown via Google OAuth
  • 7 rule models — HRV, burnout, sleep, circadian drift
  • Telegram interface via OpenClaw channel binding
Communication channel — one primitive, content-based routing
📱 iPhonepilot-swift node
send-message
Collectorinbox_watcher
ChangeEvent / SQL
Coach7 rule models
OpenClaw
💬 Telegramyou
Real Pilot built-in services: dataexchange 1001 (send-message), echo 7, handshake 444. No application-level port routing — messages are classified by JSON content shape.
How it works

From wrist to answer.

Every step is traceable. No cloud middleware, no magic.

01

Apple Watch samples HealthKit — 27 on-device models run

Anchored queries capture every sample exactly once — HRV, sleep stages, resting heart rate, SpO₂, training load, and more. 27 on-device models compute composites like burnout CUSUM, circadian drift, and autonomic balance. No server dependency for analysis.

02

pilot-swift packages and sends the envelope

The embedded Go daemon calls pilotctl send-message <collector-id> --data '...'. The envelope carries a batch UUID, sample UUIDs, and raw values. E2E encrypted tunnel — no data is visible to any relay, including the Pilot overlay itself.

03

Collector receives, deduplicates, confirms

The JSON lands in the Collector's Pilot inbox as a file. inbox_watcher.py classifies by content shape — a message with a samples array goes to the ingest path. INSERT OR IGNORE on UUID deduplicates. An Ack is sent back; only then does the iPhone advance its HealthKit cursor. Crash-safe by design.

04

Collector notifies Coach via ChangeEvent

After each batch commit, {kind: "samples_added"} is sent to the Coach's inbox. Same primitive — send-message — different content shape. The Coach classifies it by the kind field. No pub/sub, no message broker.

05

Coach runs 7 rule models; queries Collector's DuckDB

On each ChangeEvent, the Coach sends a SQL query message to the Collector. The Collector executes it read-only and replies with a QueryResult, correlated by request_id. If a rule fires — HRV below baseline, burnout CUSUM crossing a threshold, circadian drift detected — and cooldown has elapsed, a Telegram nudge goes out.

06

You ask on Telegram. The Coach answers with evidence.

The Coach combines a DuckDB query, G-Brain recall, and health-intelligence RAG — 17 peer-reviewed papers, 89 interventions — to answer in ≤200 words with inline citations. Calendar context from Google OAuth is already in its G-Brain, so "HRV dropped during my heavy meeting week" is answerable without you explaining anything.

The bigger idea

Distributed data.
Distributed compute.

Each agent is a fully independent unit. To add another — just share its Pilot node ID. The network grows without central coordination.

Design principle

One G-Brain per
use case. Per agent.

The Collector's G-Brain holds factual observations. The Coach's G-Brain holds interpretations and prior nudges. Neither agent can corrupt the other's record. They don't share a database or a socket.

G-Brains communicate effectively without a lot of shared priors — they converge on meaning through message exchange. The more agents you add, the more they pool, the better they reason.

To add a third agent: spin up a container, get its Pilot node ID, share it with the others. Done. No schema migration, no service mesh, no coordinator.

Sleep Coach
Own G-Brain. Subscribes to sleep ChangeEvents. Node ID shared with Coach.
Training Load Agent
Queries Collector directly. Maintains ACWR + monotony state in its own G-Brain.
Calendar Reasoner
Pulls Google Calendar. Correlates meeting density with HRV via Collector queries.
Family Health Node
Separate device. Separate Pilot identity. Approve the handshake — it's in the network.
Nutrition Agent
Own G-Brain trained on dietary logs. Queries health data to correlate HRV with meals.
Your next idea
One Pilot node ID. That's the only onboarding step.
Pilot Protocol
OpenClaw
G-Brain / PGLite
DuckDB
pilot-swift (Go → iOS)
HealthKit
FastAPI · RAG
Google OAuth
Telegram
Docker · GCP