You've got a dozen abandoned carts scattered across the web right now — maybe that set of gaskets you priced out last Tuesday, maybe the office chair you were comparing in three different tabs. All of them are trapped. Browser cookies, server-side sessions, tied to one vendor, one device, one moment in time. And if you wanted to hand any of them to a colleague, or compare the same basket across three suppliers, or turn one into a purchase order without retyping everything... you can't.
Daniel's been thinking about this, and yesterday he started drafting something called dot cart — an open, vendor-neutral file format for ecommerce shopping carts. It's a JSON file, UTF-8, self-describing, tax-aware, with a JSON Schema for validation and an extensions mechanism so vendor-specific data doesn't get lost. It carries the merchant, the buyer, line items with SKU and MPN and GTIN, prices before and after VAT, price breaks, shipping with Incoterms, payment terms, totals. Four operations: export, import, compare, and generate documents from a cart.
The deliberate design choice is that dot cart is a capture format, not a business document. For the actual documents, it maps onto what already exists: OASIS UBL two point one Order and RequestForQuotation, UN CEFACT ORDERS and REQOTE, PEPPOL BIS on top of UBL, ICC Incoterms twenty twenty slotting into UBL's DeliveryTerms. An RFQ omits prices and emphasizes identifiers and quantities and delivery terms and an expiry. A PO makes the prices a commitment.
He's asking two things. First: what use cases does a standard like this actually unlock once carts stop being trapped in browser sessions? Beyond the obvious — save and share, price-watch a basket, compare suppliers on an identical BOM, generate POs and RFQs. What's he not seeing? Second, and this is the bigger one: automated B2B procurement is not new. EDI and its descendants have been doing programmatic quoting and automated negotiation between large enterprises for decades. What did those systems get right, what did they never solve, and why did that machinery stay locked inside enterprise-to-enterprise relationships? Can a lightweight capture format bolted onto the agentic AI era do something the heavyweight standards couldn't — or is this rediscovering a solved problem?
He also said to be critical. It's a version zero point one draft and he'd rather hear where it's wrong than be told it's a good idea. So let's start with what dot cart actually is — and the problem it's trying to solve.
The problem is genuinely weird when you stop to look at it. Shopping carts are the working documents of procurement — they're where you assemble a bill of materials, collect quotes, compare options — and they're treated by the web as temporary scratchpads. You wouldn't accept a word processor that couldn't save a file. But we've all internalized that carts just... vanish. Clear your cookies, switch devices, close a tab, and it's gone. For someone buying a single t-shirt, that's annoying. For someone assembling a two-hundred-line-item BOM for a manufacturing run, it's a genuine business problem. They're taking screenshots. They're copy-pasting SKUs into spreadsheets. They're hoping the session doesn't time out before they finish.
Screenshots as a procurement workflow. That's the state of the art.
And it gets worse when you think about what happens next. Say you've built a cart on Supplier A's site. You want to see what Supplier B charges for the same basket. Today you open a second tab and retype everything — or you pay someone to retype everything. Then you do it again for Supplier C. Then you manually build a spreadsheet to compare. Then, if you actually want to buy, you type the winning basket into a purchase order. Four or five manual data-entry steps, each one an opportunity for error, and the original cart — the thing you spent an hour building — is still trapped in Supplier A's session.
So what's dot cart actually look like under the hood?
It's a JSON file — deliberately simple, deliberately readable. The spec is about four hundred fifty lines right now. It defines a cart object with merchant information, buyer information — including VAT ID and issuing authority for the B2B case — an array of line items, each with SKU, MPN, GTIN identifiers, quantities, unit prices before and after VAT, any applicable price breaks, shipping options with Incoterms, payment terms, and a totals block. There's a JSON Schema for validation — draft twenty twenty dash twelve — and an extensions mechanism so if a vendor has custom fields, loyalty points, whatever, those don't get lost. They live in extension slots while the core fields stay comparable.
The extension slots are smart. That's the thing that usually kills interoperability — either you lose vendor-specific data, or you bloat the core schema trying to accommodate everyone.
And the design profiles are interesting too. There's a Core profile with the essential fields, and an Expanded profile that adds procurement-specific fields — the buyer party details, the price breaks, the Incoterms, the payment terms. So a consumer cart can be lightweight, and a B2B cart can carry the full procurement payload, but they're the same format. A tool that reads dot cart can handle either.
And the four operations — export, import, compare, generate documents. The document generation is where the standards mapping comes in. Instead of inventing a new PO format, dot cart transforms into UBL two point one Order. Instead of inventing a new RFQ format, it transforms into UBL RequestForQuotation. The mapping is field-level.
Which is the right call. UBL two point one is an ISO standard — ISO slash IEC nineteen eight four five colon twenty fifteen — with over two thousand data components covering the full procurement lifecycle. It's the basis for PEPPOL BIS, which is mandated for public procurement across much of the EU. You don't compete with that. You sit on top of it.
And the Incoterms piece — the ICC standardizes Incoterms and publishes model sale contracts, but they don't publish an electronic PO or RFQ document schema. So UBL and UN CEFACT are the right baselines, and Incoterms slot into UBL's DeliveryTerms element. It means dot cart isn't duplicating anything at the document layer — it's capturing the cart state, and then the document generation is a transform into battle-tested standards.
The spec is explicitly a capture format. It says so right up front.
Okay, so we've got the format. But what does it actually unlock? Daniel asked us to think beyond the obvious use cases.
The obvious ones first, just to put them on the table. Save and share — you export a dot cart file, email it to a colleague, they import it and keep working. Price-watch — you export the same cart weekly and diff the prices. Compare suppliers — you send the same dot cart to three vendors, get three priced dot carts back, compare line by line. Generate POs and RFQs — the document transforms we just talked about.
Those are table stakes. What else?
The one I keep coming back to is cart-as-spec. A dot cart file becomes a machine-readable bill of materials that isn't tied to any vendor's system. You maintain a dot cart for your quarterly BOM — two hundred line items, all the MPNs and GTINs and quantities. That file is your specification. When you need quotes, you don't send a spreadsheet and hope someone interprets it correctly. You send the dot cart. An AI agent — or a human — imports it into each supplier's system and returns a priced dot cart. The RFQ stops being a document you create and becomes a process you run.
So the cart file becomes the canonical representation of what you need, and the quoting process becomes mechanical.
And that leads to the second one: temporal comparison. Save a dot cart snapshot every Monday for a year. Now you've got fifty-two data points on what that basket costs. When a supplier claims prices haven't changed, you produce a diff showing a seven percent increase on a specific SKU in March. When you're negotiating a contract renewal, you've got a year of pricing history, not your memory of what things cost.
That's the kind of thing enterprises do internally with their procurement systems. A small manufacturer with a WooCommerce store and a spreadsheet doesn't have that capability.
The third one is audit trail. Every dot cart export is a timestamped record of what was quoted, when, by whom. For compliance, for dispute resolution, for cost accounting — you've got a paper trail that isn't scattered across browser histories and email threads. If a supplier ships the wrong SKU and claims that's what you ordered, you've got the dot cart you exported on the day you placed the order.
And the fourth one — this is where the agentic AI piece really lands — is agent interoperability. A browser agent or MCP server can navigate an ecommerce site and read a cart page. That capability got significantly better in twenty twenty-five and twenty twenty-six. But what they can't do is output a structured, standardized cart representation that another system can consume. The agent reads the cart, does whatever it's supposed to do, and then... what? The output is trapped in the agent's memory or dumped into a chat message.
Dot cart gives agents a universal output channel. The agent navigates Supplier A's site, builds the cart, exports a dot cart. Then it navigates Supplier B's site, imports that same dot cart, populates the cart, and exports a priced version. Then it diffs the two. None of that requires Supplier A and Supplier B to have APIs. The agent is doing the work at the browser layer, and dot cart is the serialization format that connects the steps.
It's analogous to what HTML did for browsers versus what JSON APIs did for services. HTML gave browsers a standard to render. JSON APIs gave services a standard to integrate. Dot cart gives agents a standard to serialize shopping state.
And that's the unlock that didn't exist before. The reason cart portability has been attempted and failed repeatedly — going back to the Open Trading Protocol and various consumer-side efforts — is that there was no distribution mechanism. You needed ecommerce platforms to adopt the format natively, and they had no incentive to do that. Cart lock-in is a feature for them, not a bug. But if agents can read and write dot cart at the browser layer, the platform doesn't need to adopt anything. The agent handles the translation.
Wait. Hold on. That's the thesis, but let's kick the tires on it. If an agent can navigate a site and read a cart, why does it need a standard format at all? Can't it just... remember what was in the cart and type it into the next site?
It can, and that's what agents do today. But without a standard format, you lose structure. The agent remembers "three boxes of M6 hex bolts" but not the MPN, not the price break at quantity fifty, not the Incoterms on the shipping option, not the VAT treatment. You get a lossy transcription. And you can't diff two lossy transcriptions and trust the result. The format matters because it preserves the fields that matter for comparison and compliance.
So the format isn't just for humans to share carts. It's the structured memory for agents.
Yes. And it enables comparison in a way that ad-hoc agent memory can't. The extension mechanism is key here — vendor-specific data that doesn't fit the core schema isn't dropped, it's preserved in extension slots. So when you compare two dot cart files from different vendors, the core fields — SKU, quantity, unit price, VAT — are directly comparable, but you haven't lost the custom shipping option name or the loyalty points calculation from either vendor.
Let me give you a concrete scenario. A procurement officer at a mid-size manufacturer maintains a dot cart for their quarterly BOM — two hundred line items, fasteners and enclosures and electronic components. They've got an AI agent configured with access to three supplier portals. The agent takes the dot cart, navigates to Supplier A, imports it, waits for the system to calculate pricing and availability, exports a priced dot cart. Repeats for B and C. Now the procurement officer has three dot cart files. They run a diff and see that Supplier A is twelve percent cheaper on fasteners but eighteen percent more expensive on enclosures. They split the order — fasteners from A, enclosures from B — and generate two POs from the same original cart.
That's the workflow. And the POs are UBL two point one Order documents, so they drop straight into the suppliers' existing order processing systems — assuming those suppliers have EDI or PEPPOL capabilities. The dot cart piece is the capture and comparison layer that sits before the business document layer.
Which brings us to the second question — the one Daniel said he keeps circling. How does this relate to the existing B2B procurement infrastructure?
So let's talk about what EDI and its descendants actually got right, because it's important not to caricature them as obsolete. EDI — EDIFACT, X12, and the whole family — solved the problem of structured, machine-readable business documents at scale. Purchase orders, invoices, shipment notices, payment remittances. These standards enabled automated order-to-cash cycles between large enterprises. They process trillions of dollars in transactions annually. They are deeply embedded in supply chains — automotive, retail, healthcare, aerospace. If you're a Tier Two supplier to Boeing, you're using EDI.
And UBL and PEPPOL are the modern descendants.
UBL two point one is an XML-based standard with over two thousand data components covering the full procurement lifecycle. It's an ISO standard. PEPPOL — Pan-European Public Procurement Online — launched in two thousand eight, built on top of UBL, and created something important: a network effect. A single PEPPOL connection gives you access to thousands of trading partners. As of twenty twenty-five, PEPPOL has approximately five hundred thousand connected organizations. It's mandated for public procurement across EU member states.
Five hundred thousand sounds impressive until you remember there are millions of ecommerce storefronts globally. Shopify alone powers about ten percent of global ecommerce storefronts.
And that's the first thing these systems never solved: accessibility. Classic EDI implementation requires a Value-Added Network subscription — typically a hundred to five hundred dollars a month, plus per-transaction fees. You need trading partner agreements, technical onboarding, often dedicated staff. For a small supplier selling through a WooCommerce store, EDI is a non-starter. PEPPOL reduced the barrier — you need an access point provider, which costs roughly two hundred to five hundred euros a year — but you still need to comply with BIS profiles, and you still need your ERP system to output PEPPOL-compliant UBL. It's lower than classic EDI, but it's not zero.
And the second thing they never solved — and this is the one that matters for dot cart — is the capture problem. EDI and UBL start with the business document. The purchase order, the invoice. They assume the buyer already knows what they want and from whom. There's no standard way to capture a cart in progress — a tentative, pre-decisional collection of items that hasn't been committed to a PO.
That's the gap. The shopping-around phase — assembling a BOM, collecting quotes, comparing suppliers — happens before the business document layer. EDI doesn't handle it. UBL doesn't handle it. PEPPOL doesn't handle it. Those systems kick in once you've made a decision and you're ready to transact. The phase before that is spreadsheets and screenshots.
And the third thing: the consumer-B2B gap. These standards were designed for enterprise-to-enterprise relationships with established trading partner agreements. They assume a level of trust and technical capability that doesn't exist in open-web commerce. If you find a new supplier through a Google search and they have a Shopify store, there's no EDI connection to establish. You put things in a cart and check out with a credit card.
Which is why the machinery stayed locked inside enterprise relationships. The cost and complexity of EDI created a moat. Large enterprises invested in it because their transaction volumes justified it. Small suppliers were forced to comply to do business with those big buyers. But there was never an incentive to make EDI accessible to the broader web. It was a competitive advantage for the enterprises that could afford it. PEPPOL made progress on accessibility, but it remains largely a European public-sector phenomenon. It hasn't reached the millions of small and medium ecommerce storefronts.
Where does dot cart fit into this picture? Is it competing with EDI and UBL, or is it doing something adjacent?
It's adjacent, and I think that's the right call. Dot cart solves the capture problem — the pre-decisional, shopping-around phase. EDI and UBL solve the transaction problem — the committed business document exchange. The two are complementary. A dot cart becomes a UBL Order when you're ready to buy. A dot cart becomes a UBL RequestForQuotation when you're ready to solicit quotes. The document generation is a transform, not a replacement.
But here's where I want to push back, because Daniel asked us to be critical. The complementary argument is clean on paper. In practice, dot cart needs adoption to be useful. And the entities that would need to adopt it — ecommerce platforms, shopping cart software, procurement systems — are the same entities that have had decades to adopt any cart portability standard and haven't.
That's the strongest objection, and I don't think there's a clean answer to it. Merchants have no incentive to make carts portable. Cart abandonment is a problem they try to reduce, not enable. If a customer builds a cart on your site and exports it to compare with a competitor, you might lose the sale. The platform's interest and the buyer's interest are directly opposed here.
The adoption path can't be "please, ecommerce platforms, voluntarily make your carts exportable." That's been tried. It failed.
Right. Which is why the agentic AI angle matters. If adoption happens through agent tooling rather than platform buy-in, the platforms don't need to do anything. The agent reads the cart page — which is just HTML, already rendered — and writes a dot cart file. The platform doesn't even know it's happening. The distribution mechanism isn't platform adoption. It's agent capability.
That's the thesis. But let me poke at it. If an agent can read a cart page and extract structured data from it, why does it need dot cart? Why not just output the structured data in whatever format the next system expects?
Because then you've got N agents outputting N different formats, and none of them interoperate. The value of a standard isn't that any individual agent couldn't solve the problem ad hoc — it's that a standard means any agent can hand off to any other system without custom integration work. An MCP server from Anthropic outputs dot cart. An open-source agent from LangChain outputs dot cart. A procurement SaaS imports dot cart. They don't need to know about each other. They just need to know the format.
That's the JSON API argument again. And it's a real argument. But it depends on dot cart becoming the default. What happens when OpenAI or Anthropic or Google decides to define their own cart format? They've all got ecommerce ambitions. They've all got agent frameworks. If OpenAI ships an MCP server that outputs "OpenAI Cart Format" and it works with their ecosystem, why would anyone adopt dot cart?
That's the existential risk. A proprietary format from a major AI platform would have instant distribution — built into their agent framework, supported by their tools, documented in their docs. Dot cart would need to compete on openness and vendor neutrality, which are real advantages but not decisive ones. The counterargument is that procurement professionals don't want their cart data locked into a single AI vendor's format any more than they want it locked into a single supplier's website. But whether that preference translates into adoption... I don't know.
There's another risk. Scope creep. The spec is explicitly a capture format right now — version zero point one, four hundred fifty lines, deliberately simple. But the pressure to add features will be intense. Someone will want dot cart to handle partial shipments. Someone else will want it to handle backorders. Someone else will want it to handle multi-currency baskets. If dot cart tries to become a full business document standard instead of staying a capture format, it loses its differentiation from UBL. It becomes yet another procurement standard that's too complex for anyone to adopt.
UBL already has two thousand data components. You're not going to out-UBL UBL. The whole value proposition is simplicity — a format simple enough that an AI agent can reliably generate it, a developer can implement it in a day, and a procurement professional can read it with their own eyes. The moment you add partial shipment logic, you've lost all three.
Let me surface another concern about the comparison operation. The spec says you can import a dot cart into another vendor's cart for comparison. But that assumes the vendors sell the same things — same SKUs, same MPNs. In practice, Supplier A and Supplier B might sell functionally equivalent products with completely different identifiers. How does the comparison work across different catalogs?
That's a real limitation, and I don't think dot cart solves it — nor should it try to. Catalog normalization is a separate hard problem. GTIN and MPN help when manufacturers use them consistently, but a lot of industrial supply doesn't. The comparison operation works best when you're comparing the same branded products across distributors — the same SKU from DigiKey versus Mouser versus Farnell. For generic equivalents, you still need a human or an agent to do the mapping. Dot cart gives you the structured data to compare; it doesn't solve the semantic equivalence problem.
Which is fine — no format can solve that. But it's worth naming as a limit. The comparison use case is powerful for branded goods and less powerful for commodities where identifiers aren't consistent.
That's where the temporal comparison use case is actually stronger. Comparing the same cart from the same supplier over time — that works perfectly, because the identifiers are consistent by definition. You're tracking price changes on known SKUs.
Let's talk about the existing analogue that comes closest to what dot cart does: PunchOut catalogs — OCI PunchOut and cXML PunchOut.
PunchOut is the closest existing thing to a portable cart. The way it works: a buyer is in their procurement system — Coupa, SAP Ariba, whatever. They "punch out" to a supplier's catalog, build a cart, and then "punch in" back to the procurement system, bringing the cart with them. The cart is transferred as a structured cXML or OCI message. It then flows into the procurement system's approval workflow and eventually becomes a PO.
It's a portable cart between a procurement system and a supplier's catalog. That sounds like what dot cart does.
It does, but with two critical differences. First, PunchOut requires a pre-existing relationship between the buyer's procurement system and the supplier's catalog. It's not ad hoc — it's a configured integration. You can't PunchOut to a random Shopify store you found through Google. Second, PunchOut is procurement-system-to-supplier, not cart-to-cart. The cart lives inside the PunchOut session; it's not a file you can save, share, diff, or version-control. It's portable in the sense that it moves between two systems, but it's not portable in the sense that you can hand it to a colleague or compare it across three suppliers.
PunchOut solves the integration problem for established buyer-supplier relationships within a procurement platform. Dot cart is trying to solve the portability problem for any cart, anywhere, without pre-existing relationships.
Right. And that's a bigger, messier problem. But it's also the one that agentic AI makes newly tractable. A PunchOut integration requires both sides to implement the protocol. A dot cart workflow requires one side — the agent — to implement the format. The supplier doesn't need to do anything.
Unless you want the import operation to work cleanly. If a supplier's site has a "cart import" button that accepts dot cart files, that's a much better experience than an agent manually typing two hundred line items into a web form.
Agent-mediated import is the fallback, not the ideal. The ideal is native support — a WooCommerce plugin that reads dot cart, a Shopify app that exports dot cart. But the fallback is what makes the adoption path plausible. You don't need everyone to adopt the format before it's useful. You need enough agent capability to bridge the gaps.
Where does that leave us? Let me give you the honest assessment — what this means if you're building tools in this space, and what the real risks are.
For listeners building procurement tools or AI agents: dot cart is worth watching because it fills a genuine gap. The absence of a standard capture format for pre-decisional shopping carts is real, and nobody else is seriously addressing it. If you're building an MCP server or browser agent for ecommerce, consider supporting dot cart as an output format. It's simple enough to implement in a day — the spec is four hundred fifty lines, the JSON Schema is published, there's a worked example. You can be dot cart-compatible before lunch.
For listeners in enterprise procurement: don't dismiss this as just another format. The agentic AI layer changes the adoption calculus in a way that didn't exist when the Open Trading Protocol tried to do something similar in the late nineties. A format that an AI agent can read and write without human intervention has a distribution advantage that EDI never had. The question isn't whether dot cart is technically superior to UBL — it's not, and it's not trying to be. The question is whether it becomes the default serialization format for agent-mediated shopping, or whether something proprietary from a major AI platform displaces it.
The honest bottom line: this is a version zero point one draft with a plausible thesis. The biggest risk isn't technical — the spec is clean, the design choices are sound, the standards mapping is well-researched. The biggest risk is adoption. The format needs a champion. A Shopify plugin. An OpenAI MCP server integration. A procurement SaaS that imports dot cart natively. Without at least one of those, it's a well-designed spec with no users.
The second risk is scope creep. If dot cart tries to become a full business document standard — if it adds partial shipments, backorders, multi-currency, approval workflows — it loses its differentiation from UBL and becomes too complex for the agent-mediated use case that's its reason for existing. The discipline to stay a capture format is going to be harder than the initial design.
The third risk is the one we already named: a proprietary format from a major AI platform with instant distribution. Dot cart's defense against that is openness, vendor neutrality, and the fact that it maps onto existing standards rather than reinventing them. Whether that's enough... we'll see.
The thing I keep coming back to is that the comparison use case — diffing the same basket across suppliers — is valuable in a way that might create pull. If a procurement professional can save ten hours a quarter by maintaining a dot cart BOM and running automated comparisons, they'll want their tools to support it. That's bottom-up adoption pressure. It's not platform-driven, but it's real.
The temporal comparison use case — price volatility tracking on a saved basket — is something that doesn't exist today outside of enterprise procurement suites. Giving that capability to anyone with a text editor and a diff tool is a genuine democratization of procurement intelligence.
Which brings us to the open questions — the ones that will determine whether dot cart becomes a footnote or a foundation. Will ecommerce platforms adopt dot cart as an export format, or will they see it as a threat to cart lock-in? Can the format stay simple enough to be useful while covering enough edge cases to be universal? And what happens when a major AI platform decides to define their own cart format?
If dot cart gains traction, it could change the economics of comparison shopping — making it as easy to compare a basket of goods as it is to compare a single product. It could also create new business models: cart-as-a-service, where procurement agents maintain shared cart libraries for common BOMs. A manufacturer publishes a dot cart for a standard set of maintenance parts, and a dozen buyers use it as their starting point.
I'll go on the record: within a year, at least one major AI agent framework will ship with dot cart support — or something substantially similar — as a built-in output format. The need is too obvious and the format is too simple for it not to happen. The question is whether it's this spec or a clone.
I'll go on the record too: the adoption will come from the procurement SaaS side first, not the ecommerce platform side. A Coupa or a SAP Ariba will add dot cart import before a Shopify adds dot cart export. The buyers have the incentive; the sellers don't.
If you've got a take on dot cart — whether you think it's the missing piece or a solution in search of a problem — we want to hear it. The repo is linked in the show notes. And if you've got your own weird prompt, send it in.
Thanks to Hilbert Flumingtop for producing.
This has been My Weird Prompts. We'll be back soon.
