Loading
Loading
A white-page story about how SELLABLE makes any store discoverable, negotiable, and safely transactable by autonomous AI buyers — with deterministic policy and a ledger that explains every rupee.
In SELLABLE, a "held fact" is a money-relevant fact the agent has ready but is not yet allowed to release. When a buyer agent negotiates with a merchant, the Seller Agent produces three such facts: a quote (a price computed from the catalog, margin rules, and negotiation history), an upsell (a suggestion checked against stock and the buyer’s budget), and a consent token (a single-use, amount-bound authorization to pay).
The agent cannot release any of them on its own. Every held fact first goes to the deterministic policy engine, which checks budget caps, floor prices, allowed categories, remaining stock, and negotiation rounds. If the guardrails pass, the fact is released into the conversation — exactly once. If not, it is denied and the denial is logged. The fact is not hidden; it is gated.
Think of the agent as a cashier who can prepare a sale, but the register only opens when the rulebook says so. The rulebook is not another AI — it is plain, deterministic code.
This is why the held fact is the safety design itself, not a metaphor around it. The model proposes, the policy engine decides, and the XAI Ledger records every release with a trace ID, the reasoning behind it, and the policy rules that governed it. Every rupee has an explanation.
In SELLABLE, the AI can suggest and negotiate, but it can never move money by itself. A rulebook — not another AI — checks every deal, and a receipt-style log explains every step in plain language.
The answer contains money — so it does not go out on the model’s word alone. The quote waits for the policy engine.
“The LLM proposes, the policy engine disposes — and every action leaves an explanation.”
The agent never has final authority over money. It proposes; a deterministic Policy/Guardrail engine validates; the XAI Ledger records everything. The “held fact” timing discipline becomes a money discipline.
In 2025, NPCI — which runs UPI — published agent payment protocols that let AI agents initiate and approve payments on a user's behalf with per-transaction consent, spend caps, and human-in-the-loop above thresholds. At the same time, AI buyers shifted from recommending to purchasing: Perplexity's buy-with-Pro, OpenAI's shopping agents, Google's procurement agents. Commerce is no longer "human clicks Buy". It is "agent negotiates and buys".
This is not a future-state prediction. It is a present-tense infrastructure gap. Razorpay already runs pilot programs with merchants who receive orders from AI agents. NPCI's 2025 protocol specification defines consent tokens, spend limits, and audit requirements that merchants must implement now to participate in this channel. The merchants who build agent-facing infrastructure today will capture the first wave of autonomous procurement spend — estimated at $47B globally by 2027.
Two things changed at once: the rules (India's payment network now says how an AI agent may pay on your behalf) and the buyers (shopping AIs that actually buy, not just recommend). Stores today are built for people clicking a “Buy” button — an AI literally cannot read them.
Merchants today are built for human eyeballs: HTML storefronts, carts, coupon codes. They are invisible and unusable to AI buyers: no machine-readable catalog, no agent-facing API, no negotiation policy, no consent flow, no audit trail when an agent spends money. The problem is not that AI cannot buy — it is that merchants have not been built to be bought by AI.
The Track 01 brief asks for both: (a) grow the merchant's revenue using agents and (b) make the merchant sellable to AI buyers. We chose to solve (b) end-to-end and let (a) emerge from the same transaction — upsell attach, bounded negotiation that protects margin, and AI discoverability itself as a revenue channel.
The core insight is timing. In writing, the "held fact" model teaches that information should be held until the natural insertion point. In commerce, the same discipline applies to money: the agent holds a valid quote, a negotiated price, and a consent token until the policy engine confirms that every gate — budget, floor, HITL, single-use — is clear. Then and only then does the payment execute. This is not just good UX. It is the safety invariant that makes autonomous commerce auditable.
The same gating discipline governs money. The agent may hold a valid quote while the system waits for the guardrails to clear — consent, policy, HITL — then releases it exactly once.
Each step in the workflow is not just a UI state — it is a ledger event. The Buyer Agent discovers the merchant via /.well-known/agents.json, reads the machine-readable catalog, and initiates a quote request. The Seller Agent responds with a price computed from real catalog data, bounded negotiation rules, and margin floors. The Policy Engine validates both sides: the buyer's budget ceiling and the merchant's floor price. Only when both allow does the flow proceed to consent. The consent token is single-use, amount-bound, and expiring — it cannot be replayed, cannot exceed the amount, and cannot be reused after payment. If any gate fails, the flow stops gracefully with a structured explanation. Nothing is retried silently. Nothing is left ambiguous.
Here is the whole purchase in one breath: an AI finds your store, asks for a price, haggles a little, gets a one-time permission token, pays through Razorpay, and every one of those steps is written down so you can replay it later. If a rule says no at any point, the flow stops — politely, with an explanation.
Every step leaves a ledger event with actor · action · inputs · outputs · reasoning_summary · policy_refs. Nothing about money is left to “the model felt like it”.
Agents are orchestration and language surfaces; the Commerce Core owns authoritative business state and money invariants. The Trust Layer makes every decision replayable.
Picture your shop with a new front door built for robots. Two AI workers (one buys, one sells) talk to each other; a strict rulebook and a cashier's desk (the Commerce Core) actually hold the till; and a security camera with a transcript (the Trust Layer) records every exchange.
No speculative infrastructure. Every choice optimizes for a demonstrable hackathon vertical slice: deterministic commerce first, observability later.
The Policy Engine is pure, LLM-independent, and testable without a model. It evaluates buyer budget and merchant constraints in the same call and returnsALLOW /DENY(reason_code) /NEEDS_HUMAN_APPROVAL.
The engine is deterministic: given the same inputs, it always returns the same decision. This means it can be unit-tested without an LLM, debugged without a model, and audited without a prompt. The LLM's role is to propose — to phrase a counter-offer, to suggest an upsell, to present a quote. The engine's role is to dispose — to validate that the proposal falls within every guardrail. This separation is what makes the system explainable: every decision has a reason_code, every reason_code maps to a policy, and every policy is documented and testable.
The AI is the talker; the rulebook is the bouncer. The rulebook never gets tired, never gets creative, and always explains its decision with a code you can look up.
Consent in NPCI's agent payment protocol is not a blanket authorization. It is a per-transaction, amount-bound, single-use token that expires if not consumed. This means the user (or their agent) must explicitly approve each payment, knowing the exact amount, payee, and purpose. The token cannot be reused, cannot be altered, and cannot exceed the authorized amount. If any condition changes — the cart total increases, the merchant changes, the scope expands — a new consent token is required.
Human-in-the-loop (HITL) adds a second safety layer: orders above a configurable threshold (default ₹2,000) are routed to the merchant operator for manual approval before consent can proceed. This is not a UI nicety — it is a policy engine decision. The engine returns NEEDS_HUMAN_APPROVAL and the flow pauses until the operator acts. The operator sees the full context: order details, agent identity, policy evaluation, and the reason for escalation. They can approve, reject, or modify the order. This is the human-in-the-loop that NPCI's protocol requires for high-value transactions.
Every payment needs its own one-time permission slip — no blanket “charge me whenever”. And if a cart is unusually expensive, the flow rings the shopkeeper: it waits for a real human to tap Approve before a single rupee moves.
{
"consent_id": "con_123",
"order_id": "ord_456",
"amount_paise": 185000,
"payee": "merchant_001",
"scope": "single_txn"
}The bar says "every money action must be explainable". The ledger makes that a data structure, not a slide. Each event answers: who acted, what they attempted, what inputs were used, which policy fired, what changed, why.
The XAI Ledger is append-only and immutable. Every event — from catalog search to payment confirmation — is recorded with a unique trace_id that links all actions in a single transaction. The event schema includes: actor (who initiated), action (what was attempted), inputs (what data was used), output (what decision was made), reasoning_summary (plain-English explanation), and policy_refs (which rules were consulted). This is not optional logging — it is the core of the trust architecture. Without it, an autonomous agent spending money is unauditable. With it, every rupee has a story.
Think of it as a till receipt for decisions, not just for money. For every step you can ask: who did it, what exactly happened, which rule applied, and why — and the answer is stored forever, in order.
{
"event_id": "evt_7f3a",
"trace_id": "trc_88f2",
"actor": "policy_engine",
"action": "policy.validate_order",
"inputs": { "total_paise": 185000 },
"output": { "decision": "ALLOW" },
"reasoning_summary":
"Order is within buyer budget and merchant floor.",
"policy_refs": [
"POLICY.buyer_budget",
"POLICY.max_order_value"
],
"outcome_effect": { "order_state": "AWAITING_CONSENT" }
}The growth story is not a separate product — it emerges from the same transaction infrastructure. When an AI buyer discovers a merchant through agents.json, negotiates within policy, and pays via Razorpay, the merchant gains a new revenue channel that was previously invisible. The "growth" is not about adding marketing features — it is about making the merchant discoverable to a new class of buyer that did not exist before.
You don't have to run ads to get this growth. The moment an AI shopper can find, haggle with, and pay your store, you have a new kind of customer — and the same transaction already does the upselling and the discount-limit enforcement for you.
A demo that fakes its own auth is a toy. The console now runs on real Supabase Auth with asymmetric ES256 session tokens verified against the project's JWKS - and every authenticated user gets their own real merchant record, not a shared demo store. The demo store still exists, but as an actual database row used by the agent-to-agent surface - never as a fallback for a human login.
Most demo apps share one fake login. This one gives every real person their own real store with their own products, orders, and ledger — like actual software, not a stage prop.
A held fact is not a hidden fact. It is a timed fact.
In writing, timing is craft. In commerce, timing is safety. SELLABLE holds every money-relevant fact — quote, floor, consent, refund — until the policy engine says the sentence is ready for it. That is the whole case study in one interaction pattern.
The merchant side of agentic commerce is not about building a chatbot or adding an API endpoint. It is about rebuilding the merchant's interface for a new class of buyer — one that reads machine-readable manifests, negotiates within deterministic policy, pays through real rails with real consent, and leaves an audit trail that explains every rupee. This is infrastructure, not features. And it is what makes a merchant truly sellable.