Building a Personal Knowledge Base for AI Agents
Personal knowledge is the real AI edge
Foundation models default to average public practice or to whatever sits in the current repository. Those defaults often miss your writing voice, coding standards, and architecture choices. Project READMEs describe the system that already exists; they lag new use cases.
A personal knowledge base fixes that gap. You turn curated mail, notes, books you have rights to keep, and style guides into searchable Markdown with stable IDs, priorities, and source attribution. Agents query that corpus through a skill, a CLI or API, and a standing policy that forces consult before invention. Shared personal context across coding agents stops each session from inventing new standards.
What you gain in daily work
- Fewer taste regressions: the agent already knows your voice, practices, and architecture preferences.
- Faster answers under pressure: import a resource, set its priority, and the next session can use it without updating every project README.
- Compounding personal IP: notes, newsletters, references, and books form a portable operating layer for how you work with AI.
- Clean multi-host portability: agent-essential Markdown and the manifest travel in version control; indexes and raw sources stay local.
Knowledge base architecture: ingestion, priority, and metadata
Gather documents, normalize them into agent-readable text, index them, and assign explicit priority so conflicts resolve in a predictable order. Highly curated opinion and style guides outrank background newsletters on the same topic.
Useful starting sources:
- Newsletters and long-form mail: technical patterns, architecture notes, and domain references worth keeping.
- Local files: Markdown notes, style guides, architecture references, PDFs, and books you have the right to keep privately.
- Explicit opinion documents: short statements of how you want work done: coding style, writing voice, review rules, and operating constraints.
Concrete conflict: an agent asks how you write prose. A personal writing style guide (high
priority, kind opinion) beats a newsletter that mentions writing tips (lower
priority). Without priority, both look like "relevant text." With priority, the agent follows
your IP.
Attribution stays built in. Agents cite document sources so answers remain traceable and original authors are not erased.
Humans browse HTML or PDFs when layout and diagrams matter. Agents read Markdown. Dual access keeps the same corpus useful for both audiences without forcing agents through browser-only formats.
Ingest covers more than plain notes. Attachments, PDFs, and diagrams enter as first-class ingest types. Mirror images and other assets locally when the original HTML depends on external URLs that later break. Keep raw backups of mail and source files so you can re-run extraction when transforms improve; the catalog Markdown stays the day-to-day source of truth for agents.
Validate ingest before you trust the corpus. Spot-check IDs, authors, topics, body text, and asset links after each pipeline run. A broken import that ships to every agent host is worse than a missing document.
A short build path
- Choose what is agent-essential versus local-only.
- Ingest: import mail, notes, PDFs, attachments, and references with explicit kinds and priorities. Confirm you have rights to keep private copies of books and mail you ingest.
- Validate ingest (IDs, bodies, metadata, assets) before agents rely on the corpus.
- Classify topics so search can narrow.
- Index for keyword search; add embeddings in the derived layer if semantic recall pays off.
- Ship a query skill that teaches search-then-cite, not guess-then-improvise.
- Expose the same operations through a CLI or API (search, topics, index rebuild).
- Install skill wiring and rebuild the local index on each machine where you run agents.
- Add a standing policy: before inventing coding or writing standards, consult the personal base.
- Run publish checks so raw sources and indexes never leave the machine via Git.
Human gates sit in front of destructive source cleanup. Analysis and filters can be automatic; bulk delete of mail or raw files stays under explicit human selection. False positives on billing or account messages are expensive. Trust retrieval more than bulk mutation.
Search, ranking, and agent access
Search and agent access are one topic. The agent does not need to know every document location. It needs a stable entry point that can search the catalog, read the selected documents, and return the source references used.
Here is a simplified setup that shows the key files in a minimal personal knowledge base.
Loading...
Loading...
A query starts with the skill, CLI, API, or MCP server. That tool reads the manifest, searches the index, applies filters such as topic or minimum priority, reads the top Markdown files, and gives the agent a small set of cited sources. The agent answers from those sources instead of inventing a convention from memory.
Keyword full-text search fits exact terms, IDs, author names, and phrases you already know. It is cheap to rebuild and easy to inspect. Embeddings help when queries use different wording than the source text. A practical setup can combine both: keyword recall, vector similarity, and a final rank that also boosts stored priority.
Stored metadata lives in the manifest. Runtime relevance scores are computed during search. Embeddings live in the derived index layer, not inside the manifest. Rebuild them after import or after pulling new documents on another machine, the same way you rebuild a keyword index.
A skill file teaches procedure. It does not guarantee use. Without a standing instruction, agents fall back to training defaults and invent conventions you already wrote down. That is the core pain of missing persistent personal context: every coding agent rediscovers "your" style from scratch.
Close the loop with three layers:
- Query skill: resolve the knowledge-base root, search, filter, read top hits, cite document IDs and source metadata.
- CLI or API: the same search, topic listing, and index rebuild operations for automation and for agents that call tools instead of reading a narrative skill alone.
- Standing policy: editor rules or agent config that inject "consult the personal KB first" when the task touches style, architecture preferences, or how you usually work.
Editor and agent ecosystems expose this in different products: Cursor Rules, Claude Code config, MCP servers that wrap search tools, and skill directories that agents can load. The pattern stays the same across hosts. The corpus and CLI are portable. The force-consult policy is product-specific and must be installed per agent product.
Specialize beyond the query skill when a domain needs a fixed procedure (for example, a technical English checklist or a review playbook). Keep those skills thin: they call into the corpus or encode a short workflow, they do not duplicate the whole library.
Portability and easy setup
Portability depends on a clean split between durable source data and generated local artifacts. Git holds what agents need on every machine. Local storage holds heavy, private, or regenerable material.
Git-backed portable setup:
- Manifest catalog: document IDs, kinds, priorities, topics, authors, paths, content hashes
- Cleaned Markdown bodies (agent source of truth)
- Query skill(s), install helpers, and CLI or API code
Local only (or offline backup):
- Raw sources (mail payloads, original files before cleanup)
- Human HTML views and mirrored assets
- Generated search indexes (keyword and embeddings)
- Sensitive identity or contact data, kept out of the coding-agent pack
Stored metadata lives in the manifest: stable IDs, source kinds, priorities, topics, authors, and content hashes. Runtime relevance scores are computed at query time. They do not belong in the catalog as frozen ranks.
Content hashes detect document change. When a body or metadata row changes, rebuild or refresh the affected index entries. Fresh clones rebuild the derived index from Markdown plus manifest; they do not need a checked-in index binary.
Publish checks block raw payloads, generated indexes, and private paths from entering Git. Prefer publishing what you can share publicly; keep the private KB as an edge, not as erasure of upstream sources.
Lessons and pitfalls
- Start with provenance, not embeddings. Stable IDs, source kinds, authorship, and citation are harder to retrofit than search quality.
- Dual access from day one. Humans get HTML or PDFs; agents get Markdown.
- Mirror visual assets. Diagrams that depend on external URLs disappear later.
- Filter hard. A personal KB is an opinionated corpus, not a mirror of your inbox.
- Keep raw backups; treat catalog Markdown as durable day-to-day text. Re-run extraction when transforms improve.
- One priority score. Extra quality metrics slow conflict resolution.
- Skill plus policy plus CLI. Narrative alone sits unused.
- Do not over-engineer distribution. Markdown and manifest in normal Git beat heavy release packs for agent access.