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 938 tools across 87 modules, of which 401 write, 39 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.
