Why StateSet

​

The shift

AI reasoning, agent protocols and buyer readiness have all advanced. Models are already good enough to decide what should happen. The remaining bottleneck is trusted execution across real commerce systems: an agent that concludes “this customer deserves a refund” still has to find the order, check the policy, issue the payment, update inventory, and close the ticket — through interfaces designed for a human with a mouse, in systems that must stay consistent with each other afterwards. StateSet is the iCommerce company, and the iCommerce Engine is the layer that closes that gap: an agent-native commerce execution runtime and control layer that sits above and across the systems you already run.

​

How we’re different

StateSet is not only an AI interaction layer or a workflow connector. It combines commerce semantics, deterministic execution, policies, integrations, auditability and outcome measurement — and each comparison below is really about one of those.

​

Against payment and storefront APIs: embedded, not remote

They give you endpoints over the network. iCommerce is an engine you compile into your runtime. Stripe handles payments. It does not handle orders, inventory, tax, shipping, returns, or the state transitions between them. iCommerce holds that entire state machine locally — including a double-entry general ledger, AP with three-way match, AR with dunning, fixed-asset depreciation, and ASC 606 revenue recognition. The analogy we use is SQLite for commerce. Not a service you integrate with. A library you embed.

​

Against iPaaS: commerce semantics, not only orchestration

Zapier, Workato and their peers are excellent integration and orchestration tools, and the Engine is happy to sit beside them. What they do not carry is the commerce model: what an order is, which transitions are legal, what a refund does to the ledger, when an action needs a human. StateSet adds that — commerce semantics, policy, autonomous decisioning and outcome accountability — on top of the plumbing.

​

Against your ERP, OMS and WMS: above and across, not instead of

StateSet is not another ERP. Your systems of record stay where they are; the Engine makes them safely operable by agents — the Sync Server and EDI keep them agreeing with each other, and every write is validated against the commerce model before it lands.

​

Against RPA: adaptive, not brittle

RPA scripts encode pixel positions and DOM paths. Move a button and the bot breaks, silently, at 3am. Our Computer Use agents perceive the screen and reason about it, so a redesigned page is something they adapt to rather than fail on. They also run on three interchangeable engines — Claude, OpenAI, or a local zero-API engine — so you’re not locked to one vendor’s availability or pricing.

​

Against helpdesk AI: close the operation, not just the conversation

Gorgias, Intercom and Sierra-style agents automate the interaction and a selected set of actions, and they do it well. A support ticket, though, is usually a symptom of an order, subscription or fulfillment problem underneath it. StateSet is built to execute — and maintain correctness across — that underlying operation: it looks up the order, applies your policy, issues the refund, updates every record that depends on it, and replies. The interaction is resolved and the operational fix behind it is done, so closing the ticket does not create downstream work. This is also the only honest basis for outcome pricing. You cannot bill per resolution if a person still has to finish every one.

​

How it adds value

​

You pay for work completed, not capacity provisioned

Traditional software bills for seats or tokens whether it works or not. StateSet bills per verified outcome, priced against the BPO labor it replaces. Plans pair an optional platform fee with a per-outcome rate; a larger fee buys a lower rate. See Billing for the current catalog and plans.

​

Consequential actions are provable

This is the part we’d most want a skeptical buyer to test. When an agent proposes something that moves money or changes an order, the action is routed through NSR, which returns approved, denied, or refused with the cited rules that produced the verdict and a SHA-256 pin to the exact policy inputs it was evaluated against. Two properties are enforced in code, not policy:

• Grounded-only approvals. An approved verdict only executes when its proof is grounded. A confident-but-ungrounded approval escalates to a human instead.
• Fail-closed. A refused verdict and an unreachable policy engine both escalate. An outage degrades into human review, never into unauthorized automation.

High-Value Actions — by default anything at or above $100 — require human approval before execution, configured per brand.

​

The audit trail is the execution

Automated work runs as Temporal workflows. The verdict and proof chain that authorized an action live permanently in the workflow’s event history, and replays reuse them. There is no separate audit log that can drift from what actually happened. For cross-party verification, Sequencer events are Ed25519-signed and ICP receipts are JWS over a canonicalized body — verifiable offline by any party, with no callback to us.

​

It reaches the systems you actually run

An agent is only as useful as what it can touch: the commerce platforms and 3PL/WMS systems a brand runs on, through Sync, X12 and EDIFACT via EDI, phone through Voice, email through Mail — and for systems with no API at all, Computer Use drives the UI.

​

The hard questions

“Isn’t this just automation?” Automation executes predefined steps. The Engine combines an agent’s reasoning with deterministic commerce execution, policy controls and operational state — it decides what to do within the bounds you set, and the bounds are enforced in code. “AI writes are too risky.” That is the right instinct, and the Engine is designed around it: simulation, permissions, invariants, approval paths, auditability and fail-closed execution. The decision gate fails closed, ungrounded approvals escalate, and anything above your value threshold needs a human. You set where the line is. And when an outcome is wrong, you dispute it and don’t pay. “AI makes mistakes. I trust my BPO team.” Humans make mistakes too, usually from fatigue and turnover. The difference is that agents follow your written policy every time. And StateSet is not a replacement for a BPO: it removes the repetitive labor while giving a BPO a higher-leverage delivery model for QA, exceptions and managed operations. “Why not just use the Stripe API?” Stripe handles payments, not commerce. You still have to manage orders, inventory, tax, shipping, and returns state yourself. iCommerce handles that full lifecycle locally — and the finance layer underneath it. “Is this proprietary? What’s the lock-in?” The core engine is open source, dual-licensed MIT OR Apache-2.0. Inspect it, fork it, run it anywhere. We charge for enterprise features and hosted infrastructure. Because the engine is embedded and the data is a SQLite or Postgres database you control, you can export or back it up at any time. “We already have an ERP.” Good. StateSet is not another ERP; it gives agents a governed way to operate your existing systems of record. “Our helpdesk already has AI.” Keep it. StateSet can become the execution layer that safely performs the underlying commerce work across systems — it runs behind Gorgias or Intercom as the thing that actually does the work. “Why not build this ourselves?” The hard part is not an LLM call. It is years of commerce semantics, integrations, safe state transitions, policy and operational edge cases — and that is what the Engine is. “Does this require a proprietary protocol?” No. Every service speaks REST, most expose an MCP server and a skill, and the Engine interoperates with the protocols and agents you already use. “How do I know the agent did what it says?” Every automated action carries a cited proof chain in the workflow’s permanent event history. That’s a stronger claim than most vendors make, and it’s the one we’d invite you to audit first.

​

Where to start