FunilChat AI

The problem and constraints

FunilChat AI exists to answer a WhatsApp message before a human has time to open the app. The client, WA Financial Services, helps Brazilian immigrants in the United States navigate financial and legal paperwork: tax filings, entity formation, the kind of forms where a missed deadline has real consequences. Most first contact happens on WhatsApp, at hours when nobody is at a desk, and the founder, Wolney, was the only person answering it. Every minute a lead waited for a reply was a minute they might message a competitor instead.

The obvious answer (put an AI in front of WhatsApp) comes with a much less obvious set of constraints once the business is real and the AI is talking to real prospective clients about real money and real immigration status.

The first constraint was earning trust, which mattered here more than raw speed. A prospective client deciding whether to hand a stranger their tax documents is reading every signal for whether this operation is competent and careful, and a slightly-wrong AI answer costs far more than a shrug and a retry would. If the AI and a human both reply in the same thread, or the AI keeps talking after a human has already stepped in, that one visible stumble does more damage than a slow reply ever would. The handoff between AI and human had to be invisible from the customer’s side and unambiguous from the system’s side, never both replying, never neither.

The second constraint was that this had to work for more than one client without becoming more than one system. WA Financial Services was tenant one, but the plan from the start was to sell the same product to other small service businesses running their first contact over WhatsApp. That ruled out anything that assumed a single, hardcoded business (one WhatsApp number, one knowledge base, one set of users), because every one of those assumptions would have to be undone later, on a live system, for the second paying client. At the same time, there was no operations team and no budget for one: whatever “supports multiple tenants” meant, it had to be something one developer could run and reason about alone.

The third constraint was regulatory weight without a regulatory budget. The end customers here are submitting the kind of documents (SSN, ITIN, EIN-equivalent identifiers, immigration-adjacent paperwork) that a fintech or legal-services company would have a compliance team and a security budget for. This system has neither. Every security control (multi-factor authentication, session revocation, encryption of sensitive fields, malware scanning on uploaded documents, an audit trail of who changed what) had to be built into the product itself, because there was no separate security layer or team to bolt one on afterward.

The fourth constraint was operational: a single VPS, no staging environment, and a founder who is also the primary human agent answering the WhatsApp CRM every day. Every migration runs directly against the production database. There is no dress rehearsal environment where a schema change gets tried first. The safety net is careful review before running it; there is no copy of production to break instead.

The last constraint was vendor risk on the one dependency the whole product exists to talk to: WhatsApp itself. There is no official WhatsApp Business Cloud path that fits a self-hosted, cost-sensitive setup at this stage, which means the system depends on a WhatsApp automation provider whose terms, pricing or reliability are outside anyone’s control here. The system had already changed providers once. Whatever got built next had to assume it would happen again.

Architecture

A message starts on the customer’s phone and lands on a per-tenant WhatsApp module, one connected instance per client, so tenant A’s conversations never physically pass through tenant B’s session. From there it goes through Redis, which exists for one reason: people rarely send one WhatsApp message per thought. A real customer sends three or four short messages in a row, and answering after the first one means answering half a sentence. Redis holds and groups messages arriving in a short window so the AI responds to the whole thought instead of interrupting it.

The grouped message reaches an n8n workflow, which is the actual brain of the first-response layer: it holds the AI agent (backed by OpenAI), the knowledge base lookup, and the handoff logic, all as one orchestrated flow rather than scattered across services. Every time this workflow needs to read or write anything that belongs to a specific tenant (a customer record, a conversation, a task created from a conversation), it goes through the FastAPI backend rather than touching Postgres directly.

That routing choice is what makes tenant isolation real instead of aspirational. The backend sets a session-scoped Postgres variable identifying the current tenant on every request it handles, and row-level security policies on all twenty-one tenant-scoped tables use that variable to silently exclude every row that doesn’t belong to the caller. A developer who forgets a WHERE tenant_id = ... clause somewhere in application code does not leak another tenant’s data, because the database itself refuses the row before the application ever sees it. The one place this boundary is not airtight is the automation role n8n’s workflow runs as: it does not set that session variable the way the API does, so it runs with a bypass instead, a narrow, deliberately visible exception to an otherwise fail-closed rule, discussed as its own decision below.

The React CRM is where a human agent sees the same conversation the AI is handling, in something close to real time. This is also where the handoff actually happens: a button labelled “Assume” flips a flag on that conversation, and every subsequent check the AI workflow makes before sending a reply sees that flag and stays silent. Nothing about this is negotiated between the AI and the human. It’s a single boolean the workflow reads before it is allowed to speak, which is also why it was cheap to make watertight. Thirty minutes after the last human reply with no further action, the flag clears itself and the AI resumes, so a conversation a human forgot to hand back doesn’t stay stuck in silence indefinitely.

Everything the AI or the human agent touches is written by the same backend, validated by the same schema, and constrained by the same row-level security. There is exactly one write path into the system of record, regardless of which side of the human/AI boundary the write came from.