Buttons, free text, and a big base
A Viber bot lives between two worlds: the button-driven menus people expect and the free-text questions they actually type, all against a broadcast base that can be enormous. A flat prompt mishandles all of it, forcing free text through menu logic, or replying to broadcasts it should not. Architecture is what lets one agent do each correctly.
The four layers
MyChatBot agents stack in layers. System sets identity, tone and guardrails. Role narrows the job, sales, support, reactivation, and several can run per bot. Memory is the Knowledge Base: Business Domain docs and a Product Feed, so answers are factual. Tools is where it acts, CRM writes, calendar, order creation. Edit the Feed and answers update; the prompt stays put.
Reading intent past the buttons
The agent classifies before it speaks: did the person tap a button, type a real question, or reply to a broadcast? It executes buttons cleanly, answers free text with Agentic Search, and turns a broadcast reply into a real conversation. Same brain, context-aware behavior, that is what makes a Viber bot feel helpful, not mechanical.
What silently burns credits
The quiet budget killers: re-loading the catalogue per message, re-asking for info already given, and verbose system text on every turn, multiplied across a huge base, this adds up fast. Fix it with narrow Agentic Search retrieval, CRM-backed memory so context persists, and lean system layers. On Viber, scale makes cost discipline non-optional.
Designing the handoff and shipping it
Hand-off Control is part of the design: define the stop-word, value threshold and emotional cues that route a chat to a human, with silent hand-off and Flight Control in Telegram. Then ship via the Configuration Wizard, which battle-tests and versions every change, so you tune tone and triggers without ever starting over.