Let the consumer describe the outcome they want.
FromKeyword search→ToIntent
Search assumes the consumer already knows the answer. An agent can start from the problem instead: clarify it, then search the network for capabilities that could solve it. Intent-driven commerce is not new, but applying it to local capability on open rails may be.
Search assumes you know the answer
Traditional commerce starts by asking what you want to buy. Many real decisions start elsewhere: I have a problem, I have an idea, I need something done, I’m not sure what I need. Today’s systems force those missions into product vocabulary, so the consumer has to reverse-engineer their problem into catalogue terms. A good local merchant does the opposite and asks what you’re trying to do. The neighbourhood already holds that intelligence; digital systems don’t represent it.
An AI agent can invert the interaction. The consumer states an intent and the agent interprets it. The network is then searched for capability, and relevant providers respond.
From a request to a structured mission
Take this request illustrative: “I want to make my balcony nicer. I don’t want to spend more than ₹20,000, I like plants and natural materials, and I need it done before next weekend.”
The agent can turn that into a structured mission: a goal (improve the balcony), a ₹20,000 budget, a preference for plants and natural materials, a deadline and a location. The candidate capabilities are landscaping, planters, furniture and décor, and installation. The consumer doesn’t have to run five separate searches.
The agent asks what it needs, such as dimensions, sunlight and style. It then queries the network on capability, geography, availability, budget fit, service level, credentials, prior work and capacity. If a filter the user chose leaves too few providers, the agent should say so and ask whether to relax it, rather than silently widening the net[CN]. Ambiguous or high-risk requests go to a human.
Missions map to capabilities
Suppose someone says their bedroom gets very hot and they want it more comfortable without installing an air conditioner. The agent shouldn’t search for “fan.” It can decompose the mission: this is a thermal problem, which ventilation, cooling, insulation or shading could address. That points to electrical specialists, HVAC professionals, interior specialists, insulation providers and blind makers, each with offers. The agent doesn’t prescribe the answer. It shows the capabilities that could solve the problem and leaves the choice to the person.
That mapping is domain knowledge, and someone has to own it. A wrong mapping, such as the agent deciding that “hot room” means only “buy a cooler,” is agent error in another form. The practical route is a hand-built taxonomy for one category, refined from concierge logs, rather than trusting a general model to get local capability mappings right.
Let’s make the commercial capabilities of the neighbourhood computationally discoverable.
Go deeper
The rails already speak “intent”, in a narrow sense
ONDC runs on the Beckn protocol, whose core API covers a lifecycle of search, select, init, confirm, status, track, update, cancel, rating and support[1]. Its search message already carries an intent object[1]. In practice, though, that intent is a structured filter (item, category, location, fulfilment preference), not a mission expressed in ordinary language. Turning “I want my living room quieter” into the right structured requests across the right capability types is the missing step.
Intent-driven commerce is not the novelty
ONDC’s FY 2025–26 report describes VyapaarLM as the groundwork for a sovereign commerce AI, moving toward intent-driven commerce. It says the effort aims to transform cataloguing and trust, deliver real-time price intelligence, automate logistics matching at scale and enable verifiable financial identities[2]. The evidence review reads this as strong evidence that the concept fits ONDC’s direction. It is not yet evidence of a production agent that can interpret local service intent and complete multi-party transactions at neighbourhood scale.
The global direction is similar. McKinsey describes agents that research, negotiate, coordinate logistics and complete purchases on a person’s behalf, and points to trust, identity checks, explainability and human override as what builds confidence in them[3]. In January 2026 Google announced a Universal Commerce Protocol, an open standard for agentic commerce, with checkout initially limited to eligible U.S. retailers[4]. Closer to home, Closebuy turns a text, voice or photo request into offers from nearby shops. Its Google Play listing showed 50+ downloads when we checked, which shows that the product exists, not that it has traction[5].
The differentiation, if any, is what the agent searches over: capabilities, proof and locality across an open network, not only products.
What could go wrong
- Agent error.The agent may misread local-language requests or overstate what a provider can do.
- Mapping error.A thin or wrong capability taxonomy sends people to the wrong kind of provider, even when the request itself was understood.
- SKU-shaped demand.If most real requests are simple product queries, an intent layer adds cost without adding value.
- The whitespace closes.If VyapaarLM or a large buyer app ships capability-level intent search for services, the agent itself becomes a commodity. What remains is merchant representation, trust evidence and locality completeness.
How we’d test it
With about 100 requests, results will be directional rather than statistically conclusive.
Most real requests turn out to be SKU-shaped, or most missions have fewer than three relevant providers.
| The test | What we would measure | What would end the idea |
|---|---|---|
| Capability discovery (Experiment 1) | 100 real requests: share that are mission-shaped; mission-identification accuracy; relevant providers per mission | Most requests are SKU-shaped, or most missions have fewer than three relevant providers |
| Agent accuracy | Clarification rate, false matches, user overrides, performance on local-language requests | False-match rate above the agreed threshold |
How strong is the evidence?
- Established
- Agentic commerce is emerging globally and is ONDC’s stated direction; Beckn’s search already carries structured intent.
- Evidence-supported
- Request-based local shopping agents exist (existence, not traction).
- Hypothesis
- An agent can translate local missions into capability queries accurately enough to be trusted.
- Unknown
- The share of real local demand that is mission-shaped, and agent accuracy on local-language requests.
Sources
- [1]Beckn Protocol, Core transaction API specificationChecked
- [2]ONDC, FY 2025–26 in FocusChecked
- [3]McKinsey, The agentic commerce opportunityChecked
- [4]Google, New tech and tools for retailers in an agentic shopping eraChecked; the post is dated 11 January 2026
- [5]Closebuy: AI Local Shopping, Google PlayChecked; the listing showed 50+ downloads
- [CN]Voice-session working notes (internal)Provided
Spotted a source we missed or a rule we misread? Tell us what we got wrong.
An agent can find the right providers. But what should the customer see once it has?