この19システムシリーズの最終パートは少し遅れましたが、遅くともやらないよりはましです。
私が掘り下げてきた19システムに共通する6つのユニバーサルパターンは、このシリーズの根幹です。書き込み時の品質への投資。ファクトとともに旅をする来歴。RRF融合ハイブリッド検索。ヒートベースのプロモーションを伴う階層型ストレージ。明示的なコンテキスト予算。エージェントインターフェースにおける「ツール注入ではなくツール提供」。それぞれが独立した記事に値するのは、3つ以上のシステムが同じ原則に独立して到達したからです。
ユニバーサルパターンはここで終わりです。そこから、新興パターンが始まります。
この記事では、しきい値以下の8つのパターンについて説明します。これらは1つか2つのシステムに存在し、その実装は明らかに現実の問題に対処しているため、これらが希少なまま留まるとは信じがたいものです。7つは正確に1つのシステムに現れます。1つは2つのシステムに現れ、あと1つのシステムで採用されれば卒業です。最初のパターンが最も深い扱いを受けるのは、それが最も重要だからです。
初期段階であるということは、これらのいくつかは普遍化しないかもしれないということです。しかし、後手に回ることはさらに悪いです。2026年に、ある合成が「一回限りの癖」と呼んだためにストレージ層の認可なしでシステムを構築し、2027年にHacker Newsでプロンプトインジェクションのデモが公開されることになります。
ストレージエンジンだけが保持する権威
前回の記事では、エージェントがツールを保持すべきだと主張しました。エージェントにSQLツールを与えると、すぐに問題が生じます。どのテーブルを照会してはいけないのかを、何がエージェントに止めさせるのでしょうか？
単純なアプローチはよく知られており、すべて間違っています。
プロンプトレベルの指示：「あなたは会話テーブルを読むことを許可されていません。」これは協力的なモデルに対しては機能します。しかし、指示を誤解したり、禁止事項が現在のタスクに適用されないと判断したり、脱獄状態で動作しているモデルに対しては失敗します。
アプリケーションレベルのフィルター：sql_query ツールがモデルのSQLをラップし、禁止されたテーブル参照を解析し、データベースに渡す前にクエリを拒否します。これは単純なモデルに対しては機能します。しかし、テーブル名を引用符で囲んだり、ATTACH を使用したり、ラッパーとデータベースの間の解析の不一致を悪用したり、別の場所で定義されたビューを経由してルーティングするモデルに対しては失敗します。
ORM経由のアクセスのみ：エージェントは生のSQLに触れず、型付けされたメソッドを呼び出します。これは、システムがデバッグツール、分析ツール、マイグレーションツール、または「エージェントに2つのテーブルを結合させる」機能を追加するまでは機能します。その時点でルールは破られ、その破損は気づかれずに放置されます。
明確に言えば、これらはどれも強制ではありません。これらはヒントです。真のサブエージェント分離を望むシステムは、その上の層ではなく、ストレージエンジン自体に読み取りを拒否させる必要があります。これこそが、機能ベースのセキュリティがオペレーティングシステムリソースに課す規律です。カーネルが拒否し、アプリケーションが拒否するのではないのです。これはまた、PostgreSQLの行レベルセキュリティがマルチテナントSaaSに課す規律でもあります。ポリシーはデータベースに存在し、ORMには存在しません。なぜなら、「新しいマイクロサービスを構築したエンジニアがテナントフィルターを適用するのを忘れた」というバグクラスは、ストレージエンジンのポリシーだけが排除できるからです。
second-brain は、このコーパスにおける最初の実践例です。そのスコープ付きデータベースには3つの層があり、それぞれが必要であり、単独では十分ではありません。
スコープ付きエージェントごとに新しいインメモリSQLite接続。コンストラクタは :memory: を開き、実際のデータベースを読み取り専用モードでアタッチします。エージェントの接続には実際のメインスキーマはなく、次の層が配置するもの以外に読み取るものはありません。
メインスキーマ内のTEMP VIEWは、ソース内の許可されたテーブルにリダイレクトします。ビュー定義はエージェントのプロファイルから取得され、列レベルの編集や行レベルのフィルターをエンコードできます。ビュー名バリデーターは、プロファイルを介した悪意のあるテーブル名の注入を防ぎます。
SQLite C-API オーソライザーフックは、ビューを通過しないソーススキーマの読み取りを拒否します。このフックは、SQLiteが実行しようとするすべての読み取りに対して、オプティマイザがテーブル名を解決する前に発動します。ビュー本体内の読み取りは許可され、ビューがスコープフィルターとして機能します。トップレベルの読み取りは、スコープが作成したビュー名のセットに対してチェックされます。ソーススキーマに対する直接の読み取りは、例外なく拒否されます。
LLMは任意のSQLを記述できます。テーブル名を引用符で囲んだり、UNION を使用したり、ATTACH を使用したり、SQLiteの完全な文法を使用したりできます。しかし、許可リストにないテーブルから行を読み取ることはできません。なぜなら、オーソライザーがCレイヤーでテーブル名が解決される前に読み取りを傍受するからです。アプリケーションレベルのフィルターはバイパス可能です。ストレージエンジンの認可はバイパスできません。
約50行の stdlib Python。追加の依存関係、追加のプロセス、スキーママイグレーションは不要です。クエリごとのオーバーヘッドは読み取りごとに1つのCコールバックであり、クエリ自体のコストに比べて無視できます。このパターンは他のすべてとクリーンに構成できます。エージェントのツールレジストリは依然として機能ゲート可能であり、ビュー定義は列レベルの編集をエンコードでき、会話履歴は書き込み時に編集できます。これらの層はいずれも、ストレージ層の強制によって弱められることはありません。それらは強化されます。
枠組みが重要です。19システムにおける他のすべてのセキュリティパターンはヒントです。ストレージエンジンが権威なのです。
さらに3つの価値あるパターン
非同期クリーンアップの競合保護 (llm-wiki)
バックグラウンドメモリメンテナンスは、フォアグラウンドのユーザーアクションと根本的に競合状態にあります。プロジェクトAに対して開始されたスイープがプロジェクトBに対して終了すると、両方が破損します。Aの決定がBのレビューストアに移動されたり、BのアイテムがAのデータに対して解決済みとしてマークされたりします。これは、導入が容易で、検出が困難で、破損した状態が正当に見えるため、クリーンに回復することが不可能なバグクラスです。
llm-wiki は2段階のバックグラウンドレビューループを実行し、すべての譲歩ポイントで2つの競合保護シグナルを再チェックします。プロジェクトスイッチハンドラーによって発火される中止シグナルと、UIストア内の現在のプロジェクトに対するパス比較です。どちらかのチェックが失敗すると、スイープは決定を適用せずに途中で戻ります。キュー側のプロジェクトスイッチハンドシェイクが全体像を完成させます。アクティブなプロジェクトの状態をメモリをクリアする前にディスクにフラッシュし、処理中のアイテムを保留状態に戻し、実行中のLLM呼び出しと実行中のスイープ判断の両方を中止し、その後にのみ一時停止されたプロジェクトのパスに書き込みます。
メタパターンが教訓です。決定論的にできるところは決定論的に、LLMが必要なところはLLMに、どこでも中断可能に。2段階構造により、単純な存在確認で処理できるケースからLLMを遠ざけます。競合保護により、両方の段階が中断可能になります。この組み合わせは、あらゆるシステムにおけるバックグラウンドメモリメンテナンスループのテンプレートです。
自動劣化ノーオペレーションコンストラクタ (graymatter)
ライブラリAPI設計には繰り返し発生する緊張関係があります。最もシンプルな「Hello World」は、ライブラリがそのまま動作し、1行で構築、1行で呼び出せることを望みます。最も防御可能なプロダクション姿勢は、構築時に無視できない構造化エラーを伴って大声で失敗することを望みます。
graymatter は「沈黙の失敗」を選択しますが、そのトレードを生産的にする規律を伴います。コンストラクタは決してエラーを返しません。初期化に失敗した場合、bboltがロックされている、データディレクトリが書き込み不可、ベクターストアが開けない、stderrにログを出力し、すべてのメソッドがノーオペレーションである劣化したMemoryオブジェクトを返します。プロダクションの呼び出し元は、ハンドルを信頼する前に Healthy() を通じて確認します。ライブラリは go get 可能で、3行でインポートでき、デモで動作します。Healthy() がプロダクション規律の税金です。
このパターンにより、独自の起動儀式を持つエージェントハーネスにライブラリを安全に埋め込むことができます。起動中に [graymatter.New](https://graymatter.new/)(...) を呼び出し、エラーパスが存在しないためそれを無視し、続行するエージェントハーネスは、ハッピーパスでは動作するメモリ層を取得し、データディレクトリが読み取り専用の場合はメモリなしのフォールバックを取得します。どちらにしてもハーネスは起動します。これは、明示的なエラーハンドリングをすべての埋め込みサイトで要求する「大声で失敗する」コンストラクタでは提供できない、特定の種類の防御的構成です。
シャドウモード重複検出 (mem9)
重複抑制を出荷するすべてのシステムは、コサイン類似度しきい値を選択する必要があります。0.95以上はほぼ確実に重複です。0.7以下はほぼ確実に重複ではありません。その間の空間は議論の余地があり、適切なカットオフは埋め込みモデル、ドメイン、クエリ分布、およびこの特定のシステムにおける偽陽性と偽陰性のコストに依存します。
直感に基づいて1つを選び、出荷したいという誘惑は圧倒的です。mem9 はそうしません。すべてのファクトに対して重複検出クエリを実行し、コサインスコアをPrometheusヒストグラムに記録し、アクションは実行しません。しきい値は、プロダクションデータがそれを正当化するまで延期されます。「ヒューリスティックではなく、観測値を出荷せよ。」
同じ論理は、すべてのメモリシステムにおけるすべてのしきい値決定に適用されます。再ランクしきい値。リコール信頼度カットオフ。階層プロモーションヒートゲート。インサイトマージ類似度ゲート。19システムのほとんどは、これらの値を推測して出荷します。mem9 は値を延期して出荷します。この規律は稀であり、結果はより良いものです。
さらに4つ、よりタイトに
テナントごとの物理データベース分離 (mem9)
共有ストアに対する WHERE tenant_id = ? フィルターの代わりに、mem9 は TiDB Zero を通じてテナントごとに別個のTiDBクラスターをプロビジョニングします。分離はストレージエンジン側です。アプリケーションは誤ってテナント間でクエリを実行できません。なぜなら、クエリする共有ストアが存在しないからです。これは、ストレージ層の認可と同じ最終状態のより粗い粒度のバージョンです。エンジンで強制される分離であり、アプリケーションではありません。歴史的にこれを非現実的にしていたインフラコストはなくなりました。TiDB Zero は自動プロビジョニングします。Neon は PostgreSQL で同じことを行います。Cloudflare D1 は SQLite で同じことを行います。
明示的なコンテキスト予算によるソースターンデコレーション (mem9)
取得されたメモリは文字列です。「ユーザーはPostgresを好みます。」正しく、簡潔で、コンテキストなしではグラウンディング不可能です。mem9 は、発信元の会話ターンをデコレーションとして添付し、クエリに対してスコアリングされ、最小スコア、メモリごとの制限、総制限のトリプル予算でキャップされます。「ユーザーはPostgresを好みます」を読むエージェントは、ユーザーが「MongoDBを試したけど、結合がひどかったので先四半期にPostgresに切り替えた」と言ったターンを取得します。2回目のツール呼び出しは不要です。グラウンディングは結果に含まれています。前提条件はすでに普遍的です。来歴とハイブリッド検索です。19システムのほとんどは、これを2日で実装できるでしょう。
4つ目のファイルとしての purpose.md (llm-wiki)
Karpathy の LLM Wiki パターンには、生のソース、Wiki ワーキングセット、構造ルール用の schema.md の3つの標準ファイルがあります。llm-wiki は4つ目を追加します。purpose.md はユーザーが記入し、システムが行うすべてのLLM呼び出しにインライン化されます。すべての取り込みプロンプト、生成プロンプト、チャット検索がそれを読み取ります。その効果は、下流のすべての動作を条件付ける安定した方向性の事前分布です。LLMはとにかくシステムプロンプトを読みます。ユーザーの意図を追加することはコストがかからず、すべてを向上させます。ほとんどの他のシステムにこれがないことは、llm-wiki に存在することよりも説明が困難です。
権威あるエージェント契約としての AGENTS.md (Tolaria, OpenContext)
ほとんどのリポジトリは AGENTS.md または CLAUDE.md をヒントファイルとして扱います。Tolaria と OpenContext はそれを契約として扱い、すべての拘束力のある条項を、エージェントがそれに違反した場合にビルドを失敗させる機械的なチェックでバックアップします。「pre-commitフックをスキップしない」というのは丁寧な要求ではなく、CIが強制するルールです。「テストカバレッジはしきい値を超えていなければならない」というのはガイドラインではなく、テストランナーが中止する基準です。ヒントは無視できます。チェックによってバックアップされた契約は無視できません。すでに2つのシステムがこれを行っています。あと1つで卒業です。
次に普遍化するのはどれか
ストレージ層の認可が最初に普遍化します。これはソース分析の中で最も確信のある予測です。サブエージェントにSQLアクセスを与えるすべてのメモリシステムは、ストレージ層の強制なしには、プロンプトインジェクションから機密性侵害まで一手です。インフラはすでに整っています。SQLiteは2000年代初頭から set_authorizer を持っています。PostgreSQL RLSは主流です。LanceDBとClickHouseにも独自のポリシーフックがあります。障壁は技術ではなく認識です。second-brain が実践例を提供しました。次世代のマネージドAPIはこの規律をコピーするでしょう。なぜなら、代替案は擁護不可能だからです。
ソースターンデコレーションが2番目に普遍化します。前提条件はすでに普遍的です。実装は2つのクエリと予算です。エージェント側の情報ゲインは十分に大きいため、マネージドAPIで最初に出荷した者は、ソースの対話における回答のグラウンディングにおいて、2番目に出荷した者よりも明らかに優れているでしょう。コピーする圧力は高いです。graymatter はファクトごとにソースを持っています。supermemory は来歴を持っています。Hindsight は完全な会話の来歴を持っています。これらのどれも、1つのPRでこのパターンになります。
自動劣化ノーオペレーションコンストラクタは3番目に普遍化し、異なる言語で行われるでしょう。Goの文化的条件はこのパターンを安全にします。次の採用者はPythonになる可能性は低く、その文化は例外に対してあまりにも熱心ですが、Rustかもしれません。これはメモリの選択ではなく、ライブラリAPI設計の選択であり、「デモの美学とプロダクションの規律」が適切なトレードオフである場所ならどこにでも広がるでしょう。
シャドウモード導入はダークホースです。技術的には簡単ですが、文化的には困難です。2番目のシステムがしきい値をゲートする前に計測すれば、パターンは即座に卒業し、3番目と4番目は1つのリリースサイクル内で続きます。なぜなら、エンジニアリングの人間工学は一度実証されれば反論不可能だからです。
残りの4つは、それぞれ特定の展開形状がより一般的になることに依存しています。競合保護は、より多くのシステムがマルチ会話並列性を採用するにつれて普遍化します。テナントごとの物理的分離は、規制対象のエンタープライズ顧客がそれを要求し始めるときに普遍化します。purpose.md は、Karpathy LLM Wiki パラダイムが3つ目または4つ目の実装を得るときに普遍化します。契約としての AGENTS.md は、「エージェントは同僚である」という枠組みが支配的なハーネスのメタファーになるときに普遍化します。どれもありえないものはありません。どれも確実ではありません。
結論
8つすべてに共通する統一的な糸は同じ立場です。アプリケーション層は信頼できる分離境界ではありません。ストレージ層の認可は、エージェントごとの表現です。テナントごとの物理データベースは、テナントごとの表現です。契約としての AGENTS.md は、エージェントの行動ごとの表現です。このコーパスの次の反復は、この予測において、その名前で新しいユニバーサルパターンを含むでしょう。
前回の記事では、エージェントがツールを保持し、何を取得するかを決定すべきであると主張しました。今回の記事は、エージェントがそれらのツールをあなたが予期しなかった方向に向けたときに何が保持されるかについてです。6つのユニバーサルパターンはコンセンサスです。ここにある8つは、コンセンサスが次にどこに移動するかを示す先行指標です。ストレージ層の認可は最先端の最先端であり、それを見逃すコストは、Hacker News に現れる種類のコストです。
