Conversational-Ai

Fourth and final post in this series about a WhatsApp lead-qualification agent we built at a CRM for small businesses. The engine (Postgres and Celery durable runs), the loop (debounce, polling, exits), and the LLM layer (structured extraction, cost metering, injection defenses) are the first three posts. This one answers the question every engineer asks about agent work, usually first: how do you eval it? The honest answer: our v0 is about 90 lines of framework, four scripted scenarios, a staff-only page, and a human doing the judging. No scoring pipeline, no LLM-as-judge, no eval database. This post is why that is a design and not a shortcut, and why we skipped the eval packages we had already shortlisted. ...

This is the third post in a series about a WhatsApp lead-qualification agent we built at a CRM for small businesses. The first post covered the engine: durable agent runs on a Postgres table and Celery, with a lease for crash safety. The second post covered the loop: debouncing message bursts, polling the conversation, nudging through silence, and treating every exit as a designed outcome. This post is about the layer the other two exist to protect: the LLM calls. ...

In the last post we built the engine: a Postgres row per attached agent, next_run_at as the scheduler, a lease for crash safety. This post is about the loop that runs on top of it, how a WhatsApp lead-qualification agent at a CRM for small businesses decides when to speak, when to wait, and when to shut up. The agent’s job is simple to state: a lead messages a business (say, a car dealership), the agent attaches to the conversation, works through a configured list of qualification questions (which model, what timeline, what budget, trade-in, test-drive day) and detaches when it is done or when a human takes over. The LLM parts (extraction, confidence scores, prompt defenses) are the next post. This one is about everything around the LLM, which is where the product actually lives. ...