Connected Agents.
One Ecosystem.
Accelerated Outcomes.
AtOM orchestrates the complete change lifecycle — from idea and requirements to implementation, partner readiness, testing and certification — across two platforms that meet over a signed Agent-to-Agent wire.
From specification idea to certified implementation
AtOM — Agentic Orchestration & Messaging — is an enterprise Agent-to-Agent change orchestration platform that provides a single source of truth for coordinating large-scale payment-system changes across NPCI, banks and payment service providers. An idea becomes research, design documents and schemas; those go out to the organisations that must implement them; their questions come back; code is generated against the target codebase; and the result is certified.
For change owners
Create ideas, manage requirements, generate governed artifacts, coordinate decisions and retain a complete version-controlled audit trail. This is the sending side, and it is the AtOM network platform.
For ecosystem partners
Receive specifications through structured A2A communication, assess them against your own capability profile, raise queries, negotiate rollout terms, report readiness and complete certification. This is the receiving side, and it is the partner platform.
The authority side and the partner side are separate products
AtOM now ships as two independent codebases that deploy as two independent stacks. They are separate because they have different audiences: the authority runs one instance of its platform, while every partner forks its own. Nothing about the partner platform needs to be deployed alongside the network platform — it connects as an authenticated A2A client.
AtOM Network Platform
The authority's platform. It authors a change end to end — research, product canvas, requirements, technical specification, XSD schemas, an explainer deck and video, prototype screens and certification test cases — then distributes it to registered partners over A2A, generates code against the target codebase, and runs the certification conversation.
One instance, run by the authority Authors, distributes and certifies a change
Partner Platform
Reference base code that ecosystem partners fork. It receives specification changes from the authority, assesses each one against the partner's own capability profile, negotiates terms, reports readiness and drives certification — with a pluggable agent at every stage that the partner replaces with logic that knows their systems.
Forked per partner Seven agents the partner can customise
One platform for coordinated change
Purpose-built capabilities connect product governance, engineering execution and partner readiness while preserving the context behind every decision.
Every stage is evaluated before it advances
The workflow runs in three phases. Phase A turns an idea into a distributable product kit. Phase B and Phase C both consume Phase A's output and run independently — a change can go to partners without code having been generated, which is why the path forks.
| Phase | What it covers | How progress is tracked |
|---|---|---|
| Phase A Idea to design | Prompt enhancement, research, canvas, clarification, business requirements, schemas, technical specification and the product kit. | Nine strictly ordered states, with a defined evaluation checkpoint between stages. |
| Phase B Design to build | Workspace preparation, context assembly, code change, review and repair against the target codebase, ending in a build. Anything past that point runs an operator-supplied script under the operator's control. | An agentic run state machine. Interrupted runs resume from the last recorded phase rather than restarting. |
| Phase C Partner collaboration and certification | Communication, acknowledgement, negotiation rounds, implementation progress, readiness declaration, then certification through to sign-off. | A per-partner assignment lifecycle running from assigned through certified and on into production, with blockers as first-class objects and failed A2A deliveries retried by a scheduled job. |
What the authority side does
This is the platform the authority runs — one instance, operated by the body that publishes the change. It drafts each specification from source material rather than from a blank page, checks every draft before it moves on, and holds the whole change in one place from the first idea through to a partner's certificate.
Authoring pipeline
Turn one prompt into research, a product canvas, requirements, technical specifications, XSD schemas, an explainer deck and video, prototype screens and certification test cases.
Partner distribution over A2A
Distribute artifacts to registered partners, manage the negotiation loop and monitor per-partner implementation status.
Grounded in your own source material
Search the ingested corpus and the target codebase together, combining keyword and meaning-based retrieval, so agents draft from documents they actually read rather than from memory.
Code generation against the target codebase
Plan, edit, review, repair and run a build, while a human retains control of the merge request.
Governance review stages
Upload your own review skill bundles to run as extra reviewers, producing must-fix findings that hold a run until they are resolved or overridden with a recorded reason.
Certification workflow
Drive certification as a structured A2A conversation with a partner's agent, carrying each generated test case and its evidence through to sign-off.
Agent instructions are being moved out of code and into external text files, so changing what an agent is told becomes a reviewable edit rather than a code change. Six roles — product owner, product manager, tech lead, InfoSec reviewer, risk reviewer and admin — shape who sees and acts on what, alongside per-change ownership.
One place to receive, assess and certify a change
A central authority publishes a change; every bank, payment service provider and third-party app provider in the ecosystem has to read it, work out what it costs them, ask questions, build it and declare themselves ready. The partner platform does that side of the conversation. It ships as reference base code rather than a finished product: partners take a copy, point it at their authority, and replace the built-in logic with logic that knows their own systems.
Partners customise the parts that know their own systems
Seven agents ship ready to run — feasibility, design, code, test, negotiation and two review checks — with one deliberately left as a documented starting point for the partner to complete. Each can be kept as shipped, replaced with the partner's own code, or pointed at a service they host in any language, and swapping one is a configuration change rather than a code change. What stays fixed is the connection contract with the authority: it is identical on both sides and is not a partner's to alter. Every run, shipped or replaced, is recorded.
Designed for payments. Extensible beyond payments.
AtOM was created for an ecosystem where a central body publishes a change and many banks and payment providers implement it. Domain vocabulary is being moved behind a pluggable domain pack, with UPI as the default, so the platform can support additional products and ecosystems. The rule is that the core supplies the machinery and never reaches into a pack; a domain that lacks a capability declares it by omitting it, rather than stubbing it out.
User-visible wording ships as ecosystem-neutral text — "the authority" rather than any named organisation — and each deployment supplies its own labels and branding. The shipped UPI profile is an example override, not baked-in branding.
The A2A contract carries payments-ecosystem field names because they are shared between the two platforms and cannot be renamed on one side alone. They are protocol identifiers rather than branding, and they are never user-visible.
MIT, single-vendor, openly stated
Both codebases are released under the MIT License, sponsored by the National Payments Corporation of India. Contributions are accepted under a Developer Certificate of Origin rather than a contributor licence agreement — no paperwork, just a signed-off commit.
Single-vendor open source
NPCI owns the copyright, employs the maintainers and makes the final call on scope, architecture and releases. This is stated plainly because implying a neutral, multi-stakeholder foundation that does not exist would waste contributors' time.
Shared maintenance
Both repositories share one maintainer team and one governance model, because the A2A contract spans both and a wire fix has to land on both sides together. Each repository takes security reports against its own tracker.
Dependency posture
Every dependency installs from a hash-locked file with a pinned hash for each package, so a build either resolves to exactly the reviewed set or fails. Third-party licence notices are recorded in-tree, and tooling to generate a full CycloneDX software bill of materials ships with the repository.
Trademarks are separate
The licence covers code, not marks. Forks may state that they are built on AtOM, but may not imply endorsement or official status. If you fork it, name it something of your own.
Scan to open the AtOM repositories, or follow the link. Both the network platform and the partner platform are published under the MIT License.
Browse the repositories ↗Two stacks, each behind its own front door
Each platform deploys independently, with its own database, its own front door and its own operational lifecycle. The only thing they share is the signed A2A wire between them. Neither can reach into the other's data.
Frequently asked questions
Why are there two codebases instead of one?
Because they have different audiences and different lifecycles. The authority runs a single instance of the network platform, while every partner forks and adapts its own copy of the partner platform. Splitting them lets a partner deploy, secure and upgrade their side without carrying the authority's stack, and lets each repository be reviewed and released on its own schedule.
Do I need to deploy both to use either?
No. Each stack runs on its own. The partner platform is a client of a live authority instance: it needs a reachable A2A endpoint and authority-issued credentials, both entered from its settings screen. It starts and demonstrates its full flow on a fresh clone without them.
How do the two stay compatible?
Through a single shared wire contract that is mirrored between the repositories. Each repository validates its own copy, so a change to the message schemas, the token scheme or the signer is treated as a coordinated release across both. A divergence would not fail either test suite — it would surface as a rejected signature on a live call, which is exactly why the coordination rule exists.
Is this the same as NPCI's in-house version?
No. The public repositories represent the open-source edition. Internal features, integrations, controls and deployment configurations may differ.
What does Agent-to-Agent communication enable?
It enables structured exchange of tasks, artifacts, questions, progress, blockers and certification responses between authority and partner agents. The protocol defines a frozen set of messages, each with a declared direction and correlation key, carried over JSON-RPC using Google's A2A protocol.
Can a partner use their own AI models and tooling?
Yes, and that is the intended use. Every stage on the partner side is an agent that can be replaced — either as code running in-process or as a service the partner hosts in any language. The platform passes plain data in and expects plain data back, so what happens inside a partner's agent, including calls into their own internal systems, is invisible to the platform and needs nothing from it.
Is AtOM limited to UPI?
No. UPI is the initial domain pack, while the architecture is intended to extend to other NPCI products, payment systems and suitable non-payment ecosystems. Some generated prose remains payments-specific until that work completes.