How It Works

Commerce Changeset is a multi-agent system that manages commerce operations — pricing, promotions, inventory, product creation — through auditable, authorization-gated workflows. Every action flows through Auth0's identity layer.

User / Auth0Universal Login + MFA1OrchestratorPlans only — no API access2Reader AgentToken Vault OBOspreadsheets.readonly3LLM AnalysisDiscrete operations4Policy Enginejson-rules-engine — 7 rulesT0T1T2T35CIBA GateGuardian push (Tier 2+)auto-approve (Tier 0/1)6Writer AgentToken Vault OBOspreadsheets (read-write)7Reader VerifyRead-back comparison8Notifier AgentToken Vault OBOgmail.send9ReceiptSHA-256 audit hash10OBO chainCOMMERCE CHANGESET — AGENT PIPELINE

The Agent Pipeline

Four specialized agents, each with bounded capabilities and scoped token access.

Reader

Pulls product data, pricing, and launch schedules from Google Sheets via Token Vault OBO. Read-only — cannot modify any data.

get_products, get_pricing, get_launch_schedule, get_launch_windows

Read-only

Orchestrator

Decomposes natural language into discrete operations. Evaluates each against the policy engine, generates diffs, and assembles the changeset with rollback instructions.

gather_state, analyze_request, build_changeset

No API access — plans only

Writer

Executes approved operations against Google Sheets. Deterministic — no LLM involved. Loops over approved ops and calls the matching write tool.

update_price, set_promo_status, update_inventory_flag, bulk_price_change, create_product

Read-write

Notifier

Sends execution summaries and detailed audit receipts via Gmail using Token Vault OBO. Deterministic — templates the email from changeset data.

send_launch_notification

Send-only

Token Vault Flow: User connects Google once via Auth0 Connected Accounts. Auth0 stores the refresh token in Token Vault. Each agent exchanges for a scoped access token at execution time. Tokens never reach the frontend.

Token Vault & OBO Delegation

Users connect their Google account once via Auth0 Connected Accounts. Auth0 stores the refresh token in Token Vault. At execution time, each agent exchanges the stored token for a scoped access token through Auth0's On-Behalf-Of flow. The app never sees or stores the user's Google credentials directly.

Every token exchange is recorded in the execution receipt with a unique exchange ID, timestamp, and the scopes granted — creating a complete audit trail of what each agent accessed and when.

Policy Engine & Risk Tiers

Every operation is evaluated by a json-rules-engine policy engine before execution. The engine considers operation type, affected record count, price change magnitude, and the user's voice-derived stress and session duration signals.

Tier 0 — READAuto-approveRead-only queries. No approval required.
Tier 1 — NOTIFYAuto-approveNotification-only operations. Email sent, no data modified.
Tier 2 — WRITECIBA requiredSingle-record writes. Guardian push notification sent for user approval.
Tier 3 — BULKCIBA escalatedBulk writes, large price changes, or stress-escalated operations. Highest friction approval.

Execution Pipeline

Once the user confirms a changeset, it flows through a five-step pipeline. Each step is recorded for the audit trail.

1

Approve

CIBA request sent to Auth0 Guardian. User approves via push notification on their device.

2

Write

Writer Agent executes each approved operation against Google Sheets using scoped OBO tokens.

3

Verify

Reader Agent reads back the modified data and compares against expected values.

4

Notify

Notifier Agent sends an execution summary and detailed audit receipt via Gmail.

5

Receipt

SHA-256 audit hash computed over the full execution record: delegations, results, and verification checks.

Voice Interface & Stress-Aware Authorization

The voice interface uses a dual-model architecture. A primary Gemini Live model handles conversation and tool calls. A silent sidecar model analyzes the audio stream for stress markers — pitch variance, pace changes, hesitation patterns — and emits emotional state transitions without producing any spoken output.

These affective signals feed into the policy engine. When the user's stress level exceeds 0.7 or the session exceeds 60 minutes, write operations are escalated from Tier 2 to Tier 3. The system adds friction when the user's judgment may be degraded — a first step toward authorization that adapts to cognitive state, not just permission grants.

Authorization as Cognitive Protection

Traditional authorization asks whether a user has permission. This system also asks whether the user should exercisethat permission right now. Stress and fatigue signals are opt-in, assistive, and escalation-only. They never block an operation or restrict access — they add a CIBA confirmation step so the user can pause and verify intent before a write executes.

When no voice context exists, the system falls back to standard policy evaluation with no behavioral penalty. Raw audio is never stored and no biometric profiles are built — the sidecar model emits a scalar stress estimate and discards the audio stream. Aggregated session metadata (stress averages, session duration, timing) is persisted for longitudinal pattern detection — for example, surfacing that certain days or times of day tend to be more stressful. This persistence is used only for secure, aggregated analysis and the user can opt out of session history at any time.

The user can disable voice-aware escalation at any time without affecting their base permissions. The system degrades gracefully to standard tier classification — additive safety, not a gate.

Audit Trail

Every execution produces an immutable receipt containing the OBO delegation chain (user to orchestrator to individual agents), per-agent delegation records with tools granted and context scope, verification check results, and a SHA-256 audit hash over the complete record. The receipt is emailed to the user and displayed in the dashboard's delegation graph.