Applying Karpathy's LLM Wiki Pattern: Building a Compounding Knowledge Base for Tech Sellers with IBM Bob
In April 2026, Andrej Karpathy introduced the LLM Wiki that transformed personal knowledge management. He proposed a shift away from messy, unstructured notes toward a compiled system where an AI maintains a structured, interlinked Markdown wiki.
Over the past two weeks, I’ve integrated this LLM Wiki concept into my workflow as a Customer Success Engineer, and it’s significantly improved how I manage customer context, product knowledge, and day-to-day execution. In this blog, I’m sharing my project structure, tailored agent instructions, and practical tips for anyone in tech sales looking to work more efficiently and make better use of AI. Here’s my GitHub repo
You can use any AI agent for this, but I chose IBM Bob because its custom modes let me tune its behavior. Custom modes allow Bob to operate as a focused expert with defined tools and behavioral guidelines. In my case, I’ve configured it as a CSE/Solution Architect copilot that tracks deal progression, technical requirements, POCs, and product positioning. The result is a system that stays grounded in both technical depth and business impacts.
First things first: why?
This agent assisted workflow made me a much more effective CSE. For example, I can get answers to these questions faster:
What is the current status of our engagement with [fictional company], and what are the key technical challenges they’re facing with their platform?
I am meeting with [fictional contact] for their data modernization initiatives, what should I be aware of?
Who are the internal stakeholders we should involve for a [fictional product] opportunity at [fictional company]?
What are the best practices we’ve documented for implementing [fictional technology] solutions? Which client engagements have successfully deployed this pattern?
What were the key technical discussions and decisions made during our meetings with [fictional contact]?
So, what is LLM Wiki?
LLM is a pattern for building personal knowledge bases using LLMs. Instead of just retrieving from raw documents at query time, the LLM incrementally builds and maintains a persistent wiki — a structured, interlinked collection of markdown files that sits between you and the raw sources. – Andrej Karpathy
Rawsources (meeting notes, contracts, daily logs). You (the human) edits this.Wikipages are interlinked Markdown documents generated by LLM. The AI organizes your notes into structured entity pages.index.mdis a catalog maintained by LLM. When answering a query, the LLM reads it first to find relevant pages.- Every interaction (ingest, query, lint) enriches the knowledge base. The system gets smarter with every call.
In technical sales, knowledge is our most valuable asset. We need to keep up to date with product and technologies (product architecture and competitive analysis), clients, and opportunities (stakeholders, timelines, success criteria). All of these may be in meeting notes, Slack threads, architectural diagrams and CRM records. When a deal gets complex, we may find ourselves lost amongst the details. A LLM Wiki then helps you maintain the knowledge base so you can find the information you need faster.
Quick Start
- Clone or copy this template to your project directory
1
git clone https://github.com/Henry-Xiao-HX/CSE-LLM-WIKI.git
- Verify
.bob/custom_modes.yamlis present (already included in template) - Switch Bob to CSE-LLM-WIKI mode:
- Open Bob
- Select “📚 CSE-LLM-WIKI” from the list of modes
- Customize domain context (optional): Edit
.bob/custom_modes.yaml - Create your first source document in
raw/(seeraw/SAMPLE-client-meeting.mdfor inspiration) - Tell Bob: “Ingest
raw/your-meeting-notes.md” - Bob will discuss key takeaways and ask for confirmation before creating wiki pages
LLM Wiki for Tech Sales
1
2
3
4
5
6
7
8
9
10
11
12
your-wiki/
├── .bob/
│ └── custom_modes.yaml # Bob wiki mode configuration
├── raw/ # Immutable source documents
│ ├── daily/ # Daily activity logs
│ │ └── YYYY-MM-DD.md # See SAMPLE-daily-log.md
│ └── [meeting-notes].md # See SAMPLE-client-meeting.md
├── wiki/ # LLM-generated knowledge pages
│ ├── [Client-Name].md # See SAMPLE-Client-Name.md
│ └── [Technology-Name].md # See SAMPLE-Technology-Name.md
├── index.md # Content catalog (see TEMPLATE-index.md)
└── log.md # Activity log (see TEMPLATE-log.md)
1. INGEST (Adding New Knowledge)
You can drop a new meeting note into raw/, or your research into a specific technology, or an architecture shared by your clients.
1
2
3
4
5
6
7
8
9
User: "Ingest raw/client-meeting-2026-03-15.md"
Bob will:
- Read and analyze the meeting notes.
- Discuss key takeaways with you to ensure accuracy.
- Create or update Client, Contact, and Technology pages in the Wiki.
- Update index.md to reflect new entries.
- Add cross-references across 10-15 related pages (e.g., linking a pain point to a product).
- Append a record of the change to log.md.
2. QUERY (Asking Questions)
Because the wiki is interlinked, your queries are more than simple keyword searches. Bob uses the index.md as a map to navigate your technical territory.
1
2
3
4
5
6
7
8
User: "What's the status of our opportunity with Client XYZ?"
User: "I am meeting with Client XYZ about Product A, what are some key concerns?"
User: "Across my clients, what are the key themes about Product B?"
Bob will:
- Read index.md to find relevant pages.
- Read identified wiki pages to gather context.
- Synthesize a comprehensive answer with citations to your original notes.
3. LINT (Health Checks)
In software engineering, a linter finds bugs. In an LLM Wiki, the LINT workflow should find the contradictions and gaps that occur in a fast-moving sales cycle.
1
2
3
4
5
6
7
User: "Run a lint check"
Bob will:
- Check for contradictions (e.g., "The client sponsor said $50k, but the CTO says $20k").
- Identify stale opportunity stages or missing cross-references.
- Suggest follow-ups or highlight information gaps.
- Fix structural issues and append a summary to log.md.
What to Track: The Sales Taxonomy
So what are some of the things we keep track as a CSE? What is the taxonomy we can utilize? Here’s what I ask Bob to keep track of.
Clients & Opportunities
- Overview: Industry, size, and relationship health.
- Opportunities: Pipeline status, value, timeline, and blockers.
- Technical Environment: Existing stack and architectural pain points.
- Success Criteria: What does a “win” look like for this specific client?
Contacts
- Role & Authority: Mapping the Champion, Economic Buyer, and Skeptics.
- Priorities: What does this specific person care about? (e.g., “Ease of use” vs. “Security”).
- Relationship Strength: Historical sentiment and recent interactions.
Products & Technologies
- Use Cases: How are your clients actually applying your tech?
- Architecture: Technical details on how you fit into their ecosystem.
- Objections: A repository of competitive positioning that worked.
Note: Do not create wiki files yourself. Bob will generate wiki pages when you ingest your source document. Work with Bob to modify the wiki files.
Key differences
You might ask: There are so many notetaking softwares. How is this different?
- Semantic Connections: It can link a technical objection in Account A to a solution you found for Account B automatically.
- The Compounding Effect: As the quarter ramps up, your notes become more complex. At that point, the real bottleneck is finding the information. The gap between manually searching and letting an LLM retrieve context becomes increasingly apparent as complexity grows.
Conclusion
The “Maintenance Tax” is what kills most personal knowledge bases. We start with high hopes and stop updating them when the quarter gets busy. By adopting the LLM Wiki pattern and using Bob as your automated maintainer, you stop paying that tax.
You move from taking notes to building an asset. Over time, this asset becomes your greatest competitive advantage, allowing you to walk into every call with the full, interlinked context of your entire territory.