AgenticCommerce

Inspiration

[Your reason for building this. For example: what made you interested in agents that transact, or in the Razorpay Buildathon theme.]

Agentic commerce raises a hard question: how do you let an AI agent spend money without giving it unchecked control? AgenticCommerce is my answer. Agents can search a catalog and complete payments through conversation, but every money-moving action passes through policy checks and is recorded.

What it does

A shopper types a request such as "I want a chicken biryani under 400 rupees." The system then:

Normalizes the intent and runs a vector search over the catalog.
Recommends complementary items by vector affinity.
Checks the spending policy before any payment step.
Creates a Razorpay test-mode payment link for orders under the cap, or pauses for human approval above it.
Writes every step to an append-only audit ledger.

The catalog covers food delivery and instant grocery. Recommendations use cosine similarity over item attributes:

$$ \text{sim}(\mathbf{a}, \mathbf{b}) = \frac{\mathbf{a} \cdot \mathbf{b}}{\lVert \mathbf{a} \rVert \, \lVert \mathbf{b} \rVert} $$

The governance rule is a simple threshold. An order $O$ with total $T(O)$ is auto-approved only when

$$ T(O) \le \text{₹35{,}000} $$

Anything above that needs a human supervisor's approval.

How I built it

Agents and messaging: a Shopper Agent, a platform agent, and a Payment Agent communicate through A2A message envelopes such as intent_handoff, catalog_response, settlement_request, and settlement_response.
Tools: a custom MCP server exposes 21 tools in six groups: catalog, recommendations, cart and orders, payments, governance and audit, and campaigns.
Data: PGlite, an embedded WebAssembly build of PostgreSQL 16, keeps setup simple for evaluation. Setting DATABASE_URL switches to hosted Postgres.
Commerce adapters: a BasePlatformAdapter maps each platform's data into a shared UniversalItem schema, so new platforms don't require changes to the governance or payment layers.
Frontend: a React app with a shopper chat view and a merchant console for overview, inventory, orders, campaigns, and audit.

What I learned

[Your lessons here. Possible topics from the design: keeping money-moving actions behind explicit gates, designing for failure with a fallback payment path, and using a single adapter schema across platforms.]

Challenges

[Describe the difficulties you actually faced. Possible topics: integrating with Swiggy's MCP endpoints, which I could only test with a fallback because live checkout is disabled; handling the payment flow in test mode; and keeping the audit trail complete across agents.]

The Swiggy integration falls back to sample data when no live token is present or the endpoint returns 401. Live checkout stays off by default, so evaluators' funds are never at risk.