​

Why StateSet

​

The shift

By most forecasts a third of enterprise work will be done by agents within a few years. The blocker isn’t reasoning — models are already good enough to decide what should happen. The blocker is transacting: 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. StateSet builds the layer that closes that gap: the engine agents run on, and the rails they transact over.

​

How we’re different

​

Against Stripe and Shopify: 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 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 copilots: autopilot, not assistance

Gorgias AI and Zendesk AI suggest an answer for a human to send. That still requires the human. StateSet resolves the ticket and closes it: it looks up the order, applies your policy, issues the refund, updates the record, and replies — then the outcome is logged as billable work. We replace the labor rather than accelerating it. 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: 180+ commerce and 3PL/WMS integrations 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

“AI makes mistakes. I trust my BPO team.” Humans make mistakes too, usually from fatigue and turnover. The difference is that our agents follow your written policy every time, and the enforcement is structural: 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. “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 use Gorgias AI / Zendesk AI.” Those are copilots that suggest answers to humans. We’re an autopilot that resolves and closes. The two coexist fine — StateSet can run behind Gorgias as the system that actually does the work. “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