Doot Meets ONDC: Does India's Proposed Citizen AI Agent Actually Have a Commerce Layer to Shop On?

What Digi Doot actually proposes

Digi Doot is a whitepaper, not a product. It was released around the India AI Impact Summit 2026, held in New Delhi in mid-to-late February 2026, and organized under the India AI Mission's "Inclusion" work stream. The authors are a heavyweight, mostly academic coalition: Ramesh Raskar of MIT Media Lab, Srikanth Nadhamuni, the founding CTO of Aadhaar, Nitin Saxena of IIT Kanpur, and contributors from SPARC, the University of Maryland, and India's AI Foundry, among others. Sujith Nair, identified in the credits as representing Beckn Protocol, is also listed as a contributing author.

The proposal is called "Agent One": a citizen-owned AI agent, run primarily on a user's own device, authenticated through Aadhaar, and authorized to act across India's Digital Public Infrastructure, the DPI stack that already includes UPI for payments and DigiLocker for documents. The whitepaper's own language is that the agent should let citizens "discover, access, and complete government and private services through natural language, voice, and local context." The illustrative case study, run throughout the paper and repeated in nearly every piece of coverage, follows Sitabai, a 70-year-old citizen from rural Maharashtra who plans a Kumbh Mela pilgrimage entirely by speaking Hindi to her agent, which books transport, checks medical records, and applies for relevant welfare schemes on her behalf.

This is squarely a governance and civic-services proposal first. But "private services" is explicitly in the whitepaper's own framing, and the digidoot.in project site itself describes the agent booking a subsidized train ticket via IRCTC as one of Sitabai's steps, a transaction with a private-sector-adjacent booking system, not a government form. That single detail is the seam this piece pulls on: if Doot is meant to reach private transactions and not only government ones, does it actually plug into the network India already built for exactly that purpose?

What the whitepaper says about commerce, in the authors' own words

A direct text search of the whitepaper PDF, hosted at digidoot.in and run against its full extracted text, turns up zero occurrences of "ONDC." The word "commerce" does not appear either. "Beckn," the open protocol that ONDC runs on, appears exactly once in the entire document, and that single instance is in the acknowledgments section, crediting "Sujith Nair, Beckn Protocol" as a contributing author, not in a description of how the agent would transact.

Words that do appear are instructive about what the paper is actually built to describe: "transact" appears four times, but always in the context of trust architecture, audit logging, and blast-radius containment for agent actions in general, never tied to a named commerce rail. "Payment" appears three times, always tied to UPI or to the proposed governing body's mandate to "coordinate with existing regulators such as Reserve Bank of India (RBI) for financial transactions." "Vendor" appears once, in a single sentence about the agent needing an "agent-enabled" ecosystem of vendors and platforms to function well, without naming which vendor network that would be.

None of this means the authors are unaware of ONDC. It is far more likely that a whitepaper aimed at a summit audience and framed around governance, identity, and trust architecture simply was not written to specify commerce plumbing. But the gap is still real: a document that proposes agents completing "private services" transactions never names the one open, government-endorsed protocol India built specifically so that any certified app can discover and transact with any registered seller.

The GitHub specification tells a fuller, but still incomplete, story

Doot has a second, more technical layer that the whitepaper coverage mostly skips: a public specifications repository maintained by SPARC Labs at github.com/doot-ai/doot.specs, licensed under CC-BY-4.0. Its core document, ARCHITECTURE.md, is far more detailed than the whitepaper and is where ONDC actually gets named. It appears exactly twice. The first is in the opening context paragraph, listing India's DPI achievements: "Systems such as Aadhaar, UPI, DigiLocker, DigiYatra, DEPA, ABHA, ONDC, and the Account Aggregator ecosystem have transformed how citizens authenticate themselves, make payments, exchange documents, and access digital services." The second is a near-identical restatement inside the document's glossary of concepts.

Both mentions are the same move: ONDC as one item in a list of DPI background context, never as a subject with its own section, its own integration diagram, or its own protocol mapping the way UPI and DigiLocker each receive elsewhere in the document. There is no discussion of how a Doot agent would issue a Beckn Search or Select call, how it would carry ONDC's Init and Confirm order flow, or how ONDC's existing network of buyer and seller apps would authenticate a Doot-issued credential.

The clearest signal sits in Section 10, "Comparison with Alternatives." Here the authors explicitly benchmark Doot against four named agentic-commerce and authorization frameworks: the Universal Commerce Protocol (UCP), Google's Agent Payments Protocol (AP2), the Agentic Commerce Protocol (ACP) from OpenAI and Stripe, and IETF's GNAP alongside OAuth 2.0 with Rich Authorization Requests. The section argues Doot differs from each through "sovereign anchoring rather than web-PKI" and coverage "beyond commerce." ONDC and Beckn, India's own government-endorsed answer to exactly this class of problem, are absent from that comparison, even though ONDC is named twice elsewhere in the same document.

A parallel rail, not a plug into the one that exists

The architecture document does propose a mechanism for reaching merchants, and it is worth reading closely because it is not a Beckn integration. Section 8 describes a certification body, the Agent Certification Authority (ACA), that would publish "a directory of certified MCP servers keyed by capability such as booking, quoting, logistics, e-commerce, health, and civic services." The path for a business to become reachable is described plainly: "Any merchant can become a payment recipient, and any business can stand up an 'X-Doot' MCP server, pass certification, list itself in the directory, and become immediately callable by every certified citizen agent."

That is a new discoverability layer, built around Model Context Protocol servers and a new certifying authority, sitting alongside, not inside, the Beckn-based Search, Select, Init, and Confirm flow that ONDC's existing network of buyer and seller applications already runs on. For a business, those are two different onboarding paths to two different networks, each requiring its own registration, its own technical integration, and, per the ACA design, its own certification.

This matters most for the sellers who already did the first one. Under the government-run MSME TEAM Initiative, a scheme carrying a Rs 277.35 crore outlay for the three-year period from FY2025 to FY2027 and run by the National Small Industries Corporation, small enterprises are actively being recruited onto ONDC as sellers, with a target of 5 lakh MSEs and at least half women-owned. An enterprise already registered on ONDC as a seller is explicitly ineligible for the scheme's onboarding incentives, since the scheme exists specifically to get sellers onto the network in the first place. As specified today, none of that ONDC seller registration would make a business reachable by a Doot agent. A separate MCP server and a separate certification would be required.

Why this matters for the ONDC-only MSME

India's open commerce network is not a small or early experiment anymore. According to a Ministry of Commerce and Industry reply given in the Lok Sabha on 16 December 2025, there were 1.16 lakh-plus retail sellers live on ONDC across more than 630 cities and towns. By an August 2026 written reply from the Department for Promotion of Industry and Internal Trade to the Rajya Sabha, the government reported the network had crossed 500 million cumulative transactions, up from 0.2 million in FY23 to 218 million in FY26, with more than 2 lakh retail merchants and over 10 lakh service providers across mobility and logistics now active on the network, including participation from more than 10 lakh ride-hailing drivers and coverage of nearly 80 percent of India's metro ticketing inventory.

That scale is the entire premise of an MSME strategy built around ONDC: register once, on an open, non-discriminatory protocol, and become discoverable to every buyer-side app on the network without negotiating with each platform separately. It is a reasonable bet, and it is the bet a meaningful share of India's MSME digitization funding is actively subsidizing. But it is a bet on a specific commerce protocol, and Doot, as currently specified, is a citizen-identity and consent protocol that does not yet route through it. If a citizen-facing agent layer like Doot moves from whitepaper to pilot with its current design, an MSME's ONDC listing would not automatically make it visible to that agent. A second, separate integration would be needed.

None of this is a criticism of ONDC, which is a mature, government-verified network with a specific and well-documented protocol. It is a description of a gap between two initiatives that both claim to be building India's next commerce layer, one already carrying hundreds of millions of transactions, the other still a public specification repository with two GitHub stars and no shipped pilot.

What "having a commerce layer" would actually require

A genuine bridge between Doot and ONDC is not architecturally hard to imagine. Beckn Protocol, which ONDC runs on, is itself an open, non-proprietary protocol built around six core actions, Search, Select, Init, Confirm, Status, and Cancel, and it already powers more than one live Indian network, including Namma Yatri for peer-to-peer mobility. A certified "X-Doot" MCP server that translated an agent's intent into Beckn calls, rather than requiring every merchant to build a bespoke integration, would let ONDC's existing 2-lakh-plus merchant base become reachable through Doot without a second onboarding drive. Sujith Nair's presence among the whitepaper's listed authors makes that outcome plausible rather than far-fetched.

But that bridge does not yet exist in the public specification, and the reading of the evidence has three parts, held separately rather than blended into one verdict. It is established, by direct text search, that the whitepaper never names ONDC and that the architecture specification mentions it only twice, in passing, and omits it from its own comparison of alternatives. It is a fair, but still interpretive, reading that the proposed MCP-certification model constitutes a parallel discovery layer rather than a Beckn-native one. And it remains genuinely unsettled whether that omission is a considered design choice or simply an early gap in a public, version-controlled repository that is still being iterated on. Doot is a proposal, not a shipped system, and the specification could add an ONDC bridge in a future revision without contradicting anything published so far.