LLM Wiki v2（16 分間の読了）
LLM Wiki v2 は、単なる知識蓄積を超え、信頼性スコアやライフサイクル管理を導入することで、大規模運用における AI エージェントの記憶システムを劇的に改善する重要な指針を示している。
キーポイント
記憶のライフサイクル管理の欠落解消
従来の Wiki アプローチは知識を恒久的に等価とみなすが、本稿では発見されたバグやパターンの鮮度・頻度を考慮した「記憶のライフサイクル」概念を導入し、古くなった情報の価値低下を自動処理する必要性を説く。
信頼性スコア（Confidence Scoring）の実装
各事実に対して、ソース数、最終確認日、矛盾の有無に基づいた数値の信頼性スコアを持たせ、LLM が「X については確信があるが Y は低い」といった不確実性を表現できるモデルへ進化させる。
AKBP プロトコルの開発発表
これらの知見に基づき、AI エージェント間で知識を永続的に作成・更新・検索・共有するための「Agent Knowledge Base Protocol (AKBP)」の構築を進めていると明かしている。
大規模運用からの教訓
Karpathy 氏のオリジナル案の核心（再計算せず蓄積する）は正しく、実運用では「スケーラビリティでの破綻点」や「Wiki が腐敗する原因」を特定し、修正した実践的な知見が提供されている。
影響分析・編集コメントを表示
影響分析
この記事は、LLM を活用した知識ベース構築における「静的な蓄積」から「動的で信頼性のある記憶システム」へパラダイムシフトを促す重要な提言です。特に AI エージェントが長期間にわたり自律的に動作する未来において、情報の鮮度と信頼性を自動管理するメカニズムの重要性を浮き彫りにしており、実装指針として業界全体に影響を与える可能性があります。
編集コメント
Karpathy 氏のオリジナル案の延長線上にあるが、実運用での「情報の腐敗」問題を解決する具体的なメカニズム（スコアリングとライフサイクル）を提示しており、実務家にとって非常に示唆に富む内容です。
LLM Wiki v2 — エージェントメモリ構築の教訓を踏まえた Karpathy の LLM Wiki パターンの拡張
LLM を用いた個人知識基盤の構築パターン。AI コーディングエージェント向けの永続的メモリエンジンである agentmemory（GitHub スター数 1 万超）の構築から得た教訓を拡張して取り入れています。
これは Andrej Karpathy のオリジナル LLM Wiki アイデアファイル に基づいています。オリジナルの記述はすべて依然として有効です。この文書では、本パターンを実環境で運用して得た教訓、つまりスケールした際に何が破綻するか、何が欠落しているか、そして有用なウィキと腐敗するウィキを分けるものは何かについて追加しています。
現在、私の発見に基づき、AI エージェント間で永続的な知識を作成・更新・取得・共有するためのプロトコルである AKBP: Agent Knowledge Base Protocol の開発を進めています。
オリジナルが正しく捉えている点
核心的な洞察は正しいです。再導出を止め、コンパイル（集約）を開始するのです。RAG（Retrieval-Augmented Generation：検索拡張生成）は取得して忘れ去りますが、ウィキは蓄積し複利効果を生みます。3 層アーキテクチャ（生データソース、ウィキ、スキーマ）は機能します。運用プロセス（取り込み、照会、リンティング）も基本を網羅しています。まだオリジナルを読んでいない場合は、そこから始めるべきです。
以下に、数千のセッションでこのパターンを構築・運用した後に発見された事項を示します。
欠落していたレイヤー：メモリのライフサイクル
元のWikiは、すべてのコンテンツを永遠に同等に有効なものとして扱います。しかし実際には、知識にはライフサイクルが存在します。先週発見したバグの方が、6ヶ月前のバグよりも重要です。12回目に確認したパターンは、一度しか見たことのないパターンよりも信頼性が高いです。新しいソースからの主張は、自動的に古い主張を弱めるべきです。
信頼度スコアリング。Wiki内のすべての事実は、信頼度スコアを持つべきです：それを支持するソースの数、最後に確認された時期、それに反証するものがあるかどうか。LLMが「プロジェクトXはキャッシュにRedisを使用している」と記述する場合、その主張は2つのソースから来たこと、3週間前に最後に確認されたこと、そして信頼度が0.85であることを認識しているべきです。信頼度は時間とともに減衰し、裏付けによって強化されます。これにより、Wikiは同等の重みを持つ主張の単なる平坦なコレクションから、LLMが「Xについてはかなり確信があるが、Yについてはそれほど確信がない」と言えるような生きたモデルへと変化します。
代替（上位置換）。新しい情報が既存の主張と矛盾する場合や更新する場合、古い主張は単に注釈付きで残しておくべきではありません。新しい主張が明示的にそれを置き換えるべきです。リンクされ、タイムスタンプ付きで、旧バージョンは保存されるものの「古くなった」とマークされます。ファイルだけでなく、知識自体に対するバージョン管理です。
忘却。 すべてのことを永遠に保存する必要はありません。一度も忘れないウィキはノイズだらけになります。保持曲線を実装してください：かつて重要だった事実でも、数ヶ月アクセスや再強化が行われていないものは、徐々に薄れていくべきです。削除されるのではなく、優先度が下がるのです。これは何かを引き出しの奥にしまう LLM 版のアプローチです。エビングハウスの忘却曲線がここでよく機能します。保持率は時間とともに指数関数的に減衰しますが、各再強化（アクセスや新しいソースからの確認）によって曲線はリセットされます。アーキテクチャ決定はゆっくりと減衰し、一時的なバグは急速に減衰します。
統合ティア。 生の観測事実と確立された事実は同じではありません。パイプラインを構築してください：
- ワーキングメモリ（作業記憶）：最近の観測事実で、まだ処理されていないもの
- エピソードメモリ（エピソード的記憶）：セッション要約で、生の観測事実から圧縮したもの
- セマンティックメモリ（意味記憶）：セッションを跨ぐ事実で、エピソードから統合されたもの
- プロシージャルメモリ（手続記憶）：ワークフローとパターンで、反復されるセマンティクスから抽出したもの
各ティアは、その下のものよりもより圧縮され、より確信に満ちており、より長寿命です。LLM は証拠が蓄積されるにつれて情報を上のティアへ昇格させます。これが「一度これを見た」から「これが仕組みだ」という変化をもたらす方法です。
平坦なページを超えて：ナレッジグラフ
元のウィキはウィキリンクを持つページです。それは機能しますが、構造化された構造を台無しにしています。実際には、ページの上にレイヤーとして積まれた型付きのナレッジグラフ（知識グラフ）が欲しいのです。
エンティティ抽出。 LLM がソースを摂取する際、単に文章を書くだけでなく、構造化されたエンティティを抽出すべきです。人物、プロジェクト、ライブラリ、概念、ファイル、決定などです。各エンティティには型、属性、および他のエンティティとの関係性が付与されます。「React」はライブラリであり、「認証移行（Auth migration）」はプロジェクトです。「Sarah」は認証移行の所有者であり、React に関する意見を持つ人物です。
型付きの関係。 すべての接続が等価ではありません。「使用している」「依存している」「矛盾する」「原因となった」「修正した」「代替する」といった関係性は、それぞれ異なる意味的重みを持ちます。「A は B と関連する」というリンクよりも、「A が B を引き起こし、3 つのソースによって確認され、信頼度 0.9」というリンクの方がはるかに有用です。
クエリのためのグラフ走査。 「Redis のアップグレードが与える影響は何ですか？」と質問された際、LLM は単なるキーワード検索を行うべきではありません。Redis ノードから開始し、「依存している」「使用している」などのエッジを介して外側へ歩き回り、すべての下流の要素を見つける必要があります。これにより、キーワード検索では見逃される接続も捕捉できます。
このグラフはウィキページを置き換えるものではなく、それを補完するものです。ページは読むためのもの、グラフはナビゲーションと発見のためのものです。
実際のスケーラビリティを持つ検索
元の手法は、すべてのページをカタログ化する単一のファイル index.md に依存しています。これはおそらく 100〜200 ページ程度までは機能しますが、それを超えるとインデックス自体が長すぎて LLM が一度のパスで読み込めなくなり、本格的な検索が必要になります。
ハイブリッド検索。 最良のアプローチは、3 つのストリームを組み合わせるものです：
- BM25（語幹抽出と類義語拡張を伴うキーワードマッチング）
- ベクトル検索（埋め込みによる意味的類似性）
- グラフ走査（エンティティ認識に基づく関係の探索）
これらの結果を相互順位融合で統合します。各ストリームは他が捉え損ねた情報をキャッチします。BM25 は正確な用語を検出し、ベクトルは意味的類似性を発見し、グラフは構造的な接続を見つけます。これらを組み合わせることで、単一の手法よりも優れた結果が得られます。
index.md を人間が読みやすいカタログとして維持しつつ、LLM の主要な検索メカニズムとしては約 100 ページを超えた段階では依存しないようにしてください。
オートメーション：手動からイベント駆動へ
元の手法における最大の実際の課題は、すべてが手動である点です。ソースを投入して LLM に処理を指示するだけで、定期的にリンティングを実行するのを忘れたり、回答を提出するタイミングを自分で決定したりする必要があります。
実際にはフックが必要です。自動的に発火するイベントとは以下の通りです：
- 新しいソースの追加時：自動取り込み、エンティティ抽出、グラフ更新、インデックス更新
- セッション開始時：直近の活動に基づき、ウィキから関連コンテキストを読み込む
- セッション終了時：セッションを観察結果に圧縮し、洞察を提出する
- クエリ発生時：回答を提出する価値があるか確認（品質スコアが閾値を超える場合）
- メモリ書き込み時：既存の知識との矛盾がないかチェックし、置換トリガーを発動
- スケジュール実行時：定期的なリンティング、統合、保持期間の減衰処理
キュレーションと方向性の決定には人間が関与し続けるべきですが、人々がウィキを放棄してしまう原因となる事務処理部分は完全に自動化されるべきです。
品質と自己修正
- Vector search (semantic similarity via embeddings)
- Graph traversal (entity-aware relationship walking)
Fuse the results with reciprocal rank fusion. Each stream catches things the others miss. BM25 finds exact terms. Vectors find semantic similarity. The graph finds structural connections. Together they beat any single approach.
Keep index.md as a human-readable catalog, but don't rely on it as the LLM's primary search mechanism past ~100 pages.
Automation: from manual to event-driven
The biggest practical gap in the original is that everything is manual. You drop a source and tell the LLM to process it. You remember to run lint periodically. You decide when to file an answer back.
In practice, you want hooks. Events that fire automatically:
- On new source: auto-ingest, extract entities, update graph, update index
- On session start: load relevant context from the wiki based on recent activity
- On session end: compress the session into observations, file insights
- On query: check if the answer is worth filing back (quality score > threshold)
- On memory write: check for contradictions with existing knowledge, trigger supersession
- On schedule: periodic lint, consolidation, retention decay
The human should still be in the loop for curation and direction. But the bookkeeping, the part that makes people abandon wikis, should be fully automated.
Quality and self-correction
すべての LLM 生成コンテンツが良いわけではありません。品質管理がないと、ウィキにはノイズが蓄積されていきます。
すべてにスコアを付けましょう。 LLM が作成するあらゆるコンテンツには品質スコアを付与すべきです。構造化は適切か？出典は引用されているか？他のウィキの記述と矛盾しないか？LLM に自己評価させるか、異なるプロンプトで第 2 のパスを実行して評価させます。閾値以下のコンテンツはレビュー対象としてフラグを立てるか、書き直します。
自己修復機能。 元の記事にあったリンチ操作（lint operation）は単なる提案ではなく、可能な箇所を自動的に修正するべきです。孤立したページはリンク付けするかフラグを立てます。陳腐化した主張にはマークを付けます。壊れた相互参照は修復されます。ウィキは、あなたが手動で指示を出すときだけでなく、自発的に健全な状態へと向かうべきです。
矛盾の解決。 元の記事では矛盾をフラグ立てることが言及されていますが、それは第 1 のステップに過ぎません。第 2 のステップはそれを解決することです。LLM は、情報の鮮度（source recency）、出典の権威性（source authority）、および支持する観測数の多さに基づき、どちらの主張がより正しい可能性が高いかを提案すべきです。人間が上書きすることは可能ですが、デフォルトの動作は通常正しくあるべきです。
マルチエージェントとコラボレーション
元の記事は単一ユーザー・単一エージェントを想定しています。しかし、多くの実際のユースケースでは、複数のエージェントや複数の人が同じナレッジベースに貢献するケースが含まれます。
メッシュ同期。複数のエージェントが並列で作業している場合（異なるコーディングセッション、異なる調査スレッド）、それらの観測結果は共有ウィキに統合される必要があります。多くのケースでは「最後の書き込みが勝つ」方式で十分です。競合が発生した場合は、タイムスタンプに基づく解決策を採用し、必要に応じて手動での上書きを可能とします。
共有とプライベートの区別。一部の知識は個人のものであるべきです（私の好み、私のワークフロー）。一方、プロジェクトアーキテクチャやチームの決定など、共有されるべき知識もあります。ウィキには適切なスコーピングが必要です。プライベートな観測結果は、昇格された際に共有知識へと統合される仕組みとします。
作業調整。複数のエージェントが同じナレッジベースで作業する際、軽量な調整メカニズムが必要です。「誰が何に取り組んでいるか」「何がブロックされているか」「何が完了したか」を把握できる程度で十分です。完全なタスク管理システムである必要はなく、重複作業の防止と進捗追跡に十分な機能があればよいのです。
プライバシーとガバナンス
原文ではこの点に触れられていませんが、非常に重要です。ソースには機密情報が含まれていることがよくあります：API キー、認証情報、非公開の会話、個人識別情報（PII）などです。
取り込み時のフィルタリング。ウィキにデータが到達する前に、機密データを除去する必要があります。API キー、トークン、パスワード、あるいは「プライベート」とマークされたあらゆる情報は自動的に削除されるべきです。これは手動で行うものではなく、自動化されるべきプロセスです。
監査証跡。ウィキ上でのすべての操作（取り込み、編集、削除、照会）は、タイムスタンプ、変更内容、およびその理由とともにログ記録される必要があります。これが責任追跡の層となります。ウィキ上で何かが不審な場合、監査証跡によってそれがどのようにしてそこに到達したのかを特定できます。
ガバナンスを伴うバッチ処理。 wiki が成長するにつれ、古くなったコンテンツの一括削除、サブセットのエクスポート、重複エントリのマージが必要になるでしょう。これらの操作は監査可能で、かつ元に戻せるものであるべきです。
結晶化：探索からの複合効果
原文では「良い回答は新しいページとして wiki に記録できる」と述べられています。これをさらに発展させることができます。
結晶化（Crystallization）とは、完了した作業チェーン（研究スレッド、デバッグセッション、分析など）を自動的に構造化された要約へと抽出するプロセスです。問いは何だったか？何が見つかったか？関連するファイルやエンティティは何か？どのような教訓が得られたか？この要約が wiki の主要なページとなり、教訓は知識基盤を強化するための独立した事実として抽出されます。
あなたの探索活動も、記事や論文と同様に情報源です。wiki はそれをそのように扱うべきです。結果を取り込み、グラフを更新し、既存の主張を強化または挑戦してください。
マークダウンを超えた出力フォーマット
原文ではスライドデッキに Marp を、チャートに matplotlib を使用すると言及されていますが、wiki の出力はマークダウンページに限定されるべきではありません。クエリに応じて、適切な出力形式は以下のようになります：
- 比較表
- タイムラインの可視化
- 依存関係グラフ
- 発見結果を提示するためのスライドデッキ
- さらなる分析のための構造化データエクスポート（JSON, CSV）
- チームメンバーへのブリーフィング
wiki は知識の保管庫です。出力フォーマットは、対象となる読者と問いの内容によって決定されます。
スキーマこそが真の製品である
原文はこれを暗示していますが、あえて明確に述べるなら：スキーマドキュメント（CLAUDE.md, AGENTS.md）がシステム内で最も重要なファイルです。 これは汎用的な大規模言語モデル（LLM: Large Language Model）を規律ある知識労働者に転換させるものです。そこには以下のような要素がエンコードされています。
- ドメイン内に存在するエンティティと関係性の種類
- 異なる種類のソースから情報を取り込む方法
- 新しいページを作成すべきか、既存のページを更新すべきかの判断基準
- 適用すべき品質基準
- 矛盾への対処法
- 統合スケジュールの概要
- プライベートな情報と共有情報の区別
あなたと LLM は時間とともにこのドキュメントを共進化させます。最初のバージョンは粗末なものになるでしょうが、数十件のソースを取り込み、数回のリンティング（lint）パスを経ることで、あなたのドメインが実際にどのように機能しているかを反映したスキーマが完成します。そのスキーマは移転可能です。同様のドメインで作業する他者と共有すれば、彼らはすぐにスタートダッシュを切ることができます。
実装のスペクトラム
これらすべてはモジュール化されています。初日にすべての機能が必要というわけではありません。
最小限の実行可能なウィキ: 生データソース + ウィキページ + index.md + 取り込み・照会・リンティングワークフローを記述するスキーマ。これは原文が概ね説明している内容です。これで動作します。ここから始めましょう。
ライフサイクルの追加: 信頼度スコアリング、置換（supersession）、基本的な保持期間の減衰機能。これにより、ウィキがごみ箱化することを防ぎます。
構造の追加: エンティティ抽出、型付き関係、ナレッジグラフ。これにより照会精度が向上し、フラットなページだけでは見逃す可能性のある接続性が浮き彫りになります。
自動化の追加: 自動取り込み、自動リンティング、コンテキスト注入のためのフック。ここがメンテナンス負担をほぼゼロに下げるポイントです。
スケーラビリティの追加: ハイブリッド検索、統合ティア、品質スコアリング。ウィキが数百ページを超えて成長した際に必要な機能です。
コラボレーションの追加: メッシュ同期、共有/プライベートスコーピング、作業調整。これはチームやマルチエージェント設定向けです。
ニーズに応じてエントリーポイントを選んでください。このパターンはあらゆるレベルで機能します。
なぜこれが重要なのか
Karpathy の元の洞察は依然として有効です：ボトルネックは書誌管理（bookkeeping）にあり、LLM はそのボトルネックを解消します。私たちが追加したのは、ウィキがスケールしても健全性を保つための仕組みです。ライフサイクル管理により知識の腐敗を防ぎ、構造により接続が失われないようにし、自動化により人間がファイル作業ではなく思考に集中できるようにし、品質管理により時間とともにウィキへの信頼を築きます。
Memex はついに構築可能になりました。それはより優れたドキュメントや検索があるからではなく、実際に作業を行う司書がいるからです。
*この文書は、Andrej Karpathy の LLM Wiki に、agentmemory で実証されたパターンを追加したものです。agentmemory は iii-engine を基盤とした AI エージェント向けの永続メモリエンジンです。元のアイデアファイルが基礎であり、この文書ではエンジンを構築する過程で得た知見を追加しています。*
原文を表示
LLM Wiki v2 — extending Karpathy's LLM Wiki pattern with lessons from building agentmemory
A pattern for building personal knowledge bases using LLMs. Extended with lessons from building agentmemory 10K Stars ⭐️, a persistent memory engine for AI coding agents.
This builds on Andrej Karpathy's original LLM Wiki idea file. Everything in the original still applies. This document adds what we learned running the pattern in production: what breaks at scale, what's missing, and what separates a wiki that stays useful from one that rots.
Currently, Working on AKBP: Agent Knowledge Base Protocol based on my findings, a protocol for creating, updating, retrieving, and sharing durable knowledge across AI agents.
What the original gets right
The core insight is correct: stop re-deriving, start compiling. RAG retrieves and forgets. A wiki accumulates and compounds. The three-layer architecture (raw sources, wiki, schema) works. The operations (ingest, query, lint) cover the basics. If you haven't read the original, start there.
What follows is what we found after building and running this pattern across thousands of sessions.
The missing layer: memory lifecycle
The original treats all wiki content as equally valid forever. In practice, knowledge has a lifecycle. A bug you discovered last week matters more than one from six months ago. A pattern you've seen twelve times is more reliable than one you've seen once. A claim from a newer source should weaken an older one automatically.
Confidence scoring. Every fact in the wiki should carry a confidence score: how many sources support it, how recently it was confirmed, whether anything contradicts it. When the LLM writes "Project X uses Redis for caching," that claim should know it came from two sources, was last confirmed three weeks ago, and sits at confidence 0.85. Confidence decays with time and strengthens with reinforcement. This turns the wiki from a flat collection of equally-weighted claims into a living model where the LLM can say "I'm fairly sure about X but less sure about Y."
Supersession. When new information contradicts or updates an existing claim, the old claim shouldn't just sit there with a note. The new one should explicitly supersede it. Linked, timestamped, old version preserved but marked stale. Version control for knowledge, not just for files.
Forgetting. Not everything should live forever. A wiki that never forgets becomes noisy. Implement a retention curve: facts that were important once but haven't been accessed or reinforced in months should gradually fade. Not deleted, but deprioritized. The LLM equivalent of moving something to a bottom drawer. Ebbinghaus's forgetting curve works well here: retention decays exponentially with time, but each reinforcement (access, confirmation from a new source) resets the curve. Architecture decisions decay slowly. Transient bugs decay fast.
Consolidation tiers. Raw observations aren't the same as established facts. Build a pipeline:
- Working memory: recent observations, not yet processed
- Episodic memory: session summaries, compressed from raw observations
- Semantic memory: cross-session facts, consolidated from episodes
- Procedural memory: workflows and patterns, extracted from repeated semantics
Each tier is more compressed, more confident, and longer-lived than the one below it. The LLM promotes information up the tiers as evidence accumulates. This is how you go from "I saw this once" to "this is how things work."
Beyond flat pages: the knowledge graph
The original wiki is pages with wikilinks. That works, but you're leaving structure on the table. What you actually want is a typed knowledge graph layered on top of the pages.
Entity extraction. When the LLM ingests a source, it shouldn't just write prose. It should extract structured entities. People, projects, libraries, concepts, files, decisions. Each entity gets a type, attributes, and relationships to other entities. "React" is a library. "Auth migration" is a project. "Sarah" is a person who owns the auth migration and has opinions about React.
Typed relationships. Not all connections are equal. "uses," "depends on," "contradicts," "caused," "fixed," "supersedes" carry different semantic weight. A link that says "A relates to B" is less useful than "A caused B, confirmed by 3 sources, confidence 0.9."
Graph traversal for queries. When someone asks "what's the impact of upgrading Redis?", the LLM shouldn't just keyword-search. It should start at the Redis node, walk outward through "depends on" and "uses" edges, and find everything downstream. This catches connections that keyword search misses.
The graph doesn't replace the wiki pages. It augments them. Pages are for reading. The graph is for navigation and discovery.
Search that actually scales
The original relies on index.md, a single file cataloging every page. This works up to maybe 100-200 pages. Beyond that, the index itself becomes too long for the LLM to read in one pass, and you need real search.
Hybrid search. The best approach combines three streams:
- BM25 (keyword matching with stemming and synonym expansion)
- Vector search (semantic similarity via embeddings)
- Graph traversal (entity-aware relationship walking)
Fuse the results with reciprocal rank fusion. Each stream catches things the others miss. BM25 finds exact terms. Vectors find semantic similarity. The graph finds structural connections. Together they beat any single approach.
Keep index.md as a human-readable catalog, but don't rely on it as the LLM's primary search mechanism past ~100 pages.
Automation: from manual to event-driven
The biggest practical gap in the original is that everything is manual. You drop a source and tell the LLM to process it. You remember to run lint periodically. You decide when to file an answer back.
In practice, you want hooks. Events that fire automatically:
- On new source: auto-ingest, extract entities, update graph, update index
- On session start: load relevant context from the wiki based on recent activity
- On session end: compress the session into observations, file insights
- On query: check if the answer is worth filing back (quality score > threshold)
- On memory write: check for contradictions with existing knowledge, trigger supersession
- On schedule: periodic lint, consolidation, retention decay
The human should still be in the loop for curation and direction. But the bookkeeping, the part that makes people abandon wikis, should be fully automated.
Quality and self-correction
Not all LLM-generated content is good. Without quality controls, the wiki accumulates noise.
Score everything. Every piece of content the LLM writes should get a quality score. Is it well-structured? Does it cite sources? Is it consistent with the rest of the wiki? You can have the LLM self-evaluate, or use a second pass with a different prompt. Content below a threshold gets flagged for review or rewritten.
Self-healing. The lint operation from the original should be more than a suggestion. It should automatically fix what it can. Orphan pages get linked or flagged. Stale claims get marked. Broken cross-references get repaired. The wiki should tend toward health on its own, not only when you remember to ask.
Contradiction resolution. The original mentions flagging contradictions. That's step one. Step two is resolving them. The LLM should propose which claim is more likely correct based on source recency, source authority, and the number of supporting observations. The human can override, but the default behavior should usually be right.
Multi-agent and collaboration
The original is single-user, single-agent. Many real use cases involve multiple agents or multiple people contributing to the same knowledge base.
Mesh sync. If multiple agents are working in parallel (different coding sessions, different research threads), their observations need to merge into a shared wiki. Last-write-wins works for most cases. For conflicts, timestamp-based resolution with manual override.
Shared vs. private. Some knowledge is personal (my preferences, my workflow). Some is shared (project architecture, team decisions). The wiki needs scoping. Private observations that roll up into shared knowledge when promoted.
Work coordination. When multiple agents work on the same knowledge base, they need lightweight coordination. Who's working on what. What's blocked. What's done. Not a full task management system, just enough to prevent duplicate work and track progress.
Privacy and governance
The original doesn't mention this, but it matters. Sources often contain sensitive information: API keys, credentials, private conversations, PII.
Filter on ingest. Before anything hits the wiki, strip sensitive data. API keys, tokens, passwords, anything marked private. This should be automatic, not something you remember to do.
Audit trail. Every operation on the wiki (ingest, edit, delete, query) should be logged with a timestamp, what changed, and why. This is your accountability layer. When something looks wrong in the wiki, the audit trail tells you how it got there.
Bulk operations with governance. As the wiki grows, you'll want to bulk-delete stale content, export subsets, or merge duplicate entities. These operations should be audited and reversible.
Crystallization: compounding from exploration
The original mentions that "good answers can be filed back into the wiki as new pages." This can be taken further.
Crystallization is the process of taking a completed chain of work (a research thread, a debugging session, an analysis) and automatically distilling it into a structured digest. What was the question? What did we find? What files/entities were involved? What lessons emerged? This digest becomes a first-class wiki page, and the lessons get extracted as standalone facts that strengthen the knowledge base.
Your explorations are a source, just like an article or a paper. The wiki should treat them that way. Ingest the results, update the graph, strengthen or challenge existing claims.
Output formats beyond markdown
The original mentions Marp for slide decks and matplotlib for charts. The wiki's output shouldn't be limited to markdown pages. Depending on the query, the right output might be:
- A comparison table
- A timeline visualization
- A dependency graph
- A slide deck for presenting findings
- A structured data export (JSON, CSV) for further analysis
- A brief for someone else on your team
The wiki is the knowledge store. The output format depends on the audience and the question.
The schema is the real product
The original implies this but it's worth being direct: the schema document (CLAUDE.md, AGENTS.md) is the most important file in the system. It's what turns a generic LLM into a disciplined knowledge worker. It encodes:
- What types of entities and relationships exist in your domain
- How to ingest different kinds of sources
- When to create a new page vs. update an existing one
- What quality standards to apply
- How to handle contradictions
- What the consolidation schedule looks like
- What's private vs. shared
You and the LLM co-evolve this document over time. The first version will be rough. After a few dozen sources and a few lint passes, you'll have a schema that reflects how your domain actually works. That schema is transferable. Share it with someone else working on a similar domain and they get a running start.
Implementation spectrum
All of this is modular. You don't need everything on day one.
Minimal viable wiki: raw sources + wiki pages + index.md + a schema that describes ingest/query/lint workflows. This is roughly what the original describes. It works. Start here.
Add lifecycle: confidence scoring, supersession, basic retention decay. This prevents the wiki from becoming a junk drawer.
Add structure: entity extraction, typed relationships, knowledge graph. This makes queries better and surfaces connections you'd miss with flat pages.
Add automation: hooks for auto-ingest, auto-lint, context injection. This is where the maintenance burden drops to near zero.
Add scale: hybrid search, consolidation tiers, quality scoring. This is what you need when the wiki grows past a few hundred pages.
Add collaboration: mesh sync, shared/private scoping, work coordination. This is for teams or multi-agent setups.
Pick your entry point based on your needs. The pattern works at every level.
Why this matters
Karpathy's original insight stands: the bottleneck is bookkeeping, and LLMs eliminate that bottleneck. What we've added is the machinery that keeps the wiki healthy as it scales. Lifecycle management so knowledge doesn't rot. Structure so connections aren't lost. Automation so humans stay focused on thinking rather than filing. Quality controls so the wiki earns trust over time.
The Memex is finally buildable. Not because we have better documents or better search, but because we have librarians that actually do the work.
*This document extends Andrej Karpathy's LLM Wiki with patterns proven in agentmemory, a persistent memory engine for AI agents built on iii-engine. The original idea file is the foundation; this adds what we learned building the engine.*
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み