01 · QueryMind 02 · Agentic Booking 03 · Careway What I Learned
AI Projects · Side Work · POCs

Building in AI

Three projects, three different layers of the AI stack. Started with a single-turn LLM query. Now building agentic loops with tool registries, multi-role state machines, and human-in-the-loop workflows.

Prompt engineering
Single-turn LLM
Agentic loop
Tool / function calling
RAG
Episodic memory
State machine
Human-in-the-loop
QueryMind
Agentic Booking System
Careway
What I learned
QueryMind RAG architecture
Retrieval precision beats prompt quality
SQL accuracy lives or dies on whether the right schema chunks reach the model. Chunking strategy matters more than prompt wording.
Agentic Booking Tool-use design
Agentic means reasoned sequencing, not just automation
The agent decides which tool to call based on what the previous tool returned. Tool ordering is a design decision.
Careway Shared state
Multi-role state is the hardest UX problem
Same data, three mental models. The data design is simple. Making the UI feel coherent across all three roles is where the real work is.
Shipped · AI POC
Project 01

QueryMind

RAG-powered Text-to-SQL. Business users query enterprise databases in plain English — no SQL required. Built end-to-end: schema embedding, semantic retrieval, query generation and execution.

GitHub ↗ PRD ↗ Architecture
01
Schema Embedding
Tables, columns, relationships vectorised into semantic index
→
02
NL Query In
"Show me top customers by revenue last quarter"
→
03
Semantic Retrieval
Relevant schema chunks retrieved via vector similarity
→
04
Query Generation
LLM generates SQL grounded in retrieved schema context
→
05
Result
SQL executes, result returned in plain language + table
Problem
Analytics bottleneck at the SQL layer
Business stakeholders depend on data teams for every ad-hoc query. The back-and-forth is slow; context gets lost in translation. QueryMind removes that dependency — anyone who can describe a question can get the answer.
Architecture decision
RAG over fine-tuning — schema grounding matters more than model size
SQL accuracy depends on knowing the exact schema, not just SQL syntax. RAG retrieves the right tables and columns at query time. Fine-tuning would bake in a static schema — useless for evolving enterprise databases.
Commercial lens
Directly applicable to my day job
Built this to solve real friction from commercial analytics work — stakeholders asking the same data questions repeatedly. The same architecture works for any enterprise with a Snowflake, Databricks, or Supabase backend.
What I learned
Prompt engineering is only 20% of the problem
Schema design, embedding chunking strategy, and retrieval precision determine SQL quality far more than prompt wording. The hardest part was making the retrieval step return exactly the right schema chunk — not just a relevant one.
New concepts: Single-turn LLM · RAG · Vector embeddings · Semantic retrieval
In Dev · v0.2
Project 02

Agentic Booking System

Built for single-owner professional service businesses — Pilates studios, tutoring centers, clinics. WhatsApp-native scheduling agent that handles bookings, renewals, and owner follow-ups autonomously. No app. No portal. Just a message.

Customer
Book in plain language
"Book me something this week" — agent picks the best slot based on history
Zero install
Lives inside WhatsApp — no app download, no portal login, no new habit
Session awareness
Agent knows sessions remaining before it tries to book — handles renewals proactively
Auto-waitlist
If no slot fits, customer is queued by priority — notified when one opens
Owner
Morning brief
One prioritised action list every day — who to call, who to chase, who's at risk
Payment alerts
Overdue customers surfaced automatically, ranked by days outstanding
Expiry warnings
Plans flagged before they lapse — reach out before the customer disappears
Churn signals
Attendance drop-offs flagged before they become cancellations
System
Always on
Bookings handled 24/7 with no owner involvement — nights and weekends included
Auto-sync
Every booking written to DB, Sheets, and S3 — 2-tier backup, nothing lost
Security enforced
Access rules live at the database layer — not application code, so they can't be bypassed
Service-agnostic
Template works for any session-based service — yoga, tutoring, clinics, coaching
System Overview — Agentic Scheduling
WhatsApp-native · LLM-orchestrated · Production-grade
01 — Problem space
Booking friction
Manual WhatsApp threads lose class revenue daily with no structured follow-up
No plan guardrails
Session limits and expiry go unenforced without automation
Owner admin burden
Follow-ups, waitlist, check-ins consume 2–3 hrs of owner time daily
Prohibitive tooling
Custom apps need months and large budgets. This doesn't.
02 — Value proposition
Zero install
Runs inside WhatsApp — customers use the app they already have
Always on
Autonomous booking without owner involvement
Customisable
Plans, rules, extensions — all configurable per studio
Service-agnostic
Template applies to yoga, tutoring, clinics, any session-based service
03 — System architecture
Customer
WhatsApp Slot UI (HTML mobile) OTP Auth
zero install · existing habit
Intelligence
Claude Haiku agent_loop.py n8n workflows
orchestrator + tool-use loop
Data
Supabase PG Google Sheets AWS S3
primary + live sync + backup
Owner
React Dashboard Morning Brief NL Query
Claude text-to-SQL + Vercel realtime
04 — Agentic tool-use loops
Customer agent
Handles inbound booking requests autonomously. Draws on a set of tools covering plan validation, availability, preferences, and booking confirmation — deciding which to call in what order based on what it learns at each step. Customer messages once; agent handles the rest.
Owner agent
Synthesises the owner's daily action queue across payments, renewals, attendance drop-offs, and waitlist openings. Uses a set of data tools to gather signals from multiple sources, then produces a single prioritised brief — ranked by urgency, with recommended next action per item.
05 — End-to-end request loop
CustomerWhatsApp msg
→
Twiliowebhook
→
n8nrouter
→
Claude Haikuintent parse
→
Tool-use loopget_plan → check_slot
→
SupabaseRLS enforced
→
Sheets + S32-tier backup
→
Confirmationsend_whatsapp()
06 — Tech stack
Intelligence
Claude Haiku
Data
Supabase PG
Messaging
Twilio / WA
Orchestration
n8n + Azure Fn
Frontend
React + Vercel
Cloud
AWS S3 + SSM
07 — Key design decisions
Identity
OTP via WhatsApp
Phone as identity — zero friction, no passwords, no separate login
Cost
n8n self-hosted
No per-execution cost, full data sovereignty, no vendor lock-in
Security
RLS at DB layer
Security enforced by Postgres, not application code — survives any layer failure
Model choice
Haiku over Sonnet
Right-sized for tool-loop tasks — fast, low token burn, still reasons well
New concepts: Agentic loop · Tool/function calling · Episodic memory · Multi-source synthesis
Design · v6 Built
Project 03

Careway

Clinical pathway coordination for chronic disease management. One platform. Three roles — Patient, PCP, Specialist — all operating on the same live pathway, each seeing exactly what they need to act.

Careway — Clinical Pathway Coordination Platform
6 design iterations · 3 roles · shared live state · agentic coordinator layer planned
Patient
PCP
Specialist
The problem Careway solves
Fragmented pathways
PCP builds a care plan. Specialist overrides it. Patient sees neither. No one has the full picture.
Manual coordination
Walkout summaries are verbal or faxed. Overrides happen without documented reasoning. Accountability lives nowhere.
Coverage blind spots
HCPs make drug decisions without knowing the patient's insurance coverage — leading to PA delays and patient drop-off.
What each role sees — same data, different lens
Patient view
Sarah M.
My PathwayMerged steps from PCP + Specialist in plain language. No clinical jargon. "Your next step" always visible at top.
MedicationsActive meds with prescribing doctor + PA approval status. Knows who prescribed what.
Daily Check-inEnergy, symptoms, weight, BP — all logged and visible to care team.
Walkout SummaryAppears after PCP sends it — plain-language recap of the visit.
PCP view
Dr. Kim
Coverage sidebar (always visible)Insurance summary + per-drug PA status. Never tab-switches to check coverage at point of drug decision.
Pathway builderLoad ICD-10 → standard pathway loads. Add/remove/restore steps. Drug switcher updates sidebar live.
Lab sparklinesHbA1c, LDL, Weight, Fasting Glucose — trend lines in-visit.
Walkout builderAuto-generated from pathway state → "Send to patient" updates Sarah's view live.
Specialist view
Dr. Ramos
PCP pathway (read-only)Full PCP pathway visible. "Override" button per step — reason required, logged permanently.
My StepsSpecialist-owned additions. Amber coverage sidebar to distinguish from PCP view.
Unified pathwayMerged PCP + specialist steps. Overridden steps struck through with ⚡ reason shown.
Change logBoth HCPs color-coded — full audit trail. Confidence signal fires if same step edited 3+ times.
Key design decisions across 6 iterations
Patient empathy first
Plain language throughout. "You're not alone in this." Coverage sidebar never patient-facing.
Coverage at point of decision
Sidebar always visible — HCP never has to tab-switch during a visit to check PA status or formulary.
Accountability without friction
Override requires a reason. Confidence signal on repeated edits. Every action timestamped and attributed.
One truth, multiple lenses
Same live pathway data. Patient sees merged plain-language view. HCPs see attributed steps. No duplication.
Agentic coordinator layer — planned
Pre-call brief on demand
Coordinator asks: "Prep me for my 2pm call with patient X"
→Pulls pathway position + overdue steps
→Checks last contact note
→Drafts brief + 3 ranked outreach actions
Autonomous morning outreach queue
Every morning, agent decides which patients need outreach — drafts personalized messages — waits for coordinator approval — then sends.
Human-in-the-loop
approval before every send
New concepts: State machine · Human-in-the-loop · Multi-role shared state · Semantic RAG (coordinator agent)
Interested in what I'm building?
Happy to walk through any of these in a conversation — the architecture decisions, what worked, what didn't.
✉ Get in touch ← Back to portfolio