Containers Without Ports

Agentic commerce now has a standard. Simon Taylor's recent essay on the Universal Commerce Protocol is the clearest thing written on the subject to date, and its central conclusion - that merchant-owned AI converts better than aggregator-owned AI, and that UCP is fast becoming the shared language through which agents and merchants will transact - is correct. I've leaned on Simon's work before; his Future of Payments writing shaped part of my own thinking on wallet-centric identity. He's right again here. The essay does what the best analysis always does: it names the shape of the thing before most of the market has felt it.

And yet it stops one step short of where the genuinely hard problems live. That gap - two gaps, really - is precisely what we've spent since January building at Sumvin.

The Standard

A shipping container is a boring object. That is the entire point of it. Before the container, freight was a bespoke nightmare of crates and barrels and sacks, each handled differently, each negotiated separately. After it, the world agreed on a box, and the box ate global trade. Simon's metaphor is apt because UCP is doing the same job at the protocol layer: it gives agents and merchants a standardised interface (read: a shared grammar both sides can speak without a custom integration for every pairing). The conversation stops being bespoke. The conversation becomes a box.

This is converging, and it's a good thing. The merchant-owned model is winning because it converts, the protocol layer is settling, and the days of every agent-to-merchant handshake being hand-rolled are mercifully numbered.

A shared language, though, only tells two parties how to speak to one another. It says nothing about where the other party is, or when either of them should act. Those are the two questions UCP leaves wide open. They are also the two questions that decide whether any of this works at scale.

Running Errands

Simon's frame describes a smarter, faster version of something we already understand - a person wants a thing, an agent finds it, a merchant sells it, and the checkout is cleaner than it has ever been. Buy my groceries. Order the birthday gift. Find me the cheapest flight to Berlin. Each of these resolves inside a single session, one sitting, one round of intent-and-execution. For that category, UCP-native checkout is close to solved.

What about the instructions that refuse to resolve in a session? Book Rome trip when it drops below £200. Grab those trainers the moment they fall under £120. These look superficially similar, and they are nothing of the sort.

This is a category we call perpetual checkout (read: a standing instruction that lives across time rather than collapsing into a single moment). Perpetual checkout is a desire delegated - handed, with real authority, to an agent that must monitor, wait, and strike only when the conditions you set finally line up. The agent is no longer executing a known action against a known price. It is holding state, watching inventory and pricing in real time across however many merchants are in play, and making the call to transact autonomously inside the parameters you handed it. That demands a fundamentally different architecture from anything single-session checkout logic - even UCP-native checkout logic - was built to carry.

Adding time changes everything about what an agent has to be. And once it becomes the norm, something shifts in the relationship between people and the things they want. You stop refreshing the tab. You stop setting the calendar reminder for the sale. You stop being the one who hunts, monitors, and pounces. You state the intent once and hand it to something that never sleeps, never forgets, and never gets bored of checking. The hours you used to spend administering your own wants quietly evaporate, and what's left is the wanting itself - which is the only part that was ever really yours.

Ports

Simon's container metaphor is good. It's good enough, in fact, that it surfaces a problem he doesn't follow all the way to its end.

The container only ever mattered because every port on Earth agreed to handle it. Standardised cranes, standardised berths, a known manifest, customs that knew what to expect. The box is inert without the network of places willing to receive it. UCP is the box. So where is the index of ports?

The protocol tells an agent how to talk to a merchant. It does not tell that agent which merchants actually speak it, what each of them can genuinely do, or whether the specific UCP extensions a given transaction depends on are live and exposed right now. Plenty of containers. No directory of ports.

Return to the agent trying to book that hotel in Rome. To execute, it needs to know which hotel merchants are UCP-enabled, what their real-time pricing capabilities look like, and whether they support the extensions the booking actually requires. Absent a verified, live index of UCP hosts and their capabilities, the agent is guessing. And an agent guessing - across time, with your standing authority and your money - is the one thing this entire model cannot afford to tolerate. The whole proposition rests on trust, and there is no trust in a system that improvises about where it's allowed to dock.

This is the infrastructure layer that has been quietly missing since UCP shipped.

The Service

We're pleased to say that layer now exists. Through the Sumvin Identity Service Portal, developers can access our real-time index of verified UCP hosts and their capabilities - the same index that powers the Errand experience inside the Sumvin app itself.

The index is live with more than 200k sites, searchable, and updated daily. It tells you which merchants are UCP-enabled, what each one exposes, and what an agent can actually do with them at any given moment. It is, put quite simply, the port directory the shipping-container analogy always implied and never had.

We've written previously that your digital identity and your financial identity are, in our modern age, one and the same - and that whoever provides that combined identity ends up sitting at the centre of everything built on top of it. The agent layer doesn't soften that thesis; it sharpens it to a point. An agent acting on your behalf, across time, against real money, is the most demanding expression of identity and permission we've yet had to build for. It needs to know who you are, exactly what you've authorised, and where in the world it is permitted to go and act. Identity answers the first two. The index answers the third. SIS is the where.

For the Builders

Simon ends with a call to action aimed at merchants: get UCP-ready, run the experiments, don't wait. He's right, and the very same call lands squarely on the developers building the agent layer.

The constraint has moved. The merchant-owned model is winning. The protocol is converging. The next thing standing between us and agents people genuinely trust is the infrastructure that lets those agents navigate the merchant landscape at scale - not at the level of one tidy checkout session, but across time, across merchants, and across exactly the kind of standing instructions that represent the real prize in delegated money management. No builder should be out there crawling and re-verifying UCP hosts by hand in 2026. Query the index. Understand the landscape. Build against real merchant capability data from day one.

The smartphone app as the unit of distribution is on its way out, and the agent will become the surface through which people meet the digital world. When that's true, the question stops being which app do I open and becomes what do I want, and who do I trust to go and get it. In that world, a verified map of where agents can dock is as foundational as DNS — the unglamorous, low-level plumbing that everything else silently depends on. We are building that map, and we'd rather build it in the open.

The Interesting Part

The standard is here. The language is, for all intents, settled. What remains is the harder and far more interesting work - teaching agents to act across time, and handing them a verified map of where they're actually allowed to go.

That's the layer we've built, and we think it's the one that makes the rest of the stack work. You can request access to the SIS portal today. If you're building the agent layer, come and build on it - and let's go and find out what people will delegate once they finally trust the thing holding the keys.