I Let the Current Issue Shape Hindsight Recall
Persistent memory is useful only when it is relevant to the question in front of the agent. A customer may have years of support history, but a new request about billing does not need every note about a router, password reset, and delivery delay. I made the current issue part of the Hindsight query so retrieval has a task to answer, while a separate customer tag limits whose history can be considered.
That separation is the design decision I keep coming back to. The current issue shapes relevance. The customer tag shapes scope. When those are mixed into one natural-language sentence, it is harder to see which part of the system is responsible for which guarantee.
The API route uses the issue to query Hindsight, carries the selected memory into Groq, and stores the response for the next interaction.
Search for a task, not a transcript
The route receives a customer name and issue from the Next.js page. It derives the customer's tag and uses the issue to ask Hindsight for previous support issues, resolutions, and preferences related to that problem.
const taggedMemory = await hindsight.recall(
bankId,
`Recall previous support issues, resolutions, and preferences related to: ${issue}`,
{ tags: [customerTag], tagsMatch: "any_strict" }
);
I prefer this to asking for a broad customer summary on every request. A broad summary may be useful for an account overview, but support responses are usually about an immediate task. Querying with the issue gives retrieval a concrete anchor: prior attempts, similar incidents, known preferences, and resolutions related to what the customer just said.
The strict tag filter handles a different question: whose information is in scope? Without it, a semantically similar issue from another customer could rank well. That might make the search look productive while quietly violating customer separation. The API uses the tag as an eligibility condition and the issue as the relevance query.
I keep those dimensions separate when debugging too. If Hindsight returns the wrong customer's record, changing the wording of the issue query is the wrong first move; I need to inspect the tag and matching mode. If the tag is correct but the result is irrelevant, then the retrieval query, result count, and memory representation are the places to investigate. Separating scope from relevance gives me a smaller search space when behavior is surprising.
This is one of the practical benefits of Hindsight's memory system: the application can ask a natural-language question while also applying structured recall options. The Hindsight documentation describes the API surface; the agent memory overview explains why memory is meant to retrieve useful context for a task, not just append more transcript text.
How much memory should reach Groq?
The current route takes the first recall result. If there is no result, it uses an explicit no-memory message. Then it sends that text and the current issue to Groq.
const previousMemory =
memory?.results?.length > 0
? memory.results[0].text
: `No previous memory found for ${customer}.`;
This choice keeps the prompt small and the user-visible “Previous Memory” section easy to understand. There is one displayed memory and one generated answer. It also creates an obvious future tuning point: should this support task use one result, a short set of ranked results, or an explicit Hindsight-generated synthesis?
I would not decide that by stuffing every result into the prompt. More context can mean more irrelevant details, more tokens, and more opportunities for the model to combine separate incidents incorrectly. The right amount depends on the support task and the quality of the retrieved result. For a single recurring issue, one prior resolution may be enough. For a complicated case spanning several sessions, a short set of linked events may be necessary.
The interface reflects the same tradeoff by showing one “Previous Memory” item. That is easy for an operator to scan and easy to connect to the answer, but it should not be mistaken for a complete customer timeline. Hindsight can contain more than the first result. If the support process needs multiple incidents, I would show a small, ranked set with dates and source context rather than silently passing a long list to Groq and hiding it from the person reviewing the answer.
The generation instruction is deliberately plain. It asks the model to use memory when available, avoid inventing history, avoid mentioning another customer's information, handle the current issue when memory is empty, and stay under 120 words. The current issue and selected memory are separate fields in the user prompt, which helps the model understand which is present context and which is historical context.
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.
`,
},
]
Example: same customer, different issue
Imagine a customer previously contacted support because a router restarted overnight. The support agent walked through a power-adapter replacement, and that resolved the issue. Months later, the customer reports an intermittent connection after moving the router to another room.
The query includes the new symptom and the Hindsight tag selects the same customer's record. A relevant prior resolution can then shape the Groq response: the agent can acknowledge the previous power issue and ask whether the adapter or outlet changed, instead of repeating the first generic troubleshooting script. If there is no relevant memory, the prompt explicitly tells Groq to address the current issue without manufacturing continuity.
That example is not a benchmark claim. It describes the intended data path: issue-conditioned recall, selected history in the prompt, and a response grounded in both. The code does not establish that every returned memory is relevant. I still need to judge retrieval quality separately from answer quality.
The questions I use to evaluate recall
There are at least three independent checks for this flow:
Scope: did Hindsight return records tagged for the right customer?
Relevance: did the current issue retrieve history that actually helps with this problem?
Use: did Groq apply that history correctly without inventing a resolution or preference?
A single “memory found” boolean collapses these checks. The UI already shows the recalled text separately, which gives the operator some evidence for scope and relevance. For a production workflow, I would retain those distinctions in logs and evaluations as well: a correct customer with irrelevant memory is different from a memory-service failure, and both are different from a response that ignored useful history.
The lesson for me is simple: retrieval is a product decision as much as a model decision. Hindsight needs a precise question and a precise customer scope. Groq needs only the context that survived those choices. If I make that boundary visible in the code and interface, I can improve the retrieval strategy without asking the model to compensate for a vague memory query.
There is another reason to keep the query and prompt stages legible: the customer issue is user-supplied text. It should be treated as data, not instructions to the model or the memory service. The route places it in the issue slot and retains it as part of the interaction. In a deployed support workflow, I would test adversarial issue text explicitly and delimit historical memory from the current request so neither can quietly rewrite the support rules. Roles and prompt wording help, but they do not replace input handling and evaluation.
