> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stateset.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Why StateSet
> What we built, how it differs from Stripe, RPA and copilots, what it costs, and honest answers to the hard questions.
# 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.**
| | API-first (Stripe, Shopify) | iCommerce |
| ---------------- | ------------------------------ | ---------------------------- |
| Where it runs | Their servers | **Your process** |
| Latency per call | Network round-trip | In-memory |
| Works offline | No | **Yes** |
| Type safety | Whatever your client generates | Native, across 11 bindings |
| Scope | Payments, or a storefront | Full lifecycle state machine |
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](/computer-use-agent) 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.
| Live today | Price |
| ------------------------------------------------------ | ------ |
| Triage outcome — enquiry triaged and handed to a human | \$0.50 |
| Resolved customer contact — resolved end to end | \$2.00 |
Plans pair an optional platform fee with a per-outcome rate; a larger fee buys a lower rate. See
[Billing](/stateset-billing) for the current catalog and plans.
Outcomes can be **disputed within 14 days**. A dispute becomes a Stripe customer balance
transaction, so a credit lands on your next invoice, and the Outcome Accounting Dashboard shows
the full ledger. If the work wasn't done, you don't pay for it.
### 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](/stateset-nsr-decisions), 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](/next-temporal/overview). 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](/stateset-sequencer/stateset-sequencer) events are
Ed25519-signed and [ICP](/stateset-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](/stateset-sync-server-api-basics), X12 and EDIFACT via
[EDI](/stateset-edi/overview), phone through [Voice](/stateset-voice/overview), email through
[Mail](/stateset-mail/overview) — 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](/stateset-icommerce/stateset-icommerce-backup-restore) 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
Embed the engine. Open source, 11 bindings, 719 agent-callable tools.
Deploy outcome-priced agents against your existing stack.
The verified-decision contract, in detail.
Ten MCP servers across the platform.