Most people we wanted to help were never going to install another AI app. Parents, busy friends, people running a small business: they already live in WhatsApp. So we built Kubi, a personal AI assistant that lives there. You text it, send it a photo or a voice note, and it does the task.
This post is about the design decisions that turned out to matter more than the model choice.
1. The chat is the whole interface
There is no dashboard to fall back on, so everything has to work as a conversation:
- Reminders are set by just saying them ("remind me Thursday at 9 to call the bank"). A reminder can also be a phone call, which works well as a wake-up call.
- A photo of a letter or a bill comes back as a plain-language explanation: who sent it, what they want, by when. Then it offers to remind you before the deadline. Official letters are confusing in every country, so this is the one people usually try first.
- Voice notes in, and spoken replies out when you ask for them.
- Web tasks: searching flights, comparing prices, signing in to a site on your behalf.
The hard part was not any single feature. It was keeping replies short enough to read on a phone, and asking one clear question when something is ambiguous instead of guessing.
2. Use the official WhatsApp Cloud API, and design for its rules
We use Meta's official Cloud API, not an unofficial bridge on a phone. That costs some flexibility, but it is the supported path, and unofficial bridges risk getting the number banned. It comes with rules you have to design around from day one:
- You can reply freely inside a 24-hour window after the user's last message. Outside that window, a business can only send pre-approved templates. Anything proactive (a reminder, a follow-up) has to respect that.
- Media (photos, voice notes) arrives as an id you fetch separately, so the pipeline has to download, transcribe or read it, then answer, all without leaving the user staring at a silent chat.
3. Every user gets their own isolated agent
Each user's agent runs in its own isolated environment (its own pod), with its own files and memory. One user's data is never in another user's context. This made some things harder (cold starts, scheduling), but it made the trust story simple to explain: your assistant is yours.
4. The model never sees your passwords
If an assistant can sign in to sites for you, the obvious risk is the password ending up in a prompt or a log. Our answer: credentials live in an encrypted vault, and a proxy fills them into the outgoing request. The agent can use a login without the secret ever entering the model's context.
5. Anything sensitive waits for an explicit OK
Payments, deletions and changes to your accounts do not happen on the model's judgment. The agent stops and asks in the chat, and only continues after you approve. Routine reading and searching does not need approval; otherwise the assistant becomes a stream of "are you sure?" messages and nobody uses it.
6. Onboarding is also a conversation
New people don't fill a form. They message Maya, our onboarding assistant, on WhatsApp. She explains what Kubi does and puts them on the early-access list. We let people in in small batches so we can actually read the feedback.
What we'd tell anyone building on WhatsApp
- Start from the platform's rules (24-hour window, templates), not from the model.
- Isolation per user is worth the operational cost.
- Keep secrets out of the model context entirely; don't rely on "the prompt says don't print it".
- Approval gates only for things that are actually sensitive.
Kubi works in English and Hebrew today, and it's free during early access. If you want to try it, message Maya on WhatsApp to request access: https://app.heykubi.ai/wa/3d618673 (or read more at https://heykubi.ai).
We'd love to hear from people building similar things: what's the first task you'd hand to an assistant like this, and what would make you not trust it?
The Kubi team
Top comments (1)
Feels like we are past the "can it do it" phase and into "can you trust it to do it".