Give the AI a memory of each customer that is curated and decaying, not a raw event firehose it cannot use and should not keep
Every AI-orchestrated customer experience depends on a question nobody likes to answer: what does the system know about this person, and how does it know it. The fashionable answer is "everything, in a vector database," which is both unusable and indefensible. Unusable, because dumping a customer's entire event history into a model's context produces noise the model cannot reason over and a bill that scales with history. Indefensible, because remembering everything forever is the opposite of data minimization and the kind of thing that turns a customer's offhand interaction into a permanent record they never agreed to.
The context layer is the unglamorous foundation under every agentic and AI-personalization promise, and it is the part the demos skip. A useful customer memory is curated rather than complete: it holds what is worth remembering, lets the rest decay, ranks relevance for retrieval, and respects the consent state of the events it was built from. Getting that layer right is most of the work in making AI orchestration both effective and defensible, and getting it wrong is how teams end up with an expensive memory that recalls the wrong things and remembers what it should have forgotten.
This recipe builds the context layer as an editorial memory, not a raw archive.
A customer context layer that AI orchestration can read from to behave consistently, holding curated, decaying, consent-aware memory rather than raw history. The metric is context recall quality: whether the system surfaces the right context at the right moment, which is a relevance-and-freshness measure rather than a volume one, because more context is not better context. The value shows up indirectly, as better AI-orchestrated experiences and as a defensible answer when a customer or regulator asks what the system holds about them, and the honest framing is that this layer rarely produces a metric of its own; it makes the recipes built on top of it work or fail.
The second outcome is a memory that can be explained and, where required, surfaced to the customer, which is increasingly an expectation rather than a nicety.
A context store over the warehouse or CDP that supports request-time retrieval, plus the derivation pipeline that turns raw events into the curated, decaying memory the store holds. Composable stacks suit this because the context layer sits between the raw first-party data and the orchestration that consumes it, and it has to be inspectable and governable, which is hard when memory is a black box inside a vendor's agent. The capability that decides whether the layer is useful is the editorial function: deciding what is worth remembering and what should fade is a judgement, not a default, and a store that keeps everything is easier to build and worse to use than one that keeps the right things.
Compare the tools on Martech Stack Builder
Identity or CDP ownership owns the editorial layer: what is worth remembering, the decay function, and the relevance model over raw history. Data engineering builds the context store, the request-time retrieval, and the consent-aware recall. Privacy ops is critical, because the central tension of this recipe is memory versus data minimization, and resolving it (what may be remembered, for how long, and how a withdrawal propagates into the memory) is a privacy decision with real weight in the EU. Data science, where involved, builds the derived context and ranks relevance for retrieval. The recipe takes quarters because the editorial layer needs iteration to surface the right context, the decay policy needs tuning against real behavior, and the data-minimization reconciliation is substantive. Standing up a vector store is fast; building a memory that recalls well and forgets correctly is the work.
Work in this order. Decide what is worth remembering before choosing where to store it.
Memory and recall covers steps 1 to 3, session history rehydration step 4, inferred attribute generation step 5, and consent-scoped signal collection steps 6 and 7.
The first failure is memory as full history. Storing everything and retrieving broadly produces context the model cannot reason over and a cost that grows without bound, and it is the data-minimization violation that a regulator reads as a refusal to forget. The editorial layer that decides what is worth keeping is the difference between a memory and an archive, and it is the part teams skip because keeping everything is easier.
The second is the absent decay function. A memory that weights a purchase from three years ago the same as one from last week anchors the system on who the customer used to be, so the AI confidently personalizes around stale context. Decay is not optional polish; it is what keeps the memory current, and the right decay rate is set by how fast customer state actually changes in the business.
The third is recall that ignores consent and surfacing. Recalling context built from events the customer has since withdrawn consent for, or surfacing remembered detail in a place the customer finds surprising, both break trust, and the second is increasingly a place customers and regulators expect transparency. The memory has to carry consent state so a withdrawal reaches it, and the business should be able to show a customer what the system holds about them.
The Workshop works out with your team which of these matter for your stack right now, and what to do first: a 90-minute session with the people who own the decision.
The editorial decision of what to remember and what to let fade, the decay function that keeps it current, the consent-aware recall that respects a withdrawal, and the data-minimization reconciliation that keeps it defensible: those are the decisions that turn an everything-forever vector dump into a customer memory that is both useful and lawful.
Did this recipe match your situation?Anonymous response. Sign up to leave a longer note tied to your account.
Show account-relevant content to known and reverse-IP-identified B2B visitors, with explicit handling of the wrong-match case
Show returning visitors what they had going, last-viewed products, cart contents, loyalty progress, without making them sign in or start over
Swap homepage content by visitor location for store availability, regional pricing, and local campaigns, with a clean default when location is unknown