Early in the prototype, a shopper in Gqeberha asked the meal assistant to plan a braai for six. She looked at the basket and removed the 2 L cooldrink: "the kids don't need it". Three messages later she asked for "a salad to go with the meat". The salad arrived, and so did the cooldrink, back in the basket, because it was on promotion and the model thought it went well with a braai. Nothing about it was dangerous. But she noticed, and from then on she checked every line before she trusted the basket. An assistant whose basket must be audited by the shopper has lost most of its value.
The model had not malfunctioned. It had been given a tool that could add to the basket and a goal of being helpful, and it used both. The failure was in the boundary, which had never been designed.
Ubuntu Grocer is a composite, a fictional South African grocery retailer; its scenario draws on lessons from real retail-agent delivery, and its people, systems and figures are illustrative. Part 5 covered the product data every decision depends on. This part closes the catalogue-and-decision arc by deciding who may make each decision.
Three ways to orchestrate the same journey
Our series Not Every Workflow Needs an Agent sets out the general pattern choice, and part 1 explains how to locate the uncertainty in a process and wrap it in a bounded agent step. Agent Claims Decoded defines the vocabulary. This article does not repeat them. It applies them to one retail journey.
Applied to "supper for four, no peanuts, under R400", the three options look like this.
- Deterministic workflow. Menus, filters and forms: choose a recipe, tick allergens, set a budget. Every step is predictable and testable. It cannot take a sentence like the one above and turn it into a plan, which is the whole proposition.
- Workflow with bounded agent steps. A journey orchestrator, written as ordinary code, runs the steps in a fixed order and calls a model only where judgement is needed: understanding the request, planning the meal, ranking ambiguous product matches and explaining the result. Ubuntu Grocer chose this.
- Agent-led orchestration. The model receives the request and a set of tools (search, match, substitute, add to basket) and decides which to call, in which order, and when it is done. The prototype was built this way, and the cooldrink came back this way.
Pieter van Wyk, the principal architect, put the decision in one sentence: the uncertainty in this journey is in what the shopper means, not in what the system should do next. Once the request is understood, the remaining steps are known: filter by hard constraints, match, check availability, calculate quantities, propose the basket. That is the signature of a known path with a few uncertain steps.
| For this journey | Deterministic workflow | Workflow with bounded agent steps | Agent-led orchestration |
|---|---|---|---|
| Handles a free-text request | No | Yes | Yes |
| Who picks the next step | Code | Code | Model |
| Where hard constraints are enforced | Code | Code, at every step that adds a product | Wherever the model remembers to call the check |
| Can it change the basket by itself? | No | No | Only if a tool lets it |
| Load-testable with repeatable scenarios | Easily | Yes, step by step | Hard: paths vary per run |
| Model calls per journey | None | Bounded and countable: fixed per understood request, plus one per clarifying turn | Variable |
| Explaining a basket to the shopper | The rules | The rules plus each step's recorded reasons | A trace someone must read |
Two rows matter for the parts that follow. A bounded, countable number of model calls per journey is what makes the token capacity model in part 9 possible, and repeatable paths are what make the load test in part 7 meaningful.
Decision rights, action by action
Choosing the pattern is half the work. The other half is writing down, for each action in the journey, who proposes, who decides and who confirms. Lindiwe Dube, who owns the commercial outcome, signed this matrix before any agent prompt was written.
Read it row by row and a few principles appear.
- The agent asks; code executes. The agent may request a catalogue search, but the search runs through the orchestrator, which applies the hard filter from part 4 and the live availability join from part 5 before anything is returned.
- Judgement ranks; it does not override rules. Choosing between three available, eligible curry pastes is a sensible task for a model. Deciding whether a satay paste is eligible is not.
- Arithmetic has no agent. Quantities and pack sizes are calculated by code from the recipe-to-product mapping in part 3. A model that rounds "two onions" to a 2 kg bag is solving a problem that has an exact answer.
- Substitution happens twice, with different owners. During the conversation, the agent may rank substitutes within category rules and the shopper confirms. At picking time, when an item turns out to be missing in the store, the substitution follows the shopper's saved substitution preferences and the store's rules. The meal assistant has no role there.
- Promotions are offered, not applied. The agent may mention a promotion. Eligibility and application belong to the pricing and basket services, and the shopper chooses.
- Checkout and payment have one actor. The shopper, through the existing checkout. The agent holds no tool, token or route that reaches it.
The proposal-and-commit boundary
The cooldrink incident needed a mechanism, not a better prompt. Ruan Botha's team replaced the "add to basket" tool with a proposal.
The basket agent now produces a typed basket change: lines to add, remove or alter, each with its product, quantity, price at the time of the proposal and the constraint checks it passed, tied to the journey identifier and with a short expiry. The journey orchestrator validates the proposal again: it re-runs the hard filter, re-prices against live data and checks it against the shopper's own edits. Only then does the backend-for-frontend (BFF), which owns her session, show it, and only her tap commits it: the orchestrator writes the change to the existing basket service under her session.
Two details make this work.
The boundary is enforced by identity, not instruction. The agent steps run under a service identity that can read the catalogue and write proposals, and nothing else. They hold no credential that can change a basket. A prompt that says "never change the basket without asking" is a hope. An agent that cannot obtain a basket-write token is a control. Our article on why agent capability is not agent authority makes the general case, and bounded actions in the Production AI Case Study shows the same prepare, confirm and submit sequence in a fictional bank.
Shopper edits are locks. When the shopper removes the cooldrink, the journey state records that removal. A later proposal that re-adds it is rejected before she sees it, unless she asks for it again. The same applies to a quantity she changed or a brand she swapped. This is a small piece of state, and it is the piece that restores her trust: the basket only changes when she changes it.
Thandeka Mokoena, the security architect, added one more rule: proposals are validated as data against a schema, in the way described in From prompt to structured contract. A malformed proposal is discarded and logged, never repaired by guessing.
The trade-offs
The bounded design costs more engineering before the first demo. An agent-led prototype can be built in days, and it looks more capable, because it is allowed to do more. The bounded design needs an orchestrator, a proposal schema, validation and lock state.
It can also feel less fluid. Ubuntu Grocer kept the conversation itself open: the intent agent may ask clarifying questions, handle "actually, make it five people" and loop back as often as needed. What is fixed is the path from an understood request to a proposed basket, not the dialogue.
Finally, it moves slower when the business wants a new capability. A new action, such as building a weekly plan across several deliveries, means changing the workflow and the matrix, not just adding a tool. That is the point. Each new authority is a decision someone signs, and the authority ladder describes the evidence that should justify each step up.
Questions to take into your architecture review
- Where, specifically, is the uncertainty in your shopping journey, and which steps are actually known?
- Who picks the next step in each part of the journey: code or the model?
- Is there a signed decision-rights matrix for search, recommendation, substitution, quantity, basket changes, promotions and checkout?
- Which identities do the agent steps run under, and can any of them obtain a token that changes a basket or reaches checkout?
- Are basket changes proposed as typed data and validated again before the shopper sees them?
- How are the shopper's own removals and edits protected from later proposals?
- Are in-conversation substitution and picking-time substitution separate decisions with separate owners?
- How many model calls does a typical journey make, and is that number bounded: fixed per understood request, plus one per clarifying turn?
Key points
- Agent-led orchestration fails in retail less by being wrong than by acting without being asked.
- In this journey the uncertainty is in what the shopper means, not in what the system should do next, so a workflow with bounded agent steps fits.
- Write a decision-rights matrix per action before writing prompts: the agent proposes and ranks, code validates and calculates, the shopper confirms.
- Enforce the boundary with identity: agent steps write proposals, never baskets, and never reach checkout.
- Treat the shopper's edits as locks so the basket changes only when she changes it.
CloudNala's point of view
The question we ask first in a retail-agent review is not "which model?" but "which credential can change the basket?" If the answer includes the model, the boundary is a prompt, and prompts are not controls. Bounded agent steps are not a lack of ambition. They are what lets a retailer put a conversational assistant in front of its busiest weekend without auditing every basket afterwards.
Next: Part 7, Load-test the shopping journey, not an endpoint. All parts are on the series page.
How CloudNala can help
CloudNala runs agent boundary workshops for retail and consumer journeys. We locate where judgement is genuinely needed, recommend the least autonomous orchestration that handles it, draft the decision-rights matrix with your product, security and commercial owners, and specify the proposal schema, identities and lock state that make the boundary hold in production.
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