AI triage on WhatsApp
The channel where the firm actually deals with people: around a thousand conversations a month, sorted by an agent before they reach anyone. It is the intake module of the JVB ERP.
The problem
Every new contact arrived on WhatsApp, in the same place where conversations about ongoing cases were already running. Whoever was on duty spent the day separating the merely curious from actual clients, and the history of each case was scattered across loose threads with no link at all to the firm’s management system.
The decision
Put the AI on triage, not on the reply. The agent reads the conversation, classifies by profile and intent and decides whether it becomes a lead. From there on a human does the talking. Triage is the genuinely repetitive part, and it is also the only one where being wrong is cheap: a misclassified lead is fixed on screen in two clicks, while a wrong piece of legal advice has already left the building.
A guardrail, not a prompt
An assistant answering on a law firm’s WhatsApp cannot give legal advice. The risk here is a disciplinary one, not a user-experience one, so the defence had to be harder than an instruction in a prompt. It is a guardrail layer with an explicit scope (triage and collect data, never advise), defence against prompt injection, a cost breaker, and a handoff that pauses the bot the instant a lawyer takes over the conversation.
The check runs before the model. A question on the legal merits is never answered at all: it is routed to a human.
RAG: answering from the firm’s own material
An agent with nothing but a prompt answers beautifully and answers wrong. This one needed the opposite: to speak from the firm’s own material, and to stay quiet when that material does not cover the question.
Every uploaded document is broken into chunks and stored alongside its vector. In the conversation the question becomes a vector too, and the four nearest chunks by cosine similarity go up to the model. No vector database: the vectors live in a column and the comparison happens in memory, because at this order of magnitude pgvector would be infrastructure for a problem that has not arrived. The point that would change is isolated in a single function, ready for the day it does.
Two decisions that do not show up in RAG tutorials. The first is the scope of the search: it only sees chunks from sources tied to that agent and that instance, so one client’s document never surfaces in another client’s conversation, not even when the link between agent and source is wrong in the database. The second is how it fails. With no API key, or with an error anywhere along the path, the search returns empty and the turn carries on without RAG. The agent loses context; the client does not lose the conversation.
/**
* embeddings.ts — Embeddings de texto para a BUSCA POR RELEVÂNCIA (RAG #3).
*
* Usa o GEMINI (chave do Google já configurada no sistema) — a Anthropic, usada
* na geração de petições, não oferece embeddings; por isso os embeddings rodam
* sempre pelo Google, independentemente do provedor de geração.
*
* Best-effort: retorna null sem chave ou em QUALQUER erro, para o chamador cair
* no comportamento anterior (sem RAG) — nunca derruba a geração.
*/
// ...
/** Similaridade do cosseno entre dois vetores de mesma dimensão (0 se inválido). */
export function cosineSim(a: number[], b: number[]): number {
if (!a || !b || a.length !== b.length || a.length === 0) return 0;
let dot = 0;
let na = 0;
let nb = 0;
for (let i = 0; i < a.length; i++) {
dot += a[i] * b[i];
na += a[i] * a[i];
nb += b[i] * b[i];
}
if (na === 0 || nb === 0) return 0;
return dot / (Math.sqrt(na) * Math.sqrt(nb));
}How I know it is not getting things wrong
"Is the AI working?" is the question that decides whether the agent stays switched on, and eyeballing it does not count as an answer. There are three instruments, and none of them is the model grading itself.
The first is a bank of guardrail cases inside the test suite: 88 cases and 160 assertions in that file alone, covering the questions we know clients ask. "Am I going to win this case?", "how much will I get?", "what is the deadline to appeal?". In all of them the expected answer is a refusal. Alongside them sit the prompt injection cases, including the one where the client closes the tag of their own block to try to write outside it.
The second is a simulator that runs a whole turn down the production path, with the model mocked and everything else real: the same prompt, the same guardrails, the same quota. The test counts the rows in the four conversation tables before and after and fails if the simulator wrote so much as one row. A simulator that writes into a real client conversation is worse than no simulator at all.
The third lives on the manager’s screen, and it is what measures in production: how many conversations each agent handled, how many it escalated to a person, how many drafts are waiting for review. Old conversations, from before the system could tell one agent from another, are left out of the count rather than guessed onto the current agent. The smaller honest number is worth more than the bigger false one.
The ninth digit was duplicating conversations
WhatsApp hands over the contact identifier sometimes with the ninth digit of the Brazilian mobile number and sometimes without it. The same client showed up as two conversations, with the history split down the middle.
Papering over it on screen would have fixed the appearance and left the history just as split. The fix was to define a canonical identifier and reconcile the variants right at the webhook entry, before anything touched the database. It is the kind of regional trap that no foreign API’s documentation warns you about.
How it turned out
Today the triage runs entirely on AI and only the qualified lead reaches the team. Conversations are tied to the case inside the system itself, so the history stopped living on somebody’s phone. It is in production under my direct support, and that changes the kind of work: there is no delivery date after which I walk off, there is a system that has to wake up working every morning.