I built 'Ask Your Life' — a personal Coral agent that answers questions about your money & deadlines with SQL

A developer built "Life Risk Radar," a personal Coral agent that answers plain-English questions about inbox, calendar, and financial data by executing real cross-source SQL joins. The agent, created for the WeMakeDevs Pirates of the Coral-bean hackathon, surfaces risks like missed deadlines or duplicate charges with evidence and drafted actions, pivoting from a dashboard approach to an agent that queries Coral's SQL engine directly.

"Here are the personal admin risks that can cost me money, time, or access this week — with the receipts." 🪸 That one sentence is the whole pitch for Life Risk Radar , my entry for the WeMakeDevs Pirates of the Coral-bean hackathon Personal Agent track . It's a personal agent you can ask — in plain English — about your inbox, calendar, and money, and it answers with a real cross-source SQL join , the evidence behind every number , and a drafted action you can send. This post is the full build story: the problem, the architecture, how Coral https://www.wemakedevs.org/hackathons/coral turns "your life" into a queryable database, the agent loop that pairs Claude with Coral SQL, the safety model, and the things that broke along the way a -- that wasn't a comment, a Cloudflare 403, and a moment where I realised my SQL wasn't actually joining anything . Money, time, and access leak through the cracks of everyday admin, and almost always silently: Here's the thing: the evidence for all of these is already in your accounts. The renewal email is in Gmail. The charge is in your card statement. The appointment is on your Calendar. The missing file is in your documents folder. The problem was never a lack of data. The problem is that nobody joins it. Your email doesn't know about your transactions. Your calendar doesn't know which document you're missing. Each source is an island, and the risk lives in the gaps between them. That gap is exactly what Coral is built to close. Life Risk Radar has two modes, and the order matters. 1. Ask your life the hero . A command bar where you type a question: The agent turns your question into Coral SQL, runs a genuine cross-source join, and answers with a one-line verdict, a result card per row, the exact SQL it ran , and a ready-to-send drafted action. 2. Scan everything the fallback . Don't want to ask? One button sweeps every source, ranks the risks, and lays them out as a board you can open for a step-by-step "close this risk" action plan. The whole thing is light-mode, editorial, and deliberately un -dashboardy — because the star isn't a chart, it's the answer and the query behind it. I'll be honest about how this started, because the turning point is the most useful part of the story. My first version was a tidy risk dashboard . Click "Scan", get ranked cards. It looked finished. Then I opened the SQL that powered it and caught myself: WITH gmail AS SELECT ... FROM life files.gmail messages , deadlines AS SELECT ... FROM life files.manual deadlines , documents AS SELECT ... FROM life files.documents , calendar events AS SELECT ... FROM life files.calendar events SELECT FROM duplicate charges UNION ALL SELECT FROM deadline risks; It declared CTEs for five sources… and then joined none of them . The "cross-source evidence" was actually being stitched together afterwards in TypeScript with a fuzzy string matcher. I was using Coral as a fancy file reader, not as a join engine. That's backwards. The single most valuable thing Coral gives you is a SQL interface that joins across totally different sources — email, calendar, files, APIs — as if they were one database. If my SQL wasn't joining, I wasn't really using Coral. So I pivoted. Not the data, not the UI work — the thesis . From "a dashboard that reads from Coral" to "an agent whose entire job is to ask Coral the right cross-source question." That reframe is what turned a fine project into one with a point of view. If you haven't used it: Coral is a local-first SQL engine that points at "sources" — APIs, files, calendars, databases — described by small spec files, and lets you query and join them with plain SQL. It also ships an MCP server coral mcp-stdio so an agent can use it as a tool directly. Life Risk Radar uses two sources, no extra plumbing: life files transactions , documents , manual deadlines , calendar events , and gmail messages . This is the reproducible demo data, so the project runs end-to-end without touching a personal inbox. gmail message search and message details for going live later.Registering a source is two commands: coral source add --file sources/life files/manifest.yaml coral source test life files …and now five different "islands" are one schema you can join. Here's the request flow for a free-text question: You type a question │ ▼ ┌──────────────────────┐ schema + question │ Claude Opus 4.7 │ ─────────────────────► Coral SQL read-only └──────────────────────┘ │ validated against a SELECT-only allowlist ▼ ┌──────────────────────┐ │ coral sql … -- │ runs a REAL cross-source JOIN └──────────────────────┘ │ rows + evidence ▼ ┌──────────────────────┐ │ Claude Opus 4.7 │ reads the rows → headline + drafted action └──────────────────────┘ │ ▼ UI shows: verdict · result cards · THE SQL · draft to send It's a genuine two-step agent loop: The UI then shows the SQL it ran . That transparency is the design centerpiece — when you can see the query and the joined evidence, the agent stops feeling like magic and starts feeling inspectable . That matters a lot for a tool that's poking at your money. The stack: Next.js + TypeScript , Chakra UI a light editorial theme — Fraunces + Hanken Grotesk , Coral for the SQL/joins, and Claude Opus 4.7 for NL→SQL and summarization, with prompt caching on the schema system prompt. Here's a question a dashboard would never answer well: "Which missing document is blocking the most deadlines?" SELECT doc.name AS missing document, COUNT DISTINCT dl.id AS deadlines blocked, STRING AGG DISTINCT dl.title, ' | ' AS blocked items, MIN dl.due at AS earliest due FROM life files.documents doc JOIN life files.manual deadlines dl ON doc.tags LIKE '%passport%' AND LOWER dl.title LIKE '%passport%' OR doc.tags LIKE '%kyc%' AND LOWER dl.title LIKE '%kyc%' OR dl.category = 'kyc' OR doc.tags LIKE '%bank%' AND LOWER dl.title LIKE '%bank%' WHERE doc.status = 'missing' GROUP BY doc.name ORDER BY deadlines blocked DESC; The answer: address proof.pdf blocks 2 deadlines — a single point of failure. Your passport appointmentandyour bank KYC both need it. One missing file, two missed deadlines, surfaced in a single row. That's an insight a join produces and a list of cards never will. The other two flagship questions map to equally real joins: | Question | Cross-source join | What it attaches | |---|---|---| | "Am I being double-charged?" | transactions ⋈ gmail messages | the receipt email next to the duplicate charge | | "What's costing me money this week?" | manual deadlines ⋈ gmail messages ⋈ calendar events | the billing email and the calendar reminder | For example, the duplicate-charge query joins your card transactions to the receipt email that explains them: SELECT t.merchant, COUNT AS charge count, SUM t.amount AS total amount, MAX g.subject AS receipt evidence FROM life files.transactions t LEFT JOIN life files.gmail messages g ON LOWER g.subject LIKE '%' || LOWER t.merchant || '%' OR LOWER g.body text LIKE '%' || LOWER t.merchant || '%' GROUP BY t.merchant HAVING COUNT = 2; → "Adobe charged 2× — $39.98 to review," with the matching "Adobe payment receipt - $19.99" email pulled in by the join. Three sources, one row, every number traceable to where it came from. Question → SQL is a single Claude call, schema-grounded and cached: js const message = await client.messages.create { model: "claude-opus-4-7", max tokens: 700, system: { type: "text", text: schemaForPrompt , cache control: { type: "ephemeral" } } , messages: { role: "user", content: Question: ${question}\nWrite exactly one Coral SQL query. } } ; const sql = validateReadOnlySql stripFences textOf message ; // throws if unsafe Then Coral runs it, and a second Claude call reads the actual rows and writes the human answer: js const rows = await runCoral sql ; // real cross-source join const summary = await summarizeWithClaude question, columns, rows ; // → { headline: "…", draft: { subject, body } } This is what makes it an agent rather than a search box: it reasons over the results, not just the question. Two engineering constraints shaped the build. 1. The generated SQL is sandboxed. Anything Claude writes is validated before it can reach Coral — single statement, SELECT / WITH only, allowed schema only, no DDL/DML: if trimmed.includes ";" return reject "Only a single statement is allowed." ; if /^ select|with \b/i.test trimmed return reject "Only SELECT/WITH is allowed." ; if FORBIDDEN.test trimmed return reject "Write/DDL keywords are not allowed." ; // every schema-qualified reference must be life files. I unit-tested it against DROP TABLE , UPDATE , multi-statement injection, and a secrets.users reference — all rejected; legit SELECT / WITH over life files allowed. 2. The demo can never break. Three layers of graceful degradation: That's the difference between "works on my machine at 2am" and "works on stage." No build is clean. The honest log: documents ⋈ deadlines , transactions ⋈ gmail replaced TypeScript string-matching. -- that wasn't a comment. -- "What is costing me money this week?" . Passing that to coral sql "<query " made the CLI read the leading -- as a coral sql --format json -- "$ cat query.sql " . HTTP 403 . The API key was valid — Dev.to sits behind Cloudflare, which blocks the default Python-urllib User-Agent. A one-line User-Agent header fixed it. Good reminder that 403 ≠ "bad credentials." node modules . npm ci was the real fix — and a lesson to never trust a cached green check.The plumbing to read a live account already exists — the gmail HTTP source spec plus read-only OAuth. The remaining work is the genuinely hard part: But the core bet is already proven: your life is queryable, and the join is where the insight lives. If you build on Coral, the lesson I'd pass on is simple: don't just read from your sources — join them. A list of records is a chore; a joined row is an insight "this one missing file blocks two deadlines" . And if you put the generated SQL on screen, your agent earns trust instead of asking for it. Life Risk Radar is built for the WeMakeDevs Pirates of the Coral-bean hackathon Personal Agent track . Natural-language questions in, real cross-source SQL out, evidence and a drafted action every time. 🪸