On the Thursday before month-end, a grandmother planning Sunday lunch types into the app: "bobotie for eight on Sunday, my grandson is vegetarian, I want to spend less than R600, delivery Saturday morning." The meal assistant's reply is warm and sensible. It suggests a beef bobotie and a lentil bobotie for the grandson, yellow rice, and a tomato and onion salad. It would score well on any conversation-quality review.
The basket tells a different story. The mince is for four, because the recipe serves four and nothing scaled it to the seven meat eaters. There are two 6-packs of eggs where one would do. The brown lentils are in stock at the store today but not allocated to Saturday's delivery slot. The total is R640.
Ubuntu Grocer is a composite: a fictional South African grocery retailer whose scenario draws on lessons from real enterprise retail-agent delivery. Its people, systems and figures are illustrative and describe no single organisation. Part 1 argued that the model is the smallest part of the system. This part follows the journey that system has to complete, because the shopper does not buy the answer. She buys the basket.
Eleven stages from a sentence to a basket
Pieter van Wyk, the principal architect, mapped the journey as eleven stages and wrote beside each one who holds the truth.
Interpret (stages 1 and 2). The intent and meal-planning agent, a large language model (LLM) step, turns the request into structured intent (eight people, one vegetarian, R600, Saturday delivery) and proposes a meal plan. The model leads only these two stages, and their output is a structured proposal, not free text. After them it only parses recipe lines and assists in matching.
Translate (stages 3 and 4). Each recipe becomes ingredient lines, and each line is matched to products in the catalogue. Matching combines search over the catalogue with model re-ranking. Part 3 shows why this step needs an intermediate representation and cannot jump from "500 g mince" straight to a stock-keeping unit (SKU).
Constrain (stages 5 to 8). Hard constraints filter the candidates in code: no meat in the vegetarian dish, no product with an allergen the household has declared. The budget is a bounded constraint, checked against the whole basket and traded off with the shopper, never silently. Availability is checked for the fulfilment slot, not for the store right now. Substitution rules handle gaps. Quantities are computed from servings and pack sizes. Part 4 covers the constraint engine in depth.
Commit (stages 9 to 11). The basket agent proposes a basket; the orchestrator re-validates it and writes it to the existing basket service. The shopper reviews it, changes what she wants and checks out through the checkout Ubuntu Grocer already runs. The agent never takes that last step.
The eleven stages are not eleven agents. Most are deterministic code or calls to existing retail systems. The map gives each failure a place to live.
The answer can be right while the basket is wrong
Every defect in the grandmother's basket was invisible in the reply, and each belongs to a pattern Ubuntu Grocer's test team now checks first.
Scaling. A recipe has a serving count; a household has a size and a composition. Eight people with one vegetarian is seven portions of one dish and one of another. Scaling belongs in code, from the structured intent, not in the model's sense of how much mince "feels right".
Shared ingredients. Two boboties both use eggs, onions and milk. If each recipe adds its own products, the basket has duplicates; if neither accounts for the other, it has too little. Ingredients must be added up across the whole plan before products are chosen.
Availability in the wrong frame. "In stock" is not one fact. Stock at the store now, stock allocated to a delivery slot and stock at a click-and-collect point can all differ. Saturday's basket must be checked against Saturday's availability.
Price drift. Prices can change between the moment a plan is drafted and the moment the basket is built, especially around promotions. A total mentioned in the reply must come from the basket, not from an earlier estimate.
That last point generalises into the most useful rule in this part: write the basket first, then describe it. The reply the shopper reads should be generated from the validated basket, after constraints, availability and pricing have run. Write the conversation first and the two will eventually disagree, and the shopper will find out at checkout. A reply rendered from the basket cannot promise lentils the basket does not contain.
The review step is the authority boundary
The review screen is where authority passes from the system to the shopper. Lindiwe Dube, head of digital commerce, set four requirements for it.
It shows what the system decided on the shopper's behalf: "vegetarian dish checked against product data", "budget R600, basket R584". It marks every substitution and every assumption ("we assumed seven meat eaters; change this") so they can be undone in one tap. It states gaps honestly ("brown lentils are not available for Saturday; we suggest red lentils"). And it is the only path to checkout. The agent may propose; the shopper confirms; nothing reaches checkout without explicit shopper action, and payment is never initiated by the agent.
There is a legal dimension, which is general information and not legal advice. South Africa's Electronic Communications and Transactions Act, 2002, in section 43(2), requires a supplier selling online to give the consumer an opportunity to review the entire electronic transaction, correct any mistakes and withdraw before finally placing an order. If the supplier does not comply, section 43(3) lets the consumer cancel within 14 days of receiving the goods. Section 42(2) also excludes foodstuffs and everyday goods supplied to the home or workplace from the section 44 cooling-off right, which may not cover click-and-collect in the same way. Whether a design meets these provisions is a question for legal advisers. The architectural point is plain: for a basket assembled by an agent, the moment before the order is placed carries real weight and should never be optimised away.
On the general authority ladder, Ubuntu Grocer's basket agent sits on a low rung: it may propose and nothing more.
Measure the basket, not the conversation
Conversation ratings measure the prose; a thumbs-up says nothing about whether the mince was scaled. Ubuntu Grocer measures what the shopper does with the basket, line by line.
Each edit on the review screen is a labelled signal that costs the shopper nothing. A removal of an item she said she already had is a defect in the pantry rule. A quantity change tunes a rounding rule. A brand swap is a soft preference the system has not learnt. An addition is a need the plan did not cover, and often not a failure at all. Ruan Botha's AI engineering team reviews them weekly with Sipho Nkosi's catalogue team, because many are product data problems, not model problems.
From the signals come a handful of journey measures:
- Valid basket rate: the share of proposed baskets where every line passes the hard constraints, is available for the slot and fits the budget, checked before the shopper sees anything.
- Line acceptance rate: the share of proposed lines kept unchanged.
- Edits per basket, by type: removals, quantity changes, swaps and additions, tracked separately because they mean different things.
- Plan-to-checkout conversion: the share of journeys that end in a paid order.
- Cost per accepted basket: everything the journey consumed, divided by baskets checked out, a measure our Economics of AI Delivery series builds in general.
The edit log is behavioural data about a household, so it sits under the same privacy controls as the preference profile. Our Boardroom AI Test series shows how to design journey measures in from the start.
Trade-offs in the journey design
Speed against completeness. Eleven stages take time, and a shopper on a patchy mobile connection may not wait. Ubuntu Grocer shows the meal plan first, naming dishes only, and builds the basket behind it. No price, quantity or stock claim appears until the basket is written. The cost is a short window in which the plan is visible and the basket is not, which the interface must make obvious.
Asking against assuming. "Seven meat eaters" was an assumption. The team allows at most one clarifying question per journey, asked only when an assumption would change quantities materially, and shown as a tap-to-answer choice rather than another chat turn. Every extra question costs data, time and patience.
Partial against invented. When a product cannot be found, the basket shows a gap, not the closest match. A gap disappoints; a wrong product on Saturday breaks a promise.
Resumability. Shoppers leave and come back. The journey ID created by the backend-for-frontend (BFF) lets a half-built basket survive a dropped connection.
When the grandmother's request was run through the redesigned journey, the mince was scaled to seven portions, eggs were added up across both recipes into a single 6-pack, the lentils were checked against Saturday's slot and swapped for a marked alternative, and the reply quoted R584 because it was written from the basket. She changed the salad tomatoes to cherry tomatoes and checked out.
Questions to take into your architecture review
- Can you draw your journey as stages and name who holds the truth at each one?
- Is the model's output a structured proposal, or free text that later stages must reinterpret?
- Where are servings scaled to the household, and is that code or model judgement?
- Are ingredients added up across the whole plan before products are chosen?
- Is availability checked for the fulfilment slot or only for the store today?
- Is the reply generated from the validated basket, or written before the basket exists?
- What does the review screen show about assumptions, substitutions and gaps, and can each be undone in one tap?
- What is your valid basket rate, and who reviews shopper edits by type, including the catalogue owner?
Key points
- The commercial outcome is a valid, purchasable basket the shopper accepts, not a good answer.
- Eleven stages connect intent to checkout. The model leads the first two, and parses and assists in stages 3 and 4; code and retail systems decide the rest.
- Write the basket first, then describe it. A reply rendered from the validated basket cannot promise what the basket lacks.
- The review screen is the authority boundary and a legal moment, not a formality.
- Measure line-level shopper edits and cost per accepted basket, not conversation ratings.
CloudNala's point of view
Shopping assistants are still mostly evaluated by reading their replies, which is like judging a warehouse by its brochure. The reply is the cheapest part of the journey to make good and the least predictive of commercial success. What predicts success is whether the basket is right, and shoppers tell you that for free every time they edit one. Teams that instrument the review screen before they tune the prompt learn faster and spend less.
Next: Part 3, A recipe is not a basket. All parts are on the series page.
How CloudNala can help
CloudNala's Agentic Retail Review maps your assistant's journey stage by stage, names the system of record behind each decision, checks that replies are generated from the basket, and designs the review screen and edit signals that let you measure accepted baskets rather than conversation quality.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Agentic Retail Review or write to us at consult@cloudnala.co.za