I Made Hindsight Memory Survive a New Interaction

Gayathri — Tue, 29 Sep 2026 12:28:38 +0000

I Made Hindsight Memory Survive a New Interaction

The hardest part of a support assistant is not writing a plausible answer to the issue on screen. It is making the next answer better because of what happened last time, without carrying the wrong customer's history into the conversation.

I built this system around that boundary. A support interaction is short-lived browser state; customer memory is not. Hindsight sits between those lifetimes: it retrieves relevant history before generation and receives the new issue and response afterward. That sounds like a small integration, but it changed how I thought about identity, retrieval, and what “start a new interaction” should mean.

A request should outlive the page

The interface is deliberately simple. An operator enters a customer name and an issue, submits them to a Next.js route, sees any recalled memory, and reads the generated response. The client clears its fields when the operator starts over. That reset should not erase the facts the system just learned.

The request path is split at a useful boundary. The React page owns transient form state and presentation. The server route owns calls to Hindsight and Groq, so credentials stay server-side and the browser does not need direct access to either service. The API validates the two fields, recalls memory, creates a completion, retains the interaction, then returns the memory and response together.

The important part is the order. Recall happens before generation; retention happens after generation. Hindsight is not a transcript attached to the prompt by the browser. It is the persistent store that connects separate requests.

That distinction matters because a chat transcript and customer memory have different jobs. A transcript preserves a conversation in sequence. Support memory should help answer a new question: what has this customer already tried, what fixed the last issue, and what preference should the agent remember? Hindsight provides a retrieval interface for that context rather than requiring the client to resend every prior message.

The interface makes the customer issue → Hindsight memory → AI response path visible before an interaction is submitted.

The request path looks like this:

The API route orchestrates both services: it recalls tagged memory, asks Groq to respond, then retains the issue and answer with the same tag.

The boundary is customer identity

The first design decision was how to keep one customer's recall from crossing into another customer's response. The implementation uses one configured Hindsight bank and scopes each customer’s memories with a tag. The tag is derived from a normalized customer name, so capitalization and repeated whitespace do not create different partitions. The name itself is not used as the tag value.

function getCustomerTag(customer: string) {
  const normalizedCustomer = customer
    .normalize("NFKC")
    .trim()
    .replace(/\s+/g, " ")
    .toLowerCase();
  const digest = createHash("sha256").update(normalizedCustomer).digest("hex");
  return `support-customer-${digest}`;
}

Then the recall request asks Hindsight for the current issue’s relevant history while applying a strict tag filter:

const taggedMemory = await hindsight.recall(
  bankId,
  `Recall previous support issues, resolutions, and preferences related to: ${issue}`,
  { tags: [customerTag], tagsMatch: "any_strict" }
);

The strict match is doing real work. Hindsight's default tag matching can include untagged records; for a customer boundary, “close enough” is not a useful default. New interactions receive the same tag during retention. The application can therefore use the same identity rule in both directions: filter on it when reading and attach it when writing.

The API route's real Hindsight calls: strict customer-tagged recall, followed by retention with the same tag.

There is an important limitation in the current input contract: the operator supplies a name, not a durable customer identifier. Two different people with the same normalized name map to the same tag. Hashing does not solve that identity problem; it only makes the tag stable and avoids putting the raw name in the tag. In a production integration, I would use the CRM's immutable customer ID as the partition key and keep the display name as presentation data. That is a boundary I want to make explicit rather than disguise with a more elaborate hash.

A safe migration path for old memories

Adding tags creates a migration question. Existing records were retained before the tag existed. If I simply made every recall strict, those records would become invisible. If I fell back to an unrestricted natural-language search, I could put another customer's memory into the prompt.

The route handles the fallback conservatively. When tagged recall returns nothing, it searches for legacy support interactions, but accepts only results whose text begins with the exact customer marker used by the earlier retention format. The name is escaped before it becomes part of a regular expression.

function isLegacyCustomerMemory(text: string, customer: string) {
  const escapedName = customer
    .trim()
    .split(/\s+/)
    .map((part) => part.replace(/[.*+?^${}()|[\]\\]/g, "\\$&"))
    .join("\\s+");

  return new RegExp(
    `^Customer\\s+${escapedName}\\s+contacted support\\.`,
    "i"
  ).test(text);
}

This is a compatibility bridge, not a claim that every old record can be recovered. If retrieval returns a summary without the explicit marker, the route leaves it out. A missing memory is visible and recoverable; a memory leak is neither. Once tagged records accumulate, the normal path no longer depends on this fallback.

Hindsight makes this kind of migration practical because memory records can be annotated and selected at recall time. Its open-source agent memory implementation and Hindsight API documentation describe the underlying memory and retrieval model. The broader agent memory overview is useful context for why persistent retrieval is different from simply extending a prompt with more chat history.

This Hindsight view visualizes connected memories in the bank. It is a bank-level map; the support API applies a strict customer tag when selecting memory for a response.

Memory has to affect the answer

Retrieval only matters if the result changes the next action. The route takes the top recalled result, or a clear “no previous memory” string, and sends it alongside the current issue. The system instruction tells the model not to invent history or refer to another customer. The prompt stays narrow: one current issue, one recalled item, one concise support response.

const previousMemory =
  memory?.results?.length > 0
    ? memory.results[0].text
    : `No previous memory found for ${customer}.`;

const completion = await groq.chat.completions.create({
  model: "openai/gpt-oss-120b",
  messages: [
    {
      role: "system",
      content: `
You are a professional customer support agent.

Use previous customer memory when available.

Rules:
- Be friendly and concise.
- Never invent customer history.
- Do not mention information belonging to another customer.
- If there is no previous memory, simply handle the current issue.
- Keep the response under 120 words.
`,
    },
    {
      role: "user",
      content: `
Customer: ${customer}

Current issue:
${issue}

Previous memory:
${previousMemory}

Write a personalized support response.
`,
    },
  ],
});

I keep “no memory found” different from a memory-service failure. The system prompt gives the model a safe path when retrieval returns nothing, and the route returns an error if the memory service call fails. The interface also shows a found memory separately from the AI response, which gives the operator a way to inspect the context instead of presenting the answer as if it appeared from nowhere.

After generation, the route stores the interaction and answer together with the customer tag:

await hindsight.retain(
  bankId,
  `Customer ${customer} contacted support.

Current issue:
${issue}

Support response:
${response}`,
  { tags: [getCustomerTag(customer)] }
);

That write-back is what makes the next interaction different. If Ravi reports a Wi-Fi issue, receives steps that resolve it, and returns later with another connectivity problem, the earlier issue and resolution can be recalled before the new answer is generated. If Mina submits an issue, Ravi's tagged records are outside Mina's recall scope. Starting a new interaction clears the page; it does not clear either customer's Hindsight memory.

I judge memory behavior with three separate questions: Is the retrieved item relevant to the current issue? Does it belong to the right customer? Did the response use it correctly? Those are distinct failure modes. A retrieval score alone cannot prove the other two.

What I learned

Choose the memory boundary before tuning prompts. A polished answer is still a failure if its context belongs to another customer. I made the customer tag part of both recall and retention before spending effort on response wording.
Use durable identity, not convenient identity. A normalized name is enough to explain the flow, but real customer separation needs an immutable ID from the system of record. A hash cannot make ambiguous input unique.
Treat migration as part of the memory design. New metadata does not retroactively annotate old records. A conservative fallback can preserve identifiable history without making every old memory eligible for every prompt.
Make memory visible. Showing the recalled item beside the generated response helps an operator see whether memory was found and gives the system a review point when retrieval is wrong.

The useful property of Hindsight here is continuity with a boundary. The interaction can end, the form can reset, and the next request can still begin with relevant customer context. The engineering work is making sure that continuity is durable, scoped, and visible enough to trust.

DEV Community: Gayathri

I Made Hindsight Memory Survive a New Interaction

I Made Hindsight Memory Survive a New Interaction

A request should outlive the page

The boundary is customer identity

A safe migration path for old memories

Memory has to affect the answer

What I learned