ORD-10042, for
one brand, acme-outdoors, across all four engines. The conversation is answered by an agent,
the answer is grounded in the real order book, the late shipment is re-dispatched by a durable
workflow, and the goodwill credit only executes behind a machine-checked decision.
Four engines means four surfaces — each has its own host, its own key and its own auth header:
ResponseCX is
https://response.stateset.com/api/v1 with
Authorization: Bearer rcx_…; the Sync Server is
https://api.sync.stateset.com with x-stateset-api-key: ss_sync_…; the
Temporal Engine is https://api.workstream.stateset.com with
x-api-key: sk_live_…; and NSR is https://api.nsr.stateset.com
with X-API-Key: nsr_…. A key from one engine means nothing to another.1
The message lands in a ResponseCX conversation
Ada writes on chat and the brand’s ResponseCX agent picks the conversation up. Everything the
rest of this page does hangs off this one record. Read it back — a single-conversation read
includes the message transcript (Why this matters: the conversation is the thread of record. Its
from_agent: false marks the customer’s side); the id comes
from your inbox webhook, or from GET /api/v1/conversations?status=open&channel=chat.status is what we come
back to at the end — an operation is not closed while this says open.2
The agent's answer is grounded by a function, not a guess
A ResponseCX agent answers from what its functions return, and a function is just an HTTP
call the agent may make. Give the agent a Why this matters: “close the operation” starts with refusing to answer from memory. The
agent’s reply about ORD-10042 will be whatever the order book actually says, fetched at the
moment Ada asks.
lookup_order tool that points straight at the Sync
Server’s tenant order book — the Sync key travels in the function’s stored headers, so the
agent never holds it. POST /api/v1/agents/{id}/functions needs the agents:write scope;
send an Idempotency-Key so a retried create cannot register the tool twice.3
The Sync Server tells the truth: shipped, and late
This is the call the agent’s function makes. The Sync Server keeps the tenant’s order book in
agreement with Shopify and the 3PL, so one lookup returns the order and its tracking:Today is the 31st and
estimatedDelivery was the 28th: shipped, in-transit, three days late.
For a live carrier scan beyond the order book, POST $SYNC/dcl/tracking with
{ "orderNumbers": ["ORD-10042"] } fetches tracking straight from the 3PL.Why this matters: the same lookup that lets the agent answer honestly (“it shipped UPS on
time, and it is now three days past its estimate”) is what turns a chat reply into an
operational fact the next two engines can act on.4
The Temporal Engine re-dispatches the shipment durably
A late in-transit package is a remediation, not a paragraph. Start the engine’s
At 500 autonomy cap, so nothing parks at the review gate: the
workflow reserves the replacement, clears its built-in NSR gate, and dispatches.
order-fulfillment workflow — reserve inventory → NSR gate → (human review) → dispatch —
for a replacement shipment under its own order id, ORD-10042-R1. The workflow id is
deterministic per (brand, order_id), so a duplicate trigger returns the existing run instead
of shipping twice.GET /v1/workflows/order-fulfillment/{workflow_id}/status moves from "running:dispatch" to
"fulfilled:dispatch"; a connector blip mid-run is retried up to 8 times with the workflow’s
state untouched, and any terminal status that never dispatched releases the reservation.Why this matters: the agent’s promise (“a replacement ships today”) is now a durable
execution, not an intention. If the process crashes, the promise survives the crash.5
NSR verifies the goodwill credit before it executes
Three days late deserves a credit — but a credit is money, so it goes through a verified
decision, not an agent’s vibes. The brand’s goodwill policy lives in NSR the same way the
refund policy does in the verified-decision guide — a
Only after
may_credit permit rule requiring delivery_late, plus a review rule that stops credits over
$50 — installed once via POST /api/v1/rules/batch. The live facts travel in the request, the
stored policy is hydrated in, and declaring an authorization_goal is what makes an approval
carry a proof bundle you can check yourself.POST /v1/proofs/verify returns { "verified": true } on that bundle does the
agent’s credit tool fire — a function registered exactly like lookup_order in step 2,
pointing at your commerce backend. Every other path — denied, refused, a timeout, an
unreachable engine — ends without a side effect. Had Ada been owed $60 instead, the
review rule would answer refused with requires_human_review: true, and the credit would
wait for a person.Why this matters: the goodwill credit is the one step here that moves money on an agent’s
initiative. Gating it on a machine-checkable proof is the difference between an autonomous
operation and an expensive one.6
Record the outcome against the decision
Weeks later, the system that learns the truth — billing, the ledger, a chargeback feed —
closes the loop on the decision by the order id it already holds:Why this matters: reported outcomes feed
GET /v1/decisions/calibration, which tells you
whether a 0.95 confidence holds up 95% of the time — and therefore how much of this journey
can defensibly run with no human in it at all.7
Confirm the conversation — and the operation — is closed
The agent replies to Ada in-channel: the package is three days late, a replacement is
dispatched expedited, a $15 credit is on her account. Resolution itself happens where the
conversation lives — the agent (or a teammate in the dashboard) closes it on the platform;
the public API is the audit surface, so read the record back:Why this matters:
status: "closed" is honest here precisely because of everything above
it — a re-dispatch is running durably, a credit executed behind a verified proof, and the
decision has an outcome trail. The conversation closed because the operation did.What you built
Next steps
Each leg of this journey has a full per-engine guide that goes deeper than one step could:ResponseCX quickstart
Create the agent itself, launch it, and read back its rules, functions and knowledge.
Sync a Shopify store with NetSuite
Where the order book comes from — syncs, jobs, failure recovery and webhooks for one tenant.
Run a durable order workflow
The same order-fulfillment workflow end to end — review gates, event streams, cancellation and replay.
Gate a refund with a verified decision
Store the policy, read all three verdicts, verify the proof without trusting the engine, and fail closed.