Agentic Commerce on MCP: From Multilingual Intent to a Completed Checkout
A field report from the Kapruka Agent Challenge 2026 — building a shopping agent on the Model Context Protocol that parses English, Sinhala, and Tanglish intent into budget-aware cart plans and completes a real guest checkout.
Search is the wrong primitive
Every e-commerce site asks the same thing of a shopper: translate what you actually want into keywords, then reconcile the results yourself. If your intent is "a birthday hamper for my sister in Kandy, under 15,000 rupees, delivered Saturday", the search box gives you no help at all. You become the planner, the price optimiser, and the delivery validator.
Kapruka Flow AI, built for the Kapruka Agent Challenge 2026, inverts that. The primitive is intent, not search. You describe the outcome; the agent produces complete, priced, delivery-validated cart plans that you can compare and check out.
What changes when intent replaces search
| Dimension | Traditional storefront | Kapruka Flow |
|---|---|---|
| Primitive | Search → product → cart | Intent → plan → compare → checkout |
| Matching | Keyword matching | Multilingual intent parsing (en / si / Tanglish) |
| Output | A single cart | Four optimised plans |
| Catalogue | Static browse | Live MCP search, enrich, validate, order |
| Personalisation | Anonymous only | Accounts and order history shape future plans |
| Transparency | AI hidden | Every MCP tool call visible in an activity feed |
Why MCP changes the integration story
The Model Context Protocol matters here for a boring but decisive reason: it turns a merchant catalogue into a typed, discoverable tool surface. Instead of scraping HTML or negotiating a bespoke partner API, the agent calls documented tools for product search, item enrichment, delivery validation, and order placement.
That changes what you spend engineering effort on. Almost none of the build went into integration plumbing, and almost all of it went into the planning logic that sits above the tools. When the catalogue changes, the tool contract absorbs it.
The public Kapruka MCP requires no API key, which means the agent can be demonstrated end to end by anyone — including judges — without credential provisioning. Removing auth friction from a demo is an underrated design decision.
Parsing intent across three languages
Sri Lankan shoppers do not type in one language. They type in English, in Sinhala, and very often in Tanglish — Sinhala words written in Latin script, mixed freely with English. A model tuned only on clean English collapses on the third case, which is the most common one.
The intent parser normalises across all three before any catalogue call happens. It extracts the same structured frame regardless of input language: recipient, occasion, product categories, budget ceiling, delivery city, and urgency. Everything downstream operates on that frame, so the planner never has to care which language the request arrived in.
A deterministic planner beats a chatty model
The instinct in 2026 is to hand the whole problem to a large language model and let it call tools in a loop. I deliberately did not do that. Cart construction is a constrained optimisation problem: maximise relevance to the parsed intent while staying under a budget ceiling and respecting delivery constraints.
That is a job for scoring and search, not for token sampling. The planner scores every candidate item against the intent frame, then fills the cart greedily against the budget with backtracking when a constraint is violated. The result is fast, reproducible, and free of the failure mode where the model invents a product that does not exist.
def build_plan(intent, candidates, budget, strategy):
scored = sorted(
(score_item(item, intent), item) for item in candidates
)
cart, spend = [], 0
for relevance, item in reversed(scored):
price = strategy.adjust(item.price)
if spend + price > budget:
continue # skip, keep filling
if not delivery_ok(item, intent.city, intent.deadline):
continue # validated via MCP, not guessed
cart.append(item)
spend += price
return Plan(strategy.name, cart, spend, budget)Cart construction as constrained search — deterministic, auditable, and impossible to hallucinate a SKU into.
Four plans instead of one cart
A single recommended cart forces a shopper to trust the agent blindly. Four plans invite a decision. Every request produces an Ideal plan balanced on relevance, a Cheaper plan that trades brand for budget headroom, a Premium plan that spends the full ceiling, and a Fast plan optimised for the earliest delivery date.
Because the plans are generated from the same scored candidate pool, comparing them is cheap, and adjusting the budget slider re-optimises all four client-side in milliseconds. No round trip, no regeneration, no waiting on a model.
"Give a user one AI answer and they audit it. Give them four ranked options and they choose. Choice architecture is a trust mechanism."
Making the agent auditable
Agentic systems fail in public when users cannot see what happened. The interface exposes a live MCP activity feed: every tool invocation, its arguments, and its result are visible while the plan is being assembled.
This is not a debugging affordance that survived into production by accident. It is the product. When a shopper can watch the agent search the catalogue, enrich three candidate items, and validate delivery to their city, the plan stops being a black-box suggestion and becomes a traceable piece of work.
What I would build next
The obvious extension is memory. Accounts and order history already personalise future plans, but the scoring function currently treats history as a static prior. Learning per-user weights from accepted and rejected plans would make the second visit meaningfully better than the first.
The harder problem is negotiation. Real gift-buying involves trade-offs a shopper cannot articulate up front — they discover their preferences by seeing options. A planner that asks one well-chosen clarifying question, rather than assuming, would beat any amount of additional model capacity.