Beckn as Contract Language for Machines: What It Means for an MSME When the "Buyer" Is an AI Agent, Not a Person

The problem Beckn was built to solve is older than AI agents

Beckn predates the current wave of AI agents by several years. It is an open protocol, authored by the Foundation for Interoperability in the Digital Economy (FIDE) with Nandan Nilekani, Pramod Varma, and Sujith Nair among its principal architects, designed to let a buyer on one app transact with a seller on a completely different app, with no shared platform in between. It is the technical layer underneath the Open Network for Digital Commerce (ONDC), the Indian government-backed network that lets a shopper on one buyer app order from a seller registered through an entirely different app.

The protocol's own GitHub documentation describes its central design choice plainly: "Beckn is a protocol, not a platform. It adopts a decentralized architecture that obviates the need for creating a centralised platform." Rather than requiring every seller to onboard onto one dominant marketplace, Beckn standardizes the messages that discovery, ordering, fulfillment, and post-fulfillment actions send between systems, comparable to how SMTP lets two people on different email providers exchange mail without either provider controlling the other.

What changed is not the protocol's design goal but its most urgent use case. In a December 2024 interview with Analytics India Magazine, Sujith Nair reframed Beckn's decade-old interoperability problem as, specifically, the problem an AI-agent economy is about to have at scale: if an agent books a hotel or places an order on a person's behalf, "how do you verify that the AI has indeed made the booking?"

Beckn's pitch: a contract, not a conversation

Nair's answer, as reported by AIM, is that agent-to-agent commerce needs "a programmable, machine-readable method of contracting in real-time," and that an interoperable protocol like Beckn is what supplies it. He described Beckn itself as "the language of transactions," a framework built to let external systems communicate and transact reliably across organizational boundaries.

The mechanism is the transaction record itself. Every Beckn-mediated order is accompanied by what Nair called a digitally signed micro-contract, spelling out the specific terms of that transaction: price, what was promised, what was not, and the cancellation terms. In his framing, this "eliminates ambiguity and establishes a definitive ground truth," and it "establishes a record, instilling trust based on the contractual agreements regarding what's promised, what's not, and the cancellation terms." That record exists whether the party initiating the order was a person tapping a screen or an agent acting on a standing instruction.

This is a meaningfully different design philosophy from a marketplace terms-of-service page a human is assumed to have read. A Beckn transaction carries its own explicit contract, attached to that specific order, machine-parseable by both sides. A 2025 academic study of Beckn's governance, published on arXiv by researchers including Yvonne Dittrich, notes that the Beckn community recommends network participants sign and encode messages using public-private key infrastructure specifically so the messages themselves can serve as admissible evidence in a dispute under India's Information Technology Act. The contract is not a courtesy; it is designed to hold up as evidence.

Beckn is not the only protocol chasing this problem, and it is not building it alone

Beckn is India's answer to a question the rest of the industry is asking too. On September 17, 2025, Google announced the Agent Payments Protocol (AP2), an open standard built with more than sixty payments and technology partners, including Mastercard, American Express, PayPal, Coinbase, and Etsy. AP2 uses three chained "Mandates," an Intent Mandate capturing what the user asked for, a Cart Mandate locking the exact items and price once the user approves, and a Payment Mandate linking the approved cart to a payment method, each one a tamper-evident, cryptographically signed digital credential built on the W3C Verifiable Credentials standard.

The shape of the idea is close to Beckn's: an auditable, cryptographic chain of custody standing in for the ordinary trust a human buyer places in a familiar checkout page. Google's September 2025 announcement does not name Beckn, ONDC, or any Indian network participant among its launch partners, which means the two efforts are, as of this writing, parallel rather than merged. FIDE has separately signaled where it expects the convergence to happen: in May 2024 it unveiled BecknGPT, built on OpenAI's ChatGPT model, as an early demonstration of an AI agent that can search across ONDC-connected seller networks and place an order using Beckn as the underlying contract layer. It is a proof of concept, not a live consumer product, and it should be read as a signal of intent rather than evidence that agent-mediated ONDC shopping is already mainstream.

For an MSME, the practical read is not "pick a side." It is that more than one serious, well-funded effort is converging on the same conclusion: an AI agent transacting on a person's behalf needs a machine-readable, cryptographically verifiable record of what was agreed, because a screenshot and a human's memory of a phone call will not do the job anymore.

What this actually touches for an MSME already on ONDC

An Indian MSME does not need to build anything to be technically inside this system if it already sells on ONDC. Registration requires a valid PAN, GST registration, and a bank account in the business's name, and a Micro or Small Enterprise can additionally register through the Ministry of MSME's MSME TEAM Scheme, a Rs. 277.35 crore initiative running FY 2024-25 through FY 2026-27, implemented by the National Small Industries Corporation, targeting five lakh MSEs with at least half women-owned, that pairs Udyam-registered sellers with onboarding help, catalog creation support, and account management through Seller Network Participants.

What Nair's framing changes is what that seller profile is understood to be for. A catalog listing on a human-facing marketplace app is written to be read by a shopper who can tolerate ambiguity, infer intent, and forgive a vague return policy because a chat window is one tap away. A catalog entry inside a Beckn network is a field in a structured, machine-parseable schema that becomes part of a signed contract the moment an order is placed, whether the counterparty reading it is a person or an agent acting for one.

The distinction matters because the two are not graded the same way. A page that reads well to a person can still be structurally thin, an unclear cancellation term, an inconsistent price across catalog fields, a return window that is not machine-parseable, in ways a human shopper glosses over and an agent-mediated transaction cannot. Beckn does not fix that gap by itself. It gives the transaction a verifiable record of whatever terms were actually published, which makes the quality of that publication, not the charm of the storefront, the thing that decides whether the contract that gets signed is the one the business meant to offer.

The limits of the trust the protocol supplies

A signed contract proves what was agreed. It does not, by itself, prove that an AI agent evaluating an MSME's listing chose fairly among competing sellers in the first place. A 2026 evaluation of AI shopping-agent behavior by researchers including Amine Allouah, Omar Besbes, and Yash Kanoria, posted to arXiv under an auditing framework the authors call ACES, found that agents exhibit what they term choice homogeneity, a tendency to concentrate purchasing decisions on a narrow set of products rather than distributing attention the way a human browsing a full catalog would. The same study found agents display measurable position bias that varies across AI providers and model versions, and that agents penalize items carrying sponsored tags while favoring platform-endorsed ones.

None of that is a Beckn-specific finding, and none of it is resolved by a better contract layer. It describes a separate, upstream problem: whether an MSME's listing gets evaluated by an agent at all before any contract is ever signed. Beckn's verifiable micro-contract answers the question "can this transaction be trusted once it happens." It does not answer the question "will an agent find and consider this seller in the first place," which is a discovery and structuring problem, not a contracting one.

Beckn is real, live, and used by India's largest public digital-commerce network, and that its architects are explicit about building for an agent-mediated future rather than only a human one. It is also true that BecknGPT is a demonstration rather than a deployed consumer habit, that AP2 and Beckn remain separate efforts as of this writing, and that the deeper question of whether an AI agent will even surface a given MSME's listing sits outside what any contracting protocol, Beckn included, is designed to solve.

How to read this without overclaiming

Two things can be true at once here. Beckn genuinely does what its architects say: it turns a transaction into a signed, verifiable record instead of an implicit understanding, and it was designed from the outset to work whether the party initiating the order is a person or a machine acting for one. That is a real, structural answer to a real problem in a world where more buying decisions get delegated to software.

What it is not is a guarantee of visibility, ranking, or preference. An MSME whose ONDC catalog is thin, inconsistent, or poorly structured gets the same cryptographic contract infrastructure as one whose catalog is precise and complete, applied to whatever terms it actually published. The protocol enforces that the contract is honest to the listing. It does not make the listing itself any more complete, competitive, or legible than the seller made it. That work still sits with the business, not the network underneath it.