AI Engineer World's Fair 2025

Machines of Buying & Selling Grace

Loading slides…

Read the talk

Machines of Buying & Selling Grace

AI commerce changes who participates in a store and how they interact, demanding more than automated checkout: explicit intent, reliable product access, negotiation, and portable interfaces.

From a talk by Adam Behrens

What is a store?

What makes a store a store? Start with a shop where the merchandise sits behind the counter. A customer tells a clerk what they want; the clerk retrieves it from the back. Conversation is the interface to inventory. Adam Behrens, a philosopher turned engineer, opens with this example to make his recurring questions concrete: what is a thing, and why does it exist?

Black-and-white photograph of a clerk behind a wooden counter, surrounded by shelves of packaged goods.Open full source frame
A store with merchandise behind the counter.

Information systems enabled larger stores, and merchandise moved out front for customers to browse. Behrens associates this transition with the 1950s and 1960s, naming Walmart and Costco, although Costco’s history places Price Club in 1976 and the first Costco warehouse in 1983. The architectural change matters more than that compressed chronology: customers could inspect inventory themselves. The internet then combined merchandise scale with worldwide distribution, making browsing available around the clock.

That browsing model remains substantial. Behrens reports almost 500 million Walmart online shoppers and 170 million Home Depot online shoppers in the preceding month. The figures lack a specified geography, measurement source, or distinction between visits and unique shoppers. Scale also brought uniformity: his comparison of Adidas, Reebok, and Brooks storefronts shows how interchangeable online shopping can feel.

A store is both a location and a protocol for transactions. Merchants want to sell, buyers want to buy, and a system facilitates their interaction. Shelves, counters, and websites are implementations of that relationship, rather than its defining requirements.

0:000:22
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:00 · section reference included

From browsing to agent interactions

If ecommerce digitized merchandise and distribution, AI can digitize the participants and their interactions. Static websites become merchant agents; consumers gain agents that act for them; payment infrastructure expands into intent infrastructure. The transaction remains the goal. At New Generation, Behrens frames the design problem across three connected layers: human and agent customers, dynamic generative interfaces, and infrastructure capable of supporting those interfaces.

Two routes could connect those participants. Consider someone using ChatGPT to find a television for gaming. In the website route, the consumer’s agent visits a merchant surface that can accept a richer expression of intent than a keyword search. That surface selects relevant products from the catalog, combines them with brand guidelines, and returns content into the chat. When the customer decides to buy, the agent goes back to the website and completes checkout.

The programmatic route starts with the same request but substitutes an API or Model Context Protocol (MCP) server for the website visit. In Behrens’s proposed architecture, the endpoint reasons over the request and generates rich UI elements for the chat client. Purchasing becomes another API call.

StepWebsite routeProgrammatic route
Express intentAgent visits a merchant websiteAgent calls an API or MCP server
Present productsWebsite returns tailored contentEndpoint returns generated UI elements
PurchaseAgent completes website checkoutAgent calls a purchase endpoint

Both routes require a merchant to do more than publish a static catalog. The merchant must interpret a request and return something useful to the requesting interface.

2:142:21
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

2:14 · section reference included

When software clicks Buy

Work backward from a successful transaction. The desired outcome is a satisfied customer who keeps the purchase, not merely a recorded conversion. In software, clicking Buy creates a payment intent, which moves through checkout states until payment succeeds and money moves. Replacing the human click with software introduces an immediate problem: the payment flow may not accept an agent as the actor. Behrens describes Operator as mostly erroring on ecommerce sites at the time of the talk, without presenting a measured evaluation.

He distinguishes two ways to bridge that gap:

  • Virtual cards: The customer checks out with the software provider. The provider creates a virtual card and uses it to purchase from the merchant on the customer’s behalf. Behrens calls this a Stripe SDK approach; his companion article identifies the example more specifically as an Order Intents demonstration.
  • Delegated authentication: The agent uses the customer’s existing card relationship to complete checkout. Visa’s announced mechanism uses consumer-authorized tokenized credentials and spending conditions, rather than requiring the agent to receive raw card details.

These approaches make payment execution possible. They do not yet tell the agent what to buy, which merchant to choose, or whose preferences should govern the decision.

Slide listing “Solution 1: virtual cards” and “Solution 2: delegated authentication.”Open full source frame
Two proposed solutions: virtual cards and delegated authentication.
4:484:54
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

4:48 · section reference included

From a request to an inventory item

The next layer is buying intent. Conventional ecommerce infers it from keywords, clicks, and site metrics. A conversation contains a more explicit account of what someone wants, and a consumer agent can potentially answer direct questions about its task. That changes the input to product discovery, but it does not eliminate the need to resolve ambiguity.

A request for running shoes is not a SKU, the inventory identifier needed to purchase a particular product. The system still has to translate a broad category into a specific item. Behrens describes the contemporary workaround as forcing the specificity up front: give the agent a product-detail-page URL, then ask it to buy that product. This avoids the selection problem by making the customer solve it first.

Among merchants New Generation works with, Behrens reports higher conversion, dollar value, and lifetime value for customers arriving from AI channels. He supplies no numerical uplift, cohort definition, or observation period. That observation leads him to a speculative fulfillment tradeoff: if these customers are sufficiently valuable and returns are easy, merchants might tolerate some incorrect-item deliveries. This is an economic proposal about the cost of mistakes, not a solution to identifying the right SKU.

6:156:23
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

6:15 · section reference included

Offers need live product access

On the seller side, a product detail page is a narrow expression of intent: a price, a Buy button, and perhaps a discount or bundle. A merchant agent could express a much more dynamic offer, combining real-time availability, contextual pricing and discounts, and bundles spanning multiple merchants. But richer offers make the underlying data requirement harder. Once a buyer wants an item, the system must locate a store that actually has it.

Behrens compares three approaches to obtaining that data:

ApproachAccess patternMain constraint
Existing product feedsChat products integrate with merchants individuallyMany separate merchant relationships
Website scrapingRepeatedly extract product data from sitesRepeated work and added bot traffic
Proposed unified APIAggregate access across merchantsRequires shared merchant integration infrastructure

His team has tried scraping and considers its repeated work and website load undesirable. Their proposed alternative resembles Plaid’s aggregation model, but connects merchants rather than financial institutions. The goal is a common way to access product data across merchants, not another independent scrape for every requesting agent.

7:497:58
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

7:49 · section reference included

Preferences make this a market-design problem

Product access still leaves buyer and seller preferences poorly represented. Today, customer context is scattered across accounts and transaction histories, with limited LLM memory. Businesses disclose little strategic intent beyond periodic reporting. Behrens’s proposed alternative is two-sided: richer customer context extending beyond purchases, alongside explicit merchant goals such as inventory priorities, desired customer groups, or responses to tariffs.

More context does not automatically create agreement. Preferences are complex, change over time, and conflict across participants. Each side may also benefit from misrepresenting what it wants. The problem is market design as well as information retrieval. Naively trusting incoming information leaves an agent exposed to manipulation, including prompt injection. Drawing on his work on trading and market systems at Bridgewater, Behrens points to third-party institutions and market makers as an analogy for managing differences between buyers and sellers.

Even this infrastructure is not yet fully agentic. The remaining frontier is intelligence at each layer: consumer and merchant agents must reason over intents and preferences, then negotiate them. Shared infrastructure must move beyond matching participants toward coordinating them, while generating the interfaces those participants need in real time. Data access supplies the inputs; reasoning and coordination determine what happens next.

9:319:42
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

9:31 · section reference included

An enterprise bridge to agentic commerce

Large enterprises are often treated as too slow to adapt, but their longevity can also indicate experience surviving major technological shifts. Samsung provides Behrens’s example: a trading business that moved into televisions and eventually became a technology giant. His historical sketch overstates its age and describes its origins as fish trading; Samsung’s official chronology instead dates its founding as a grocery trading store to 1938 and supports the move into televisions in the 1970s. The relevant continuity is its capacity to change businesses and interfaces.

The next adaptation concerns how Samsung’s brand appears when customers interact through AI. A merchant needs a bridge from its existing ecommerce systems to agent interactions, while retaining a recognizable way to present its products.

A phone labeled “Galaxy AI” surrounded by colorful objects on a blue background.Open full source frame
Galaxy AI imagery illustrates Samsung’s present-day AI branding.
11:5012:01
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

11:50 · section reference included

Normalize the catalog, then attach the brand

The implementation sequence begins with a shared product interface:

  1. Expose an API and MCP server that chat clients can use.
  2. Normalize the underlying product systems behind consistent endpoints.

Behrens says Samsung has 10 verticals, each with its own inventory representation. The integration work is to absorb those differences behind a cohesive API, so clients do not need to understand each source system.

A small TypeScript example makes that normalization boundary concrete. Two illustrative inventory formats become the same product shape; neither the client nor the next stage needs to inspect the original field names.

typescript

type InventoryRecord =
  | { source: "tv"; modelCode: string; unitsAvailable: number }
  | { source: "appliance"; itemId: string; stockCount: number };

type Product = {
  sku: string;
  availableQuantity: number;
};

function normalize(record: InventoryRecord): Product {
  switch (record.source) {
    case "tv":
      return {
        sku: record.modelCode,
        availableQuantity: record.unitsAvailable,
      };
    case "appliance":
      return {
        sku: record.itemId,
        availableQuantity: record.stockCount,
      };
  }
}

const inventory: InventoryRecord[] = [
  { source: "tv", modelCode: "TV-01", unitsAvailable: 4 },
  { source: "appliance", itemId: "FRIDGE-02", stockCount: 0 },
];

const products: Product[] = inventory.map(normalize);

The architecture shown in the recording is broader: structured and unstructured data pass through indexing stages into search indexes, a backend, and an API serving different clients. Normalization is the interface boundary within that larger system.

Architecture diagram showing structured and unstructured data, embedding and indexing stages, search indexes, a backend, an API, and frontend, chat, and MCP/API clients.Open full source frame
Structured and unstructured data feed search indexes connected to a backend and API.

Next, connect product data to other company data, beginning with the brand and design system. This is an initial representation of seller intent: not just which products exist, but how the merchant wants them presented. The resulting interface can move beyond a generic carousel toward content shaped by the merchant’s own design language.

12:4912:59
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

12:49 · section reference included

Create a surface where agents can transact

The third step is an AI subdomain: a contained surface for experimenting with generative interfaces that ingest both product and brand data. Conversation here can include images, product representations, and other content, rather than only text and bullet lists. The interface becomes a place to test how a merchant responds to a customer’s expressed needs.

The final step is to enable payment flows on that surface for agent traffic. This reverses the usual posture of a retail website, where bots are commonly treated as something to block. Behrens describes AI-chat traffic as small but higher intent, deeper in the purchase funnel, and better converting. That is why he urges merchants to provide an agent-accessible surface, rather than treating all automated visitors alike.

The prepared talk ends where it began: ask what the store is and how it works before deciding what to build. Stores need not disappear. In this account, they evolve toward their earlier conversational form, with software taking on some of the clerk’s work of interpreting a request and connecting it to merchandise.

13:5114:05
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

13:51 · section reference included

When the website travels into chat

An audience member working in banking invokes Gartner’s When Machines Become Customers and asks when this becomes an everyday experience, including the question of break-even. Behrens offers a transitional architecture rather than a date or economic threshold. Shopping is already entering chat products, he says, but the complete journey is not yet contained there: users still follow links out to merchant websites.

He does not expect those external surfaces to disappear immediately. Brands want a surface they own, so the practical starting point is a web-like experience whose data and components are transportable. When a chat application can host more of the purchase journey, those components can move into it without rebuilding the merchant experience. Instead of always sending the customer to the website, the website’s functionality can appear in many different places.

15:4415:52
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

15:44 · section reference included

Which payment rails will agents use?

A further question separates the ability to use cards from whether cards are the right long-term mechanism. Behrens sees three possibilities:

  • Stablecoins and crypto: A conceptual fit for AI-native payments because an agent can operate within a wallet.
  • Existing consumer credit cards: The likely practical bridge because customers already use them.
  • A persistent agent card: An agent holds its own ongoing card, which the user tops up.

The distinction is between a payment mechanism that fits the agent’s operating environment and one that fits existing consumer behavior. Behrens treats these as possible paths, not a settled choice of rail.

17:1917:24
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

17:19 · section reference included

Merchant control inside a shopping super app

The final questions turn from infrastructure to platform power. Taking super apps in China and Brazil as a comparison, the questioner asks whether Claude and ChatGPT will try to host the entire shopping experience. Behrens believes that is their goal, which makes merchant control a central concern. He sees a possible alignment: model providers want to get users to the right outcome, and merchants can supply the products and information that make that outcome possible. This is his interpretation of their incentives, rather than a guarantee that the platform and merchant will always agree.

Asked about revenue sharing, Behrens predicts something closer to affiliate revenue than advertising. He also proposes another possibility: when a merchant supplies high-quality data that can be attributed to a good answer, a model provider might return some value to that merchant. No commercial arrangement is announced. The closing possibility is that a merchant’s role extends beyond fulfilling an order to supplying the information that helps an agent choose it.

18:0518:11
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

18:05 · section reference included

Resources

From the talk

  • Adam Behrens explains how merchant agents expose inventory, offers and brand context to consumer agents and payment systems.

Updates since the talk

Transcript download
Full transcript

Loading transcript…