AVM：AIエージェントのメモリを再考する
AIエージェントはすべてを忘れる。すべてのセッションはゼロから始まる。唯一の継続性は、最初に明示的に渡した内容だけだ。そしてナイーブな解決策は、すべてをMarkdownファイルの山に積み込んで全部読み込むことだ。
これはある程度は機能する。機能しなくなるまでは。
本当の問題はストレージではない
メモリの限界にぶつかると、ストレージについて考えるのが本能だ：データをどこに置くか？しかしそれは間違った問いだ。実際の制約はコンテキストウィンドウだ——エージェントはディスクから読まず、トークンから読む。メモリに入るすべてのものは、有限で高価なバジェットに収まらなければならない。
だから本当の問いは「どこにメモリを保存するか？」ではなく、「今、どのメモリを読み込む価値があるか？」だ。
この再定式化がすべてを変える。大きなディスクは必要ない。トークンコストを意識した検索システムが必要だ——クエリを見て、バジェットを超えずに最も関連性の高いコンテキストを返せるシステムが。
なぜファイルシステムなのか
AVMはエージェントのメモリを仮想ファイルシステムとして整理する。これは奇妙な選択に見えるかもしれない。なぜデータベースではないのか？ベクトルストアでは？グラフでは？
ファイルシステムが、私たちが持つ構造化情報のための最も普遍的なメンタルモデルだからだ。すべての開発者がパス、ディレクトリ、パーミッション、ファイル操作を理解している。さらに重要なのは：エージェントもそれを理解しているということだ。エージェントがすでに使っているツール——読む、書く、一覧表示、検索——がファイルシステム操作に直接マッピングされる。
より深い理由もある。メモリは単一のものではない。エージェントには共有すべきでないプライベートなノート、エージェント間で流通すべき共有知識、緊急シグナルのためのブロードキャストチャンネルがある。ファイルシステムはこれらの区別を可視化し、ナビゲート可能にする。フラットなデータベースにはそれができない。
/memory/private/{agent}/ ← あなただけのもの
/memory/shared/market/ ← 誰でも読める、専門家が書く
/memory/shared/events/ ← ブロードキャスト、誰でも書ける名前空間がポリシーだ。
メモリは上書きされるべきではない
何かについての意見を更新するとき、以前考えていたことを消去しない。古い観察の隣に新しい観察を追加する。歴史は重要だ——それがあなたの思考が進化した証拠だから。
AVMはデフォルトで書き込みを追記操作として扱う。新しい観察はそれぞれ新しいノードを作る。古いバージョンは残る。何かを想起するとき、システムはすべてのバージョンから最も関連性の高いノードを見つけ出し、トークンバジェット内で統合する。
これがメモリの正しいセマンティクスだ。上書きは設定に適している；知識には間違っている。二つのエージェントが同じ市場シグナルを独立して観察し、それぞれが分析を書いたなら、両方の分析が欲しい——最後に書いたものだけではなく。
/procの洞察
Linuxにはエレガントなトリックがある：/procはファイルシステムのように見えるが、そうではない。cat /proc/cpuinfoを実行するとき、ファイルを読んでいるのではなく——ライブシステム状態をテキストとしてフォーマットするカーネル関数をトリガーしている。ファイルシステムインターフェースは単なる普遍的なAPIだ。
AVMはメモリメタデータに同じことをする。すべてのノードには仮想サブファイルがある：
note.md:meta— ノードの重要度スコア、タイムスタンプ、来歴note.md:links— このノードが関連する他のノードnote.md:history— コンテンツが時間とともにどう変化したか:search?q=RSI— ディレクトリレベルの検索、ファイル読み取りとしてレンダリング
重要な洞察：ファイルシステムインターフェースは任意の操作を表現するのに十分完全だ。特別なクライアントライブラリは必要ない。新しいAPIを学ぶ必要もない。シェルコマンド、スクリプト、エージェント——ファイルを読めるものなら何でもすぐに動く。
マルチエージェントはファーストクラス
ほとんどのメモリシステムは単一エージェント用に設計されている。マルチエージェントサポートは後付けで追加される——通常は誰のデータかを区別するためにプレフィックスを付けることで。
AVMはマルチエージェントをファーストクラスの設計制約として扱う。パーミッションモデルは宣言的だ：各エージェントは特定の名前空間への読み書きアクセスを明示的に持つ。エージェントは誤って自分のプライベートコンテキストを別のエージェントに漏らすことができない。共有知識は明示的に共有名前空間に置かれなければならない。
これが重要なのは、エージェントが間違いを犯すからだ。機密な推論を共有名前空間に書き込むエージェントはそれを全員に公開する。別のエージェントのプライベートノートを読むエージェントは、見るべきでなかったコンテキストによって汚染されるかもしれない。パーミッションシステムは官僚主義ではなく——各エージェントが自分のコンテキストを信頼できるようにする境界だ。
「トークンバジェット」が本当に意味すること
トークンを意識した検索は最適化のように聞こえる。実際には設計哲学だ。
目標は古いメモリを削除することではなかった——削除は情報を破壊する。目標は特定のセッションに何が読み込まれるかを制御することだった。recall()はファイルを返さない；関連性、鮮度、重要度でスコアリングされ、指定されたトークンバジェットに収まるように刈り込まれた統合されたサマリーを返す。
これはデータベースクエリよりも人間の記憶の働き方に近い。あるトピックについての全記憶を検索するのではなく——コンテキストでフィルタリングされた最も顕著な部分を検索する。エージェントが自分でそのフィルタリングをしなくていいように、システムがそれを行う。
ファイルシステムの比喩、追記のみの書き込み、仮想ノード、宣言的パーミッション——これらは実装の選択ではない。同じ根本的な問いへの答えだ：エージェントにとって「記憶する」とはどういうことか？
保存することではない。検索することでもない。今役立つ形で、重要なことを本当に引き継ぐことだ。