Summary
The repository includes a reference Offline POS handoff path based on product, price, inventory, policy, and capability artifacts. This is a design and test surface, not a claim of a live POS-vendor integration.
It does **not** run POS transactions, capture payments, create orders, reserve inventory, or turn simulator results into live paid states. Payment and final order records still come from the merchant POS, Shopify, or approved payment provider.
Who This Is For
This is for Shopify merchants, POS/payment partners, commerce developers, and operators who need buyer agents to help shoppers prepare in-store purchases while keeping checkout authority with the systems that already own it.
The Runtime Flow
In the intended flow, a promoted buyer channel asks a product question and the runtime evaluates cached artifacts. Labels such as `Source: Shopify catalog` and `Updated 4 min ago` are illustrative output examples, not observed production data.
When the buyer asks to buy in store or pick up locally, AgenticOrg checks artifact freshness, price and inventory freshness, merchant policy, buyer/session scope, channel capability, and provider or POS evidence. If those checks pass, AgenticOrg builds an Offline POS handoff packet. If they do not pass, the agent returns a precise blocker instead of inventing success.
Visual Workflow
Buyer question -> OACP cache lookup -> source/freshness answer -> purchase preparation -> Offline POS packet -> POS/provider confirmation -> buyer-safe confirmation or blocker -> optional artifact refresh with non-sensitive evidence refs.
What The Handoff Packet Contains
The packet includes tenant, merchant, Seller Commerce Agent, store or POS location, buyer session reference, product and variant, quantity, displayed price and currency, catalog/price/inventory artifact refs, freshness timestamps, expiry window, risk tier, allowed action labels, blocked action labels, and non-sensitive evidence refs.
The packet intentionally excludes raw payment payloads, provider secrets, raw Shopify Admin payloads, card data, bank data, and private merchant credentials.
Confirmation And Reconciliation
The POS or provider can return statuses such as accepted, price_changed, out_of_stock, expired, needs_staff_review, unsupported, payment_pending, payment_confirmed, payment_failed, or receipt_available. AgenticOrg then reconciles the status into buyer-safe wording and operator-safe state.
A payment_confirmed or receipt_available status is not trusted just because text says so. It requires verified callback evidence and a provider/POS evidence reference. Without that evidence, the safe outcome is staff review or a blocker.
Repository Surfaces (Not a Production Availability Claim)
The repository contains packet-building, readiness, handoff, confirmation-intake, simulator, and reconciliation code paths. Availability still requires environment-specific tests, credentials, tenant enablement, monitoring, and readiness promotion.
The simulator is deterministic and useful for tests. It is not a live POS vendor integration and must not be presented as live payment or order execution.
What Requires External Approval
Live POS provider callbacks require merchant approval, provider approval, callback signature configuration, store/POS location metadata, operator monitoring, and production readiness review. In this reference architecture, the authority service verifies artifact, policy, and evidence references rather than running POS transactions.
Failure Modes
If price or inventory is stale, the agent refuses commitment and asks for refresh. If POS location metadata is missing, it blocks the handoff. If the POS reports a price change, the buyer must confirm the new price. If the POS reports out of stock, the agent tells the buyer it cannot complete the purchase.
If Grantex is unavailable but the OACP cache is still valid, AgenticOrg may continue non-binding Q&A. Commitment still depends on cached policy, risk, freshness, and required evidence.
Safe Buyer Wording
The following are illustrative response templates, not customer or production observations:
Source: configured catalog. Updated at the displayed timestamp. Final price requires POS confirmation.
The POS accepted the handoff. Staff must confirm final price and payment at the store.
The POS reported a price change. Please confirm the new price before payment.
I cannot claim payment or order success without verified POS/provider evidence.
Inventory needs refresh before I can prepare this handoff.
Topics
Ready to try it?
Explore the public playground, or create an account to evaluate an agent with your own approved data and controls.