Skip to main content

​
iCommerce Agent

An iCommerce agent combines three things: the embedded engine for state, the MCP server for tools, and the CLI safety model so writes stay explicit. The result is an agent that resolves work rather than describing it — and leaves a record of what it did.

​
The loop

1. Gather. Orders, inventory, customer history — all reads, no side effects.
2. Propose. Decide the action and state it, before doing it. For consequential actions this is where the decision gate belongs — the agent proposes, the policy engine authorises. 3. Execute with explicit write intent.
4. Record. The outcome, and what authorised it.

​
What an agent can do

The MCP surface exposes 719 tools across 63 domains, of which 287 write, 47 admin, and 21 delete.
Scope the agent to the domains it needs. A support agent resolving refunds does not need the manufacturing or general-ledger tools, and giving it the full catalogue means a mis-planned action can reach places you never intended.

​
Making it safe

Four layers, from coarse to fine:
These compose rather than substitute. --apply grants permission to attempt a write; the engine’s idempotency keys, terminal-state guards, and High-Value Action threshold still apply underneath.

​
Running it sandboxed

For untrusted or long-running work, run the agent inside a sandbox — isolated execution with a bounded timeout and its own resource profile.

​
Deterministic beats fluent

Use stateset-direct rather than the natural-language binary for anything an agent runs unattended. Interpretation is useful at a terminal and a liability in a loop: the same instruction can resolve differently as the model changes.