Back to Projects





AI Agents
CRM Digital FTE — Omnichannel AI Customer Success Agent
Autonomous AI customer success agent handling Gmail, WhatsApp, and Web Form simultaneously. Built with OpenAI Agents SDK on Groq LLaMA 3.3 70B, FastAPI, PostgreSQL with pgvector for RAG, AIOKafka event streaming, and deployed on Kubernetes with dual HPA auto-scaling.

// Problem
A SaaS company needs 24/7 customer support across 3 channels but human FTEs cost $75,000/year. This Digital FTE operates at under $1,000/year with no downtime and no sick days.
// Solution
5-tool OpenAI Agents SDK agent with cross-channel customer identity resolution, pre-LLM guardrails for pricing/legal/aggression, idempotent Kafka pipeline, and production Kubernetes deployment with separate API and worker HPA policies.
// Screenshots

Customer submits a High-Urgent technical support ticket — AI agent picks it up within seconds

Ticket confirmed — unique tracking ID generated, AI response guaranteed within 5 minutes

Web Form webhook live — ticket_id created, AI response queued, estimated_response_time returned

Live PostgreSQL schema — all 8 tables: customers, conversations, messages, tickets, knowledge_base, and more

Production stack running: API, Kafka, PostgreSQL, metrics, and worker containers all live
// Tech Stack
[OpenAI Agents SDK][Groq LLaMA 3.3 70B][FastAPI][PostgreSQL + pgvector][AIOKafka][Next.js][Docker][Kubernetes][Twilio][Gmail API (Pub/Sub push)][sentence-transformers]
// Metrics
- ✓3 channels handled simultaneously — Gmail (Pub/Sub push), WhatsApp (Twilio), Web Form
- ✓8-table PostgreSQL CRM schema with pgvector cosine similarity RAG
- ✓Dual HPA: API pods 3→20, Worker pods 3→30 (70% CPU trigger)
- ✓Idempotent Kafka producer (acks=all) — zero duplicate ticket processing
// Highlights
- →5 function_tools: search_knowledge_base (pgvector + ILIKE fallback), create_ticket, get_customer_history (cross-channel last 20 msgs), escalate_to_human, send_response
- →Pre-LLM guardrails: keyword check for pricing_inquiry, aggressive_language, legal_threat — agent never sees escalation-worthy messages
- →Cross-channel identity resolution via customer_identifiers table — same customer on email and WhatsApp recognized as one record
- →contextvars processing context: customer_id, conversation_id, channel set once per Kafka message — no parameter threading
- →asyncio.Queue fallback for Hugging Face Spaces deployment — no Java/Kafka required in cloud demo
- →Channel-aware response formatting: email gets formal greeting + sign-off, WhatsApp capped at 300 chars, web form triggers email notification