​

Agentic Commerce PRD

This is the canonical consolidated PRD for Grantex Commerce and AgenticOrg agentic commerce. It brings the seller journey, buyer journey, existing merchant systems, buyer-agent channels, standards fit, safety gates, implementation gaps, and fast-track roadmap into one place. This document is planning and documentation only. It does not deploy, create cloud resources, change production configuration, touch secrets, approve a real merchant, enable public discovery, enable production Commerce V1, enable checkout/payment creation, enable live payments, enable live Plural, or set a production allowlist.

​

1. Product Thesis

Agentic commerce should let a buyer ask an AI agent to discover, compare, and buy from a real merchant without the merchant rebuilding their business and without the agent inventing commerce facts. The product boundary is:

Grantex is the seller and merchant control plane. AgenticOrg is the buyer and agent-facing workflow layer. AgenticOrg may help a buyer shop, but every commerce fact and every protected action must come from Grantex.

The finished product should allow:

• Sellers to self-serve into a sandbox merchant workspace.
• Sellers to connect systems they already use.
• Grantex to normalize those systems into governed commerce capabilities.
• Buyers to start from familiar chat or agent surfaces.
• AgenticOrg to run a buyer-agent session using only Grantex-approved tools.
• Grantex to enforce consent, policy, Commerce Passport, payment boundaries, audit, rollback, and merchant approval.
• Standards-facing surfaces to be generated from one canonical commerce model, not hand-maintained per platform.

​

2. Non-Negotiable Safety Boundary

An AI agent can initiate a commerce checkout through a payment provider only when Grantex can verify:

• buyer consent;
• scope;
• merchant policy;
• revocation status;
• tenant boundary;
• agent identity;
• channel capability;
• amount cap;
• product/cart hash or equivalent cart evidence;
• idempotency;
• provider readiness;
• audit evidence;
• rollback readiness.

AgenticOrg must not:

• hold provider credentials;
• call Plural, Stripe, Pine, Razorpay, Cashfree, Adyen, PhonePe, or another payment provider directly for commerce execution;
• call Shopify, WooCommerce, Magento, ERP, OMS, WMS, logistics, CRM/support, or merchant private APIs directly for commerce execution;
• become the catalog, inventory, order, refund, settlement, or payout source of truth;
• store raw Commerce Passport values, JWTs, tokens, idempotency key values, webhook secrets, DB/Redis URLs, private keys, raw payloads, private merchant artifacts, pricing terms, contracts, or customer data;
• invent sellers, products, prices, discounts, stock, delivery promises, return eligibility, order status, payment status, settlement state, payout state, or refund outcomes.

​

3. Ownership Model

​

4. Current Implementation Snapshot

Status as of 2026-06-07:

• Grantex seller-control-plane work is implemented through the sandbox read-only discovery handoff path: C5Z, C6A, C6B, C6C, C6D, C6E, C6F, and C6G are merged on Grantex main.
• AgenticOrg read-only buyer discovery consumer foundation is merged through C6H. C6I buyer-session orchestration is merged on AgenticOrg main.
• Grantex protocol-adapter and connector foundations C6J, C6K, C6L, C6M, and C6N are merged on Grantex main.
• The open-protocol packaging draft is an internal docs-only PR refreshed on the merged C6I-C6N base. It is not public protocol publication, not certification, and not production approval.
• Public discovery, production Commerce V1, checkout/payment enablement, live payments, live Plural, production allowlists, certification claims, provider calls, and AgenticOrg direct merchant-system calls remain blocked.

​

4.1 Grantex Foundation

​

4.2 AgenticOrg Foundation

​

5. End-To-End Architecture

Existing merchant systems may include:

• Shopify;
• WooCommerce;
• Magento;
• custom storefront;
• marketplace backend;
• ERP;
• PIM;
• inventory system;
• WMS;
• OMS;
• logistics provider;
• payment provider;
• CRM;
• support desk;
• finance/reconciliation system;
• CSV/API/manual maintenance process.

Those systems connect to Grantex. AgenticOrg does not connect to those systems for commerce execution.

​

6. One-Time Seller Setup

The seller setup must be self-serve for preparation, but not self-approval for live commerce.

​

7. One-Time Buyer Setup

The buyer setup should feel like normal chat/app account linking. Buyer setup is not a standing payment approval. Every payment-affecting action still needs Grantex consent, Commerce Passport evidence, policy approval, idempotency, and audit.

​

8. Regular Agentic Commerce Transaction

Plain-English happy path:

1. Buyer asks an agent to find, compare, or buy.
2. AgenticOrg starts or resumes the buyer session.
3. AgenticOrg asks Grantex which merchant and channel actions are approved.
4. AgenticOrg searches catalog and checks inventory through Grantex only.
5. Grantex returns grounded product, price, policy, return, warranty, and stock freshness facts.
6. AgenticOrg explains options and caveats.
7. Buyer chooses an item.
8. AgenticOrg creates a Grantex cart draft with exact variant IDs.
9. Grantex recalculates totals, policy, amount caps, inventory freshness, and checkout eligibility.
10. Buyer approves or denies Grantex consent.
11. Grantex issues scoped Commerce Passport status only if consent and policy pass.
12. AgenticOrg requests payment intent and checkout handoff through Grantex.
13. Provider interaction happens through Grantex only.
14. Grantex receives webhooks, reconciles status, writes audit, and creates or references order state where supported.
15. AgenticOrg reports buyer-safe status.
16. Post-purchase order, delivery, support, return, refund, settlement, and payout answers come only from Grantex after those APIs exist and are approved.

​

9. Exception And Recovery Flows

​

10. Existing Merchant APIs And Systems

Merchants should not rebuild for agents. They should connect the systems they already run. Connector rule:

A connector imports or syncs data. It does not make a merchant live for agents. Live agent access requires readiness checks, policy activation, consent, human approval, audit, and rollback ownership.

​

11. Buyer Channel Requirements

Buyers should be able to launch from familiar surfaces, but no channel is launch-ready until its platform-specific constraints and approval gates pass. Launch-ready acceptance:

• real user starts without developer setup;
• account/channel identity is bound safely;
• merchant discovery comes from Grantex;
• actions are labeled read-only, consent-required, checkout-capable, or blocked;
• Grantex-only tools execute commerce actions;
• consent and checkout copy is clear;
• platform write-action limitations are respected;
• redacted telemetry and audit evidence exist;
• smoke tests and refusal tests pass;
• fallback exists for unsupported actions.

​

12. Standards And Protocol Fit

The strategy is one canonical Grantex commerce model with protocol views generated from it. Do not claim certified UCP, ACP, AP2, A2A, MPP, schema.org production, or live provider readiness until implementation, conformance tests, approvals, and release evidence exist.

​

13. Conceptual Data Model

The implementation should preserve these conceptual records. Some already exist in V1 form; others are future gaps.

​

14. Product Requirements By Surface

​

15. Comprehensive Gap Register

​

16. Fast-Track Roadmap

Current sequencing decision:

1. C6I-C6N are merged in dependency order across AgenticOrg and Grantex.
2. The open-protocol packaging draft is refreshed on the actual merged commits and remains internal, preview-only, non-publication, and non-certifying.
3. The next runtime chain is C6O: public-safe conformance fixtures, the first real connector sync adapter foundation, order/fulfillment backbone planning, and controlled pilot readiness without enabling public discovery or live checkout.

​

17. Release Acceptance Criteria

Before a real merchant pilot:

• Merchant workspace, identity, category, and owners are approved.
• Existing-system connector or approved manual maintenance path is healthy.
• Catalog, price, tax, warranty, return, inventory, delivery, and support data pass category requirements.
• AgenticOrg can only see Grantex-approved capabilities.
• Buyer channel has auth, account/session linking, capability labels, consent handoff, fallback behavior, telemetry, and smoke evidence.
• Checkout/payment creation remains blocked until Commerce Passport consent, policy, audit, idempotency, provider readiness, and rollback checks pass.
• Paid flow has order, fulfillment, support, and return/refund handoff.
• Live provider approval, webhook signature evidence, outage handling, and rollback are complete for any live checkout scope.
• UCP/ACP/AP2/schema.org/A2A language is backed by implementation and tests, or clearly marked future/planned.
• Docs-only changes do not trigger cloud auth, image build, image push, deploy, e2e, or indexing jobs.
• No private merchant artifacts, secrets, raw payloads, tokens, JWTs, DB/Redis URLs, provider credentials, production config values, or concrete allowlist values are committed.

​

18. Stop Conditions

Stop implementation or rollout if any of these occur:

• real merchant identity is missing or unapproved;
• private artifacts, customer data, secrets, raw payloads, tokens, JWTs, DB/Redis URLs, private keys, provider credentials, or production config values appear in Git or public docs;
• AgenticOrg adds a direct provider or private merchant-system execution path;
• checkout can happen without consent, Commerce Passport, policy, idempotency, audit, and amount-cap checks;
• catalog, price, tax, inventory, delivery, return, warranty, order, payment, or refund data is stale or unverifiable but presented as guaranteed;
• paid checkout is enabled before order, fulfillment, support, return/refund handoff, and rollback are ready for the pilot scope;
• synthetic/demo data is treated as production approval;
• public discovery, production Commerce V1, checkout/payment creation, live payments, live Plural, or allowlist values are enabled without separate approval;
• certification or compliance with UCP, ACP, AP2, A2A, MPP, schema.org, or a provider program is claimed before evidence exists;
• docs-only changes trigger cloud build/push/deploy-adjacent work without an explicit policy decision.

​

19. Documentation And Workflow Updates

​

20. End-To-End Review Checklist

This PRD has been reviewed against the requested coverage:

• seller one-time setup covered;
• buyer one-time setup covered;
• regular transaction flow covered;
• failure and recovery paths covered;
• Grantex and AgenticOrg responsibilities covered;
• existing merchant APIs and systems covered;
• ChatGPT, Claude, Gemini, WhatsApp, Telegram, web/mobile, and future channels covered as launch surfaces;
• MCP, UCP-style, ACP-style, AP2-style, schema.org, and future agent surfaces covered without unsupported certification claims;
• catalog, inventory, pricing, tax, delivery, order, fulfillment, support, return, refund, settlement, payout, audit, analytics, and ops gaps covered;
• self-serve onboarding, scans, review gates, smoke evidence, and rollout gates covered;
• safety boundaries, stop conditions, and production gates covered;
• documentation/navigation/workflow coverage covered;
• next implementation sequencing covered.

Remaining decision for the team: use the merged C6I-C6N base and internal open-protocol packaging draft to plan C6O. The next implementation chain should focus on conformance fixtures, one real connector sync adapter foundation, order/fulfillment backbone planning, and controlled pilot readiness without enabling public discovery or live checkout.