I Made Hindsight Memory Survive a New Interaction

Tejaswini Bandla — Tue, 29 Sep 2026 13:31:25 +0000

I Added a Safe Legacy Path to Hindsight Recall

The easiest migration is the one you do not notice. The dangerous one is when old data quietly stops showing up—or worse, when a compatibility workaround makes data from the wrong customer eligible for a response.

I ran into that choice while adding customer tags to a Hindsight-backed support agent. New interactions could carry a customer-specific tag, but older records had been retained without one. Strictly filtering by tag protected new reads and made the old history disappear. Removing the filter preserved old history and weakened the boundary. I needed a migration path that admitted only what the old format could identify safely.

A metadata change changes what can be found

The API route stores support interactions in a configured Hindsight bank. Each record contains a customer marker, the current issue, and the generated support response. When I added per-customer tags, new writes became easy to scope. Old writes did not gain tags retroactively.

That means the same recall call cannot treat every record identically. A strict tag filter can find the new records, but it excludes records with no tag. A bank-wide semantic query can find old records, but it may also return another customer's history. The problem is not just migration mechanics; it is deciding how much confidence an old record deserves before it reaches a model prompt.

I chose a two-stage path. First, recall by the current customer's strict tag. If that returns results, use them. Only when tagged recall is empty do I query for legacy interactions and filter the returned text against the exact marker in the earlier retention format.

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

if (taggedMemory.results.length > 0) {
  return taggedMemory;
}

The fallback does not get to bypass customer verification. Its query asks for records explicitly associated with the customer, but that query is only candidate generation. The local predicate makes the final decision.

Why the fallback checks the retained text

The earlier route retained text beginning with this sentence pattern: Customer <name> contacted support. The compatibility code checks for that marker at the start of the recalled text. It escapes the supplied name before building the regular expression, so punctuation in a customer name cannot change the pattern's meaning.

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);
}

The start anchor matters. It rejects a result that merely mentions the customer's name somewhere inside another customer's record. The spaces are flexible so the check tolerates harmless whitespace differences, while the words around the name remain fixed.

I deliberately do not treat the query text as evidence. Natural-language recall is probabilistic by design: its job is to find likely relevant material. The ownership check is deterministic and local to the route. That makes the fallback easier to audit. Someone reviewing a result can see the exact string pattern that admits it, instead of trying to infer whether a prompt instruction was strong enough.

The fallback is intentionally conservative. Hindsight may return a summarized observation that no longer begins with the original marker. That summary might be useful, but this route cannot prove its ownership from the available text. It is excluded. I would rather handle the current issue without old context than turn an ambiguous result into personal history in the prompt.

This tradeoff makes one limitation visible: backward compatibility is not the same as perfect recall. The old records can only be recovered when the retrieval result preserves enough of the old format to identify the customer. If the historical data is important enough to recover more completely, I would run an explicit migration that reads the source records, assigns a verified customer ID, and retains tagged replacements. I would not weaken every live recall request to get there.

The bank-level graph is useful for understanding how retained memories relate; the application still checks explicit customer ownership before using legacy records.

An explicit migration would also give me a place to measure coverage before switching reads. I would count how many source records have a reliable customer identity, how many can be transformed, and how many fail validation. Then I could compare the new tagged records against the old set before retiring the fallback. That work is different from trying to repair history opportunistically during every support request. A live endpoint should remain predictable; a migration job can be slower, retryable, and more verbose about records it cannot classify.

New writes make the migration converge

The normal path gets simpler as tagged interactions accumulate. Each response is retained with the same tag used for recall:

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

Current issue:
${issue}

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

On the next request, the tagged recall should be the path that supplies memory. The fallback remains useful for older records that still meet its explicit ownership check, but it does not become a permanent alternative global search. This is an important property of a migration path: it should have a clear direction toward the new invariant.

I also want the retention contract to be simple enough to verify. The same helper computes the tag for both operations, so the key does not drift because recall and retain each reimplement normalization. If customer-key rules change later, that helper becomes a deliberate migration point. Changing the key casually would strand memories under the previous tag, which is another reason to treat identity as schema rather than formatting.

Hindsight's tag filter is useful during this transition because the new path can be strict without deleting or rewriting old data. The fallback is an explicit compatibility branch, not a change to the configured bank or a destructive cleanup. That gives the application time to accumulate tagged interactions and gives operators a clear explanation when an older record cannot be safely attributed.

Hindsight is valuable here because the read and write operations can both carry selection metadata. The Hindsight repository and Hindsight documentation describe the memory API and filtering features used for that transition. The Vectorize agent memory overview is a useful framing for why retained, retrievable context needs an explicit lifecycle instead of being treated as an ever-growing prompt.

Memory migration lessons

I took four rules from this change:

Do not confuse “found by search” with “safe to use.” Search returns candidates. A separate rule decides whether a candidate belongs in the current prompt.
Keep legacy compatibility narrower than the new path. New records have structured tags; old records pass only if their original text makes ownership explicit.
Make the failure mode asymmetric. Omitting an uncertain memory loses personalization for one answer. Including the wrong customer's memory can disclose information and mislead the response.
Give the migration an end state. New writes should satisfy the new invariant so ordinary reads no longer need a bank-wide fallback.