StateSet combines commerce operations, customer-support agents, policy decisions, and durable
workflows. Build an operation by selecting the service that owns each result, then connect
those services through their documented APIs or MCP tools.
The earlier version of this page presented proposed wallet, SDK, marketplace, and command-line
interfaces as implementation examples. Those examples have been removed. Use the concrete
entry points below to establish a working integration.
Choose the components for one task
Each service has its own setup and credentials. An MCP connection supplies access to a tool
surface; it does not provision another service or grant that service’s permissions.
Trace an operation end to end
For an order-status request, identify the customer’s order in the authoritative system, read its
state, apply the response policy, and prepare the customer answer. If the workflow requires a
mutation, define that action separately and verify its result in the owning system.
The order-status journey connects those steps. Before
using business data, complete the local operation, which gives an
agent an exact order ID and database path and independently checks its answer.
Define an agent handoff
Use the agent operating procedure to turn that brief into a
tool-based workflow. Compare the available schemas with the task before executing a write.
Keep authorization and execution separate
A policy verdict can allow an action without performing it. A workflow can accept a launch
without completing it. A payment record can exist without funds having moved. Retain the
identifiers for each stage and verify the final business outcome independently.
Idempotency is an endpoint contract. A workflow replay or an agent retry does not make every
external action safe to repeat. Preserve keys where supported and reconcile uncertain
outcomes using error handling. Operate a durable agent
Use the durable-agent walkthrough for launch, status, steering,
and cancellation. Confirm scope and execution budget before launch. After a stop request,
read status again; closing a client window does not establish cancellation of remote work.
Record the model/tool configuration, source-record versions, decisions, and execution IDs.
When a result is wrong, capture the failure as an evaluation case
before changing configuration, then compare the repeated test with the original evidence.
Rollout criteria
Start with an isolated fixture, then a reviewed trial, then a bounded live workflow. At each
stage verify access, correct data, intended side effects, and recovery from interrupted work.
The first-week guide provides the operating sequence;
connect your operation maps the data owners and handoffs. Last modified on September 21, 2026
