My cache fix was fine—until it wasn’t

My cache fix was fine until it wasn't.

The day I realized we were shipping amnesia

My cache fix passed tests, code review, and staging. It still caused production pain two weeks later, for a reason someone had already explained in a meeting six months earlier. That was the day I stopped thinking our biggest engineering problem was bad code and started treating it as missing memory.

Most teams don’t fail because they can’t write software. We fail because we can’t consistently remember why we made decisions in the first place. In our stack, the “why” lived in Slack scrollback, incident calls, and the heads of whoever happened to be awake during a postmortem. The result was predictable: repeat incidents, repeat arguments, and repeat “how did we miss this again?” moments.

So I built a system that sits in the developer workflow, continuously recalls prior decisions, and intervenes while code is being written. It doesn’t wait for CI. It doesn’t wait for another outage. It tells you, in real time, when you are about to repeat known failure patterns.

What this system does and how it hangs together

At a high level, the architecture follows a simple loop: capture, structure, retrieve, intervene. The project’s README calls out that exact sequence—capture events, extract decisions, store memory plus embeddings, retrieve context, and warn during development (, indexed through retrieval pipelines and fed by operational sensors (meeting transcripts, incident notes, commit metadata, and runtime signals). I started from aligned with what we were seeing: context loss is not an edge case; it’s the default.

In our system, the runtime has four concrete subsystems:

1. 
   Signal ingestion from engineering events.


2. 
   Decision extraction into memory atoms (rule, context, source, severity, temporal scope).


3. 
   Retrieval and ranking by current code intent plus repository context.


4. 
   Inline intervention in the editor stream, with suggested corrective actions.

The repository includes a compact front-end simulation of that behavior in code.html, where a knowledge graph of prior incidents is checked continuously against active code input ().

js

{

  lib:"pickle",

  rule:"Do not use pickle for inter-service serialization",

  reason:"Caused silent data corruption between Python 3.10 and 3.12 services.",

  flaggedBy:"Sana",

  flaggedDate:"2025-02-20",

  context:"Microservices communication layer",

  source:"Engineering all-hands transcript",

  severity:"CRITICAL"

}

That metadata is what moves a warning from opinion to engineering artifact.

3) Attributable: every warning points back to tribal evidence

The right pane in code.html intentionally renders source provenance next to the violation—who flagged it, when, where, and why. This turns “AI says no” into “here is the historical failure you are about to replay” ( were useful: the model of writing durable, queryable memory from operational events maps directly to engineering reality. Postmortems are already written; the missing step is transforming them into low-latency intervention rules.

The key design decision was to store lessons as atomic norms instead of long narrative blobs. The UI literally reflects this with “3 atomic norms loaded,” and that language matters ().

That clear-state behavior is not cosmetic. It gives developers closure and confidence. Warnings without clear dismiss/resolve semantics create chronic distrust.

Code-backed design details that mattered more than I expected

Diff-aware messaging

The analyzer tracks previously seen violations and only announces net-new ones. This reduces repetitive noise when a developer pauses and resumes typing ().

Temporal framing

The initial reasoning stream includes explicit temporal context (“April 2026”). That sounds minor, but it prevents one of the easiest failure modes in memory systems: stale advice presented as timeless truth (

Data Filtering:

Limitations and Pain Points

This system is not magic, and it is certainly not perfect.

• Memory Bloat: The biggest limitation is that the agent can "remember" too much. If we keep every single comment from every Slack thread, the retrieval noise becomes unbearable. We’ve had to implement an automated pruning pipeline that aggressively de-prioritizes rules older than 12 months unless they are explicitly tagged as "Architectural Constant."

• Trust Calibration: Engineers are rightfully sceptical of "automatic changes." If the agent can't cite the source—a specific meeting, a PR comment, or a bug report—the engineers tend to override the agent's interventions. We have learned that explainability is non-negotiable. If the agent doesn't have a clear citation, it must default to "Alert" rather than "Act."

• Sensor Noise: Our meeting transcript parser often misinterprets sarcasm or brainstorming as definitive technical requirements. We are currently implementing a "human-in-the-loop" step where a senior engineer must verify any rule flagged by the agent before it becomes an immutable constraint.

References

[1] Panopto. (2019). Workplace Knowledge and Productivity Report. Survey of 1,000 U.S. full-time employees.

[3] Hansen, M. T., Nohria, N., & Tierney, T. (1999). What's your strategy for managing knowledge? Harvard Business Review, 77(2), 106-116. Replication data in Management Science, Vol. 52, No. 11, 2006, pp. 1725-1745.

[4] Polanyi, M. (1966). The Tacit Dimension. Doubleday. University of Chicago Press reprint, 2009

[5] DeLong, D. W., & Fahey, L. (2000). Diagnosing cultural barriers to knowledge management. Academy of Management Executive, 14(4), 113–127. DOI: 10.5465/ame.2000.3979820

[6] Argote, L., & Miron-Spektor, E. (2011). Organizational learning: From experience to knowledge. Organization Science, 22(5), 1123–1137. DOI: 10.1287/orsc.1100.0621 · ResearchGate PDF