Skip to guide
AgenticOrgDocsOpen 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 teams5 min readReviewed 2026-10-21
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.

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 the supported source today. AgenticOrg reads it with read-only access.
  • Your merchant settings add the rest: limits, stores, payment rail and 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.

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;
  • checkout tools for MCP clients, 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. A payment provider moves money only after an allow decision, and only once.

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 fix the merchant settings, then sync 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. PaysOwner: Payment provider

    The provider charges once, against a consumed allow decision.

    Blocked / exception

    Without a registered executor, checkout stops at executor_unavailable.

Where to go deeper

Implementation references

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