The problem
Tasks don't arrive in a task manager. They arrive mid-run as a thought, as a screenshot of a job post, as a link someone sends. The friction of opening the right app and filing it properly means most of it evaporates.
Every productivity tool answers this by asking the user to change behavior. That's the same adoption bet enterprise software loses every day: a system that requires new habits loses to the messy channel people already use. The fix isn't a better app — it's meeting the input where it happens.
Who it's for
One user (me), one channel (WhatsApp), several downstream systems (Sheets, Calendar, Gmail). But the shape is the universal intake problem: a requester who won't fill out a form, systems of record that need structure, and an owner who pays for every dropped request in follow-up chaos.
Swap the nouns and this is the ops-team version a business leader would fund: requests arriving by chat and email, an agent extracting the structure, rows landing in the system of record — with the requester never leaving the channel they started in.
The approach
A WhatsApp number that acts as the single capture point, built around an AI agent:
- Any modality in: plain text, voice notes (transcribed with Whisper), or screenshots (read with a vision model — snap a LinkedIn job post and it extracts title, company, location).
- An agent with memory works out what the message is and which tool to call — no commands or syntax to remember. The interface is literally "just say it."
- Tools it routes to: append rows to the right Google Sheets tab (to-dos, job leads, reading list, wedding planning), create Google Calendar events, draft Gmail replies, or search the web.
- Confirmation comes back on WhatsApp, so the loop closes in the same thread the thought arrived in.
Architecture decisions
The whole system is one importable n8n workflow: trigger, switch on message type, transcription/vision branches, agent node, and a fan of tool nodes. Three decisions carried it:
- Low-code on purpose. Swapping a tool or adding a new list is a node edit, not a deploy. For a workflow whose requirements change weekly, iteration speed beats code elegance — it's the fastest path from "I want an assistant that does X" to an assistant that does X.
- The agent decides, the tools constrain. The model chooses which tool to call, but each tool writes to a fixed, typed destination. Flexible understanding, rigid outputs.
- Structured rows, not notes. Everything lands as columns in the right tab, so the sheets stay queryable instead of becoming another pile to read.
Business impact
- The capture rate is the metric. When filing a task costs one WhatsApp message — in whatever form the thought arrived — everything gets filed. The sheets became trustworthy because they were finally complete, and a system of record people trust is the compounding asset.
- Build cost was an evening; run cost is pennies. The low-code bet means total cost of ownership is one person occasionally editing nodes — no repo, no pipeline, no maintenance burden to justify.
- The pattern is the pitch: this is the smallest honest demo of "agent + tools + existing systems of record," the same architecture that intake automation, CRM hygiene, and ticket routing all reduce to. Proving it on a personal workflow is how you learn the failure modes before proposing it with a budget attached.
Risks & guardrails
- Drafts, not sends: the Gmail tool only drafts replies; a human hits send. Same principle as every system I build — autonomy in processing, human control at the point of external action.
- Fixed tool destinations mean a confused agent can file to the wrong list, but can't touch anything outside its fan of tools.
- Confirmation on every action closes the loop in-channel, so a mis-filed item is caught in seconds, not discovered weeks later.
Where it goes next
An n8n canvas screenshot and a WhatsApp exchange for this page, a weekly digest message summarizing what got filed, and retiring lists as life changes — the wedding-planning tab has a natural expiry date.