WhatsApp Automation & AI Agent Platform

Automated WhatsApp workflows for a client: incoming messages arrive by webhook, get routed by user state, and are answered by conversational agents on LLaMA and OpenAI APIs — for customer queries, appointments and payments. The client is described only as a client of Shivohini TechAI; no client names or confidential details are published here.

The client needed customers to be able to ask questions, book appointments and pay over WhatsApp without a person answering every message. That is harder than a single chatbot reply: each incoming message has to be matched to a user and to where that user is in a conversation, the AI answer can take seconds while WhatsApp expects the webhook to be acknowledged immediately, and the conversation history has to survive between messages.

The brief also changed shape as the work went on, which is why part of my role was talking to the client directly to find out what they actually needed rather than building to the first description.

Backend-focused AI/ML intern. I built the backend for the agents, the WhatsApp automation (webhook ingestion, message routing, template management via the Meta Business API), and talked directly to the client to work out what they actually needed.

A FastAPI service receives WhatsApp webhooks and hands the work — message processing, AI inference and database writes — to Celery workers over Redis, so the webhook returns immediately. User state and conversation history live in PostgreSQL.

• Keeping context across turns without blowing the token budget.
• Migrating the client's databases from MySQL to Supabase/PostgreSQL mid-project while the agents kept running.

The platform worked as designed: webhooks are acknowledged straight away while Celery workers handle message processing, AI inference and database writes; user state and conversation history persist in PostgreSQL; and the client's databases were moved from MySQL to Supabase/PostgreSQL mid-project while the agents kept running. The detail of that migration is written up in the migration guide.

I am not publishing message volumes, response times or hours saved for this client, because those figures belong to them and were not cleared for publication. This page only states what the system does.

• Context management is a trade-off: keeping more history improves answers but spends more of the token budget, so older turns have to be summarised or dropped.
• No load figures are published, so this page is not evidence of throughput at any particular volume.
• What I would add next: idempotent webhook handling so a re-delivered event is never processed twice (see the idempotency guide), a fixed question set to evaluate agent replies before changes ship (see the RAG evaluation checklist), and alerting on queue age and failed messages.