By Revaz Ghambarashvili, AI Lead at Redberry – creator of the open-source LarAgent WhatsApp framework. July 8, 2026
We built an AI feature that turns a sentence into a working marketing automation – and the hard part was not the AI. It was making the AI’s output safe to run against real customers on a channel that punishes mistakes. Here’s what we learned shipping it into a client’s production platform.
Marketing automation tools have a usability problem that gets worse as they get more capable. Marketers know what they want to run – recover abandoned carts, retarget high-value customers in specific countries, follow up after a purchase – but turning those ideas into working automations means configuring triggers, conditions, and delays node by node in a visual builder. Testing an idea means building the flow by hand. Localised or personalised campaigns mean stacking layers of logic manually. Campaign iteration slows to the speed of flow-building, and the best ideas never make it into the tool.
Our team ran into this directly on a client’s product – a Shopify-integrated WhatsApp marketing platform used by e-commerce merchants. We solved it by building an AI automation builder into the platform: a merchant types a marketing goal in plain language, and the system generates a complete flow – triggers, conditions, delays, and messages, wired together and ready to edit and publish.
What did the platform already do – and why was it still slow?
The builder was capable; assembling flows by hand was the bottleneck. At its core is a visual, node-based flow builder where every automation is a graph: one trigger as the entry point, optional condition nodes with YES/NO branching, delay nodes for timing, and action nodes that send approved WhatsApp templates. It supports ten triggers (order placed, abandoned checkout, back-in-stock, customer tagged, and more), eleven condition types, and AND/OR grouping – so a merchant can express “order value above 100 AND customer country is Germany.” None of that is unusual; most serious martech has some version of it. The problem is effort: the builder could express almost any campaign, but each one had to be assembled by hand, and the merchants with the most ambitious ideas paid the highest setup cost.
What does the feature actually do?
A merchant types a goal – “Send a WhatsApp message if the order is over $100 and the customer is in Germany” – and the system generates the flow. But not immediately. First it returns a plan in plain language: a trigger on order placed; an AND condition group checking order value greater than 100 and customer country equal to Germany; if yes, send the message action, if no, end. The merchant reviews and edits that plan before anything is created. Only after approval does the system generate the actual flow – every node created, configured, and connected on the canvas. Merchants can reference their existing triggers and message templates by name in the prompt, so the AI builds with the assets they already have.
Why show a plan instead of just building the flow for Whatsapp?
Because the cheap moment to catch a misunderstanding is before anything runs. We considered direct generation – prompt in, finished flow out – and rejected it. It demos better, but it hides how the AI interpreted an ambiguous request. Showing the plan first surfaces that interpretation while it costs one click to fix, instead of after a live automation has messaged the wrong customers. On a channel where a bad flow can spam real people and get a merchant’s WhatsApp sender-quality rating downgraded, that review step earns its place.
How is the AI stopped from generating something that can’t run?
By never letting it write freeform anything. The feature is a multi-agent pipeline built on LarAgent – the open-source Laravel AI-agent framework created by our AI Lead – sitting on the platform’s Laravel backend. The work is split across specialised agents: a planning agent that first decides whether the request is even possible against the platform’s documented capabilities and drafts the plan; a guard agent that screens the prompt for content violations – violence, profanity, off-topic, and illegal or inappropriate content; a node generator that emits the flow; and an agent that wires the nodes into a valid graph.
The load-bearing decision was constraining what the AI can produce. Every agent returns a typed, structured object – not prose – validated against a fixed schema of the platform’s real building blocks: the defined triggers, the supported condition types, the delay options, the approved message templates. When the generator needs a template or a currency, it calls a tool that returns only templates and currencies that actually exist in the platform; it cannot invent a template that was never created. It doesn’t write code, and it can’t produce a step the automation engine can’t execute. It assembles the same node-and-edge graph a merchant would build by hand.
That distinction is the whole game. This is not AI that writes text describing an automation; it’s AI that outputs the automation itself, as data. Because the output is a structured graph rather than freeform text, it can be validated programmatically before the merchant ever sees it – referenced templates must resolve to approved ones, and the graph’s connectedness is checkable by machine in a way that free-form prose never is. Frequency caps and exclusion rules are reviewed rather than skipped.
Those guardrails exist because WhatsApp is a strict channel. Messages outside a customer-service window must use pre-approved templates. Consent has to be respected on every send. Merchants who over-message get their sender-quality rating downgraded by the platform itself. An AI feature that generated technically valid but non-compliant flows would be worse than no feature at all – so the compliance boundary isn’t a filter bolted on at the end; the generation operates inside those constraints from the first token.
What would we tell other WhatsApp product teams? The plan-gate-generate loop.
Four principles carried this project, and they apply well beyond martech:
- Generate structures, not prose. The feature is trustworthy because a machine can validate its output before it runs. If your product has a structured internal representation – workflows, rules, configurations, queries – that’s where AI generation can be made safe.
- Limit the building blocks. Every capability the AI can touch is something you have to validate. Restricting generation to existing, tested components turns an open-ended reliability problem into a bounded one.
- Keep a human checkpoint where mistakes are expensive. The plan-review step costs a few seconds and prevents the failures that actually hurt: wrong audience, wrong logic, wrong timing.
- Spend your effort on validation, not generation. The underlying models improve without you. The evaluators, the constrained inputs, and the review loop are what made this dependable in production – and they took more engineering time than the generation itself.
The pattern – plain-language intent, agent-orchestrated planning, constrained generation into a validated structure, human approval – applies to any product with a workflow builder, a rules engine, or a configuration layer users find hard to learn. It’s the same approach we use in our AI agent development work at Redberry, where we help teams prove agentic automation on one real workflow before committing to scale.
The merchants on this platform never asked for AI. They asked for campaign ideas to become working automations faster. Keeping the focus there – the workflow, not the technology – is what made the feature something people actually use.
