Case study: a WhatsApp number that answers from your documents and asks before it acts

Most business software fails at the same place: somebody has to open it. A tool that lives behind a login and a dashboard competes for attention with every other tool behind a login and a dashboard.

WhatsApp does not have that problem. It is already open, on the phone of every person in the business, all day.

So the question was what happens if the assistant lives there instead. This is what came out, and it is live in production today.

What it does

You send it a message like you would send a colleague.

It answers from your own documents. Forward it a contract, a policy, a price list, and it becomes searchable. Ask what the notice period is on a particular agreement and the answer comes from that agreement, not from the model's general knowledge of what notice periods usually are.

It reads your Google Workspace. What is on the calendar tomorrow, what did that client last email about, where is the file we sent them.

It acts, but only with permission. Tell it to email someone and it writes the message, shows it to you in the chat, and waits. Nothing goes out until you confirm.

It listens. Voice notes are transcribed, so the whole thing works while driving, which is when a lot of business thinking actually happens.

The constraint that shaped everything

Sending an email on a misread intent is not a recoverable mistake. You cannot unsend it, and the person on the other end does not know a machine wrote it.

So the system splits every capability into two categories with a hard line between them.

Reads run immediately. Looking something up is free. If it looks up the wrong thing, you ask again.

Writes wait. Anything that changes the world outside the chat gets composed, stored as a pending action, and executed only after you confirm it.

That distinction is not a prompt instruction. This matters more than it sounds like it does.

Why the gate is in the database, not the prompt

A prompt saying "always ask before sending" is a preference. It holds most of the time. It does not hold when a message is phrased unusually, or when a conversation gets long, or when someone works out how to talk around it.

Here, the pending action is a row. Confirming it is a conditional update that only succeeds if the row is still unconfirmed. Two people confirming the same action at the same moment produce exactly one email, because the second update matches nothing.

There is a test for that specific race, because it is the kind of bug that happens once in production, looks like nothing, and destroys confidence in the whole system.

The difference in practice: a prompt-level guardrail is a strong suggestion to a language model. A conditional write is a guarantee made by the database. Only one of those survives a determined user, an unusual phrasing, or a bad day.

What runs underneath

Retrieval runs on Postgres with pgvector, and the embeddings are computed locally rather than through an API. That keeps document content inside the system and makes a lookup cost milliseconds instead of a network round trip.

Conversation state is checkpointed in Postgres too, so a chat survives a restart or a deploy. You do not lose your thread because we shipped something.

The model sits behind one interface with more than one provider available, so the reasoning engine can be swapped without touching the tools it calls. Model pricing and capability move quickly. Being locked to one vendor is a decision worth not making.

Message deduplication moved out of application memory and into a database constraint early on, after a redelivered webhook produced a double reply. A constraint survives a restart. A set in memory does not.

It is actually running

This is not a prototype recorded once for a demo video. It is deployed behind automatic TLS, a token gated webhook and a sender allowlist, with CI that builds and deploys on every push, waits for a health check before switching traffic, and rolls back with one command.

That last part is not a detail. Plenty of AI projects work on the machine they were built on. The gap between that and a system a business can rely on is mostly operations work, and it is the part that gets skipped.

What this means for you

If you are evaluating an assistant that can act inside your business, the questions that matter are about the boundary, not the intelligence.

• Which actions can it take without a human? There should be a specific list, and everything on it should be trivially reversible.
• Where is that rule enforced? If the answer is "in the prompt", it is a preference and not a rule.
• What happens when two people act at once? Somebody should be able to answer this precisely.
• Where do your documents live? Retrieval means your content is stored somewhere. You should know where and in what form.

An assistant with write access to your business is only as trustworthy as the narrowest thing standing between it and a mistake. It is worth asking what that thing is.