Agentic commerce needs more than a working demo. A commerce agent can search a
catalog, prepare a handoff, ask for consent, and verify provider capability
metadata, but that does not prove the system is ready to touch live payment,
bank, POS, order, refund, or fulfillment rails.
This article is retained as a readiness-boundary note. The current OACP split is
that AgenticOrg owns merchant self-service runtime and buyer/seller agent
channels, while Grantex owns OACP authority and artifact verification. Merchant
configuration, including Shopify today and future WooCommerce/ERP/bank/provider
refs, is not by itself live execution approval.
What Works Today In The Current OACP Split
The current OACP runtime path covers:
- AgenticOrg merchant self-service config scoped by tenant, merchant, and seller
agent.
- Shopify read-only Admin GraphQL runtime sync when the merchant provides valid
credentials.
- WooCommerce, ERP, PIM, OMS, WMS, custom API, bank-owned rail, fintech rail,
and custom provider setup as pending-adapter config, not fake-live support.
- Grantex OACP authority requests, signed/internal artifact issuance or refusal,
artifact verification, and protocol adapter governance.
- AgenticOrg OACP cache and buyer-channel answers with source/freshness labels.
- Plural/Pine provider-owned capability verification where configured, without
claiming payment execution.
- Offline POS handoff packets and verified confirmation evidence refs without
Grantex executing POS transactions.
That is enough to prepare buyer-safe answers and handoffs. It is not a claim
that every merchant, channel, provider, bank, POS, or order path is live.
Why Flags Are Not Enough
Live payment or order execution depends on legal language, provider or bank
contracts, webhook signature behavior, data-residency review, final buyer
confirmation, merchant support ownership, audit verification, incident runbooks,
monitoring, and rollback ownership.
Those are not just deployment details. They are part of the safety model.
Commerce V1 therefore exposes a machine-readable live-readiness snapshot. The
snapshot reports only safe values: booleans, requirement keys, env names, and
blocker strings. It does not carry passports, bearer tokens, provider secrets,
raw payloads, DB URLs, Redis URLs, or webhook secrets.
If any readiness acknowledgement is missing, provider, bank, POS, or merchant
execution paths must fail closed with a precise blocker.
The Required Evidence
The readiness gate requires acknowledgements for legal approval, provider or
bank contract confirmation, sandbox E2E completion, webhook signature
confirmation, data residency, final user confirmation text, merchant approval,
OACP E2E evidence, production secret review, audit verification, operator
runbook approval, support ownership, and rollback owner assignment.
This keeps the release posture clear:
- Shopify runtime sync can continue when credentials are valid.
- Future WooCommerce/ERP/bank/provider configs can be saved as pending-adapter
setup without implying live support.
- Public docs and demos must distinguish OACP authority evidence from provider
settlement, bank authorization, POS confirmation, channel approval, or
certification claims.
- AgenticOrg must preserve OACP artifacts, source/freshness labels, and
fail-closed blockers across buyer channels.
- Execution starts only after the evidence packet, provider/bank/POS approval,
and runtime readiness snapshot all clear.
Current Status
As of June 25, 2026, the current public OACP posture is not a broad live-payment
or live-order claim. AgenticOrg owns merchant self-service config and Shopify
runtime sync; Grantex owns authority artifacts; provider, bank, POS, and
merchant systems own execution. Public wording must keep those owners separate.
That boundary must stay visible in code, tests, docs, and operations: “OACP
authority artifacts are available” is different from “a merchant/provider/bank
has approved live execution.” Last modified on June 25, 2026
