Grow4Me is an AI agent that talks to a brand’s customers on its website and WhatsApp, directs them to the right product or department, and collects requests for the team. Most architectural decisions were not about model choice. They concerned data sources, limits and when a person should take over. This article explains them.
Where the agent’s knowledge comes from #
A language model does not know the brand’s products; it needs a catalogue. Rather than embedding it in the model, we built a layer that retrieves relevant information for each question and supplies it to the model: retrieval-augmented generation, or RAG. Catalogue changes update the search index, not the model.
Two more sources connect alongside the catalogue: stock and rules. Without stock data, the agent may recommend unavailable products. Without rules, it may invent discount, return or delivery information. The brand defines the rules, which accompany every conversation; the agent follows what the brand has specified.
What the agent cannot do #
It is tempting to let the first version do everything. We began with the opposite: a list of prohibited actions. It cannot change prices, invent promotions, cancel orders or use personal data outside the conversation. In sensitive areas such as healthcare, it does not diagnose; it only directs users to the right department and stops when emergency language appears.
The list is included in model instructions and enforced in the application, providing a second safeguard if the model fails to follow instructions. Permitted actions are equally clear: finding products or departments, comparing options, providing stock and delivery information, opening a request form in the conversation and forwarding submissions.
Human handover #
Every conversation has a handoff threshold. If a customer repeats a question, uses complaint language or asks for something beyond the agent’s authority, the conversation is summarised for the team. The customer is clearly told that a team member will continue.
We regularly review handoffs and unanswered questions. If handoffs do not decrease, the problem is often missing or contradictory catalogue information, not the model. Knowledge gaps are therefore shown separately in the dashboard.
One agent for web and WhatsApp #
The website chat and WhatsApp use the same agent, catalogue and rules; the message format changes by channel. On WhatsApp, short options work better than long lists, and product links better than images. Continuing a conversation across channels requires a shared customer identity, a decision to make at setup.
Meta’s business-account rules apply on WhatsApp, including the customer-service window, message templates and approval. These may seem technical but shape the product; for example, the agent’s ability to start a conversation is limited.
Staying model-independent #
We did not tie the agent to one provider. Model calls pass through one layer, which changes when providers change. There is a cost: some provider-specific capabilities cannot be used, and tests must run across multiple models. In return, the model can change without altering the rest of the product.
Setup sequence #
- Connect catalogue, stock and rule sources; list the gaps.
- Document prohibited actions and enforce them in the application.
- Define handoff thresholds and the format of conversations passed to the team.
- Build a test set from real customer questions and rerun it after every change.
- Launch web first, then WhatsApp, and review handoffs regularly.
We set out the questions to ask before adding AI in 7 questions to answer before adding AI. If you want a similar function in your product, we offer it as part of our software development service.
Sources #
- WhatsApp Business Platform, Meta; customer-service windows and message-template rules
- Retrieval-Augmented Generation, Lewis et al. (2020); the source of the RAG approach
