The Operator Changed
For twenty years every checkout tool assumed a human sits in a dashboard and clicks. That assumption is now wrong, and adding an AI assistant to a dashboard does not address it. When an agent operates the machinery instead, the guardrails that quietly lived in the interface evaporate — which is why bolting an API onto a product built for human operation produces an agent-operable liability rather than an agent-native one. The constraints have to live in the core.
What actually happens when software sells on your behalf
For twenty years, every checkout tool has been designed around the same assumption: a human being sits in a dashboard and clicks. Create product. Set price. Add bump. Configure upsell. Save. Preview. Publish.
The assumption was so total that nobody named it. It was just what software was.
That assumption is now wrong, and most of the industry hasn't noticed yet — because the thing that changed doesn't look like a change. It looks like a feature. Companies are adding AI assistants to their dashboards, and calling that the answer.
It isn't. The operator changed. That's a different problem entirely.
The interface was never the product
Start with what AI actually did to this category.
Landing pages used to be a business. There were companies whose entire product was “put a headline, an image and a button on a page.” That business is over. Any competent model will now produce a better landing page in thirty seconds than most humans produced in a day, and it will do it for free.
So the page — the thing everyone thought they were selling — turned out to be the cheap part.
What didn't get cheap is the machinery underneath. Taking a card. Adding an item to an order without a second charge. Charging a saved card thirty seconds after a purchase. Computing tax across jurisdictions. Issuing a sequential invoice that survives an audit. Retrying a failed renewal for seven days without human intervention. Tracking an affiliate's referral through a refund and clawing the commission back.
None of that got easier. It's the same regulated, adversarial, edge-case-ridden work it always was. AI made the surface free and left the substrate untouched.
Which means the interesting question isn't “can AI build my page.” It's: can AI operate the machinery?
Description replaces design
When an agent operates the machinery, the first thing that goes is the dashboard metaphor.
A dashboard exists because a human needs to see state in order to change it. You look at a list of products, you find the one you want, you click into it, you change a field. The interface is a map of the data, laid out so a person can navigate it.
An agent doesn't navigate. It doesn't need a map. It needs an API and a description of intent.
“Sell my course at forty-nine dollars, add the workbook as an order bump, and offer the coaching call as a one-click upsell after purchase.”
That sentence contains everything. There's no ambiguity in it that a dashboard would have resolved. The human has specified the outcome; the only remaining work is execution, and execution is exactly what machines are for.
This inverts the bottleneck. For twenty years the bottleneck was execution — knowing which settings produced which behaviour, and clicking through them without error. Now the bottleneck is specification: knowing what you want. Which is a much better bottleneck to have, because it's the part that was always the actual work.
The new hard problem is authority
Here's where it gets genuinely difficult, and where most of the current wave of “AI-powered” tooling is going to fail.
An agent that can operate your selling system can also break it.
It can set a price wrong. It can ship a checkout that doesn't compute tax. It can create urgency that isn't real — a countdown timer that resets forever, a scarcity claim with no scarcity behind it. It can issue a refund it shouldn't. It can do all of this fluently, confidently, and at speed, which is precisely what makes it dangerous.
The usual response is to keep a human in the loop. Approve every action. Review before publish.
But that response destroys the value. If a human has to check everything, you haven't automated anything — you've added a review queue to a job that used to be a click.
The real answer is structural, and it's the thing I think defines this category: you don't constrain the agent, you constrain the system.
An agent should be physically incapable of the dangerous things, not merely instructed to avoid them. Concretely:
Prices are computed on the server. Not read from the page, not passed in the request. The server rebuilds every total from its own records, so a modified page — whether modified by an agent or a buyer with developer tools open — still charges correctly. The agent can style a checkout. It cannot price one.
Honest mechanics by construction. A countdown that hides when it reaches zero and cannot reset is not a policy. It's a property of the software. Urgency becomes real because faking it isn't an available operation.
Custody stays with the merchant. Money settles directly in the merchant's own processor account. When you hand operational authority to software, the last thing you want is an intermediary holding the funds. There should be nothing to withhold.
Every action is attributed. When an agent refunds an order, the log must say which agent, acting on whose authority, under which role. An API key inherits the permissions of the person who created it and can never exceed them — and it dies the moment that person is removed. “Who did that?” has to remain answerable, or nobody will ever hand over the keys.
Notice that none of these are features in the marketing sense. They're guarantees. They're the things that make delegation rational.
Why bolting on an API won't be enough
The prediction I'd make: over the next two years, most SaaS companies will add an MCP server to their existing product and announce that they're agent-ready.
Nearly all of them will be wrong, for a structural reason.
Products built for dashboard operation encode their safety in the interface. The reason you can't set a negative price isn't usually that the server rejects it — it's that the form field won't accept it. The reason you can't publish a broken funnel is that the wizard won't let you proceed. Decades of accumulated guardrails live in the UI layer, because for decades the UI layer was the only way in.
Expose that same system through an API, and every one of those guardrails evaporates. The agent goes around the form. What you've built isn't an agent-operable product; it's an agent-operable liability.
Being genuinely agent-native means the invariants live in the core — that there is no path, through any interface, that produces a mispriced order or a checkout that can't deliver.
That's not an integration. That's an architecture, and you mostly can't retrofit it.
What this means if you sell things
Three practical consequences.
Your leverage shifts to specification. The competitive advantage stops being “I know how to configure this tool” and becomes “I know what a good offer looks like.” Direct-response knowledge — what to bump, when to upsell, how to price a bundle — appreciates in value, because execution no longer rations it. Everyone can now execute. Not everyone knows what to execute.
Speed changes shape. The gap between “I have an idea for an offer” and “the offer is live and taking money” collapses toward zero. That doesn't just make you faster; it makes you willing to test things you'd previously have dismissed as not worth the setup. The cost of trying is what governs how much you learn.
Trust becomes the purchasing criterion. When you're evaluating tools that your agent will operate, the question isn't “what can it do.” It's “what can it not do.” The feature list matters less than the guarantee list. Buyers haven't fully internalised this yet. They will, the first time an agent does something expensive.
The uncomfortable part
I don't think this is uniformly good, and I'd rather say so than pretend.
Making offers trivially easy to build makes bad offers trivially easy to build too. The same conversational speed that lets a legitimate business launch in ten minutes lets a predatory one launch in nine. The constraint that used to slow down manipulative marketing was partly friction — it took effort to build a funnel, and effort filters.
That friction is going away and it isn't coming back. Which puts the burden on the infrastructure. If the software makes dishonest urgency impossible, dishonest urgency stops being a competitive strategy. If it makes it easy, it becomes the default, because the honest operator is now competing against something automated.
Categories get shaped early. What the first generation of agent-operable commerce tools makes possible will set the norm for what everyone does, long after anyone remembers the decision was made. That's worth taking seriously now, while the decisions are still cheap.
I build GoCushy, an MCP-native commerce platform — the machinery above is what we've had to work out in practice. We opened the founding round last week and took $10,500 in the first seven days. Small numbers, early days, but real ones, and everything above is written from inside the problem rather than about it.
Arguments and counterexamples welcome. This is a young category and I'd rather be corrected early than be confidently wrong in public for a year.