Customers message the store in Telegram, WhatsApp and other channels with product and order questions, but managers can't keep up at peak times, overnight or on weekends, and checkout often falls apart across several scattered messages.
We built an AI consultant with a shared core across channels: the model carries the conversation and picks products from the catalog and knowledge base, while a separate deterministic code path handles the total, address, invoice and payment confirmation; complex or unusual cases are handed off to a manager with a conversation summary.
Routine questions about stock, price and checkout are handled automatically around the clock, and the CRM and the manager get an order already assembled - total, address, items - with no chat thread to sort out by hand.
Customers write in when a manager may not be around
A large share of an online store's buyers start choosing not on the website but in a messenger. In Telegram, WhatsApp and other channels they ask whether an item is in stock, how much it costs, which option suits them, how to pay, and when delivery across Ukraine via Nova Poshta will arrive.
At peak times managers cannot keep up with everyone. At night and on weekends a question may go unanswered, and by the working morning the customer has already moved to another store. Even when a manager is available, the selection takes time: you have to find a suitable model, check the variation and stock, then pull the contacts, address and order contents out of the conversation.
Placing an order often gets spread across several messages. In one the customer names the product, in another the city, in a third the branch office, and the payment confirmation arrives later still. You cannot automate such a conversation with a single form: a person writes freely, clarifies, changes their mind, and comes back a few hours later.
For this flow we built a single AI consultant with a shared core for the different channels. It runs the conversation and helps with the choice. Everything where a mistake affects money, delivery or order contents is moved into ordinary predictable code or handed to a manager.
One conversation passes through several handlers
Take a customer asking about a product and its options. The model understands the question and decides what data it needs. It can turn to the catalog, check availability, read the terms from the knowledge base, and return cards with a photo, price and link.
If the customer has made up their mind, the conversation moves into the ordering loop. The code calculates the total, checks the address, creates an invoice, and forms structured data for the CRM. If a photo, a voice message or an atypical question comes in, the auto-reply in that conversation stops and a human steps in.
The model here is not a scripted bot with a "pressed A - got B" branch. It chooses the tool to fit the meaning of the message itself. But a tool is not a paragraph in a prompt - it is a function over the store's real data, with a defined input and result.
The main engineering work was therefore not in connecting a ready model to a chat. We had to decide which functions to give the agent, which arguments to allow, in what form to return the data, and how to explain to the model the boundary between similar actions. Searching for a product, clarifying a specific variation, and answering from the knowledge base can look like a single conversation to the customer, but inside they are different tools with different sources of truth.
After calling a tool, the model reads its response and decides whether there is enough data for a message to the customer. A single request may require several calls: first find a group of products, then clarify a specific variation, and only after that formulate a recommendation.
The instructions were tuned on messages written the way people actually write in messengers: with words dropped, imprecise names, and several intentions in a single line. The agent had to choose the right function and not confuse knowledge about store rules with a fact about the availability of a specific product.
The catalog had to be prepared before the agent
In the raw export, products do not form a tidy "size plus color" table. One category has size and material, another has its own axis of characteristics, and a third is missing some properties entirely. Variations are dynamic, and there is no universal set of columns for the whole assortment.
Identical models in different versions were grouped into a single card. Otherwise the customer would get two dozen nearly identical results instead of one clear product with options. This grouping was not assigned automatically: it was shown to the client and corrected until the structure matched how the store itself understands its assortment.
Such agreement matters, because technically similar items are not always variants of one product from the store's point of view. The system did not try to invent a product structure on its own from matching names. The client confirmed the groups, and only after that did they become the basis for search and cards in the conversation.
For the products we prepared descriptions and search attributes. From the catalog we assembled a compact map that the agent uses for quick orientation. The exact price, the characteristics of a specific variation and the stock it still requests from the database at the moment of the reply.
The search sequence is essential: first the system keeps only items in stock, then searches among them by the meaning of the request. The model does not receive an out-of-stock product as an acceptable result and cannot confidently recommend something that is not currently in the warehouse.
This is how preparing the catalog becomes part of the consultant's quality. Tidy groups, attributes and current stock give the model the material for a useful answer, and their absence is not compensated by anything.
A strong language model on top of chaotic cards only retells the chaos more convincingly.
Every strict rule grew out of a specific mistake
Free dialog makes the model useful, but its answers are non-deterministic. To similar lines it may react a little differently, and a small deviation when working with a product sometimes turns into a wrong cart or an invented identifier.
The agent was run through dozens of normal, poorly worded and nonsensical messages. Fixing one unfortunate answer was not enough: after each class of mistakes a constraint appeared that also works in the following dialogs.
| Mistake caught | How the behavior was constrained |
|---|---|
| The model referred to a non-existent product or identifier | Only items returned by the database may be shown and ordered |
| The wrong variation ended up in the cart | After adding, the agent checks the result against the choice, rolls back the erroneous item and adds the correct one |
| The answer was built on a stale fragment of memory | Price and availability are requested from the current source every time |
| The message "I paid" was taken as confirmation | The fact of payment comes only from the payment service |
The customer does not see this self-check. The agent fixes the cart and continues the conversation, without turning its own mistake into a separate message and needless alarm.
These rules do not make the model deterministic as a whole. They constrain the areas where freedom of wording can harm the order, and leave flexibility where it helps to understand the person.
In parallel, the agent keeps the state of the conversation: the customer is still choosing, is already ready to place the order, or is waiting for a manager. This is not a decorative label. The permitted next step depends on the state: continue clarifying, move to the ordering code, or stop the automatic reply after the handover to a human.
The total, payment and delivery are not the model's to decide
In consultation, different wordings are acceptable: two good salespeople would also answer in different words. In an order such freedom is dangerous. A mistake in the total, the contents or the delivery branch is no longer an awkward phrase but a ruined purchase.
That is why the system is split into two loops:
| Task | AI consultant | Deterministic code |
|---|---|---|
| Understand a free-form question | ✓ | ✗ |
| Pick a product and explain the options | ✓ | Gets data from the catalog |
| Calculate the total | ✗ | Calculates from the order contents |
| Check the city and branch | ✗ | Checks existence and delivery limits |
| Create an invoice | ✗ | Returns a link for full payment or prepayment |
| Confirm payment | ✗ does not trust the customer's message | Gets the fact from the payment service |
| Hand off the order | Forms the conversation context | Sends the "what, where, to whom" fields to the manager and CRM |
For an oversized item, not every branch will do. If the customer named a regular one, the code checks the limits and offers the nearest freight branch. The model does not guess which branch was meant and does not replace the check with a nice confident answer.
The invoice is also created outside the AI. The code supports full payment and prepayment, gives the customer a link, and waits for the payment service's confirmation. A line in the chat stays a line until an external source reports an actual payment.
After the order is placed, the CRM and the manager receive a ready order structure, not a set of messages that still needs to be parsed by hand. The AI brings the customer to a choice; the further actions repeat identically no matter how exactly the conversation was worded.
Both the tool loop and the dialog memory have a hard stop
The agent works in iterations: it calls a tool, gets a result, decides whether the next one is needed. Without limits it can get stuck in this loop and keep calling functions instead of answering the customer.
Each tool therefore has its own call counter, and the whole dialog has a shared iteration limit. On the last allowed step the tools are disabled. The model has to form text from the context already gathered and cannot start another round.
This is how technical "thinking" gets a predictable boundary in time and number of calls. The customer sees an answer, and the cost of the model does not grow because of an endless internal loop.
The second boundary runs through memory. History in a messenger can stretch on for weeks. If it is passed in full every time, answers become more expensive and slower, and old information keeps influencing new choices after prices and assortment change.
After a pause the context is compressed: the customer's interest and the significant decisions remain, while service details and repetitions are discarded. About a day later the previous correspondence is detached from the agent's active context. For the customer it is still visible in the chat, but the model starts a fresh conversation without the long tail.
This both limits the cost of tokens and protects against stale memory. Even if a product name was preserved in the brief context, the consultant asks the database again for the current price and availability.
Both limits work together. Neither a long correspondence nor a complex request turns the next answer into an uncontrollably growing call to the model.
The engine and the channel can be replaced separately
The language model is connected through an adapter and is not an irreplaceable part of the core. Two engines are used at the moment. The stronger one is chosen for complex wordings, ambiguous requests and a careful tone; the cheaper one covers typical consultations at comparable quality on simple dialogs.
If an external provider gets more expensive, loses availability or handles the task worse, the engine is changed without rewriting the consultant's behavior. The architecture is not tied to a specific plan: the prices and capabilities of models change faster than the store's rules.
Other engines have not been connected yet because there was no practical need. This is not a limitation of the architecture: a new provider comes in through the same adapter if the existing options stop being satisfactory on price, availability or quality. The choice remains an operational decision, not a reason to remake the agent.
The messengers are connected on the same modular principle. A channel brings messages into the shared core and returns a reply to the user; the catalog, knowledge base and order rules stay shared. A new channel does not require assembling a separate consultant with its own logic.
Three fragments add up to one customer thought
People do not write in a messenger in paragraphs. The customer sends "hi", then "do you have this", and a few seconds later "how much". Formally these are three messages; by meaning, one question.
While the agent is processing the current line, new messages accumulate and pass into the next step. It does not launch three parallel answers to three fragments and returns a coherent reaction to the customer's thought.
The manager steps in together with the context
Right now the agent works with text. It does not try to interpret a photo or a voice message at random. For such a conversation the auto-reply is turned off, the manager gets a notification, and continues the conversation without competing messages from the bot.
The handover also happens for atypical cases that are not closed by the tools and the knowledge base. The human joins not an empty chat: the system assembles a short summary of what the customer was looking for, which options they chose or rejected, and how far they got toward an order.
The summary also keeps an assessment of interest, so the manager can tell a chance question from a customer who was already choosing a specific variation. Even when the order has not been created yet, the conversation continues from the point reached, and the human does not have to ask the product name again and figure out the need from scratch.
The handover to a manager really does stop the AI in that particular conversation. This protects the customer from a situation where a human and a bot answer differently at the same time.
Even if the purchase did not go through, the manager gets an interested customer with a history, not a faceless "someone asked something" notification.
An abandoned cart returns to the same channel
The messenger account is linked to the customer's account on the website. If an item is left in the cart, after a set interval the consultant can remind them of the unfinished purchase.
The message arrives where the customer last communicated. A WhatsApp user is not sent the same text in Telegram as well. The intervals and the messages themselves are configured in the admin area.
The configuration is needed not only for the tone of the message. The store sets the pause before the next contact and the length of the whole series, without changing the consultant's code. The channel is chosen by the customer's last activity, so one cart does not create several parallel reminder chains.
The reminder series is finite. After a set number of attempts the customer gets an inactive status, and the system stops writing. Returning a cart does not turn into endless automatic spam.
An unsuccessful dialog adds to the knowledge base
If the consultant did not find an answer and handed the question to a manager, that case remains material for improvement. The administration reviews problem dialogs, sees what knowledge was missing, and adds it to the base.
At the next similar question the agent gets a new answer through the same tool and no longer calls a human. The behavior improves through the content of the knowledge base, without changing the program code and retraining the model on every new question.
This is how the boundary of automation gradually shifts along real requests. The team does not try to invent all possible questions in advance, but supplements the knowledge where the customer actually found a gap.
The store gets consultation at any time, but not an autonomous salesperson
Typical questions, search by availability and initial selection stop depending on the managers' work schedule. A human joins for a complex case, media or a ready order, rather than repeating the same delivery terms in every chat.
The boundary of the decision stays explicit. The AI does not count money, does not confirm payment, does not guess the address, and does not continue the dialog after the handover to a manager. It consults within the available tools and the knowledge base. The code places what must repeat identically.
Right now media from the customer stays with a human. Possible next steps are to teach the system to parse such messages and analyze dialogs more deeply. These features can connect to the existing channels and the shared core, but are not considered an already implemented part of the project.
Oleksandr
The client cleared this case study with the technical detail intact, so we go further here than usual. We still keep the client's name and business specifics private - this is only about the engineering.