The Organisational Memory Engine

Like many of my colleagues, I was drowning in my own meeting notes. Not because there were too many. Because I couldn't do anything useful with them between meetings, so I built something about that. Here's what it does and how it's changed how I operate.

🎯 The actual problem I was solving.

I run reviews across multiple domains. Each has their own rhythm, their own KPIs, their own open items. By the time I'm walking into the third review of the week, I'm relying on my memory recall which degrades fast when you're context-switching across that many threads and I started to drop the ball in a few cases. I could not physically re-reading notes before every call, hunting for action items I knew existed but couldn't locate because I decide to over organize then into folders, trying to remember which customer name came up two weeks ago in a completely different conversation.

I needed the organisation's knowledge to be queryable. the Co-Pilot did not give me exactly what I was looking for, So I built a tool that makes it that way, nothing fancy, just what I needed for my personal use.

🔑 What I built.

A local, LLM-powered memory layer. Runs entirely on my laptop. No database. No cloud infrastructure beyond the API. The entire memory store is a flat JSON file.

Architecture:

→ Lightweight Node.js/Express server handles ingestion and API calls
→ I upload meeting notes and transcripts as documents
→ Claude processes each one through a structured prompt chain: summarise → extract entities → classify → write to memory
→ Frontend is a single HTML file, vanilla JavaScript no framework, no build step
→ Dashboard reads the memory JSON at load and renders it as structured cards

The chat interface injects the full memory JSON as context into every query. No vector database, no embeddings. Works because the memory is compact and curated I edit anything the LLM gets wrong before it becomes canonical.

✅ What it extracts from every document I feed it:

→ Executive summaries by domain lead and by topic
→ KPI signals targets vs actuals, flagged trends
→ Customer and stakeholder mentions with context
→ Open action items with owner, deadline, priority, and overdue status
→ Highlights and lowlights per area

All of this writes to memory once. From that point, it's queryable through the dashboard or through the chat interface in plain language.

💡 How I actually use it day-to-day.

Before any weekly review, I open the dashboard, select the person I'm meeting, and read a generated brief. It pulls everything from every prior meeting with them their open actions, their area's KPIs, customer names that have come up, risks flagged in their domain synthesised into a single view.

I walk into that call already oriented. I'm not catching up in the first five minutes. I'm asking the second and third-order questions from the start.

The chat interface is where I spend the most time outside of reviews. I'll ask things like "what are the overdue actions across all domains" or "which customers have been flagged more than once this month" and get a structured answer drawn from everything in memory. That used to be a manual trawl. Now it's a thirty-second query.

🎯 The proactive layer is the part I didn't expect to value as much as I do.

On dashboard load, a lightweight rules + LLM hybrid scans the memory store and surfaces patterns I haven't asked about.

An action item that went past due with no update. A metric trending in the wrong direction across two consecutive meetings. A customer name appearing in threads from two separate domain leads.

I would have spotted these eventually. The tool spots them before the meeting where they become a problem. That's the shift from reactive to ahead of it.

📌 What I kept human.

Every LLM-generated summary is editable before it writes to memory. Suggestions from the proactive layer can be dismissed and dismissals are stored so they don't resurface. I can annotate any record with my own context.

The tool generates candidates. I decide what's canonical. That boundary matters LLM synthesis is good at structure, not good at what went unsaid in a room.

❌ Honest trade-offs.

The JSON approach starts degrading around 50 meetings context window fills up and chat quality drops. For a rolling quarter of reviews, that's not a problem. For anything longer, it would be.

The proactive layer throws false positives. An action flagged as overdue might have been resolved verbally and never updated. I still apply judgment to every suggestion the tool narrows what I have to look at, it doesn't replace the look.

LLM summaries flatten nuance. Tone, subtext, the read on whether someone was actually committed that doesn't extract into JSON. The tool captures what was said.

➡️ What I'm changing next.

The prompt chain is sequential right now summarise first, then extract. Nuance lost in step one doesn't recover. I want to run entity extraction in parallel against the raw document, not the summary.

The proactive layer needs confidence scoring. A pattern backed by three data points should surface differently than one backed by one.

Email ingestion is the obvious next frontier. A lot of the real coordination happens there, not in structured meeting notes. Messier to process but that's where the gaps are.

I'm not drowning in my notes anymore. I'm actually using them.

What are you doing with the organisational knowledge that lives in your meeting notes or is it just accumulating somewhere?