How Grantex Stays a Trust Authority Without Becoming a Transaction Toll Booth

Summary

Update, 20 October 2026. Since this post was written, Grantex signs every OACP artifact (ES256) and AgenticOrg's main branch checks each signature before caching. A fixed-rule arbiter now decides every purchase handoff, POS handoff and checkout completion, allow or refuse, without waiting for a person, and a ledger records each commerce change. UCP and ACP checkout, Grantex mandates and a Plural payment executor exist behind switches that default to off, so with the defaults nothing moves money. The AgenticOrg changes are not yet in its production deployment. The newer post 'OACP explained: one trust layer under UCP, ACP and AP2' has the current picture. Grantex also countersigns each allow decision and can witness the ledger's chain head; valid cached artifacts still answer non-binding questions without a call to Grantex.

The reference architecture assigns OACP authority, policy, artifact issuance, verification, and adapter governance to Grantex, while AgenticOrg handles buyer and seller runtime concerns. Actual responsibilities depend on the deployed contract and promoted integration.

Why Cache Exists

Buyer agents need fast answers for non-binding questions like product details, comparisons, and source freshness. AgenticOrg can answer from valid cached artifacts while TTL, scope, source, risk, and revocation checks pass.

Where Grantex Returns

Grantex is involved when AgenticOrg needs authority artifacts, verification, refusal handling, policy changes, adapter governance, or updated evidence refs. Commitment-bound requests still need fresh policy, source, provider, POS, or merchant evidence.

What This Avoids

The design aims to avoid two failure modes: making the authority service a hot-path relay for every chat message, and inventing commerce facts without authority. Valid cache can support discovery; execution requires approved downstream systems.