Private buyer context in. Policy-safe commerce out. Measurable learning back.
GrowthLoop is an agent-to-agent decision and payment layer for commerce. It lets a buyer agent communicate useful intent and consented purchasing signals to a merchant agent without handing over the buyer's raw history. The merchant agent turns that context into a bounded offer, completes the purchase through Razorpay and learns from verified outcomes—not clicks or coupon redemptions in isolation.
The result is a different relationship for both sides:
- Buyers can use their history as negotiating context without disclosing an itemized behavioral record or being reduced to an opaque "high value" label.
- Merchants can personalize inside explicit margin, budget, inventory and experiment limits instead of publishing the same coupon to every visitor.
- Every commercial decision remains traceable from consent and evidence through quote, payment, order, attribution and the next merchant-approved policy.
The LLM interprets, ranks and explains. Deterministic services own identity, consent, eligibility, experiment assignment, prices, limits and payment authority.
Most checkout promotion systems begin with the cart and end with a discount. They do not know which context a buyer is willing to contribute, cannot show why one offer was selected and rarely connect the decision to a trustworthy commercial outcome. More context usually means centralizing more personal data; more automation often means giving a probabilistic model authority it should not have.
GrowthLoop separates those concerns. A buyer-controlled evidence boundary reduces history to purpose-specific traits. A merchant-owned policy engine creates the valid commercial choices. An LLM operates only inside that choice set. A persisted quote—not the model response—authorizes payment. Verified payment outcomes feed a bounded, auditable experiment rather than silently retraining an unconstrained pricing model.
flowchart LR
B[Buyer agent] -->|request + consent| V[Private evidence vault]
V -->|signed coarse traits| S[Merchant agent]
S --> P[Policy-valid offer set]
P --> L[LLM ranking and explanation]
L --> Q[Integrity-bound quote]
Q --> R[Razorpay payment]
R -->|verified event| O[Order + attribution]
O --> E[Merchant experiment]
E -->|human approval| N[Next policy version]
Raw history remains on the buyer side of the boundary. The seller receives only consented, signed and request-bound traits. Gemini receives an even narrower input: verified coarse traits, the current request, the assigned experimental arm and already-valid options. It never receives the evidence signature, buyer reference, raw purchases, merchant COGS or internal thresholds.
GrowthLoop is not a bargaining chatbot and the LLM does not invent discounts. The buyer agent expresses structured authority: product constraints, full payable budget, substitution rules and consent. The merchant agent combines that request with verified signals and merchant policy, asks Gemini to rank feasible choices, revalidates the selection and issues a quote. If the model is unavailable or returns an invalid choice, the transaction remains inside deterministic safety rules.
A controlled no-history shadow run helps explain whether the supplied evidence changed the recorded decision. It has no payment authority, reserves nothing and never enters conversion metrics. Separately randomized actionable offers provide the evidence used for merchant learning.
- Commerce teams that want conversion improvement without uncontrolled discounting.
- Marketplaces and agent platforms that need a safe buyer-agent to seller-agent handoff with explicit commercial authority.
- Privacy-conscious buyers who want relevant treatment without exposing raw history.
- Merchant analysts who need payment-confirmed measurement, uncertainty and a clear approval trail before a new policy takes effect.
The repository contains the end-to-end buyer request and Demo Vault journey, strict signed evidence, bounded experiment assignment, policy-filtered seller decisions, actionable/shadow isolation, normalized quote issuance, idempotent acceptance and a pre-provider Razorpay payment-attempt state machine. PostgreSQL schemas and domain tests also cover orders, provider events, attribution, experiment metrics and policy recommendations as those capabilities are connected to the live journey.
Requires Node.js 26+, pnpm 11.5.2, Go 1.26+, Docker and PostgreSQL tools.
cp -n .env.example .env && pnpm install --frozen-lockfile && docker compose up -d postgres && make db-migrate && make db-seed && make verifyThen run cd apps/api && go run ./cmd/api, run pnpm --dir apps/web dev, and open
http://localhost:3000/. Live Gemini/Razorpay require test credentials in .env.
- Architecture and invariants
- API and payment contracts
- Privacy model and research
- Judge runbook
make verifyruns tests, type checks, lint and production builds.scripts/test-guided-commerce-schema.shproves PostgreSQL commercial constraints.
Final screenshots and the video link will be added only after the progressive UI and fresh-clone rehearsal are complete.
- Identity, external purchases and the attestor are simulated. A Vault signature proves issuer and payload integrity, not that a real-world purchase occurred.
- The shadow run cannot reserve, pay, convert or enter learning metrics.
- Seeded outcomes are synthetic. One test payment proves integration, not uplift; recommendations require samples and merchant approval.
- Production authentication, refunds, independent attestors, AP2, Reserve Pay and production-scale reconciliation are not complete.
- Contribution is estimated and formula-versioned where costs are incomplete.
ROI-constrained promotion uplift, multiple-choice uplift optimization, multi-objective recommendation, selective-disclosure trade-offs, W3C BBS, SD-JWT, and AP2.
These sources motivate the design; they are not evidence of production uplift.