“We taught an HCL Commerce store to answer a question asked in plain English. Solr still runs the search. What changed is that something now understands the question first — and we built it with a team of agents, not story by story.”
Shoppers stopped typing keywords
Watch anyone search a store today. They do not type "shirt blue". They type the way they would ask a person standing in the shop.
Keyword search was never built for that. It takes the words, matches them against the index, and returns whatever overlaps. A sentence full of ordinary words — between, most, under, dollars — comes back empty or comes back as noise. Either way the shopper leaves.
The usual fix is to patch around it. Add a synonym. Write a redirect rule. Build a landing page for the query that keeps failing. Every patch is manual, every patch covers one query, and the list never stops growing. Merchandising teams lose hours a week to it and the gap never closes.
Real Conversational Query Examples
What it does now
Four queries from the demo, typed into the ordinary store search box on a standard Aurora sample store:
No category, no filter.
It picked up the brand.
That is a category and a sort order, read out of three words.
Product type, gender and a price range, all from one sentence.
The rule we set first
“Before any code, we set one rule: the platform does not change.”
That rule is not modesty, it is what makes the work sellable. Any enterprise commerce lead who has survived a migration will stop listening the moment you suggest another one. So the layer we built sits in front of Solr and hands it a better query. If the layer is switched off, search goes back to exactly what it was this morning.
The rule also shaped the architecture. Because we could not touch the engine, every piece of intelligence had to live in an extension that HCL Commerce already knows how to load.
Why we used an agent team
The normal way to build this is to write the stories, assign them, and work through the backlog. That works. It is also slow, and most of the slowness is not typing. It is context switching, waiting for review, and the long tail of "is this piece actually finished?"
So we tried something else. We split the work into ten jobs and gave each one to an agent with a written brief.
This is the part people get wrong about agentic delivery. It is not an AI that writes your code while you watch. It is a way of organising work so that each piece is small enough for an agent to own end to end, and so that finishing is something you can check rather than something you feel.
If you cannot write down what "done" means for a piece of work, you cannot hand it to an agent. That constraint turns out to be good for human teams too.
nlp-coordinatorThe coordinator
One agent sits above the rest. We called it nlp-coordinator. It holds the plan. It reads the epic, the story files and the reports, and it answers one question: which agents should run next, and which are blocked. When a wave finishes it checks what met its criteria and launches the next one.
Three Deliberate Limits That Ensure Trustworthiness
It cannot write code
Read, search and list only. A planner that can also edit becomes a planner that quietly fixes things, and then nobody knows what state the work is in.
It cannot launch agents itself
It tells the main session exactly which agents to start, in what order, and why. A human sees that instruction before anything runs.
It never guesses
If a story has no report, it is not finished. If the environment profile is missing, the wave does not start.
The Nine Story Agents
Each one owns a single piece of the system. Each has its own brief, its own tools and its own definition of finished.
Lays the ground
Project structure, configuration, shared contracts and the interfaces every later agent codes against. Get this wrong and the next eight argue with each other.
Reads the catalog schema
Which fields exist, which are searchable, what the facets are called. This is what stops the model inventing a field that is not there. The schema, not the prompt, is the source of truth.
Structured intent extraction
The part people think is the whole job. It turns a sentence into structured intent: product type, brand, price floor and ceiling, sort order, gender. It also owns the prompt, the intent schema and the validator that rejects output which does not fit.
Solr query profile injection
Takes that intent and writes it into the Solr query profile. Filters, facets, sort. This agent is why the search still behaves like Solr: it produces a normal query, not a new engine.
Storefront REST integration
Exposes it as a store REST endpoint, so the storefront calls it the same way it calls any other search.
Linguistic indexing
Adds language fields to the index so matching copes with plurals, stems and word forms. Unglamorous, and the difference between good results and nearly-good results.
End-to-end tests & logging
End-to-end tests and per-request logging. Built alongside the feature, not bolted on after. Nothing else can be trusted without it.
The money agent
An intent cache so repeat questions never reach the model, a bypass classifier that throws out nonsense before it costs anything, and a spend guard that caps the bill.
Operations view
Builds the view: every request, model time, Solr time, cache hit or miss, cost. The thing you show an operations team before they will let this near production.
Done criteria are the whole trick
Every story carries a file that says what finished looks like. Not "implement caching" but the specific, checkable things: these tests pass, this report exists, this endpoint returns this shape.
The coordinator reads those files. A story with no report is not done, however much code sits in the branch. A story whose tests do not run is blocked, and the next wave waits.
This sounds like paperwork. It is the opposite. It is what lets you run several agents at once without the work turning to mush, because the question "can we move on?" has an answer that does not depend on anyone's judgement at 7pm on a Friday.
It is also the honest answer to the fear every engineering leader has about this: that AI-written code accumulates faster than anyone can review it. The guard rail is not reading every line. It is deciding in advance what the piece has to prove.
What came out
Real Java, inside an HCL Commerce extension project. Not a prototype in a notebook.
The interesting part is not the model call. It is everything built around it to make the model call safe:
An intent validator
Model output is never trusted straight. It is checked against a schema and rejected if it does not fit.
A keyword fallback
If the model is slow, over budget or unavailable, search degrades to normal keyword behaviour. It does not break.
A cache layer
In memory and distributed. Ask the same thing twice and the second one never reaches the model.
A bypass classifier
Gibberish is caught before it costs anything. In the demo, a junk query was bypassed in 82 milliseconds at zero cost.
A spend guard
A bad day cannot run up an unbounded bill.
Three gates stand between a question and the model
Read it top to bottom. Every gate on the way down is a chance for the question to be answered without the model, and the one at the bottom is what happens when the model gives an answer we cannot use.
Bypass Classifier & Cache Layer
Immediate Pre-Model FilterInstant resolution for repeat questions from memory and distributed cache. Junk or gibberish queries bypassed in 82 milliseconds at zero cost.
Spend Guard & Latency Budget
Economic & SLA ProtectionIf the model is slow, over budget, or unavailable, search gracefully degrades to normal keyword behavior. It never breaks.
Intent Schema Validator & Solr Query Profile Injector
Output Quality & SafetyModel output is never trusted straight. It is strictly validated against the catalog schema and injected into Solr query profiles.
Measuring every request
We gave observability its own agent, early, rather than leaving it to the end. That was the right call.
The dashboard shows every request: how long the model took, how long Solr took, whether it came from cache, how many tokens went in and out, and what it cost. There is a matrix view that breaks it down minute by minute.
In a 22-request lab run: a third of requests served from cache, no fallbacks, around 1.2 US cents per request, median total latency 2.6 seconds. Those are lab numbers on a small sample, not a production benchmark, and I would not quote them as one.
The point is not the figures. It is that the figures exist at all. Nobody running an enterprise store will switch on a feature that calls a paid model on every search without being able to answer: what is this costing me today, and what happens when it is slow? Most AI search demos cannot answer either question. That is why they stay demos.
What agentic commerce means at Dvanta
The phrase is getting worn out, so here is what we mean by it, concretely. We do not mean a chatbot bolted onto a storefront. We do not mean replacing your platform with something that has AI in the name. We mean two things:
AI inside the commerce stack, where it earns its place
Search that understands a question. Catalog work that does not need a person for every row. Support flows that resolve rather than deflect. Always with a fallback, a cost ceiling and a dashboard, because enterprise commerce has uptime and margins to protect.
An agentic way of delivering it
Work broken into pieces an agent can own, each with a written brief and checkable done criteria, with a coordinator holding the plan and a human approving each wave. That is how this search layer went from nothing to working software in weeks rather than quarters — and why the output is reviewable rather than a pile of generated code nobody wants to touch.
Where to start
If you run HCL Commerce, the honest starting point is not a project. It is a question: how many of your zero-result searches are sentences rather than keywords? Pull a week of search logs and look. Most teams are surprised.
Three things you can do this week, without talking to anyone:
Ready to quantify your zero-result search opportunity?
Discuss your site search logs directly with Deepak Soni and the Dvanta HCL Commerce team.
Results And Impact
“If you cannot write down what 'done' means for a piece of work, you cannot hand it to an agent. That constraint turns out to be good for human teams too.”
