on June 30, 2026 at 9:20 am Agent-Ready Commerce, Part 10: The Reference Architecture​Dimitrios S. Sfyris

​

The reference architecture for agent-ready commerce has one central rule:

Every external surface should be a projection of the same commerce decision spine.

A storefront, product feed, MCP-style tool, ACP-style interaction, AP2-related payment flow, marketplace API, admin UI, support view, and future agent interface may all need different shapes of response.

They should not produce different commercial meanings.

If one surface says a product is checkout-ready and another blocks checkout, the architecture has drifted.

If one adapter quotes a return policy and another says return-policy coverage is missing, the architecture has drifted.

If a generated summary says a product is ready to ship while eligibility says inventory is stale, the architecture has drifted.

If a payment artifact causes payment to proceed while checkout is not valid, the architecture has failed.

Agent-ready commerce is not a chatbot attached to a store. It is not only a product feed. It is not an adapter for a protocol. It is not a payment token. It is not generated product copy.

It is a commerce platform that can expose its facts, policies, actions, state transitions, authority boundaries, generated claims, and evidence to agents without losing control of commercial meaning.

That requires a decision-centered architecture.

This is the tenth and final article in the Agent-Ready Commerce series.

Part 1 introduced the broader architecture model:

Facts → Eligibility → Authority → State transition → Evidence → Audit
Enter fullscreen modeExit fullscreen mode

Part 2 focused on commercial truth. It argued that catalog data is not enough. A platform needs source-backed, freshness-aware product facts before agents or other systems can safely rely on product information.

Part 3 focused on action eligibility. It argued that “available” is too broad. A product may be discoverable but not checkout-ready, comparable but not policy-quotable, or checkout-ready for a human flow but not eligible for delegated payment.

Part 4 focused on policy structure. It argued that agents should not interpret free-text policy pages as executable rules. Policies need structured facts with applicability, evidence, lifecycle, conflicts, and quoteability.

Part 5 focused on protocol adapters. It argued that ACP, MCP, AP2, feeds, tools, and future interfaces should translate domain decisions rather than becoming separate sources of commercial meaning.

Part 6 focused on checkout state. It argued that checkout is where agent-ready commerce crosses from answering into mutating commercial state. Checkout should therefore be modeled as a state machine, not a form endpoint.

Part 7 focused on delegated payment. It argued that a payment artifact is not enough. Delegated payment requires bounded authority over a specific checkout snapshot, amount, currency, merchant, actor, buyer, time window, evidence, and audit.

Part 8 focused on generated claims. It argued that generated commerce text should be treated as a derived claim with dependencies, scope, review status, allowed use, invalidation, expiry, and audit.

Part 9 focused on evidence and audit. It argued that agent-ready commerce needs a proof layer, not just logs.

This final article connects the pieces into a reference architecture.

The central argument is that agent-ready commerce should be built around a shared decision spine:

Source systems
      ↓
Commercial truth
      ↓
Policy facts
      ↓
Eligibility
      ↓
Authority
      ↓
State transitions
      ↓
Generated claims
      ↓
Evidence and audit
      ↓
Projections
      ↓
Operator remediation
Enter fullscreen modeExit fullscreen mode

Protocols and channels sit at the edges. They do not own the meaning.

The architecture is not a topology

A reference architecture is not the same thing as a deployment diagram.

The system can be implemented as:

a modular monolith
a set of services
a workflow-based platform
an event-driven architecture
a hybrid
Enter fullscreen modeExit fullscreen mode

The deployment shape matters less than the semantic boundaries.

A small team may implement commercial truth, policy facts, eligibility, checkout, generated claims, and audit as modules inside one application.

A larger organization may split them into services.

Both can work.

The important questions are different:

Can adapters bypass eligibility?
Can feeds publish readiness without decision records?
Can checkout proceed without policy coverage?
Can payment proceed without valid checkout state?
Can generated claims bypass review and allowed use?
Can policy summaries become quoteable without policy facts?
Can admin UI compute readiness differently from the agent feed?
Can support explain why an agent refused an action?
Enter fullscreen modeExit fullscreen mode

If the answer to those questions is yes, the architecture will drift regardless of whether it is deployed as one service or twenty.

A well-structured monolith with clear domain boundaries is safer than a distributed system with duplicated rules.

The reference architecture is about ownership of meaning.

The decision spine

The decision spine is the path through which commercial meaning is produced.

A simplified version:

Raw source data
      ↓
Source-backed facts
      ↓
Commercial truth snapshot
      ↓
Policy applicability and quoteability
      ↓
Action eligibility
      ↓
Actor and payment authority
      ↓
Checkout or payment state transition
      ↓
Generated claim selection or creation
      ↓
Evidence record
      ↓
Audit event
      ↓
Protocol-safe projection
      ↓
Operator remediation
Enter fullscreen modeExit fullscreen mode

Each layer answers a different question.

Layer Question
Source systems What data exists in operational systems?
Commercial truth Which facts can the platform currently rely on?
Policy facts Which terms apply in this context, and are they quoteable?
Eligibility Which actions are valid now?
Authority Who may request the action?
State transition What mutation occurred, if any?
Generated claims Which derived language is safe to use?
Evidence Why was the decision made?
Audit What happened, when, and under which inputs?
Projection What should this audience or protocol see?
Operator remediation What must be fixed to unblock the path?

The spine prevents agents, adapters, feeds, generated text, and checkout flows from inventing their own interpretation of commerce state.

The Travel Backpack end-to-end

Use the running example one final time:

Product: Travel Backpack
SKU: BAG-TRAVEL-42
Price: €129
Catalog status: active
Inventory status: in_stock
Category: Travel Bags
Enter fullscreen modeExit fullscreen mode

The commercial truth layer currently says:

Price: fresh
Inventory: stale
Return policy: missing for Travel Bags
Warranty policy: known
Shipping policy: known for EU, unknown for US
Generated description: pending review
Feed publication: last published yesterday
Enter fullscreen modeExit fullscreen mode

The action matrix is:

Action Result
discover allowed
compare allowed
quote_policy blocked
add_to_cart requires_revalidation
prepare_checkout blocked
delegate_payment blocked

Now suppose an agent asks:

Can you buy the Travel Backpack for the buyer if the total stays under €150?
Enter fullscreen modeExit fullscreen mode

A channel-first implementation may try to answer inside the adapter:

Product active?
Inventory says in_stock?
Price below €150?
Payment artifact present?
Proceed.
Enter fullscreen modeExit fullscreen mode

That is unsafe.

A decision-centered platform follows the spine:

Protocol request
      ↓
Canonical intent
      ↓
Commercial truth selection
      ↓
Policy coverage check
      ↓
Eligibility decision
      ↓
Checkout state decision
      ↓
Payment authority decision
      ↓
Evidence and audit
      ↓
Protocol-safe projection
      ↓
Operator tasks
Enter fullscreen modeExit fullscreen mode

The correct result is:

Delegated payment is blocked.
Reason:
Checkout is not valid.
Checkout blockers:
- inventory requires revalidation
- return-policy coverage is missing for Travel Bags
Payment:
not attempted
Operator tasks:
- revalidate inventory
- attach or approve return-policy coverage for Travel Bags
Enter fullscreen modeExit fullscreen mode

This answer is not produced by an adapter improvising.

It is produced by the platform’s decision path.

That is the architectural goal.

Source systems provide inputs, not truth

Source systems may include:

Catalog systems
PIM
ERP
Inventory services
Pricing systems
Promotion systems
Shipping systems
Tax systems
Policy documents
Merchant configuration
CMS
Payment providers
Order management
Identity and account systems
Support systems
Operator input
Enter fullscreen modeExit fullscreen mode

These systems contain important data. But their data is not automatically safe for agent use.

A catalog field may say the product is active. That does not mean checkout can be prepared.

An inventory source may say in_stock. That does not mean the inventory fact is fresh enough for payment or fulfillment.

A policy page may describe returns. That does not mean a quoteable return-policy fact applies to this product, category, region, buyer type, and channel.

A payment provider may authorize a payment. That does not mean the order has been committed.

The ingestion layer should therefore convert source inputs into referenced facts.

type SourceRef = 
  system: string;
  objectType: string;
  objectId: string;
  version?: string;
  url?: string;
  hash?: string;
  capturedAt: string;
;
type SourceBackedFact<TValue> =  "returns"
    ;
Enter fullscreen modeExit fullscreen mode

This layer answers:

Where did the fact come from?
When was it captured?
Which version was used?
Is it still fresh?
Has it been superseded?
Is it scoped to this product, category, buyer, region, or channel?
Enter fullscreen modeExit fullscreen mode

Without this layer, every downstream decision becomes weaker.

Commercial truth is the first platform boundary

Commercial truth is the set of source-backed facts the platform can currently rely on.

It is not a copy of the catalog.

It is not the product page.

It is not generated copy.

It is a decision input.

For the Travel Backpack:

Catalog:
active
in_stock
€129
Commercial truth:
price fresh
inventory stale
return policy missing for Travel Bags
EU shipping known
US shipping unknown
generated description pending review
Enter fullscreen modeExit fullscreen mode

The difference is the architecture.

A product may be active but not checkout-ready.

A product may have a price but not a fresh enough price for payment.

A product may have a policy page but no quoteable policy fact.

A product may have generated copy but no approved generated claim.

A commercial truth snapshot may look like this:

type CommercialTruthSnapshot = 
  snapshotId: string;
  subject: 
    productId?: string;
    sku?: string;
    categoryId?: string;
  ;
  selectedFacts: SourceBackedFact<unknown>[];
  missingFacts: Array<
    domain: string;
    reason: string;
    requiredFor: string[];
  >;
  conflicts: Array<
    conflictId: string;
    domain: string;
    factIds: string[];
    resolution: "unresolved" >;
  evaluatedAt: string;
;
Enter fullscreen modeExit fullscreen mode

The snapshot may be stored, cached, or computed on demand. The important property is consistency.

Feeds, adapters, checkout, generated claims, and admin UI should not each select different truth.

Policy facts are not policy pages

Policy pages communicate terms to humans.

Policy facts support machine decisions.

A policy layer should turn returns, shipping, warranty, cancellation, regional restrictions, and business-buyer rules into structured facts with applicability and quoteability.

type PolicyFact =  "returns"
    ;
Enter fullscreen modeExit fullscreen mode

For the Travel Backpack:

Warranty policy:
known
EU shipping:
known
US shipping:
unknown
Return policy for Travel Bags:
missing
Enter fullscreen modeExit fullscreen mode

A generated summary cannot fill that gap.

An adapter cannot quote a generic return page and treat it as applicable.

A checkout flow cannot assume return terms are available because the category has a public policy page somewhere.

The policy layer owns applicability and quoteability.

That ownership prevents agents from over-quoting policy language.

Eligibility is action-specific

Eligibility prevents available from becoming an unsafe boolean.

The platform should evaluate actions separately:

discover
compare
quote_policy
add_to_cart
prepare_checkout
delegate_payment
Enter fullscreen modeExit fullscreen mode

Each action has different requirements.

type CommerceAction =
  | "discover"
  | "compare"
  | "quote_policy"
  | "add_to_cart"
  | "prepare_checkout"
  | "delegate_payment";
type EligibilityDecision =  "blocked"
    ;
Enter fullscreen modeExit fullscreen mode

For the Travel Backpack:

discover:
allowed
compare:
allowed
quote_policy:
blocked because return-policy coverage is missing
add_to_cart:
requires_revalidation because inventory is stale
prepare_checkout:
blocked because inventory is stale and return-policy coverage is missing
delegate_payment:
blocked because checkout is not valid
Enter fullscreen modeExit fullscreen mode

This layer should be shared by every surface.

The feed should not compute action readiness separately.

The adapter should not infer checkout readiness from product status.

The admin UI should not show a different readiness result from the agent feed.

Eligibility is the action contract.

Authority is separate from eligibility

Eligibility answers:

Is this action valid in this commercial context?
Enter fullscreen modeExit fullscreen mode

Authority answers:

May this actor request this action?
Enter fullscreen modeExit fullscreen mode

Those are different questions.

A product may be eligible for checkout, but an agent may not be authorized to prepare checkout for a buyer.

A buyer may authorize an agent to buy an item, but checkout may still be invalid.

A payment artifact may exist, but mandate scope may not match the cart snapshot.

A support operator may view blockers but not request payment.

Authority belongs in its own layer.

type ActorContext = 
  actorId: string;
  actorType: "human" ;
type AuthorityDecision = 
  authorityDecisionId: string;
  actor: ActorContext;
  action:
    ;
Enter fullscreen modeExit fullscreen mode

Part 7 introduced the delegated payment authority question:

May this actor request this payment action for this buyer, merchant, checkout snapshot, amount, currency, and time window?
Enter fullscreen modeExit fullscreen mode

That question should not be answered inside a payment adapter.

It should be answered by the platform authority layer.

Checkout is the mutation boundary

Checkout is where the platform crosses from answering into mutating commercial state.

The reference architecture should treat checkout as a state machine, not as a form endpoint.

type CheckoutState =
  | "draft_cart"
  | "cart_requires_revalidation"
  | "cart_blocked"
  | "checkout_ready"
  | "checkout_prepared"
  | "payment_authority_required"
  | "payment_authority_validated"
  | "payment_pending"
  | "order_committed"
  | "expired"
  | "cancelled"
  | "failed";
type CheckoutCommand =
  | "add_item"
  | "remove_item"
  | "revalidate_cart"
  | "select_shipping_region"
  | "select_shipping_method"
  | "prepare_checkout"
  | "attach_payment_authority"
  | "request_payment"
  | "commit_order"
  | "expire_checkout"
  | "cancel_checkout";
Enter fullscreen modeExit fullscreen mode

Adapters should not perform hidden checkout mutations.

They should map external requests into commands.

async function protocolAdapterHandler(req: ProtocolRequest) 
  const command = mapToCheckoutCommand(req);
  const result = await checkout.handleCommand(command);
  return projectCheckoutResult(result);
Enter fullscreen modeExit fullscreen mode

The checkout state machine coordinates commercial truth, policy facts, eligibility, authority, cart snapshots, idempotency, expiry, payment state, evidence, and audit.

It should not duplicate all of those domains internally.

For the Travel Backpack:

add_item:
requires revalidation
prepare_checkout:
blocked
delegate_payment:
blocked because checkout is not valid
Enter fullscreen modeExit fullscreen mode

This prevents payment or order logic from discovering too late that the cart was never eligible.

Payment authority binds to checkout snapshots

Payment authority should not be modeled as a token check.

It should be modeled as bounded authority over a specific checkout snapshot.

type PaymentMandate =  "active"
    ;
Enter fullscreen modeExit fullscreen mode

Before payment execution, the platform checks:

checkout state
cart snapshot match
amount
currency
merchant
expiry
revocation
confirmation
actor authority
idempotency
payment attempt state
Enter fullscreen modeExit fullscreen mode

For the Travel Backpack, payment is blocked before provider execution because checkout is not valid.

That causal chain is important:

delegate_payment blocked
      ↓
checkout is not valid
      ↓
prepare_checkout blocked
      ↓
inventory stale
return-policy coverage missing
Enter fullscreen modeExit fullscreen mode

Payment authority cannot make checkout valid.

It can only authorize payment if checkout is valid and the request is inside the mandate scope.

Generated claims are derived projections

Generated text should not become a parallel truth layer.

Generated claims should be stored with dependencies, scope, review status, allowed use, invalidation, expiry, and audit.

type GeneratedClaim =  "superseded";
  scope:  "support";
    language?: string;
  ;
  allowedUses: Array<
    ;
Enter fullscreen modeExit fullscreen mode

For the Travel Backpack:

“Ready to ship and easy to return”
should be blocked.
Reason:
inventory is stale and return-policy coverage is missing.
Enter fullscreen modeExit fullscreen mode

A different generated sentence may be safe:

This product is discoverable and comparable, but checkout is blocked because inventory requires revalidation and return-policy coverage is missing.
Enter fullscreen modeExit fullscreen mode

That sentence is safe only if it is derived from the current eligibility and checkout decisions and approved for that use.

Generated claims are useful. They are not authoritative by themselves.

Evidence and audit form the proof layer

Part 9 argued that agent-ready commerce needs a proof layer.

The reference architecture should treat decision records, evidence references, projections, invalidation events, and audit timelines as first-class product infrastructure.

A decision record should answer:

What was requested?
Who requested it?
What was targeted?
Which context applied?
What was decided?
Which blockers were returned?
Which evidence supported the result?
Which projection was sent?
Which audit event recorded it?
Enter fullscreen modeExit fullscreen mode

A simplified evidence reference:

type EvidenceRef =  "inventory_fact"
    ;
Enter fullscreen modeExit fullscreen mode

Evidence should support:

buyer-safe explanations
agent-facing blocker codes
operator remediation
support timelines
audit review
scenario testing
adapter drift detection
claim invalidation
feed republishing
Enter fullscreen modeExit fullscreen mode

Without this layer, the platform may still respond. It cannot reliably prove why.

Adapters are projection boundaries

Protocol adapters should remain thin in the sense defined in Part 5.

They may own:

protocol parsing
schema validation
authentication context extraction
request normalization
canonical intent mapping
idempotency propagation
response projection
protocol-safe error mapping
Enter fullscreen modeExit fullscreen mode

They should not own:

product truth
policy interpretation
eligibility rules
checkout readiness
payment authority
generated commercial claims
evidence decisions
operator remediation logic
Enter fullscreen modeExit fullscreen mode

A canonical intent helps preserve the boundary:

type CommerceIntent =  "quote_policy"
    ;
Enter fullscreen modeExit fullscreen mode

The adapter maps external protocol language into this intent.

The domain evaluates the intent.

The adapter projects the result back out.

This prevents semantic drift.

Feeds are projections too

Agent-facing feeds are not neutral exports.

They are projections of commercial truth, eligibility, generated claims, and allowed actions.

A feed item should not publish optimistic readiness.

For the Travel Backpack, an unsafe feed item would say:

Product active.
Price €129.
Inventory in_stock.
Checkout ready.
Enter fullscreen modeExit fullscreen mode

A safer feed item would say:

"sku":"BAG-TRAVEL-42","title":"Travel Backpack","price":"amount":129,"currency":"EUR","freshness":"fresh","actions":"discover":"allowed","compare":"allowed","quotePolicy":"blocked","addToCart":"requires_revalidation","prepareCheckout":"blocked","delegatePayment":"blocked","blockers":["INVENTORY_STALE","RETURN_POLICY_MISSING"],"generatedClaims":"description":"pending_review","publishedAt":"2026-06-28T09:00:00Z"
Enter fullscreen modeExit fullscreen mode

The feed is compact, but it preserves the decision model.

It should be refreshed or invalidated when dependencies change.

Otherwise, downstream agents may act on stale projections.

Operator workflows close the loop

Agent-readiness is not only a runtime problem.

Many blockers are operational:

missing policy coverage
stale inventory
unreviewed generated claims
conflicting policy facts
unsupported region
expired feed projection
invalidated checkout explanation
missing payment configuration
unresolved authority workflow
Enter fullscreen modeExit fullscreen mode

The architecture should include operator tasks as part of the system.

For the Travel Backpack:

Task:
Revalidate inventory for BAG-TRAVEL-42.
Task:
Attach or approve return-policy coverage for Travel Bags.
Task:
Review generated product description.
Impact:
Agents can discover and compare the product, but cannot quote return terms, prepare checkout, or proceed to delegated payment.
Enter fullscreen modeExit fullscreen mode

Operator workflows should connect to evidence.

When an operator resolves a blocker, the platform should refresh affected decisions, invalidate old generated claims, republish feeds, and update audit timelines.

The loop is:

Decision blocked
      ↓
Evidence recorded
      ↓
Operator task created
      ↓
Operator resolves source issue
      ↓
Fact or policy updated
      ↓
Dependent decisions invalidated or recomputed
      ↓
Generated claims refreshed
      ↓
Feeds republished
      ↓
Audit timeline updated
Enter fullscreen modeExit fullscreen mode

This is how agent-ready commerce stays current.

Runtime path: policy question

Consider a request:

What is the return policy for the Travel Backpack?
Enter fullscreen modeExit fullscreen mode

A safe runtime path:

Adapter maps request to quote_policy intent.
      ↓
Commercial truth selects product and category.
      ↓
Policy layer checks returns applicability for Travel Bags.
      ↓
Return-policy fact is missing.
      ↓
Eligibility returns blocked.
      ↓
Generated policy summary is not used.
      ↓
Evidence records missing policy coverage.
      ↓
Protocol projection returns a safe blocked answer.
      ↓
Operator task is created or linked.
Enter fullscreen modeExit fullscreen mode

The response might be:

"result":"blocked","reason":"RETURN_POLICY_MISSING","message":"Return-policy terms are not available for this product category.","nextAction":"operator_review_required"
Enter fullscreen modeExit fullscreen mode

The platform does not summarize a policy page.

It does not generate plausible return terms.

It does not quote a generic policy.

It preserves the policy boundary.

Runtime path: checkout request

Now consider:

Prepare checkout for the Travel Backpack for an EU consumer buyer.
Enter fullscreen modeExit fullscreen mode

A safe runtime path:

Adapter maps request to prepare_checkout intent.
      ↓
Commercial truth snapshot selected.
      ↓
Inventory freshness checked.
      ↓
Policy coverage checked.
      ↓
Eligibility evaluates prepare_checkout.
      ↓
Checkout state machine attempts transition.
      ↓
Transition blocked.
      ↓
Evidence and audit recorded.
      ↓
Decision-derived explanation generated or selected.
      ↓
Protocol response projected.
      ↓
Operator tasks updated.
Enter fullscreen modeExit fullscreen mode

The result:

"result":"blocked","action":"prepare_checkout","blockers":["code":"INVENTORY_STALE","nextAction":"request_inventory_revalidation","code":"RETURN_POLICY_MISSING","nextAction":"operator_policy_review_required"]
Enter fullscreen modeExit fullscreen mode

The checkout service does not discover the missing policy by accident near payment.

It uses the same decision model used by feeds, adapters, support, and admin.

Runtime path: delegated payment

Now consider:

Buy the Travel Backpack if the total stays under €150.
Enter fullscreen modeExit fullscreen mode

A safe runtime path:

Adapter maps request to delegate_payment intent.
      ↓
Platform checks checkout state.
      ↓
Checkout is not valid.
      ↓
Payment authority is blocked.
      ↓
Payment provider is not called.
      ↓
Evidence records checkout dependency.
      ↓
Protocol response explains blocked delegated payment.
      ↓
Operator tasks point to checkout blockers.
Enter fullscreen modeExit fullscreen mode

The response:

"result":"blocked","action":"delegate_payment","reason":"CHECKOUT_NOT_VALID","causedBy":["INVENTORY_STALE","RETURN_POLICY_MISSING"],"paymentAttempted":false
Enter fullscreen modeExit fullscreen mode

This preserves the causal chain.

Payment is not attempted because checkout is not valid.

The payment artifact does not bypass checkout.

Runtime path: generated claim publication

Consider a generated description:

This backpack is ready to ship and easy to return.
Enter fullscreen modeExit fullscreen mode

A safe runtime path:

Generated claim is created.
      ↓
Claim is segmented.
      ↓
Inventory clause depends on inventory freshness.
      ↓
Return clause depends on return-policy coverage.
      ↓
Inventory is stale.
      ↓
Return policy is missing.
      ↓
Claim is rejected or remains pending review.
      ↓
Audit records unsupported segments.
      ↓
Operator tasks link to inventory and policy blockers.
Enter fullscreen modeExit fullscreen mode

The claim should not enter the agent feed.

A safer generated explanation may be allowed:

This product is discoverable and comparable, but checkout is blocked because inventory requires revalidation and return-policy coverage is missing.
Enter fullscreen modeExit fullscreen mode

Only if it is derived from current eligibility and checkout decisions.

This preserves the generated-claim boundary.

Cross-cutting invalidation

The reference architecture needs invalidation as a cross-cutting mechanism.

When a dependency changes, projections and claims may need refresh.

Examples:

Price changes:
Invalidate price claims, feed projections, checkout snapshots, and affected mandates.
Inventory becomes stale:
Invalidate checkout readiness and availability claims.
Return-policy fact is approved:
Supersede RETURN_POLICY_MISSING blockers and refresh quote_policy decisions.
Generated claim is rejected:
Remove it from feeds and block agent quotation.
Checkout session expires:
Invalidate payment authority decisions tied to that checkout.
Mandate is revoked:
Block payment execution and audit the revocation.
Adapter projection bug is fixed:
Republish affected feed or protocol projection records if necessary.
Enter fullscreen modeExit fullscreen mode

A simple invalidation event:

type InvalidationEvent =  "source_fact_expired"
    ;
Enter fullscreen modeExit fullscreen mode

Invalidation prevents stale truth from continuing to act as current truth.

It also lets the platform explain why an answer changed.

Component responsibility map

A reference architecture should make ownership explicit.

Component Owns Does not own
Source systems Raw operational data Agent readiness
Ingestion Normalization, source refs, freshness Eligibility decisions
Commercial truth Selected reliable facts Policy interpretation beyond facts
Policy facts Applicability, quoteability, conflicts Generated summaries as authority
Eligibility Action-specific decisions Actor permission
Authority Actor, buyer, mandate, payment permission Product readiness
Checkout state Cart and checkout transitions Payment authority as a shortcut
Payment state Payment attempts, provider outcomes Order commitment without checks
Generated claims Derived claim lifecycle Source truth
Evidence and audit Decision proof and timelines Business rule invention
Adapters Protocol translation and projection Commercial meaning
Feeds External projection Independent readiness decisions
Admin UI Remediation workflow Separate agent-readiness logic
Support UI Customer-safe explanations Rule interpretation

This table is not bureaucratic.

It prevents drift.

Every team should know where a rule belongs.

Architecture invariants

The architecture should enforce a small set of invariants.

These are more important than the deployment shape.

1. Source data is not automatically truth

Every source fact needs source references, freshness, scope, lifecycle, and conflict handling.

2. Product readiness is action-specific

available: true is not enough. The platform must distinguish discovery, comparison, policy quotation, cart mutation, checkout preparation, and delegated payment.

3. Policies must be applicable and quoteable

Policy pages do not automatically become agent-quoteable terms.

4. Eligibility and authority are separate

A valid action is not necessarily an authorized action.

An authorized actor does not make an invalid action valid.

5. Mutations go through state transitions

Cart, checkout, payment, and order changes should not be hidden inside adapters or request handlers.

6. Payment authority is bounded

A token or artifact is evidence, not permission by itself.

Payment authority must match actor, buyer, merchant, amount, currency, checkout snapshot, lifecycle, confirmation, and state.

7. Generated claims remain derived

Generated text should never become source truth, policy authority, checkout authority, or payment authority.

8. Decisions need evidence

Allowed and blocked decisions should reference the facts, policies, rules, states, authority records, claims, and projections that justify them.

9. Projections must preserve meaning

Adapters and feeds may change response shape. They should not change the domain decision.

10. Blockers should create remediation paths

Missing facts, stale facts, policy gaps, invalidated claims, and authority blockers should produce operator-visible work when actionable.

These invariants are the real architecture.

Where the architecture can go wrong

A reference architecture reduces drift, but it can still fail.

The architecture becomes a diagram only

If adapters still implement local readiness checks, the diagram does not matter. The domain decision path must be the easiest path to use.

Commercial truth becomes catalog copy

If truth does not include freshness, source references, missing facts, conflicts, and lifecycle, the platform will overtrust raw data.

Policy facts are skipped

If agents or adapters summarize policy pages directly, policy applicability and quoteability are bypassed.

Eligibility becomes a boolean

If the platform exposes only available: true, it loses action-specific readiness.

Authority is treated as authentication

Knowing who the actor is does not mean the actor may request checkout mutation, payment authority, or buyer delegation.

Checkout remains endpoint-driven

If checkout mutations happen inside request handlers, the platform cannot reliably enforce state, idempotency, snapshots, expiry, or audit.

Payment artifacts become permission

If a token is treated as delegated authority, the platform may bypass mandate scope, checkout state, and cart snapshot matching.

Generated claims become truth

If generated text is read back as product or policy truth, the dependency direction has inverted.

Evidence is optional

If decisions can be made without evidence references, audit will be incomplete exactly when it matters.

Operator workflow is disconnected

If blockers do not create actionable tasks, agent-readiness becomes a runtime failure instead of an operational loop.

Feeds are optimistic

If feeds publish what the storefront hopes is true rather than what the decision layer allows, agents will act on stale or unsafe projections.

Testing the reference architecture

The reference architecture should be tested with end-to-end scenarios, not only component tests.

A useful test includes:

Input source facts
Policy coverage
Generated claim state
Actor context
Buyer context
Requested action
Expected eligibility decision
Expected authority decision
Expected state transition
Expected generated claim use
Expected evidence refs
Expected protocol projection
Expected operator task
Expected invalidation behavior
Enter fullscreen modeExit fullscreen mode

For the Travel Backpack:

Scenario Expected architecture behavior
Agent asks to discover product Allowed; product facts referenced
Agent asks to compare product Allowed only on known facts
Agent asks for return policy Blocked; missing Travel Bags return-policy fact
Agent asks to add to cart Requires inventory revalidation
Agent asks to prepare checkout Blocked; stale inventory and missing return policy
Agent asks delegated payment Blocked; checkout not valid; payment not attempted
Generated claim says “ready to ship” Blocked or pending because inventory is stale
EU shipping claim requested for US buyer Blocked as out of scope
Operator approves return-policy coverage Policy fact becomes active; affected decisions refreshed
Inventory revalidated Inventory blocker superseded
Feed republished Feed projects updated eligibility decisions
Adapter projects blocked checkout as success Projection test fails
Buyer-safe explanation requested Internal evidence redacted, blocker meaning preserved
Audit replay requested Decision inputs, evidence refs, rule versions, and projections available

A simplified test type:

type ReferenceArchitectureScenario = 
  name: string;
  sourceFacts: string[];
  policyFacts: string[];
  generatedClaims: string[];
  intent: CommerceIntent;
  expectedEligibility: EligibilityDecision["result"];
  expectedAuthority?: AuthorityDecision["result"];
  expectedCheckoutState?: CheckoutState;
  expectedBlockerCodes: string[];
  expectedEvidenceKinds: string[];
  expectedProjection: string;
  expectedOperatorTasks: string[];
;
Enter fullscreen modeExit fullscreen mode

The goal is to test whether the architecture preserves meaning across layers.

The same scenario should not produce one answer in the feed, another in the tool adapter, another in checkout, and another in admin.

A practical implementation roadmap

A platform does not need to implement the full architecture at once.

A practical roadmap:

  1. Define the action vocabulary.
    Start with: 
discover
compare
quote_policy
add_to_cart
prepare_checkout
delegate_payment
Enter fullscreen modeExit fullscreen mode

  1. Build commercial truth snapshots.
    Add source references, freshness, missing facts, conflicts, and lifecycle.

  2. Structure policy facts.
    Model returns, shipping, warranty, cancellation, regional restrictions, and business-buyer rules with applicability and quoteability.

  3. Add eligibility decisions.
    Produce action-specific allowed, blocked, requires_review, and requires_revalidation decisions.

  4. Keep adapters thin.
    Map external protocol requests into canonical intents. Project domain decisions outward.

  5. Move checkout behind commands.
    Introduce explicit checkout states, cart snapshots, idempotency, expiry, and transition audit.

  6. Model payment authority.
    Bind mandates to actor, buyer, merchant, amount, currency, cart snapshot, expiry, revocation, and confirmation.

  7. Store generated claims as records.
    Attach dependencies, scope, review status, allowed use, invalidation, expiry, and audit.

  8. Add decision evidence.
    Attach evidence references to allowed and blocked decisions.

  9. Build operator remediation.
    Create tasks from missing facts, stale facts, policy gaps, generated-claim review, checkout blockers, and authority blockers.

  10. Publish feeds from decisions.
    Do not publish readiness from catalog flags alone.

  11. Add invalidation.
    Refresh decisions, claims, feeds, and tasks when dependencies change.

  12. Test cross-surface consistency.
    Use the same scenario across feeds, tools, adapters, checkout, payment, admin, and support.

This roadmap builds the architecture in layers while reducing the highest-risk drift first.

The tradeoff

The reference architecture adds structure.

It requires facts, policy modeling, eligibility decisions, authority checks, state machines, generated-claim lifecycle, evidence, audit, projections, invalidation, and operator workflows.

That is more work than adding an agent endpoint to an existing storefront.

For simple read-only product discovery, a lighter approach may be enough for a while.

Agent-ready commerce changes the threshold when agents can quote policies, compare products, prepare checkout, operate under buyer authority, explain payment refusal, or act across multiple protocols.

The tradeoff is between local integration speed and platform consistency.

A shortcut can make one adapter work.

A reference architecture keeps the platform from developing several incompatible versions of commercial truth.

The goal is not to make commerce rigid.

The goal is to make commercial decisions explicit enough that agents can use them safely.

The series in one model

The full series can be reduced to one chain:

Facts
      ↓
Commercial truth
      ↓
Policy facts
      ↓
Eligibility
      ↓
Authority
      ↓
State transition
      ↓
Generated claims
      ↓
Evidence
      ↓
Audit
      ↓
Adapters and projections
      ↓
Operator remediation
Enter fullscreen modeExit fullscreen mode

Each article strengthened one link.

Part 1 introduced the model.

Part 2 made facts source-backed and freshness-aware.

Part 3 made readiness action-specific.

Part 4 made policies machine-readable and quoteability-aware.

Part 5 kept protocol adapters from owning commercial meaning.

Part 6 turned checkout into explicit state transitions.

Part 7 treated delegated payment as bounded authority over a checkout snapshot.

Part 8 treated generated text as derived claims with lifecycle.

Part 9 made evidence and audit part of the product.

Part 10 connects those ideas into a complete reference architecture.

The architecture is not about letting agents do everything.

It is about making clear what agents may know, say, request, mutate, and pay for, and why.

Final Thoughts

Agent-ready commerce is a platform capability.

It is not a product feed alone. It is not a chatbot. It is not a protocol adapter. It is not a payment token. It is not generated product copy. It is not an admin flag called agentReady.

It is a commerce architecture where facts, policies, eligibility, authority, checkout state, payment boundaries, generated claims, evidence, audit, projections, and operator workflows are connected.

For the Travel Backpack, the architecture gives a precise answer:

Discover:
allowed
Compare:
allowed on known facts
Quote return policy:
blocked because return-policy coverage is missing for Travel Bags
Add to cart:
requires inventory revalidation
Prepare checkout:
blocked because inventory is stale and return-policy coverage is missing
Delegate payment:
blocked because checkout is not valid
Generated description:
pending review
Operator tasks:
revalidate inventory
approve return-policy coverage
review generated description
Enter fullscreen modeExit fullscreen mode

That is the difference between catalog availability and agent-ready commerce.

The platform does not need to guess.

The adapter does not need to invent rules.

The generated text does not become truth.

The payment artifact does not bypass checkout.

The audit trail can prove the decision.

That is the reference architecture this series has been building toward.

About the author

Written by Dimitrios S. Sfyris, Founder & Software Architect at AspectSoft.

AspectSoft designs and develops custom software platforms, e-commerce systems, SaaS infrastructure, integrations, analytics tools, and practical digital products.

You can also follow the AspectSoft LinkedIn page for updates on software platforms, commerce systems, AI tooling, and developer-focused products.

 

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *