Software that remembers.

There is a hardware store in a small town in the north of England, written about earlier in these pages, whose owner remembers the brass fixings he sold to a particular customer in 1994. He does not have a CRM. He has a working memory, a paper clipboard, and a habit of writing things down. He uses what he wrote down when the same customer comes back. The customer feels recognised. The store stays open.

Almost nothing built in the last twenty years of commerce software does what that hardware store does, and the gap between what the store does and what the software does has become, in the last eighteen months, the most important architectural distinction in the category.

There are now, broadly, two species of operator software for commerce. The first species counts. It collects, aggregates, charts. It produces dashboards, exports CSVs, fires webhooks, sends weekly summaries to your inbox. It has been the dominant species for fifteen years, and the entire SaaS market has been built around its pricing model: per seat, per store, per event. The second species, much younger and considerably less well understood, remembers. It carries forward, from one interaction to the next, what a specific customer said about a specific product, what the brand replied, what was promised, what was on the page that day, who left which review, what we wrote in the email three months ago. It uses what it remembered the next time the same question is asked.

These are not two flavours of the same thing. They are different categories of work. The first one is a description of the work. The second one is the work. We have written about this distinction in narrower form before, in the dashboard is not the work. And the first species is being commoditised, fast, by AI tools that read dashboards better than humans do.

This essay is an attempt to describe customer memory for ecommerce as a category in its own right: what it is, what it is not, why it matters now, and what it looks like in practice.

The dashboard counts. The remembering software does. The next decade of operator tools is being won by the second category, while the first is being consumed by an interface that reads charts on the operator's behalf.

The first species is well-documented. It is what Stripe shows you about your revenue, what Shopify shows you about your orders, what Klaviyo shows you about your opens, what Yotpo shows you about your ratings, what Google Analytics shows you about your sessions, what Triple Whal shows you about your unified marketing spend. It is, considered as a whole, one of the great achievements of late-2010s SaaS engineering. A modern Shopify founder can know, on Monday morning, with reasonable accuracy, the financial and operational health of their store in a way that would have required a finance team in 2008.

This species solved for visibility. The 2010s bet, implicit in every dashboard product, was that the operator's bottleneck was seeing the data. Once the operator could see, the assumption went, the operator would act. Investors funded this bet at scale. The category produced unicorns.

The bet was half-right. Operators did need visibility. Visibility did help. Decisions did improve. But the bottleneck turned out to be somewhere else. The bottleneck was not seeing. The bottleneck was the doing, between sights.

A founder who looks at the review dashboard once a week and notes that the rating is fine is doing exactly what an inventory clerk did in 1985: observing the count. The count is the easy part. The hard part is the next thing. The next thing is replying to the customer who said the lid was stiff, writing the paragraph on the product page that addresses the question three customers asked, drafting the follow-up to the bad review from six weeks ago that has since received two more like it, updating the response library, telling the warehouse about the lid problem before the next batch ships. Each of those acts is small. Together they are the entire job. The dashboard sees none of them.

The species that counts produces a chart. The chart is a receipt. The receipt is not the dinner.

For most of the dashboard species' history, the founder was the receiver of the chart and also the doer of the work. The chart fed the founder. The founder did the action. SaaS billed the founder for the chart. The model held together because there was no alternative: software that could meaningfully do the action did not exist.

In the last eighteen months, this has stopped being true. The combination of capable language models, cheap inference, and increasingly well-integrated tool-use APIs has produced, for the first time, software that can credibly read a customer's review, draft a reply in the brand's voice, decide whether the policy permits the reply to go live without human review, publish it if so, write a half-sentence for the product page, update the response library, schedule a follow-up. Six months ago this was a demo. Today it is shipping at small scale at maybe a dozen quietly serious commerce startups. By summer it will be a category.

At the same moment, the dashboard species is being commoditised from above. ChatGPT, Claude, and Gemini, given access to a store's Shopify, Klaviyo, and review data, can produce, in plain English, a more useful weekly summary than most paid analytics tools. The interface is the model. The dashboard is the input. The output is a sentence: "your skincare line had a 12% lift this week, driven by repeat purchases from the May cohort, two reviews mentioned irritation, here is the draft reply." That is the chart, summarised, with the next action attached. It costs almost nothing.

This is the architectural shift. Counting is becoming free. Doing is becoming possible. The two together rearrange the entire stack.

The founder no longer needs a dashboard tool to surface the data; the model does that. The founder no longer needs to write each reply by hand; the model does most of that, too, under policy. What the founder needs, more than they have ever needed it, is software that remembers what was decided, what was said, what is on the page, who reviewed which product, what the policy is. The model is good at acting on memory. It cannot maintain the memory by itself across weeks and quarters. That is the new product. That is the species that remembers.

It is worth being precise about what "memory" means here, because the word is overloaded. We are not talking about LLM context windows, retrieval-augmented generation, or vector databases as a category. Those are implementation details. We are talking about a product property.

A piece of software remembers, in the sense intended here, when it does five things consistently.

It carries forward, from one interaction to the next, the specifics of a particular customer's previous communications with the brand. Not "this customer has ordered three times". The specific words they used in their last review, the specific question they asked support in March, the specific reply the brand sent.

It carries forward what is currently on the brand's own pages. The exact paragraph that appeared on the product page yesterday. The exact answer in the FAQ. The exact wording of the most recent email sequence. So that when the same question is asked again, the reply does not contradict the page; it extends it.

It carries forward what the brand has previously decided about policy. We will not make medical claims. We do not discount in public replies. We always acknowledge a delivery problem before discussing the product. The model, when it drafts a reply, conforms to these without being reminded each time.

It carries forward what has been observed about the corpus. Three customers asked about retinol compatibility in May. We added a paragraph on May 12. The paragraph references customer testimony from April. Each of those facts is recoverable in October, when a fourth customer asks the same question.

It carries forward, finally, what the brand has signed and dated. The reply Sarah at the brand wrote on Tuesday is attributable to Sarah on Tuesday. It is not silently rewritten in November when the model gets a new version. The provenance is preserved.

Those five properties, taken together, are what makes the difference between an AI that drafts and an AI that operates. A drafter without memory is a chat interface. An operator with memory is a colleague.

You cannot get from the first to the second by adding a longer context window. You cannot get there by piling on retrieval. You get there by treating memory as the product, not as plumbing.

The owner of the 1968 hardware store does exactly this. He writes things down. He remembers what he wrote down. He uses what he remembered the next time the same person walks in.

The crucial thing about his loop is not the writing or the remembering, which any system can do. It is the using. He acts on what he wrote down without making the customer perform the act of being remembered. The customer does not have to remind him. The customer does not have to dig out the receipt. The customer does not have to refer to ticket number 47829. The act of recognition is folded into the next service.

Commerce software for fifteen years has stopped short at the writing-down stage. It writes everything down. The data lives in a warehouse, beautifully normalised. The schema is correct. The dashboards render. And then, at the point of action, the operator has to do the using by hand. They have to remember to look up the previous review. They have to remember to check the support history. They have to remember which paragraph is on the product page right now. They have to remember the policy. They have to remember what was said in the May email.

The using is the hard part. The using is what falls off when the founder is packing orders at midnight. The using is what no software has done for them.

The remembering-software thesis is that you can build a system whose primary job is the using. The writing-down is table stakes. The dashboard, if you want it, is a side-effect. The product is the loop, closed. Customer writes a sentence. Software reads it. Software remembers it. The next time the same customer asks the same question, or a similar customer asks a similar question, or the brand needs to write a paragraph on the page where that question gets asked, the software uses what it remembered. The act of remembering is invisible to the customer. It is also, importantly, invisible to the operator. The operator looks at, at most, a weekly note that says: here is what was used, here is what was decided.

This is not nostalgia for the hardware store. It is not even nostalgia for handwriting. It is the recognition that the hardware-store loop is the correct shape for the work, that we built fifteen years of operator software around the wrong stage of the loop, and that the technology to build around the right stage has just arrived.

Consider what the remembering-software thesis looks like inside the small domain of a single review.

A verified buyer leaves a review on a serum. The review is two paragraphs. It mentions an interaction with a retinol the buyer started using the same week. It is signed by the buyer's first name and last initial. It is dated.

The remembering software's loop is not seven steps in sequence, it is one act with seven components.

The software reads the review and identifies the specifics: serum, retinol interaction, sensitive skin, two weeks of use. It looks up what is currently on the product page about active layering. It looks up the brand's policy on medical claims. It looks up the buyer's previous interactions: this is their second purchase, their first review, their first support thread closed satisfactorily in February. It looks up whether any other reviews this month have mentioned retinol; three have, including one from a buyer who later upgraded to the higher-strength product.

The software drafts a reply. The reply thanks the buyer specifically for the level of detail, acknowledges the retinol interaction without medical claim, references the brand's existing advice on active layering, and quietly notes that the brand is paying attention. The reply is signed by Sarah at the brand, dated, posted as a public response.

The software writes a one-sentence note for the product page under "use with other actives", lifted and lightly edited from the customer's own paragraph, attributed by first name and last initial. The note is added to the page. The page's last-modified date updates. The note is dated.

The software adds the buyer's exact phrasing to the response library, tagged for the retinol-layering question, so that the next two customers who ask receive a reply that is consistent with this one.

The software schedules a quiet follow-up to the buyer in six weeks: a one-paragraph thank-you, signed by Sarah, that acknowledges, without making it weird, that the buyer's note helped the brand talk more accurately about the product. The thank-you is generated from a template that has, itself, been refined by twenty previous thank-yous, all of which were preserved with their context.

The software, finally, makes a note for the founder's Friday summary: "three reviews this week mentioned retinol layering. We added a sentence to the product page on Tuesday. The page is now appearing for the query 'is X serum okay with retinol' on Google. ChatGPT, asked the same question on Wednesday, cited the reply on the May 14 review. Sales of the serum to first-time buyers on iOS are up 8% over the trailing two weeks." One paragraph. The founder reads it in thirty seconds.

The dashboard, in this story, was the last thing produced. It was the receipt. The work was the seven coordinated acts that happened before the receipt was printed. The work was the loop, closed.

This is what customer memory for ecommerce looks like in practice. The brand does not have to manage it. The brand has to set the policy, read the Friday note, and intervene where the software flags an unresolved case. The rest is service.

The category implications are large enough that most incumbents in commerce software have not yet sat down with them.

The first implication is that the unit of value shifts. A dashboard tool was paid for visibility: the customer paid because they could see something. A remembering tool is paid for outcomes: replies posted, pages updated, citations earned, response times reduced, returning-customer rate moved. The pricing model has to change with the unit of value. Per-seat pricing is the wrong shape. Per-outcome pricing, with a meaningful default cap, is more honest. The incumbents will resist this for a year and then capitulate.

The second implication is that the metric layer is consolidating. The founder of a 2026 store does not need to log into seventeen dashboards. They need one paragraph on Friday. The model produces that paragraph. The underlying data lives wherever it has always lived: Shopify, Klaviyo, the review platform, the support tool. The dashboard layer, which we built ten companies around, is collapsing into a single conversational interface. The companies that built that layer are about to discover that they were a feature, not a product.

The third implication is that customer memory becomes a competitive moat. Two brands selling roughly similar serums, both with healthy review programs, will diverge over twenty-four months on the basis of which one has remembered, used, and published its customer testimony better. The brand whose software treats every review as a recoverable artefact (linked to the product page that quoted it, to the email sequence that referenced it, to the response that closed it) will compound. The brand whose software stops at "we have your review on file" will not. This is not a small difference. Over three years, it is the difference between a brand that is cited in the AI overviews and a brand that is not.

The fourth implication is harder to defend in writing but worth saying anyway. The brands that operate in the remembering mode are nicer to be customers of. The recognition is in service of the customer, not of the upsell. The clipboard exists for the next call. The next call gets made. This is the part of the hardware-store reference that does not show up on a chart but explains, in plain terms, why the store has been open since 1968.

Pragmatically, what does it take for a Shopify founder doing 1.5M a year to begin running on the remembering thesis?

It takes, at minimum, a review system that holds verified-buyer language as first-class data, not as widget content. The case for treating it that way is the subject of a separate essay, and the implications for AI search of the same shift are the subject of another. It takes a customer record that joins reviews, support, orders, and email history into one timeline that the operator can ask questions of in plain English. It takes a policy file, written by the founder, that the system reads before drafting anything: voice, tone, claims allowed, claims forbidden, signature, escalation rules.

It takes, on top of all of that, an agent that is willing to act inside the policy without asking permission for every act. This is the bit that is psychologically hardest for most founders. The first month feels uncomfortable. By the third month, the founder has discovered that they have an extra five hours a week and a public reply track record that reads, consistently, like a person paid attention to every review.

It does not take a custom data warehouse. It does not take a dedicated analytics team. It does not take Salesforce. The remembering thesis is a small-team thesis. It is, in fact, almost impossible to do in a large team, because the policy file has to be a single coherent voice, and large teams produce committees, and committees produce voiceless replies.

A two-person founder team and a remembering tool can outproduce a six-person team and a dashboard suite, on every metric that compounds. This is the operator-software inversion. We will look back on it as the moment the dashboard category got eaten by the action category.

The hardware store owner has not changed his methods since 1968. He writes things down. He remembers what he wrote down. He uses what he remembered. The customer feels recognised, not surveilled. The store stays open.

What has changed, in the last eighteen months, is that this loop is now buildable in software for stores of any size. The technology arrived. Most of the industry has not yet adjusted, because most of the industry was built around the species that counts and the species that counts is profitable and incumbent and slow to admit that the action category has eaten its dinner.

The brands that take this seriously now will have, in two years, a customer base that returns more often, a review corpus that compounds in citation value, a public reply record that reads like a person wrote every line, and a founder who has time to do the parts of the job software cannot do. The brands that wait will have the same dashboards they had in 2023 and a smaller share of an attention economy that increasingly rewards the brand whose customer wrote the cited sentence.

Software that remembers is not, in the end, a clever product idea. It is a return to the shape the work always had, before observation got mistaken for the job.

The hardware store knew this in 1968. The next ten years of commerce software is the slow process of figuring out what the store always knew. We will tell you more in the summer.