Commerce Infrastructure Must Be Rebuilt for Agents, Not Browsers

The Browser Era Is Over

Every commerce platform you use today was built on a single assumption: a human is sitting at a screen.

Shopify assumes a merchant is clicking through an admin panel. Salesforce assumes a rep is dragging deals across a pipeline. Zendesk assumes an agent is reading a ticket and typing a reply. Stripe assumes a customer is watching a checkout page load.

This assumption is baked into every API endpoint, every webhook, every OAuth flow, every rate limit, every state machine in the commerce stack. It's not a feature. It's the foundation.

And it's wrong now.

Five Ways Browser-Era Infrastructure Breaks

I've spent the last two years building commerce infrastructure for autonomous agents. Here's what actually breaks when you stop assuming a human is on the other end.

1. APIs Designed for Screens, Not State Machines

Today's commerce APIs are built around the assumption that a human is interpreting the response. They return HTML fragments, paginated lists meant for scrolling, and error messages written in prose.

An agent doesn't scroll. An agent doesn't “see” a 404 page and know to try again. An agent needs deterministic state transitions: order.placed → order.confirmed → order.fulfilled. Not a JSON blob with 47 optional fields and a message: "Something went wrong" string.

When we built our commerce engine, we didn't wrap existing APIs. We rebuilt the state machine from scratch in Rust so that every transition is deterministic, every side effect is explicit, and every response is machine-readable. That's 293,000 lines of code. It's not a weekend project. It's the kind of engineering that the market has been avoiding because browser APIs were “good enough.”

They're not good enough anymore.

2. Auth Models That Assume a Human Is Present

OAuth was designed for a world where a user clicks “Allow” in a browser popup. It assumes session cookies, redirect URIs, and visual confirmation.

Agents don't have browsers. They don't click popups. They operate at 3 AM on a Saturday processing 400 returns while your team sleeps.

What agents need is delegated authority: cryptographically scoped permissions with explicit spending limits, time bounds, and action constraints. Not “this app can access your Shopify store.” Rather: “this agent can process refunds up to $200 per transaction, for orders placed in the last 30 days, on this specific product category, until this token expires.”

3. Webhooks That Fire and Forget

The webhook model assumes a server is reliably receiving and processing events. It also assumes that if something goes wrong, a human will notice, check a dashboard, and fix it.

Agents operating autonomously need guaranteed delivery and idempotent processing. They need to know: did this event already get handled? Can I safely retry? What's the canonical state right now?

When an agent is managing inventory across three warehouses, a dropped webhook isn't a minor inconvenience. It's a stockout or a double-shipment. And no human is watching the dashboard at 2 AM to catch it.

We replaced webhooks with event-sourced state. Every state transition is recorded, ordered, and replayable. An agent can crash, restart, and pick up exactly where it left off. That's not a feature request on top of existing infrastructure. That's a different architecture.

4. Rate Limits Calibrated for Humans

Most commerce APIs rate-limit at levels that assume human-speed interaction. A few hundred requests per minute. Enough for a merchant clicking around an admin panel.

An agent managing a flash sale across 12,000 SKUs needs to make decisions in milliseconds. It needs to check inventory, calculate margin, evaluate discount eligibility, and execute the transaction before a human would have finished loading the page.

The solution isn't “higher rate limits.” The solution is embedded execution. Move the commerce logic to where the agent runs. Don't make the agent call a remote API for every state check. Give it a local runtime with the full commerce state machine in-process.

5. No Concept of Multi-Agent Coordination

Browser-era commerce has one user per session. One cart. One checkout. One buyer.

In the agentic world, a procurement agent might be negotiating price with a supplier agent while a logistics agent is optimizing routing and a compliance agent is validating the transaction against policy. These agents need to coordinate on shared state without stepping on each other.

Today's commerce APIs have no concept of this. There's no transaction isolation between agents. No conflict resolution. No protocol for one agent to delegate a sub-task to another agent with bounded permissions.

This isn't an edge case. This is the default architecture of the autonomous enterprise.

Browser-Era vs. Agent-Native Infrastructure

What Agent-Native Infrastructure Requires

If I had to distill what we've learned building for agents over two years into a set of requirements, it would be this:

The Uncomfortable Truth About “Agentic Commerce”

Here's what concerns me about the current conversation around agentic commerce.

Visa, Stripe, and Microsoft are all building for this future. That's the right instinct. But they're building payment and discovery rails for agents. They're answering: how does an agent pay? How does an agent find products? How does an agent check out?

Those are important questions. They're also the easy questions.

The hard questions are operational:

• How does an agent process a warranty claim that requires checking order history, verifying a damage photo, cross-referencing warranty terms, and issuing a replacement?
• How does an agent decide between a refund or exchange when the contribution margin is negative after tariff adjustments?
• How does an agent handle a subscription save when LTV data suggests retention is worth a 25% discount but the promotion stack caps discounts at 20%?

These aren't checkout problems. They're execution problems. And execution is where the complexity lives.

This Is the Third Platform Shift

Commerce has gone through two major infrastructure rebuilds. We're entering the third.

Every time the “user” changed, the infrastructure that assumed the old user became a bottleneck. Catalog-era infrastructure couldn't serve mobile commerce. Monolithic backends couldn't serve headless frontends. Browser-era APIs can't serve agents. The pattern repeats.

The Rebuild Is Already Underway

We're not waiting for the industry to catch up. We've spent two years building agent-native commerce infrastructure:

This isn't a wrapper around Shopify's API. This is new infrastructure for a new era.

The Question Every Commerce Leader Should Ask

If you're running commerce operations today, ask yourself this:

Is your infrastructure designed for the entity that's actually going to use it?

If the answer is “it was designed for browsers and we're adapting it for agents,” you're building on a foundation that will crack under the weight of what's coming.

Agents don't browse. They execute. They don't read error messages. They need deterministic outcomes. They don't click through OAuth flows. They need delegated, bounded authority. They don't tolerate latency. They need local state.

The commerce stack needs to be rebuilt. Not upgraded. Not wrapped. Rebuilt.

And the companies that understand this first will define the next era of commerce.