The AI Harness for Commerce

Any brand can subscribe to the same frontier model we do. Almost none of them can run their returns queue with it.

That gap is the whole business.

The models are not the scarce resource anymore. A twenty-dollar subscription buys a system that can read a shipping policy, reason about a damaged-in-transit claim, and write a better customer response than most contractors. The intelligence is sitting right there, available to everyone, priced like a streaming service.

And yet the returns queue still has twelve people in it. The exceptions dashboard still gets worked by hand every morning. The WISMO tickets still pile up overnight and get triaged by someone at 8 a.m. who opens six tabs to answer one question.

The usual explanation is that the models are not good enough yet. That explanation is wrong, and it has been wrong for about a year.

The model was never the missing piece. The harness was.

What a Harness Actually Is

The clearest proof of this happened in software engineering, in public, faster than anyone expected.

For a while, large language models could write code but could not ship it. They produced plausible functions in a chat window. A human copied the output, pasted it into a file, found the import was wrong, fixed it, ran the tests, pasted the failure back, and repeated. The model was smart. The workflow was clerical.

Then something changed, and it was not primarily that the models got smarter — though they did. What changed is that we wrapped them in a harness.

The harness gave the model a filesystem it could actually read. Tools it could actually call. A loop that kept running until the task was done instead of stopping after one reply. A permission model so it could not casually delete a production database. And a verifier — the compiler, the type checker, the test suite — that could tell the model it was wrong without a human having to notice first.

Same weights. Radically different capability. The intelligence was latent the entire time; the harness is what converted it into work.

Commerce operations never got that layer built. We got the chat window. We got the copilot in the corner of the helpdesk that drafts a reply for a human to approve. We got demos where an agent browses a storefront like a confused shopper.

What we did not get is the thing that made coding agents work: an execution environment where a model has real tools, real state, a loop that survives the night, limits it cannot talk its way around, and a way to know whether the outcome actually happened.

That is what StateSet builds. That is what we mean by the AI harness for commerce operations.

The Five Things an Ops Harness Has to Supply

A harness is not one feature. It is five obligations, and a system that skips any of them degrades back into a chat window with better marketing.

Tools with authority

Most “AI integrations” in commerce are read integrations. The agent can look up an order. It cannot change one.

This is the quiet reason so many pilots stall at deflection. An agent that can only read can only answer questions, and answering questions is the cheap half of the job. The expensive half is doing something: issuing the refund, cutting the replacement order, updating the subscription, releasing the fraud hold, filing the carrier claim.

Authority means typed, scoped, reversible write actions into the systems of record — with idempotency so a retry does not refund a customer twice, and a rollback path for when the third system in a five-step sequence rejects the call. We have written before about why a connector list is not the same as the ability to act.

Context that is true

The second failure is feeding the model documents when it needs state. Retrieval over a help center tells an agent what the return policy says. It does not tell the agent that this order shipped to a reshipper in Delaware, that the customer has filed three claims this quarter, or that the item is currently sitting in a returns bin unscanned.

The harness has to assemble the live picture — order, payment, fulfillment, inventory, subscription, carrier, customer history — at the moment of the decision. Otherwise the model reasons beautifully about a situation that is not the one in front of it. That is the failure mode we have spent the most time arguing against.

A loop that outlives the session

A coding agent can finish in ten minutes because the compiler answers immediately. Commerce does not answer immediately. It waits on a warehouse shift, a carrier scan, a settlement file, a supplier email, a human approval.

So the loop has to be durable rather than conversational. It has to be able to pause for three days, wake on a webhook, retry a failed leg without redoing the successful ones, and resume from state rather than from scratch. That is what our durable workstream engine and isolated sandboxes are for.

Constraints it cannot argue past

Every team that deploys an agent eventually discovers the difference between a rule in the prompt and a rule in the system.

A prompt-level constraint is a strong suggestion to a probabilistic system. It holds until the customer is upset enough, the phrasing is unusual enough, or the context window is full enough. A harness-level constraint sits outside the model: the proposed action is evaluated against policy before it can execute, deterministically, the same way every time, with a record of which rule applied and why.

This is the job our neuro-symbolic reasoning layer does. The model proposes. The symbolic layer disposes. You get the flexibility of language and the predictability of code, without asking either one to be something it is not.

A verifier

This is the one almost everybody skips, and it is the one that made coding agents work.

The test suite is what let a coding agent iterate without a human babysitting each step. It is an oracle: an independent, automatic answer to “did that work?” Without it, an agent is just generating confident output into the void.

Operations needs the same oracle, and it is harder to build because there is no compiler for a returns queue. The harness has to define, per outcome type, what counts as resolved — the state transition occurred, the refund settled, the replacement shipped, the customer did not come back within the window — and then check it.

An agent without a verifier cannot improve, cannot be trusted, and cannot be priced. All three limitations have the same root cause.

The Second Meaning: Harnessing the Horsepower

The word has an older sense, and it is the right one.

A harness is what turns raw power into directed work. The horse was always strong. The harness is what made the strength pull a plough in a straight line instead of expending itself in a field.

Frontier models are enormous raw capability currently being spent in chat windows, one human attention span at a time. A person can supervise maybe three or four agent sessions before the supervision costs more than the work. That ceiling is why so much AI in operations produces impressive demos and unimpressive P&Ls.

A harness removes the human from the critical path of keeping the work alive. Thousands of exceptions can move concurrently. Each one has its own state, its own budget, its own escalation threshold. The operator is no longer the one pressing Enter — they are the one setting policy, watching aggregate throughput, and handling the small fraction that genuinely needs judgment.

The Third Meaning: The Kind You Wear

A harness is also the thing that lets you work at height.

Nobody puts on a safety harness because they intend to fall. They put it on because the harness is what makes it rational to go out on the roof at all. The restraint is not the opposite of the ambition. It is the precondition for it.

This is the part operators feel in their gut and vendors tend to skip past. The question is never “can the model write a good refund email.” It is “what happens the night it decides to refund four hundred orders.”

The harness answers that question structurally, before it is asked:

• Authority is scoped per action, not granted wholesale to an agent.
• Value ceilings, rate limits, and blast-radius caps are enforced outside the model.
• Defined boundaries route to a human instead of guessing.
• Every action leaves an audit record: what was proposed, which policy applied, what executed, what changed.
• Reversible actions have a rollback path that is tested, not theoretical.

Teams that install these controls end up granting agents dramatically more autonomy than teams that do not — not less. The harness is what makes letting go survivable.

What It Looks Like in Production

Abstractions are easy to nod along to, so here is a single ordinary exception moving through the harness. Not a heroic case — the kind a brand sees a few hundred times a week.

Notice how little of that is model work. Step three is the model. The other six steps are harness: gathering true state, enforcing policy, executing typed actions, waiting durably, and verifying the result.

That ratio is the actual shape of the problem. It is also why buying a smarter model does not fix an operation, and why the teams who understand this are not shopping for models at all.

Why This Is the Business, Not Just the Architecture

There is a commercial consequence to all of this that took us a while to appreciate.

We price on verified outcomes — not seats, not conversations, not tokens. Customers like this because it moves the risk onto us. But the deeper point is that outcome pricing is not a pricing strategy you can simply choose. It is a capability you have to earn.

You cannot bill for an outcome you cannot verify. Verification is a property of the harness.

A vendor without a harness has no idea whether the ticket it answered actually resolved the customer, so it bills for the conversation. A vendor without policy enforcement cannot promise the agent stayed inside your rules, so it bills for the seat and hands you the supervision. A vendor without durable execution cannot own anything that takes longer than a session, so it sells you a copilot and leaves the remaining eighty percent of the work on your team.

Every one of those pricing models is an architecture confession. The business model tells you exactly which parts of the harness the vendor did not build.

The Bottleneck Was Never Intelligence

The models will keep getting better. Next year’s will reason more reliably about a partial return with a promotional discount and a split shipment than this year’s does. That is genuinely good, and it is also not where your constraint is.

Your constraint is that the intelligence has nowhere to grip. It cannot reach into your systems with authority. It cannot see your true state. It cannot keep working past the moment you close the tab. It cannot be stopped by anything sturdier than an instruction. And it cannot tell you whether what it did actually worked.

Fix those five things and the model you already have access to becomes an operation.

Skip them, and the smartest model in the world is a very expensive way to draft an email.

Building the AI harness for commerce operations at StateSet.