From 147 Unread Meeting Notes to a Living Knowledge Base in 30 Days

After just 30 days at GEICO, I already have a folder called "meeting_notes_Q32025" with 147 markdown files, 1 for each meeting I've had. 🫠 I've opened maybe six of them since I wrote them. They're basically write-only memory at this point, which helps nobody!

My hypothesis: somehow, LLM's via the Cursor IDE can help operationalize my scattered KB! To test, I spent a week piloting a few different approaches to building a personal "knowledge base"(KB) on my Macbook Pro. Spoiler alert, but my DIY KB is already adding serious real value in my roles as Engineer & Evangelist at GEICO. Here's the long version:

Phase 1: Building the foundation

The first attempt was to build a baseline knowledge graph representing everything I know about my job. Here's the process I used:

Create a private GitHub repo
Copy in meeting notes & a few corporate docs.
Record a long voice memo on everything related to the job, from org dynamics to my own personality quirks and preferences. Transcribe & copy into repo.
Run Perplexity deep research for knowledge existing outside the walls of the enterprise, from Wall Street takes to strongly-relevant Reddit gossip. Copy into repo.
Write a brief README describing the above data source. Load it into Cursor and submit this prompt:

You are a guru-level librarian and builder of world-class knowledge bases. This repo contains scattered documents comprising a holistic view of my role at GEICO. Convert this information into a knowledge base a) oriented towards my goals, b) organized by topic, and c) architected to scale over time.

NOTE: In truth, I submitted a much more sophisticated prompt that a) clarified KB success/failure, b) laid out fine-grained steps for adding new information to the KB, and c) instructed the LLM to process large blocks of information using batches.

Behind the scenes, Cursor maintains a Merkle tree of your files (excluding .cursorignore) and every 10 minutes chunks and stores files in turbopuffer (see Cursor Security docs).

(An image appears here in the original article on LinkedIn.) The inference architecture is a little dense, but basically:

Turbopuffer uses k-means search to return relevant files.
Your selected frontier model (e.g. Sonnet 4.5) analyzes and makes suggestions.
Cursor's own prompting/models convert suggestions into small/large file-edits.

(An image appears here in the original article on LinkedIn.) In our KB scenario, this architecture allows your Cursor Agent to speak coherently on topics like:

*Based on my 2026 goals, write a **PR/FAQcelebrating my success!*
Propose 1:1 meetings (with agenda) for the top 10 key individuals in my organization.
What obvious dependency or critical issue is not being talked about?

Phase 2: Keeping it fresh over time using AGENTS.md

Our KB is humming, but how do we keep it organized? We need Cursor - which doesn't retain memory between completions - to ingest new knowledge in a consistent way.

Our solution: AGENTS.md, a comprehensive instruction manual for Cursor agents which functions as the "operating system" that ensures consistency, quality, and strategic orientation over time.

Specifically for my KB use case, it guides Cursor in a few key ways:

Document Processing - Check new/ folder for documents, ask questions to understand context, extract key insights to the right KB locations, archive the original file.
**Content Distribution - **Don't just file content in one place! Spread relevant insights across ALL domains where they're useful. Example: knowledge on AI adoption might appear in KB domains for DevEx Tooling and Internal Evangelism.
Formatting/style - Ingest all knowledge into 4 "buckets": Facts, Assumptions, Actions, or Questions. Add timestamps: YYYY-MM-DD, Tag changes: ADDED, UPDATED, DEPRECATED, and write like an Amazonian (direct, objective, <30 words/sentence).
Answering questions - Search multiple KB locations (not just one), show different perspectives (even contradictory ones), express doubt and raise questions, explain how thinking evolved over time, and suggest who to talk to for clarification.

Here's a snippet for handling knowledge conflict:

## Escalation Procedures

### When Classification is Unclear:
1. Analyze content for strategic vs tactical value
2. Check for reusability across multiple initiatives
3. Consider long-term decision-making value
4. If still unclear, output to `00_meta/intake/temp/` and flag for user review

### When Integration is Complex:
1. Map content to multiple domains if applicable
2. Create multiple cross-references as needed
3. Update multiple appendix files if insights span domains
4. Document integration rationale for future reference

### When Knowledge Base Conflicts Arise:
1. Identify conflicting information with timestamps
2. Flag conflict in relevant appendix with UPDATED tag
3. Research most current authoritative source
4. Update decision log with conflict resolution rationale

---

**Remember: The knowledge base is a strategic asset. Every document interaction should strengthen its value for long-term decision-making while keeping tactical/ephemeral content properly separated and organized.**

Bottom line: AGENTS.md is a semi-structured rulebook that lives in the context of every conversation and serves to keep my KB organized, connected, and valuable over time (preventing it from becoming a messy file dump).

Phase 3: Tightening my process with .cursor/rules/*.mdc

Soon, my AGENTS file grew to 1,000+ lines covering both the philosophy and workflow of my KB; however, I found that Cursor did not efficiently apply some of my more deterministic instructions, especially when processing larger quantities of new information.

To solve for this, I extracted specific rules into .mdc files stored in .cursor/rules directory, which serves as the tactical enforcement layer. Most of my rules are:

Scoped by specific file patterns, applied globally or not, triggered intelligently based on AI relevance detection, or invoked manually with @-mentions.
Nested in subdirectories (e.g., backend/.cursor/rules/) and automatically activated when relevant files are referenced, enabling modular, domain-specific guidance without overwhelming the AI with irrelevant context.
Split into multiple, composable rules under 500 lines, with concrete examples or referenced files with laser-focused guidance.

Here's an example of a writing style rule for the KB domains where content will likely be shared internally or externally:

---
description: Amazon Writing Style for docs to share
globs: ["04_external_blogs/**/*.md", "06_internal_content/**/*.md"]
alwaysApply: true
---

- Keep sentences under 30 words
- Replace adjectives with numbers: "faster" → "reduced latency from 10ms to 1ms"
- Eliminate weasel words: "would help", "might improve", "arguably best"
- Format acronyms on first use: "Non-Disclosure Agreement (NDA)"

In conclusion, we now have a clear division of labor:

AGENTS.md is my strategic guide explaining why multi-domain distribution matters and how to think about contradictory information
.cursor/rules/*.mdc enforces the must-follow formatting standards: the four-bucket system (Facts, Assumptions, Actions, Questions), keyword-based domain classification, and Amazon Writing Style compliance

When do we need true RAG?

At some point, we're going to see cracks as it scales. Here's how I'll eventually need to rebuild as an enterprise RAG-based knowledge management system:

File count limits - Cursor's Turbopuffer indexing works well up to roughly 10,000-50,000 files, which will take me 28 years to hit at my current pace. But for a team of 28 engineers (imagine a shared KB repo with a department), I'll hit that limit in 12 months. This is where we'd eventually migrate to an Enterprise RAG system based on distributed vector databases (Pinecone, Weaviate, Qdrant) linked via MCP to Cursor.
Search sophistication - Turbopuffer's k-means search is good, but enterprise needs some hybrid search (semantic + keyword + metadata filtering, etc), multi-hop reasoning across documents, and possibly citation tracking.
**Cost at scale - **Running frontier models (Sonnet 4.5) at scale for every query gets expensive with hundreds of daily queries, especially if you forget to turn off Max mode. Cursor is already working on this problem - for example, Auto mode and Composer-1 - but currently there's strong demand for smaller, fine-tuned models for routing, caching layers for common queries, batch processing for bulk updates, and cost-aware model selection

Our living breathing KB

Story time: Last week, I asked my KB to identify the top 10 people and I should build relationships with based on my 2026 goals. One of the individuals it highlighted was Terry. Why? Because 1) Terry told me in our 1:1 that "her real work day starts at 5 PM when the meetings end and it's finally quiet", 2) in the past few meetings, a disproportionate number of action items were allocated to her, and 3) that the org would be crippled if she left 😭. So, I told her exactly that and we had a great conversation on setting boundaries.

The system keeps getting better as I feed it more data. A random hallway conversation gets transcribed and filed. A Slack thread about a production incident finds its way into three different KB domains. The context compounds!

Stay tuned for more posts about the thorny distributed systems problems we're tackling at GEICO (and of course reach out if you want to learn more about joining the team)! 🦎

GEICO Tech #BuildWithUs