The problem

Enterprise chatbots needed to connect customer workflows, product knowledge and backend systems. A useful conversation could require a FAQ answer, a document lookup, an automated action or a transfer to a live agent. The product also had to handle high-volume messaging workloads.

My role

My first nine months focused on backend/services and enterprise delivery, followed by product engineering. I worked with 25+ enterprise customers in an environment spanning approximately 50 integrations overall. I contributed to both the underlying Dynamic Chat and Zero Setup features and their customer delivery.

Architecture / Yellow.ai

A conversation with several possible paths

Intent routing and knowledge paths sit above a high-volume messaging backbone.

Request / data flowEvent / ingestion flowControl / fallbackSwipe to explore →
A conversation with several possible pathsIntent routing and knowledge paths sit above a high-volume messaging backbone. Customer channels: Chat / WhatsApp; Multi-turn conversations. Input checks: Validate incoming messages; Apply safety constraints. Intent + entity routing: BERT / spaCy · adapted open-source models; Choose knowledge, task or conversation path. Knowledge answers: Trained FAQs + documents; Zero Setup: website / file ingestion. Business workflows: Backend actions + integrations; CRM / ticketing / customer systems. Dynamic Chat: Goal-oriented LLM conversations; Context-sensitive responses. Output + confidence checks: Validate generated responses; Select answer or fallback. Fallback / live agent: Nearest-match suggestions; Escalate when automation fails. Customer response: Grounded answer or task result; Continue the conversation. Kafka event processing: Partition / workload distribution; 50–100M product events per day. Application databases: MySQL · PostgreSQL · MongoDB; Query and index optimization. Redis: Cache frequently accessed data; Reduce repeated database work. Discovery → architecture / cost tradeoffs → product implementation → enterprise rollout. 25+ enterprise customers · approximately 50 integrations across the platform01 / CONVERSATION RUNTIMEKnowledge, task execution and human handoff are distinct paths02 / MESSAGING & PERSISTENCEShared platform infrastructure supporting customer workloads03 / PRODUCT & CUSTOMER DELIVERYImplementation decisions informed by enterprise use casesanswerfallbackhot readsCustomer channelsChat / WhatsAppMulti-turn conversationsInput checksValidate incoming messagesApply safety constraintsIntent + entity routingBERT / spaCy · adapted open-source modelsChoose knowledge, task or conversation pathQUERY ROUTERKnowledge answersTrained FAQs + documentsZero Setup: website / file ingestionBusiness workflowsBackend actions + integrationsCRM / ticketing / customer systemsDynamic ChatGoal-oriented LLM conversationsContext-sensitive responsesOutput + confidence checksValidate generated responsesSelect answer or fallbackFallback / live agentNearest-match suggestionsEscalate when automation failsCustomer responseGrounded answer or task resultContinue the conversationKafka event processingPartition / workload distribution50–100M product events per dayPLATFORM SCOPEApplication databasesMySQL · PostgreSQL · MongoDBQuery and index optimizationRedisCache frequently accessed dataReduce repeated database workDiscovery → architecture / cost tradeoffs → product implementation → enterprise rollout25+ enterprise customers · approximately 50 integrations across the platform
A conceptual routing flow. Knowledge retrieval and backend actions are alternative paths selected for the query; they are not mandatory sequential calls. Customer discovery and feedback shaped the workflows.
Read the architecture as text

Intent routing and knowledge paths sit above a high-volume messaging backbone.

  • Customer channels: Chat / WhatsApp. Multi-turn conversations.
  • Input checks: Validate incoming messages. Apply safety constraints.
  • Intent + entity routing: BERT / spaCy · adapted open-source models. Choose knowledge, task or conversation path.
  • Knowledge answers: Trained FAQs + documents. Zero Setup: website / file ingestion.
  • Business workflows: Backend actions + integrations. CRM / ticketing / customer systems.
  • Dynamic Chat: Goal-oriented LLM conversations. Context-sensitive responses.
  • Output + confidence checks: Validate generated responses. Select answer or fallback.
  • Fallback / live agent: Nearest-match suggestions. Escalate when automation fails.
  • Customer response: Grounded answer or task result. Continue the conversation.
  • Kafka event processing: Partition / workload distribution. 50–100M product events per day.
  • Application databases: MySQL · PostgreSQL · MongoDB. Query and index optimization.
  • Redis: Cache frequently accessed data. Reduce repeated database work.

Discovery → architecture / cost tradeoffs → product implementation → enterprise rollout

25+ enterprise customers · approximately 50 integrations across the platform

Start with the customer workflow

I worked with customer stakeholders, product and customer-success teams to map requirements to platform features. Before implementation, I explained architecture options, resource needs, cost and delivery-time tradeoffs to director-level stakeholders using accessible diagrams and discussions.

Customer feedback informed the product work. Dynamic Chat supported goal-oriented LLM conversations, while Zero Setup supported bot setup from website and document knowledge. My role covered implementation and delivery for both.

Improve intent handling and safe routing

I worked with BERT/spaCy-based NLP and adapted open-source models using LoRA for intent and entity handling. Owned components achieved a 35% relative improvement in intent-classification accuracy and a 60% reduction in unrecognized inputs or fallback rates.

Queries were routed across FAQs, document knowledge and automated flows. Input validation, output checks, nearest-match suggestions and live-agent handoff provided controls when a reliable automated answer was unavailable. CSAT improved 35% relative to the baseline.

Support high-volume messaging

The product handled approximately 50–100 million events per day across customers. I refined Kafka partitioning and workload distribution for high-traffic segments such as banking and marketing campaigns.

I reduced API response time from 820 ms to 490 ms by optimizing queries across MySQL, PostgreSQL and MongoDB and moving hot reads into Redis. The event volume describes the platform; the latency change describes the API work.

Outcomes

  • Delivered enterprise chatbot solutions for 25+ customers by translating customer requirements into platform features, implementing integrations and coordinating launches with product and customer-success teams.
  • Improved intent-classification accuracy by 35% relative to the baseline and reduced unrecognized inputs or fallback rates by 60% in owned components by improving intent/entity handling and adapting open-source models with LoRA.
  • Improved CSAT by 35% relative to the baseline by strengthening query routing across FAQs, document knowledge and automated workflows, with nearest-match suggestions and live-agent handoff when required.
  • Reduced API response time from 820 ms to 490 ms by optimizing MySQL, PostgreSQL and MongoDB queries and caching hot reads in Redis.

Tradeoffs

Deterministic workflows remain useful when a business process requires a specific action. LLM-driven handling adds flexibility, but confidence checks, bounded fallbacks and human handoff are necessary parts of the experience.

Tools and technologies

Node.jsPythonKafkaMySQLPostgreSQLMongoDBRedisBERTspaCyLoRAintent classificationentity recognitionconversational AICRM integrations

Related work