Skip to guide
AgenticOrgDocs
Open app
Documentation/OACP — agentic commerce, made safe

OACP — agentic commerce, made safe

How OACP works, end to end

Follow your shop's facts through seven steps: signed by Grantex, verified and kept by AgenticOrg, decided by the arbiter, recorded in the ledger and rendered for every buyer agent.

Merchants, product and platform teams6 min readReviewed 2026-10-30
Markdown source
On this page

The whole flow on one page

From your shop to every buyer agent

Seven steps: the shop states its facts, Grantex signs them, AgenticOrg verifies and keeps them, the arbiter decides allow or refuse, the ledger records the decision, adapters speak each standard, and buyer agents receive the same answer.

Seven steps. The merchant states its facts once. Grantex signs each fact with an expiry and a revocation slot. AgenticOrg verifies each fact before keeping a copy. The arbiter decides allow or refuse with fixed rules and nobody waits for a person. The ledger records every decision in signed rows you can export and check. Adapters speak UCP, ACP, AP2, MCP and A2A. Buyer agents get the same answer.1MerchantStates its facts onceCatalog, price, stock, policy, limits2GrantexSigns each factSignature, expiry, revocation slot3AgenticOrgVerifies, then keeps a copyRefuses unsigned, changed or revoked4AgenticOrg arbiterDecides allow or refuseFixed rules; nobody waits for a person5AgenticOrg ledgerRecords every decisionSigned rows you can export and check6AdaptersSpeak each standardUCPACPAP2MCPA2A7Buyer agentsGet the same answerSame price, same rules, same refusals

Each step has one owner. The next sections explain them one at a time.

See the flow in one order

The recording below runs the whole flow once on the live service: the shop states its facts, Grantex verifies them, the arbiter checks the order against the shop's limits, and the buyer gets the merchant's payment link.

One OACP order, end to end

Recorded on the live service with a demo shop and a Plural test payment. The shop owner adds products (a Shopify store connects through a read-only app in its Shopify admin; the demo shop uploads a spreadsheet), sets rules, limits and their own Plural account, and turns Sell everywhere on. A buyer's AI assistant finds the shop through the AgenticOrg MCP server, fills the cart and gets a payment link. The buyer pays the shop, and the order reaches the Orders page with the delivery address. Narrated, with English captions. Download the video · Captions

Step 1. Your shop states its facts

Your shop already knows its products, prices, stock and policies. AgenticOrg reads them. It does not invent them.

  • Shopify is read with read-only access, through a custom app in your own store. A shop without Shopify uploads its catalog as a CSV or JSON file instead, recorded as uploaded by you.
  • Your merchant settings add the rest: order limits, your shipping fee, stores, where buyers pay and your policies.
  • Other systems (WooCommerce, ERP, PIM and others) can be saved as settings. They stay "pending adapter" and are never called.

Step 2. Grantex signs each fact

AgenticOrg sends the facts to Grantex and asks for authority. Grantex turns each fact into a signed record, called an artifact.

Every artifact carries:

  • a signature (ES256) over the exact content;
  • an expiry time, so old facts stop counting;
  • a slot on a public revocation list, so a fact can be withdrawn.

Grantex publishes the keys that check these signatures, and the revocation list. Anyone can check an artifact with those two public things.

Step 3. AgenticOrg checks before it keeps anything

AgenticOrg verifies every artifact before it stores a copy. This is the most important safety step.

Four checks before a fact is kept

Each artifact must pass the signature check, come from a published Grantex key, be in scope and unexpired, and be valid on the revocation list. Passing artifacts are kept with source and freshness labels. A failure keeps nothing from that batch.

A signed fact arrives from Grantex. AgenticOrg checks four things: the signature matches the content, the key is a published Grantex key, the fact is in scope and not expired, and it is valid on the revocation list. If all pass, it is kept with source and freshness labels. If any fails, it is refused, and in strict mode nothing from that batch is kept.GrantexA signed fact arrives1. Signature matches the content2. Key is a published Grantex key3. In scope and not expired4. Valid on the revocation listALL PASSKeptwith source andfreshness labelsANY FAILSRefusedstrict mode keepsnothing from the batch

In production, staging and preview, one failed artifact means nothing from that batch is kept. This is called strict mode, and it is on by default there.

Step 4. The arbiter decides

When an agent wants to buy, the arbiter decides. It is a fixed set of rules, not a person.

  • It answers allow or refuse. It never answers "pending".
  • An allow is single use. It is bound to the exact cart, price and quantity, and it expires after 10 minutes.
  • A refusal names the first rule that failed, so you know exactly why.

Today the decision comes before the payment link: the arbiter checks your signed facts and your order limits, including the daily maximum, and only an allow gives the buyer a link to your own Shopify checkout or Plural page. The rules are listed in plain words in Safety and trust.

Step 5. The ledger records it

Every commerce write and every decision is written to the commerce ledger in the same database transaction.

  • Each row is signed.
  • When audit-chain sealing is on, rows are also linked into a hash chain, so a removed or edited row shows up.
  • You can export the ledger and check it on your own computer with scripts/verify_ledger.py.

Sealing and outside witnessing are separate switches. Both start off.

Step 6. Adapters speak each standard

The same verified facts are rendered into each standard's own shape:

  • a UCP business profile at /.well-known/ucp, with catalog, checkout and orders;
  • an ACP product feed and ACP checkout sessions;
  • Intent, Cart and Payment mandates with AP2 field names, for agent-executed payment, which is switched off;
  • checkout tools for MCP clients, the AgenticOrg shopping bot on Telegram, and a seller agent for A2A.

Each surface has its own switch, so you can turn on one channel at a time.

Step 7. Buyer agents get the same answer

Because every channel reads the same signed facts, agents see the same price, the same stock and the same refusals. Once you have chosen where buyers pay, every channel ends a ready checkout the same way: a link to your own payment page, where the buyer pays. AgenticOrg never holds the money.

Who does what, at a glance

  1. States the factsOwner: Merchant

    Products, prices, stock and policies come from your shop.

    Blocked / exception

    Reconnect Shopify or upload your catalog again, fix the merchant settings, then read the catalog again.

  2. Signs the factsOwner: Grantex

    Each fact becomes a signed, expiring, revocable artifact.

    Blocked / exception

    AgenticOrg keeps nothing new and asks for a fresh request.

  3. Verifies and keepsOwner: AgenticOrg

    Signature, key, scope, expiry and revocation are checked before storing.

    Blocked / exception

    The batch is refused with the exact refusal code.

  4. DecidesOwner: AgenticOrg arbiter

    Fixed rules answer allow or refuse at once.

    Blocked / exception

    The refusal names the first failing rule.

  5. RecordsOwner: AgenticOrg ledger

    The decision and every commerce write go to the ledger.

    Blocked / exception

    A write route that skips its ledger row is answered as an error.

  6. Hands over the payment linkOwner: AgenticOrg, then your payment page

    After a consumed allow, the buyer gets a link to your own Shopify checkout or Plural page and pays there. A confirmed Plural payment becomes an order.

    Blocked / exception

    Without a payment method, the buyer gets no link and is told to pay with you directly.

Where to go deeper

Implementation references

This guide is checked against repository sources. Enabled features and deployed versions may differ by environment.