Deterministic vs stochastic outcomes
The result of any task can be either deterministic or stochastic.
Deterministic means a system’s future state is fully predictable and has no randomness. Given the same inputs, it will always produce the exact same output. Run it a thousand times and you get the same answer a thousand times.
Stochastic means a system incorporates randomness or probability. Even with the same initial inputs, repeated runs can yield different outcomes drawn from a probability distribution. Ask the same question twice and you might get two slightly different, and both perfectly acceptable, answers.
Most of the typical agentic tasks we celebrate today, like writing text or writing code, are stochastic in nature. And that is fine. You don’t really care how a paragraph gets phrased or how a function gets written, as long as the code compiles and meets the requirements, or the text conveys the intended idea. There are many correct paths to the same good result, and the model is free to pick any of them.
Commerce is a different animal. The majority of commerce tasks are anything but stochastic. If your customer asks “where is my order?” (the classic WISMO question), their order is in a specific place, right now. It contains particular products, at a particular price, purchased through a particular payment method. Product attributes, price lists, configurations, order details, payment records, promotion rules: everything has specific, predefined values, and there is exactly one correct answer. You cannot creatively reinterpret where a package is. You cannot round a price to something that reads nicely.
This is precisely what makes agents in a commerce context different from agents in a software engineering, personal assistant, or creative writing context. The tolerance for improvisation is close to zero. A commerce agent that is 95 percent right about an order total is not charmingly imperfect. It is wrong, and it has probably just cost someone money and trust.
Commerce tasks are not the same
It would be convenient if we could treat “commerce” as a single workload and point one model at it. We can’t. Commerce tasks fall into distinct categories, and each one asks something different from the underlying model.
At KIBO we defined 5 categories of tasks to which every single prompt is mapped into.
Engagement tasks happen when the agent interacts with a shopper directly through chat or another surface. These demand the most capable model available, because the agent has to replicate natural human interaction as closely as possible. Tone, nuance, and context all matter here, since this is the part of the system the customer actually experiences.
Configuration tasks happen when an agent is asked to create or configure something in the system: a promotion, a product attribute, a workflow, or any structural change. The agent still needs to interpret the user’s prompt correctly, but the space of valid outcomes is narrow and well defined. There is a right way to configure a promotion, and the job is to land on it.
Explain tasks happen when an agent is asked to explain why something occurred, for example why an order was routed a particular way. This requires the agent to interpret the question, pull the correct data from several different tables, and trace the workflow step by step to reconstruct what actually happened.
Analyze tasks lean on more conventional data analysis skills. Here the agent works through datasets, such as historical order data, to answer questions about trends, patterns, and performance over time.
Optimize tasks are the most complex of the group. The agent is expected to analyze the current state of the system and then make changes that move it toward a new state, one that is optimized against specific parameters like margin, delivery speed, or conversion. These tasks require the most effort and the most reasoning of any category.
Line these up next to each other and the point becomes obvious. A friendly chat reply and a system-wide optimization run are not the same kind of problem, and pretending one model should handle both, equally well and at the same cost, is wishful thinking. Ideally you would use a different agent, and quite possibly a different LLM, for each type of task. That is exactly what leads us to composability.
Composable agents
Composability means there is a single, unified experience for the user that branches into multiple specialized agents depending on the task, and then routes each request to the most appropriate LLM for the actual processing. This lets you optimize inference deliberately: getting the best result for each task while minimizing both effort and cost.
This might sound like someone trying to force composability into places it doesn’t belong. It isn’t. Composable agents have quietly been the norm at frontier labs for a while now:
- Switching which model you use inside Claude Code or Claude Cowork is composability in action.
- Asking ChatGPT a question, where a “router” then hands it off to a specific model behind the scenes, is the same idea.
In each of these examples, the company has built a multi-agent, multi-LLM service that routes the incoming request to the right agent and model based on what the user actually asked for. The user never sees the machinery. They just get a good answer.
Composable agentic commerce can be pictured in three layers:
- A unified agentic experience, where the user interacts with a single chat and nothing else.
- Multiple agents underneath, with each request routed to the agent best suited to handle it.
- Multiple LLMs, invoked by the agents in the layer above as the task demands.
Seen this way, one requirement becomes non-negotiable: BYOM, or Bring Your Own Model. To have the freedom to use different LLMs for different tasks, a company needs the ability to plug multiple models into its agentic commerce stack. Without that, composability collapses back into a single model trying to be everything at once, which is the exact problem we set out to avoid.
Agent composability is an integral part of overall composability philosophy that spans across the KIBO platform including commerce and order management capabilities built on a composable MACH based architecture. We strongly believe that every part in every aspect of our offering is fully composable allowing our customers to design the right solution based on their needs.
