OACP Architecture

The Grantex view of the OACP four-party architecture.

OACP Architecture

Canonical end-to-end flow: OACP authority overview.

OACP separates facts, authority, runtime behavior, and payment rails so no agent has to invent commerce state.

Responsibilities

Party	Owns	Does not own
Merchant systems	Catalog, price, inventory, order, policy, support, and source timestamps.	OACP artifact policy.
AgenticOrg	Merchant self-service config, Seller and buyer agents, Shopify connector runtime, pending-adapter setup refs, cache, buyer channels, public publishing, POS handoff orchestration, and capability verification.	Canonical OACP authority or payment/bank/POS rail execution.
Grantex	Policy, trust, artifacts, verification, and adapter authority.	Merchant connector runtime, buyer sessions, orders, or payments.
Provider/bank/POS rails	Mandate and payment execution, provider status, settlement, receipt evidence, and provider webhooks.	OACP trust authority or buyer-agent answers.

Why Grantex Is Not In Every Loop

Grantex signs and verifies authority artifacts. AgenticOrg can answer non-binding questions from valid cached artifacts until TTL, revocation, or policy state requires refresh. This reduces latency and avoids making Grantex a relay for every buyer question while preserving a hard boundary for commitment requests.

Failure Shape