I Stopped Rotating API Keys When Support Memory Pointed to Permissions

I Stopped Rotating API Keys When Support Memory Pointed to Permissions
A support agent can be technically correct and still waste hours. The most expensive mistake is often not a bad answer; it is repeating a troubleshooting step that already failed for the same customer.

I built ResolveLoop around that problem. It is a support continuity agent that retrieves durable customer history before recommending the next action, distinguishes failed attempts from confirmed resolutions, and lets a human approve the outcome before writing new learning back to memory. The important design choice is that memory is not a side panel. It changes the decision.

The support problem is temporal
A new ticket usually contains only the present-tense symptom: a webhook stopped arriving, an integration timed out, or a deployment changed something unexpectedly. The useful evidence may be weeks old.

For one synthetic customer, AcmePay, an earlier webhook incident had two important facts:

• regenerating the API key had already been attempted and did not help;
• restoring the webhook-publish permission resolved the incident.

A stateless model sees “webhook events are missing” and may suggest a familiar checklist. A memory-aware agent should say: do not repeat the failed key rotation; check the permission that fixed the previous incident.

That difference is the product.

Why I used Hindsight as the memory boundary
I wanted the application database to hold operational metadata—customers, tickets, resolutions, and demo state—but not pretend that a few SQLite rows were an agent memory system. Hindsight is the durable memory boundary.

ResolveLoop writes support interactions with structured context: customer ID, issue, category, outcome, technical environment, tags, timestamp, and document ID. It recalls by a natural-language query plus strict customer tags. The customer tag matters because a support recommendation must not accidentally use another company’s history.

The integration is deliberately isolated in one provider adapter:

result = hindsight.recall(
query=query,
tags=[f"customer:{customer['id']}", "resolveloop"],
)

The adapter sends the official Hindsight HTTP request and normalizes the response into the application’s memory model. It preserves provider IDs, timestamps, metadata, tags, entities, and document IDs so the interface can show where a recommendation came from.

Customer-scoped recall uses an all-tag match. A memory must belong to the requested customer and the ResolveLoop namespace. This is a small implementation detail with a large consequence: relevant memory is useful only when its identity is correct.

The loop is Store → Retrieve → Reason → Resolve → Learn
The ticket flow has five deliberate stages.

First, ResolveLoop stores historical support memories through Hindsight. Second, a new ticket retrieves memories for the selected customer. Third, the language model receives the current ticket, customer profile, memory status, and normalized memories as separate context. Fourth, it produces a structured brief: failed actions, successful resolutions, recommendation, risk, reasoning, communication style, and a draft reply. Finally, a human support agent records what actually happened.

Only the human-confirmed resolution is written back as new learning. The application never treats a draft recommendation as truth.

The learning payload contains three kinds of memory:

items = [
new_issue_memory,
confirmed_resolution_memory,
optional_lesson_memory,
]

If Hindsight rejects the write, ResolveLoop returns learned: false. It does not show a green success state simply because the resolution form was submitted. That distinction is important in systems where memory affects future decisions.

Making the improvement visible
The interface is designed as a short proof rather than a feature tour.

The ticket analysis page shows the current issue, customer context, relevant memories, failed actions, successful resolutions, recommendation, risk, and source labels. A Memory Impact panel places two recommendations side by side:

• Before Hindsight: a generic current-ticket-only suggestion;
• After Hindsight: a recommendation changed by the customer’s confirmed history.

For the AcmePay scenario, the after-recommendation checks webhook-publish permission before rotating credentials. The failed-action warning makes the negative evidence visible, while the successful-resolution card shows why the alternative is credible.

The next step is not “trust the model.” It is “inspect the evidence, edit the draft if necessary, confirm the real resolution, and let the system learn.”

What I learned building it

1. Memory needs identity, not just text
   A paragraph saying that a permission fixed an incident is less useful than the same paragraph attached to a customer, environment, category, outcome, and timestamp. Structured metadata gives retrieval and review something to reason about.

2. Failed actions are first-class knowledge
   Many support systems record what worked and silently lose what did not. A failed attempt is often the most valuable guardrail in the next interaction. ResolveLoop renders failed actions explicitly instead of burying them in a transcript.

3. Human approval is part of the memory design
   The agent can recommend. It cannot decide what actually solved the issue. The resolution form captures the action taken, whether the recommendation was useful, what really fixed the problem, and an optional lesson. This makes learning auditable and keeps uncertainty visible.

4. Provider failure must be a product state
   Hindsight and Groq can be unavailable. The UI therefore distinguishes retrieved, empty, unavailable, and authentication-error states. A blank memory panel is not presented as successful retrieval, and a failed write is not presented as learning.

5. The best demo is a changed decision
   A memory system is hard to judge from an architecture diagram alone. The useful demonstration is one ticket before memory, one ticket after memory, and a clear explanation of what changed. If the recommendation does not change, memory is probably decoration.

ResolveLoop’s goal is simple: make the next support interaction better because the previous one was remembered correctly. Hindsight provides the durable memory layer; the application turns that memory into an inspectable, human-controlled decision.

Learn more about Hindsight on GitHub, read the Hindsight documentation, or explore what agent memory means for AI systems.