Long-Running Agents for Commerce

The next generation of commerce automation will not wait for a human to keep pressing Enter.

Most AI agents are trapped inside a session.

You open a CLI or web app. You give the agent a task. It works for a few minutes. Then it asks a question, loses a connection, hits a timeout, or waits for you to come back and tell it what to do next.

That is useful for assistance. It is not enough for operations.

Commerce work does not fit neatly inside a chat window. A return investigation can take hours. A fulfillment exception can span multiple systems and multiple days. A campaign optimization loop needs to observe results before it decides what to do next. A finance reconciliation may need to wait for a settlement file, investigate mismatches, and route exceptions for approval.

The work keeps moving even when nobody is watching the screen.

The agent should too.

We have combined two of the most powerful pieces of infrastructure we have built: StateSet iCommerce Workstream Engine, our Rust-based durable workstream engine built on Temporal, and StateSet iCommerce Sandbox Engine, our isolated execution environment for AI agents. Together, they make long-running agentic automation possible for commerce.

The result is an agentic system that can work in the background for hours or days, coordinate multiple agents in parallel, recover from failure, wait for external events, and persist the final outcome back into a durable workstream.

The Session Is the Bottleneck

The current interface for most agents is still a human sitting in front of a terminal or browser.

The human starts the task. The human watches the progress. The human responds when the agent pauses. The human restarts it when the process fails. The human collects the output and moves it into the next system.

The agent may be intelligent, but the operating model is still manual.

This creates an obvious ceiling. A person can supervise a handful of sessions. A commerce business may have thousands of operational outcomes moving at once: late orders, inventory exceptions, return requests, payment disputes, campaign experiments, supplier follow-ups, catalog corrections, and customer escalations.

You cannot run that operation one chat window at a time.

Long-running agentic automation removes the requirement that a person remain in the loop merely to keep the process alive. The human defines the objective, authority, constraints, and approval points. The system carries the work forward.

Two Systems, One Operating Model

Long-running agents require two different kinds of infrastructure. They need a durable system that remembers what must happen. And they need an execution environment where the actual work can happen safely.

That is what this combination provides.

StateSet iCommerce Workstream Engine: The Durable Queue

StateSet iCommerce Workstream Engine is the orchestration layer. It owns the lifecycle of the work.

It tracks the current state, schedules activities and child workflows, waits for external events, applies retry policies, manages timeouts, routes approvals, and resumes execution after interruptions. If an API is unavailable, a worker restarts, or the process needs to wait three days for a carrier update, the workstream does not disappear.

It continues from durable state.

This layer is deterministic where commerce requires determinism: which step comes next, which policy applies, whether approval is required, what happens after a failure, and when the workflow is complete.

StateSet iCommerce Sandbox Engine: The Execution Environment

StateSet iCommerce Sandbox Engine is where agents do the work.

Each sandbox gives an agent an isolated Kubernetes environment with the tools, code, files, scoped secret access, network policy, and resource limits required for its assigned task. An agent can execute code, automate a browser or desktop, call approved services, generate artifacts, run evaluations, operate against commerce systems, and return a structured result.

The environment is temporary. The work is not. StateSet iCommerce Sandbox Engine supports agent sessions that can rotate into fresh sandboxes while carrying their tools and context forward. It also provides checkpoints, artifacts, audit events, and cost, iteration, and duration budgets.

Multiple sandboxes can run at the same time. That means a workstream does not have to send every problem through one general-purpose agent in sequence. It can divide the outcome into specialized tasks and execute them in parallel.

The workstream provides durability. The sandbox provides agency and isolation.

Together, they create a system that can reason adaptively while executing reliably.

What the Architecture Looks Like

Consider an inventory risk workstream for a brand with multiple warehouses and sales channels. Its objective is to reduce stockout risk without increasing excess inventory.

The agents are allowed to explore, reason, and adapt inside their sandboxes. The workstream remains responsible for orchestration, policy, state transitions, and completion. Side effects stay behind explicit activities and commit boundaries instead of being hidden inside an open-ended model loop.

That separation matters.

An LLM is probabilistic. A purchase order approval rule should not be. An agent may produce three possible plans. The workstream must still know which plan was approved, which action was executed, and whether the intended business outcome occurred.

We are not making probabilistic agents deterministic. We are placing their work inside a deterministic operating system.

Long-Running Does Not Mean Unbounded

Autonomy without limits is not an operating model.

StateSet iCommerce Workstream Engine manages long-running work through bounded turns. Each turn has an explicit timeout and runs as a child workflow. The parent carries forward a compact ledger of what was attempted, what completed, and what should happen next. It periodically starts a fresh workflow history so an active agent can keep progressing without allowing its execution record to grow forever.

The workstream can enforce:

• An active-time budget.
• A maximum number of turns.
• A maximum number of failures.
• A timeout for each turn.
• An allowlist of workflow types the agent can start.

Operators can pause, resume, cancel, steer, enqueue new work, reprioritize the queue, or extend an approved budget while the agent is running.

StateSet iCommerce Sandbox Engine enforces another boundary around execution: cost caps, iteration limits, duration limits, CPU and memory limits, scoped network egress, and sandbox rotation. If a client disconnects, it can reattach to the agent session instead of losing the work.

This is not an agent running forever with a credit card and a shell.

It is controlled autonomy with a durable off switch.

Can Multiple AI Agents Work Together?

Yes. In many cases, that is the point.

A complex commerce outcome rarely belongs to one function. A late-order recovery process may require customer context, carrier investigation, inventory availability, refund policy, and margin analysis. Asking one agent to process every step sequentially is slow and creates a single point of failure.

A durable workstream can fan the task out across specialized agents:

• A customer agent reconstructs the conversation and identifies the promised outcome.
• A logistics agent investigates carrier scans, warehouse events, and replacement options.
• A policy agent evaluates refund, reshipment, and appeasement rules.
• A finance agent calculates the cost of each resolution.
• A resolution agent assembles the recommended action and customer communication.

These agents can work in parallel inside separate sandboxes. Their results return as structured outputs. The workstream can then wait for all required inputs, reconcile conflicts, request an approval if needed, and persist the aggregate result.

This is not a group chat between bots.

It is coordinated execution with explicit ownership, bounded authority, and a durable record of what each agent contributed.

What Long-Running Commerce Workflows Become Possible?

Once an agent can survive beyond a single session, a different class of automation becomes practical.

Customer Experience

An agent can own a complex case from the first customer message through final resolution. It can investigate an order, wait for a carrier response, monitor a replacement, update the customer at defined intervals, issue an approved credit, and confirm that the outcome was completed.

The goal is not “respond to the ticket.” The goal is “resolve the customer’s problem.”

Operations

Agents can continuously investigate fulfillment exceptions, reconcile inventory across systems, monitor supplier commitments, prepare purchase orders, identify catalog errors, or coordinate a product launch across the storefront, warehouse, and support operation.

These workflows may contain long periods of waiting followed by short bursts of execution. Durable orchestration is built for exactly that shape of work.

Finance

An agent can reconcile payouts against orders and refunds, investigate mismatches, collect supporting evidence, route material exceptions for approval, update the ledger, and produce an audit package.

It can keep working until the books reconcile—not until a browser tab closes.

Marketing

Multiple agents can research customer segments, develop campaign variants, verify claims against brand rules, launch approved experiments, wait for performance data, and recommend the next allocation of budget.

The workflow can run across an entire evaluation window while preserving every hypothesis, change, metric, and decision.

Cross-Functional Outcomes

The most valuable workstreams cross department boundaries. An agentic margin-improvement workstream might investigate returns, fulfillment costs, discount leakage, support appeasements, and paid acquisition at the same time. Each specialist agent works on one part of the problem. The orchestration layer combines the evidence and drives the shared outcome.

The unit of automation is no longer the task. It is the business result.

Can We Track What the Agents Actually Did?

Long-running automation without observability is just long-running risk.

Every workstream needs a durable record of execution. That record should answer:

• What objective was the system given?
• Which agents and tools participated?
• What data and policy versions were used?
• Which steps completed, failed, retried, or timed out?
• What artifacts and recommendations were produced?
• Which approvals were requested, and who provided them?
• What actions were taken in systems of record?
• What business outcome resulted?

Because execution is attached to a durable workstream, the result is more than a chat transcript. StateSet iCommerce Workstream Engine records terminal status, proposed actions, commit results, token usage, context summaries, and first-class outcome records. StateSet iCommerce Sandbox Engine records session events such as execution, rotation, and failure while preserving checkpoints and generated artifacts.

Together, those records create a timeline of state transitions, agent outputs, approvals, actions, and outcomes.

For a customer recovery workflow, that outcome might be resolution time, refund amount, retained revenue, and customer satisfaction. For inventory, it might be stockouts prevented, days of supply, and working capital released. For finance, it might be exceptions resolved and dollars reconciled.

The system does not just report that an agent ran. It records whether the work produced value.

That is the foundation for auditability, evaluation, and eventually outcome-based automation.

Why This Is Not a Cron Scheduler

A cron scheduler answers one question:

When should this job start?

A durable agentic workstream answers a much larger set of questions:

• What outcome are we trying to reach?
• What state is the work currently in?
• Which activities can run in parallel?
• What should happen if one of them fails?
• What event are we waiting for?
• Does this action require approval?
• Which policy version governs the decision?
• How do we resume after an interruption?
• What evidence proves the outcome was completed?

Cron is useful for predictable, stateless repetition: generate a report every morning, clear a cache every hour, trigger a backup every night. A schedule can also start a workstream. But once the work begins, the schedule does not own its state or outcome.

Commerce operations are not stateless repetition. They branch. They wait. They fail halfway through. They depend on people and external systems. They require approvals, compensation, retries, deadlines, and an audit trail.

A cron job can restart the script.

A durable workstream knows where the business process left off.

That is the difference between scheduling computation and orchestrating an outcome.

From Copilots to Background Operations

The first wave of enterprise agents waited inside applications for a human to ask a question.

The next wave will run in the background.

They will wake up when a signal arrives. They will gather context across systems. They will divide work among specialists. They will wait without losing state. They will ask for human judgment only at defined boundaries. They will act within bounded authority. They will survive worker restarts and client disconnects. They will measure the result and continue until the outcome is complete or a defined budget or safety boundary stops them.

This changes the role of the human operator.

Instead of supervising every step, the operator defines goals, policies, budgets, permissions, and escalation thresholds. The infrastructure handles execution. Humans remain in control without becoming the bottleneck.

For brands, this means customer experience, operations, finance, and marketing processes can continue moving overnight, through weekends, and across the long gaps where today’s agents simply stop.

The agent is no longer a tool you operate. It becomes infrastructure that operates for you.

We Are Looking for Design Partners

We believe long-running agentic workflow execution will become a standard part of commerce infrastructure over the next year. But the highest-value workstreams should be built with the operators who live inside these problems every day.

We are looking to work with a small group of early design partners to identify and deploy the most valuable long-running use cases across customer experience, operations, finance, and marketing.

This will be a collaborative exercise: define the outcome, map the current process, establish permissions and approval boundaries, deploy the workstream on StateSet iCommerce Workstream Engine and StateSet iCommerce Sandbox Engine, and measure the result in production.

If your team has an important commerce process that takes hours or days, crosses multiple systems, and still depends on a person to keep pushing it forward, we want to talk.

Building long-running agentic infrastructure for commerce at StateSet.