CUSTOMER MEMORY VS. A GENERAL-PURPOSE LLM

When a general-purpose LLM is enough — and when it stops working

Everyone asks it eventually: why not point Claude or ChatGPT at customer calls, interviews, tickets, and reviews? Here’s where each approach genuinely wins—with the numbers.

USE A GENERAL PURPOSE LLM

Small set of documents, a question you'll ask once? Use Claude or ChatGPT. Under roughly 30 documents the whole set fits in one context window, the model reads every word, and you'll get a better answer than any memory system will give you. No setup, no cost, no us.

We'd rather say that plainly than sell past it. Everything below is about what happens when those conditions stop holding — which, for most teams, is sooner than they expect.

First, the objection everyone gets wrong

“It won’t fit in the context window.”

The wall is somewhere else. It is economics, physics, and forgetting.

The wall is somewhere else.
It is economics, physics, and forgetting.

That is not the problem, and repeating it makes the rest of the argument easy to dismiss. A capable model can fan out—one sub-agent per call, ticket, or response—and read everything in parallel, at any volume. Every item genuinely gets read, which even beats retrieval at counting.

one question

fan out

aggregation

Q

300k–600k

tokens funnel back in

the long-context problem, again

one question

fan out

aggregation

Q

the long-context problem, again

300k–600k

tokens funnel back in

What actually breaks, and what it costs

Four things go wrong when raw data is re-read on every question—and all four get worse as the archive grows.

01 / COST

You pay to read everything, every time

Every question re-reads the entire archive. At 1,000 items, that’s 2.3M tokens per question—again and again.

01 / COST

You pay to read everything, every time

Every question re-reads the entire archive. At 1,000 items, that’s 2.3M tokens per question—again and again.

02 / LATENCY

Concurrency turns parallel back into sequential

You cannot run 1,000 sub-agents at once. At realistic concurrency, 1,000 items become 63 sequential waves.

02 / LATENCY

Concurrency turns parallel back into sequential

You cannot run 1,000 sub-agents at once. At realistic concurrency, 1,000 items become 63 sequential waves.

03 / AGGREGATION

The reduction step recreates the problem

The long-context problem you thought you escaped reappears at the join, losing fidelity at every level.

03 / AGGREGATION

The reduction step recreates the problem

The long-context problem you thought you escaped reappears at the join, losing fidelity at every level.

04 / WASTE

Most of the spend buys nothing

Fan-out reads every record to discover the few that mattered. Knowing what to read first is the work memory does.

04 / WASTE

Most of the spend buys nothing

Fan-out reads every record to discover the few that mattered. Knowing what to read first is the work memory does.

relevant (20)

read but irrelevant

relevant (20)

read but irrelevant

Three things that never work, at any size

Those four problems are problems of scale. These three don’t depend on scale at all—they fail at five calls exactly as they fail at five thousand.

No memory between sessions

“What changed at this account since our last conversation?” needs state. A general-purpose model starts cold every time.

No knowledge of your business

Taxonomy, product aliases, segments, and CRM context must be re-explained in every prompt—unless memory carries it forward.

No consistency between answers

Ask the same question twice and the judgment calls get made again. Tags applied once make trends and counts real.

Where the line falls

It’s not a size limit. It’s volume × how often you ask—and both flip together.

ONE-OFF QUESTIONS

REPEATED QUESTIONS · MANY PEOPLE · GROWING ARCHIVE

USE CLAUDE / CHATGPT

AND WE’D TELL YOU SO

THE AWKWARD MIDDLE

QUERY VOLUME DECIDES IT

ONLY MEMORY HOLDS

COST, LATENCY AND WASTE ALL COMPOUND PAST HERE

0

~30 ITEMS

LOW HUNDREDS

THOUSANDS

ONE-OFF QUESTIONS

USE CLAUDE / CHATGPT

AND WE’D TELL YOU SO

THE AWKWARD MIDDLE

QUERY VOLUME DECIDES IT

ONLY MEMORY HOLDS

COST, LATENCY AND WASTE ALL COMPOUND PAST HERE

A general-purpose LLM is the right call when

The whole set fits in one context window. The question is one-off. Someone can supply business context each time. Nobody needs the answer to be reproducible six months from now.

You need customer memory when

You need customer memory when

You need customer memory when

The archive keeps growing. Questions come back. The question has a time dimension. The work should run unattended. Answers must carry your taxonomy, segments, and product mapping automatically.

The objections, answered straight

These come up in every evaluation. Here are the real answers.

“Context windows keep getting bigger.”

They do, and it doesn’t help. Cost per question, the concurrency ceiling, the aggregation step, and the lack of state are untouched by a bigger window.

“Isn’t memory less accurate than raw text?”

On a one-off question over a small set—yes. Compression trades some coverage for speed, cost, and repeatability: a decisive trade at 1,000.

“Models keep getting cheaper.”

Cheaper tokens shrink both sides equally. Reading everything on every question stays linear and permanent; memory is paid once at ingestion.

“We don’t want another tool to be locked into.”

The memory is yours—normalized, tagged, and callable by whatever needs it. That is the point of a layer rather than a feature.

THE HONEST SUMMARY

Memory is not a smarter answer. It’s the work of reading once—and keeping what matters.

A general-purpose model reads brilliantly and remembers nothing. NEXT reads once, connects each signal to its customer context, and puts that memory to work wherever the work already happens.