Buyer and seller AI agents need commerce facts they can trust.
AgenticOrg runs merchant self-service config, deployed Shopify read-only sync, buyer sessions, web/MCP/OpenAPI/A2A/search/WhatsApp/Telegram bridge contracts, OACP cache, and provider-owned capability verification. Grantex remains the protocol, trust, policy, and artifact authority.
Source of record
Merchant systems
Shopify and future approved WooCommerce/ERP sources, catalog, inventory, policy, OMS, support, POS, and payment status systems keep operational truth.
Merchant setup
Seller commerce agent
AgenticOrg stores tenant/merchant/store-scoped config, creates the Seller Commerce Agent, stores Shopify connector custody, and prepares Grantex authority requests.
Trust and policy
Grantex authority
Grantex validates public-safe facts and issues canonical OACP artifacts or blockers.
Scoped runtime memory
OACP artifact cache
AgenticOrg stores public-safe references scoped by buyer agent, seller agent, tenant, and merchant.
Answer or refuse
Buyer agent
The buyer agent checks TTL, freshness, revocation posture, risk, source refs, and action boundary.
User surface
Buyer channels
Web, MCP, OpenAPI, A2A, Perplexity/search, WhatsApp, and Telegram receive grounded answers or refusals from the same cache path.
Provider-owned execution boundary
Mandates, payment capture, checkout execution, holds, refunds, and provider rails remain outside this page unless a separate approved implementation and verification path exists.
Current implementation status
One flow, three truths.
The runtime is real, but every external ecosystem and transaction rail still has its own setup and authority boundary.
Deployed runtime
Shopify evidence to buyer-safe answers
Merchant config, encrypted Shopify credential custody, read-only Admin GraphQL sync, Grantex authority requests, durable OACP cache, protocol payloads, buyer answers, purchase preparation, and Offline POS handoff/reconciliation are implemented.
Tenant and partner setup
Credentials and approvals still matter
Public catalogs, WhatsApp, Telegram, Grantex tenant authority, Pine/Plural capability checks, external AI clients, and real POS/provider callbacks require environment-specific credentials, scopes, and approval.
Not a universal claim
Adapters are not external certification
WooCommerce/ERP runtime sync, channel marketplace listing, live payment/order execution, and public OACP certification or standardization are not implied by protocol payload generation.
Full evidence and boundaries: current product status and canonical end-user flow.
End-to-end commerce custody
From merchant data to a buyer-agent answer.
The protocol keeps responsibility explicit: merchant systems own facts, Grantex owns artifact authority, AgenticOrg owns agent runtime behavior, and provider rails own execution.
Seller configures existing systems
The merchant can configure and later edit source systems, buyer channels, provider-owned payment rails, public publishing, and POS metadata. Shopify is runtime-supported now; WooCommerce, ERP, PIM, OMS, WMS, and custom APIs are saved as adapter-ready config until approved adapters exist.
Public-safe evidence is reviewed
Connector custody produces source and freshness evidence without exposing raw provider payloads, secrets, credentials, card data, bank data, or private merchant APIs.
Grantex issues OACP artifacts
Grantex applies protocol and policy checks. Signed artifacts, freshness windows, revocation posture, blocked capabilities, and unsupported actions become the agent input.
AgenticOrg caches scoped references
The cache is a local runtime aid for non-binding discovery and prepared handoff behavior. It is not transaction authority and cannot override Grantex.
Buyer asks through any channel
The buyer agent answers only from valid OACP artifacts and approved evidence. Missing, stale, revoked, ambiguous, private, raw, or executable records fail closed.
Commitment requests become prepared or refused
A commitment-bound request can be prepared for review only when policy, freshness, eligibility, provider/POS capability, and dry-run checks support it. Checkout and payment execution remain separately gated.
Runtime decision model
Each evaluated buyer request should resolve to one bounded posture.
A buyer agent should not guess. It should either answer from valid artifacts, refresh through approved authority, prepare a non-executing handoff, or refuse.
Answer
When
Valid artifact, low-risk request, fresh source evidence
Result
Show grounded product, policy, or support facts with source and freshness labels.
Refresh
When
Missing or stale evidence where a separate authority refresh path is approved
Result
Ask the authority path for new evidence before answering or preparing anything.
Prepare
When
Commitment-adjacent request with valid boundaries and allowed_to_execute=false
Result
Create a non-executing handoff state for human or approved downstream review.
Refuse
When
Revoked, ambiguous, private/raw, executable, high-risk, or unsupported artifact state
Result
Return a clear refusal instead of inventing facts or calling checkout/payment/provider rails.
Commitment boundary
OACP explains where the agent stops.
AgenticOrg can use OACP artifacts for discovery, comparison, source/freshness explanation, and prepared-only handoff behavior. It must not turn those artifacts into live commerce execution without merchant, provider or bank, POS, channel, and rollout approval.
Non-goals this page does not claim
Surfaces and ownership
Where OACP appears in the product.
Merchant settings
Tenant/merchant/seller scoped source connectors, buyer channels, provider rails, public publishing, and POS refs that merchants can update during or after onboarding
Seller Commerce Agent
Merchant config, Shopify connector custody, preview, gap review, and Grantex authority request
Buyer agent
Read-only discovery, grounded comparison, prepared-only handoff, and refusal copy
Public catalog
Seller profile, product pages, catalog JSON, Schema.org JSON-LD, sitemap, and llms.txt from public-safe cached evidence
MCP
ChatGPT/Claude-style tool surface backed by the same artifact cache
OpenAPI
Gemini-style schema and ask route with source/freshness labels
Search and Perplexity
Crawlable public catalog pages, Schema.org JSON-LD, sitemap, llms.txt, and clean public summaries when the merchant enables publishing
A2A
Agent card and task metadata for agent-to-agent discovery
WhatsApp and Telegram
Webhook bridges that require configured secrets before accepting messages
Payment providers
Plural/Pine capability evidence now; bank-owned, fintech, and custom provider refs saved as non-executing provider-owned config until adapter approval
Audit
Source refs, freshness, policy blockers, risk tier, and non-execution posture stay reviewable
Next step
Read the runtime docs and MCP-backed preview.
The runtime docs explain merchant self-service config, Shopify onboarding, artifact cache behavior, buyer surfaces, provider-owned capability checks, POS bridge status, and purchase handoff blockers. The workflow example shows how an MCP client reaches the same guarded path.