45 Minutes vs 4 Months: What Beckn Onix's Onboarding-Speed Claim Means for How Fast New AI-Native Networks Could Route Around ONDC

What Google Cloud and Beckn Labs actually announced

The claim originates in a single press release. On November 3, 2025, Google Cloud and Beckn Labs published a joint announcement introducing Beckn Onix as, in their words, the first scalable, cloud-native implementation of the Beckn Protocol. The release states plainly that organizations which previously took four to five months to build an open network can now do so in as little as 45 minutes, and that the tool is available on GitHub as open source.

Anil Bhansali, VP of Engineering at Google Cloud, is quoted calling open networks "the digital rails for the next generation of AI" and Beckn Onix "the catalyst for action." Sujith Nair, CEO of Beckn Labs, describes it as "a common plug-and-play adaptor enabling network orchestrators and participants to tap into Beckn's potential." Pramod Varma, a co-founder of Networks of Humanity and one of the original architects of the Beckn Protocol and India Stack, is quoted framing open networks as creating value through "massively interconnected yet unified systems." These are the words of the people selling the product and the protocol they helped design, and that framing matters for how much weight the 45-minute figure should carry, a point this piece returns to.

The release also states that Beckn Onix integrates Google's open-source Agent Development Kit, ADK, so that developers can build AI agents against Gemini or any other model "from day one" inside a Beckn network. That is a specific, checkable technical claim, not vague marketing language: ADK is a real, publicly documented toolkit, maintained in the google/adk-python and google/adk-docs repositories, for building and deploying multi-agent AI systems, and the Beckn Onix announcement is one of the first times it has been positioned as the AI layer for open commerce infrastructure specifically.

What Beckn actually is, and why the speed claim is technically plausible

Beckn is not ONDC. It is the open protocol ONDC is built on top of. The protocol defines how a buyer-side application, called a BAP in the protocol's terminology, and a seller-side platform, called a BPP, exchange search, order, and fulfillment messages through a shared registry and gateway, regardless of which company built either app. ONDC is one specific network instance running that protocol, governed by an Indian nonprofit under the Department for Promotion of Industry and Internal Trade. It is not the only one.

The public GitHub repository for beckn-onix describes itself as "a production-ready, plugin-based middleware adapter for the Beckn Protocol," with modules that handle validation, routing, message signing, schema checking, and caching between BAPs and BPPs, and a setup script that automates most of that configuration. A companion Google Cloud repository, dpi-accelerator-beckn-onix, goes further: it packages a full Beckn network, including a registry, gateway, and adapter, as an automated rollout that provisions the underlying Google Cloud infrastructure, GKE clusters and Cloud SQL, using Terraform, with the application layer deployed through Helm and a browser-based installer sitting on top. That repository's own documentation describes the goal as an "automated workflow to get a full Beckn network running in minutes," which is the more conservative, technically-scoped version of the 45-minute press-release figure.

Put together, the plausibility case is straightforward. What used to require months of custom integration work, standing up a registry, wiring a gateway, building signing and validation logic by hand, has been repackaged as infrastructure-as-code plus a managed adapter. That is a real and fairly ordinary kind of speedup in cloud engineering. It does not require ONDC's cooperation, India-specific rules, or government approval, because none of that lives at the protocol layer. Anyone standing up a Beckn-compatible registry and gateway is building a new network, not joining ONDC's.

ONDC is already not the only Beckn network, and that is the part worth noticing

This is not a hypothetical extension of the announcement. It is already the documented pattern. The same Google Cloud and Beckn Labs press release names several live Beckn-based networks operating outside ONDC entirely: ONEST for education and skilling transactions, VISTAAR for agriculture, DEG and the Unified Energy Interface for energy and EV charging, alongside sector work in healthcare, tourism, and mobility. The release also cites a concrete rollout, an Open Network Stack for Agriculture built with Beckn Onix in Uttar Pradesh that had engaged more than 12,800 farmers by the time of the announcement.

Beyond the Beckn Onix launch material, the pattern has been visible for a while. The Unified Health Interface runs on Beckn for healthcare appointments and records. Namma Yatri, the Bengaluru auto-rickshaw booking platform, was built on Beckn as an alternative to proprietary ride-hailing apps, independent of ONDC. Each of these is its own registry, its own governance, its own participant list, connected only by the fact that they all speak the same underlying protocol.

The strategic reading is not that ONDC is being replaced. It is that "the Beckn network" was never a single thing to begin with, and the infrastructure cost of adding one more instance of it has just dropped by roughly two orders of magnitude, if Google Cloud's own figure is taken at face value. A state government, an industry body, or a private platform that wants a commerce or services network with the same open, interoperable design as ONDC, but its own governance and its own registry, now faces a substantially lower engineering bar to stand one up.

What this means for an MSME whose only channel is ONDC

Most of the reporting on ONDC's reach describes participation, not exclusivity: industry estimates put the share of small and medium sellers among total ONDC-onboarded participants at a majority, and the Ministry of MSME's own TEAM initiative, a three-year, roughly Rs 277.35 crore program launched in June 2024, was built specifically to bring five lakh, 500,000, additional micro and small enterprises onto the network, half of them women-owned. That is a serious, funded government bet on ONDC as the on-ramp for small-business digital commerce, run through the Ministry of MSME's RAMP scheme and documented on ONDC's own site.

That investment is real and it does not disappear because a second network exists somewhere else. What it does mean is that an MSME whose entire digital storefront lives inside one seller app connected to one registry, ONDC's, should be precise about what it actually has: a listing inside one instance of an open protocol, not a listing that is automatically visible to every buyer-side application that might ever speak that protocol. Those are different claims, and the difference is exactly the kind of thing a business owner has no easy way to check without technical help, because "which registry is my listing actually in" is not a question most seller-app dashboards surface.

This is the precise version of the "routing around ONDC" idea in the headline. It is not that a competing network is about to strip ONDC of its sellers. It is that the cost of a new, adjacent, protocol-compatible network being built by someone else, in a different sector, a different state program, or a different country entirely, has fallen sharply, and each new network is a separate room a buyer-side AI agent might search that a single-registry MSME is not necessarily standing in.

Where the agentic commerce layer comes in

The Beckn Onix announcement leans on a second, separate development to make its AI framing land: the idea that buyer-side agents, not just buyer-side apps, will increasingly be the thing searching these networks. That is a real and fast-moving space, but it is worth being precise about what is connected to what.

Google's own Agent Payments Protocol, AP2, announced September 17, 2025 with more than 60 launch partners including Mastercard, PayPal, and American Express, is a separate open standard for how an AI agent proves what a user authorized it to buy and pay for, built on top of Google's Agent2Agent and the Model Context Protocol. On April 28, 2026, Google donated AP2 to the FIDO Alliance, the same body that governs passkey standards, to be developed under open, multi-vendor governance alongside Mastercard's Verifiable Intent framework, through two new FIDO working groups. Nothing in Google's AP2 launch material or its FIDO donation announcement mentions Beckn, India, or ONDC by name. AP2 governs how an agent pays; Beckn governs how a buyer and seller discover and transact with each other. They are adjacent, Google-touched developments in the same "AI agents doing commerce" moment, not, as of this writing, a documented integration.

What is documented is narrower and still meaningful: Beckn Onix's own use of Google's Agent Development Kit means any new Beckn network built on this stack can wire in AI agents as first-class participants from the start, on either the buying or selling side. That is the specific, sourced claim. The larger idea that agent-to-agent payment rails and open commerce discovery protocols will eventually need to interoperate is a reasonable industry expectation, but it should be labeled as exactly that, an expectation, not a shipped integration.

How to read the 45-minute number

The 45-minute figure and the "four to five months" comparison come from one press release, issued jointly by the company selling the cloud infrastructure and the nonprofit that stewards the protocol being deployed on it. That does not make the figure false. The companion GitHub documentation for the underlying rollout tooling independently describes an automated, Terraform-and-Helm-based install aimed at getting "a full Beckn network running in minutes," which is directionally consistent with a large, order-of-magnitude speedup even without repeating the specific "45 minutes" figure. But no independent, third-party benchmark of the claim exists in the public record as of this writing, and the four-to-five-month baseline it is compared against is not itself sourced to a specific study of pre-Beckn-Onix rollouts; it reads as the vendor's own before-and-after framing.

The reasonable position sits between two extremes. It would be wrong to treat "45 minutes" as an audited, third-party-verified benchmark, because it is not. It would also be wrong to dismiss it as pure marketing, because the underlying mechanism, infrastructure-as-code plus a packaged middleware adapter replacing bespoke integration work, is a well-understood and genuinely fast pattern in cloud engineering, and the GitHub repositories backing the claim are real, inspectable, open-source code, not vaporware. The fair label for the overall claim is emerging: technically plausible, partially independently corroborated by the tooling's own documentation, not yet independently benchmarked.