When Shopping Becomes a Conversation, What Must an AI Remember?

Imagine shopping for a dining table after moving into a new apartment.

The table needs to seat six, fit through a narrow doorway, and arrive before your parents visit next month. Your budget is $900, including delivery. You prefer solid wood, but you would consider another material if it holds up well. You cannot take a weekday off to wait for a truck.

These are ordinary shopping concerns. They rarely fit neatly into a search box.

A shopping agent for buyers promises to handle them together: compare tables, check dimensions, investigate delivery, explain compromises, and help complete the purchase.

Now consider the seller. A furniture retailer notices that dining-table sales have fallen despite steady website traffic. Its shopping agent for sellers investigates inventory, delivery charges, advertising, returns, and customer questions. It may discover that the problem is not the tables themselves, but a delivery surcharge customers encounter at checkout.

This is the broader ambition of agentic commerce: AI systems that carry out parts of a commercial task, from discovering products to supporting transactions and store operations. Companies are building infrastructure for that shift. Shopify and Google introduced the Universal Commerce Protocol to connect agents with merchants, while OpenAI’s Agentic Commerce Protocol provides a framework for shopping and checkout integrations. Shopify, OpenAI

These developments suggest a future in which more shopping happens through conversation. But connecting an agent to a catalog or checkout system solves only part of the problem.

The buyer’s agent must carry a household’s changing requirements through a long search. The seller’s agent must carry business constraints and evidence through an investigation. Both must distinguish what they know, what remains uncertain, and what they are allowed to do.

That raises a less visible question beneath the excitement about AI shopping: what information reaches the model when it makes its next decision?

1. What does a shopping agent actually know?

Context assembly and the context window

After comparing a dozen tables, the buyer’s agent recommends one that costs $849. It seats six and looks right for the apartment.

Only later does the buyer discover a $129 delivery charge—and a delivery window that requires someone to be home on Tuesday.

It is tempting to say the agent forgot the instructions. But the application may have failed to include them in the request that produced the recommendation.

A model does not automatically see everything its application stores. The application may hold the full conversation, saved preferences, product listings, delivery policies, and earlier calculations. Each model call receives a selected portion of that material.

That selection process is context assembly. The context window is the model’s bounded capacity for the information supplied to a call and the response it produces.

For the buyer’s shopping agent, the next request might need the total budget, doorway measurements, delivery restrictions, and three shortlisted tables. For the seller’s shopping agent, it might need the sales question, recent findings, relevant records, and permission to inspect—but not change—the store.

The application assembles this view before the model responds. In that sense, context is a built artifact: a package whose contents reflect deliberate choices, or the absence of them.

If an important requirement is missing from the package, storing it elsewhere in the application does not make it available to that decision.

2. Why can more information make the task harder?

Token budgeting and relevance filtering

The buyer’s search soon produces a crowded trail: product descriptions, customer reviews, assembly instructions, promotional offers, and conversations about chairs.

The seller’s investigation produces even more: transaction records, advertising reports, inventory snapshots, and support tickets.

Sending everything may sound thorough. It also creates expense, delay, and a growing burden of irrelevant detail.

The buyer’s agent does not need twenty nearly identical reviews praising a table’s appearance when the unresolved question is whether the packaging fits through the doorway. The seller’s agent does not need every support ticket when it is examining how delivery charges affect checkout abandonment.

Relevance filtering selects information that helps the current decision. Token budgeting allocates the available space among instructions, working state, evidence, tool descriptions, and other material, while reserving room for the response.

That budget is also a policy.

The buyer’s $900 total limit deserves protection. The seller’s instruction to recommend changes without applying them deserves protection. Repeated descriptions and reproducible tool results can receive less space.

Authority and retention require separate attention. A rule can govern the task while still being accidentally removed from a later request. Placing it high in an instruction hierarchy does not ensure that the context builder keeps it.

The useful question is: if this information disappears, could the next decision become wrong?

For the dining table, delivery costs and scheduling restrictions pass that test. A discarded color option probably does not.

3. When should the agent learn a new procedure?

Progressive disclosure and skill routing

The buyer now finds a promising table sold by a retailer with an unfamiliar delivery policy. Does “room of choice” include carrying it up two flights of stairs? Is assembly included? Can a delivery appointment be moved?

The agent needs a procedure for checking delivery terms. It does not necessarily need procedures for refunds, warranty claims, or financing at the same moment.

The seller’s agent faces a similar choice. Investigating abandoned carts requires a different method from reconciling refunds or planning a promotion.

Progressive disclosure introduces procedures in layers. The agent first receives a short description of an available skill: what it does and when it applies. When the task calls for it, the full procedure loads. Supporting references and scripts remain available for later retrieval.

Skill routing determines which procedure to select. The model may choose from descriptions, the application may use rules, or the user may request a procedure explicitly.

These are distinct steps: choosing a skill, loading its instructions, and admitting those instructions into the next model request.

Timing matters, too. If the agent requests a delivery procedure during one call, the returned instructions can guide a later call. They cannot change the reasoning of the call already underway.

Progressive disclosure works when it brings the right expertise into the task before a consequential decision.

4. How can the agent use a large catalog or sales report?

Just-in-time retrieval, tool execution, and provenance

The furniture retailer may have thousands of products and months of order records. The buyer may be searching across several stores.

Neither agent benefits from having every row pasted into every request.

With just-in-time retrieval, the application keeps large resources outside the active context and supplies targeted information when needed. A catalog can be filtered by dimensions, price, material, and availability. A sales export can be examined through bounded operations such as filtering, aggregation, and row retrieval.

For the buyer, a tool might calculate the delivered cost of three tables and return each total with its delivery conditions. For the seller, a tool might compare checkout completion across regions with different delivery charges.

The model decides which question to investigate. Tool execution performs the calculation or lookup outside the model and returns the relevant result.

But access alone is insufficient. The result needs provenance: a traceable account of where the evidence came from and how it was produced.

Suppose the seller’s agent sees five complaints about expensive delivery. Those complaints suggest a hypothesis. They do not establish why sales fell across the business.

A stronger investigation would examine the relevant checkout records, account for other plausible explanations, and report the limits of the finding. Similarly, a buyer’s agent should distinguish a delivery estimate from a confirmed appointment.

A preview explains what a dataset contains. Evidence supports a conclusion. Shopping agents need to keep that distinction clear.

5. What happens when the conversation becomes too long?

Compaction and structured working state

By the third evening, the buyer has changed some preferences. A round table is now acceptable. Extendable tables are out after several reviews mention unreliable mechanisms. The budget and weekend delivery requirement remain firm.

Meanwhile, the seller has ruled out weak advertising performance but has not yet established whether delivery charges explain the decline.

A long conversation may need compaction: rebuilding a smaller working context by removing material, clearing bulky results, summarizing exchanges, or combining these methods.

Every approach loses something.

A summary that says “find an affordable dining table” has discarded much of the buyer’s actual assignment. A summary that says “delivery costs caused the sales decline” has turned the seller’s unresolved hypothesis into a fact.

A better approach preserves structured working state. It records the goal, active constraints, confirmed findings, rejected options, evidence references, open questions, next action, and authorization.

For the buyer, that state should explain why an extendable table was rejected and which delivery requirements remain binding. For the seller, it should preserve the difference between a correlation already measured and a cause still under investigation.

Compaction should be tested against these distinctions. Can the agent resume without changing the meaning of the task? Can it retrieve the evidence behind a finding? Does a pending question remain pending?

The quality of a summary depends on the decisions it enables.

6. Which details deserve to survive?

Persistent state and future decision value

The oldest detail in a conversation may be the most important.

The buyer mentioned the narrow doorway on the first evening. Two days later, it still determines whether a table is a viable purchase. The seller set a minimum acceptable margin at the start of the investigation. That constraint still matters when the agent considers a promotion.

Future decision value is a better retention principle than age alone: preserve information likely to affect what happens next.

For work that spans many model calls, persistent state can hold a shortlist, rejection reasons, completed calculations, unresolved questions, and evidence references outside the conversation itself. Relevant parts are then brought into later requests.

This avoids endlessly compressing the same transcript. It also helps the agent stop repeating work.

The buyer should not have to explain again why the attractive table from the first search was unsuitable. The seller should not have to pay for another analysis of an advertising issue already ruled out.

A useful record preserves the reasoning needed to continue, including corrections and exceptions—not merely a list of things that happened.

7. How do we know whether the model or the context failed?

Observability, context manifests, and authorization boundaries

Suppose the buyer’s agent eventually purchases a table that exceeds the agreed total. Or the seller’s agent launches a discount when it was authorized only to prepare recommendations.

The model may have acted incorrectly despite clear instructions. It may also have received an incomplete or misleading request.

Observability makes that distinction inspectable. A context manifest records what entered a model call, what was shortened or omitted, and why.

For the buyer’s failed purchase, the record should show whether the total budget and purchase approval were present, and whether delivery costs had been verified. For the seller’s unauthorized promotion, it should show whether the boundary between proposing and applying a change survived.

That record must match the request actually sent. Because it can contain customer and business information, access should be controlled and routine inspection views should be redacted.

Teams can then hold the task and model fixed, change the context policy, and measure the result. They can also test whether authorization boundaries survive retrieval, summarization, and long-running work.

This is where the promise of agentic commerce meets its everyday test.

A buyer wants a table that fits the apartment, the schedule, and the household budget. A seller wants a sound explanation of falling sales and a considered response. Both are asking the agent to carry a set of concerns through a sequence of decisions.

The industry is building the connections that let agents participate in commerce. Reliability also depends on the information carried across those connections—and through each subsequent model call.

When a shopping agent makes a bad decision, the first question should be concrete:

What, exactly, did it receive when it decided?

This is Week 7 of a 26-week series on agent systems from first principles: capability maps, skills vs. tools, memory and context, loops, harnesses, and the patterns that separate a demo from production.

Happy learning, happy building.
Tao