エージェント・ハーネスにおけるメモリ状態の現状(12 分読)
本記事は、AI エージェントの実行環境である「ハルネス」におけるメモリ管理の複雑さを解明し、作業用・外部・パラメトリックという3つのメモリ概念を区別することで、業界が直面する未解決課題と今後のインフラ構築の方向性を示している。
キーポイント
エージェントハルネスの役割変化
Cursor や Devin などの環境は単なる実行場所ではなく、コンテキスト管理やツール協調を行う製品そのものへと進化しており、モデル自体よりもハルネス設計が重要視されている。
メモリ管理の3つの分類と特性
セッション中の「作業用メモリ」、セッションを跨ぐ「外部メモリ(ベクトルストア等)」、学習によって重みに埋め込まれる「パラメトリックメモリ」の3つが明確に区別され、それぞれ異なる課題を抱えている。
未解決の記憶問題と現状
セッション終了後の情報保持やコンテキストウィンドウの圧縮(compaction)といった問題は依然として未解決であり、各ハルネスが独自の解決策を試行錯誤している段階である。
2026 年の実装状況
2026 年時点では、実用化されているのは外部メモリのみであり、パラメトリックメモリ(重みへの知識埋め込み)は理論上の概念として存在するものの、生産環境での採用事例はない。
メモリ定義の明確化と限界
作業用(コンテキスト内)、外部(永続化ストレージ)、パラメトリック(重み内)の3層を区別し、検索ベースのシステムがパラメトリックに匹敵するにはΩ(k²)の例が必要という理論的限界がある。
主要ハッチの機能と欠陥
Claude CodeやCodexはセマンティック検索を欠きファイル名依存、Managed Agents は容量制限が厳しく個人用長期記憶には不向き、Copilot は引用検証に優れるが非構造化事実の扱いに弱みがある。
OpenClaw と Hermes のアーキテクチャと補完
OpenClaw はネイティブでセマンティック検索を持つが長期記憶の選別が不安定、Hermes は軽量なローカル層を持つが Mem0 などの外部プロバイダーなしでは検索精度に欠ける。
影響分析・編集コメントを表示
影響分析
この分析は、AI エージェント開発におけるインフラ設計の優先順位を再定義するものであり、単なるモデル性能向上ではなく、持続可能なメモリ管理システムの構築が今後の開発競争の核心であることを示唆しています。企業や開発者は、モデル選定だけでなく、ハルネス内のデータ永続化戦略を即座に再評価する必要があり、RAG やベクトルデータベースのアーキテクチャ設計がより重要視されるようになるでしょう。
編集コメント
モデルの性能競争が一段落しつつある現在、実装基盤であるハルネスの設計思想、特にメモリ管理の難解さが業界の次のボトルネックとして浮き彫りになっています。この記事は、開発者が単なる API の呼び出しを超えて、システム全体のデータフローをどう設計すべきかを考えるための重要な指針となります。
エージェント・ハルネスは、AI ソフトウェアが実際に実行される場所です。Cursor、Devin、Claude Code、Codex:これらの環境はコンテキストを扱い、ツールをオーケストレーションし、エージェントを調整し、ますます記憶(メモリ)を管理します。ソフトウェアを納品する製品として注目されているのは、モデルではなくハルネスの方です。
記憶(メモリ)の設計が難しくなるのがここです。
どこに配置されるのか?セッション終了時に何が保持されるのか?これは依然として未解決の問題であり、主要なハルネスはそれぞれ異なるアプローチでこの問題に取り組んでいます。
本稿では、各製品が実装した機能と、それぞれの不足点、そしてそのギャップが記憶インフラストラクチャに何を要求しているかについて解説します。
エージェントの記憶(メモリ)とは実際には何か
「記憶」と呼ばれるものは三つあり、それぞれ異なる故障モードを持つため、この区別は重要です。
- ワーキング・メモリ(作業記憶):セッション中にコンテキストウィンドウ内に存在するものです。セッション終了時にリセットされます。ウィンドウがいっぱいになった際に何が生き残るかという問題(圧縮問題)もここに属します。
- 外部メモリ:重み(ウェイト)の外に永続化されるあらゆるもの、すなわちベクトル・ストア、知識グラフ、ファイルなどです。セッションを跨いで保持されますが、重み自体は変化しません。2026 年現在、実運用環境の記憶(メモリ)のほぼすべてがここに存在します。
- パラメトリック・メモリ:勾配降下法を通じて重みに符号化された知識で、ハルネスが提供するトレーニング・ループによって形成されます。例を検索するのではなく規則を適用することで一般化します。2026 年現在、実運用環境でのデプロイメントはゼロです。
(認知科学における意味記憶/エピソード記憶/手続的記憶という分類は、保存される情報の種類を記述するものですが、上記の三つの階層は情報がどこに存在するかを記述するものです。)
論文「Contextual Agentic Memory is a Memo, Not True Memory」(arXiv:2604.27707) は、その上限を形式化しています。つまり、パラメトリックメモリが O(d) の重み更新で達成できることを、検索機能は Ω(k²) 個の保存済み例を必要とします。以下のすべてのシステムはこの制約内で動作します。
主要なハーンチス(Agent Harness)が提供した機能 [概要]
1.
Claude Code
2 つのトラックがあります。
一つ目は人間が作成した設定ファイルで、規約や指示を含み、セッション開始時に読み込まれます。もう一つは自動メモリ機能で、バックグラウンドの抽出エージェントによって Claude 自身が作成したメモであり、MEMORY.md インデックスを中心に ~/.claude/projects/<repo>/memory/ ディレクトリに保存されます。このインデックスは最大 200 行 / 25KB に制限されており、ユーザー、フィードバック、プロジェクト、参照の 4 つのカテゴリに分かれています。
検索機能によって限界が形作られます:Claude Code は各ターンで、ファイル名と説明のマニフェストを伴って小さなモデルに別々の呼び出しを行い、そのモデルがどのファイルをロードするかを選択します。埋め込みベクトルは使用されず、1 ターンあたりの最大ファイル数は 5 つです。上限を超えた部分は静かに切り捨てられ(カットオフ)、超過したファイルには警告が出ません(そもそもロードされないため)。
短所:選択基準がファイル名に基づくものであり、意味検索ではありません。そのため、名前が関連していれば、内容が関連していても勝ってしまいます。チーム共有機能は TEAMMEM フラグの背後に存在しますが、その下層ではローカルでリポジトリ範囲限定のマークダウンであり、意味的なインデックスはありません。
詳細はこちら:
mem0
@mem0ai
Claude Code のメモリソースコードを読みました。この制限により、エージェントのメモリーが静かに削除されてしまいます
Claude Code のメモリソースコードを読み込みました。
200 行のインデックス上限。1 ターンあたり最大 5 ファイル。埋め込みベクトルなし。
Claude が「あなたを覚えている」と言うとき、実際には何が起こっているのか、そしてその対策について詳しく解説します。
この漏洩...
Managed Agents
Managed Agents は、Claude Code のようなローカル製品ではなく、Anthropic が提供するホスト型エージェントランタイムです。セッションは、一度も変更されない追加のみ可能なイベントログであり、ロールバックと監査機能は後付けではなくアーキテクチャに組み込まれています。メモリストアは /mnt/memory/ としてファイルシステム上にマウントされ(ワークスペースあたり最大 8 つ、各々約 100KB)、すべての書き込みが不変バージョンとなります。複数のエージェントが一つのストアを同時に共有でき、競合ではなく監査可能な履歴を残すことが可能です。
短所です。これはワークスペース規模でのマルチエージェント協調のために構築されたものであり、長期的な個人用メモリ向けではありません。1 つのストアあたり 100KB という上限とワークスペースごとのスコーピングにより、セッションを跨ぐ個人コンテキストには、上位に構築されたパターンが必要です。
3.
Codex
Codex のメモリは、~/.codex/memories/ 内の 1 つのディレクトリ形式の Markdown で構成されます(SQLite も埋め込みベクトルも使用しません)。まず memory_summary.md が読み込まれ、必要に応じて MEMORY.md が grep され、さらに raw_memories.md、skills/ ディレクトリ、rollout_summaries/ ディレクトリが利用されます。この機能はデフォルトでは無効で、features.memories フラグをオンにする必要があります。
書き込みパスは 2 フェーズです。フェーズ 1 はロールアウトごとに行われます。セッションが 6 時間アイドル状態になると、Codex は厳格なスキーマに基づいて抽出を行い、機密情報を削除し、ローカル状態データベース(メモリディレクトリではなく)に書き込みます。フェーズ 2 はグローバル処理です。ロックの下で、統合サブエージェントがマージ、パッチ適用、または削除を行い、差分を書き出します。これは制限付き(最大 256 ロールアウト)、年齢ベースの剪定(30 日以内)、レート制限対応となっています。読み込みパスは意味論的ではありません。サマリーは固定の 5,000 トークンの予算に切り詰められ、それ以外の情報は MEMORY.md に対する grep で検索されます。
短所。5,000 トークンの要約は静かに切り捨てられ、grep は部分文字列のみを検索するため、言い換えられた事実は検出できません。6 時間のアイドルゲートにより、連続するセッションが統合されない可能性があります。状態はローカル限定であり、発売当初は EEA(欧州経済領域)、英国、スイスでは利用できませんでした。
詳しくはこちら:
mem0
@mem0ai
Codex CLI におけるメモリの仕組み
Codex CLI は、生成された非同期要約メモリストアを ~/.codex/memories/ に提供します。これは公式機能であり、developers.openai.com/codex で文書化されており、github.com/openai/codex で完全にオープンソース化されています。
4.
Copilot
Copilot の特徴的な動きは、その場での引用検証です。メモリエントリは構造化されたオブジェクト(主語、事実的内容、ファイルと行の引用、推論)であり、使用前にエージェントが現在のブランチに対して引用を検証し、コードによって矛盾するようになったメモリを再書き込みします。また、メモリは 28 日後に自動的に期限切れになります。
これは、公開された結果データを持つ唯一の展開済み陳腐化防止メカニズムです:A/B テスト(p<0.00001)により、メモリ有効時に PR マージ率が 83% から 90% に上昇し、コードレビューの精度が +3%、再現性が +4% 向上しました。この 7 ポイントの上昇は、コーディングエージェントにおけるメモリの唯一の公開された実世界プロダクション指標です。他社はすべてベンチマークを報告しています。
短所。引用スキーマでは、根拠のない事実や好みに基づく事実(「最小限の抽象化を好む」など)をきれいに保持できず、厳密にリポジトリ範囲内に限定されています。
OpenClaw のネイティブメモリは見た目以上に機能しています:~/.openclaw/workspace 内の Markdown(厳選された MEMORY.md と日付付きの日常ログ)が、埋め込みベクトルとハイブリッド検索(70% ベクトル、30% BM25)を備えたエージェントごとの SQLite インデックスによってバックアップされています。つまり、ネイティブで意味検索が可能です。
問題は、何が保存されるかです。ウィンドウがいっぱいになると、OpenClaw は「サイレント内部ターン」を発火させ、クリアする前に重要なコンテンツをディスクに書き込むようモデルに指示します。書き込まれる内容は、その 1 ターン内でモデルが決定したものに過ぎないため、長期メモリは選択的かつ一貫性に欠けます。Mem0 プラグイン()はこの依存関係を排除します:Auto-Recall は各ターン前に関連するメモリを注入し、Auto-Capture は各やり取りの後に永続化します(新しい事実は保存され、古くなったものは更新され、重複は統合されます)。これらはセッションの実行 ID と長期ユーザー ID にスコープされています。この 247,000 スターという採用数は、このギャップを埋めたことによる部分が大きいです。
詳細はこちら:
6.
: Hermes Agent
Hermes(135,000 スター、200 以上のモデル)は、3 つのビルトインレイヤーと 8 つのプラグ可能プロバイダーを搭載しています。レイヤー 1 は作業メモリで、MEMORY.md(2,200 文字)と USER.md(1,375 文字)からなり、合計約 1,300 トークンです。§区切りで利用状況ゲージを備え、容量の 80% で統合されます。書き込みはディスクに保存されますが、システムプロンプトには次回のセッションまでスナップショットが凍結された状態で保持され、プレフィックスキャッシュが維持されます。レイヤー 2 はスキルで、5 つ以上のツール呼び出しタスク後に記述された手続ドキュメントをスケジュールに基づいて厳選します。レイヤー 3 はセッション検索で、すべてのセッションにわたる SQLite FTS5(フルテキスト検索)を使用し、必要に応じて要約を行います。
短所。キャパシティは非常に小さい(永続的メモリで約800トークン)、FTS5 はキーワード検索のみ対応(「429 エラー」では「レート制限」にマッチしない)、かつローカル環境限定です。そのため、Hermes にはプロバイダースロットが用意されています。Mem0 を利用すればキャパシティの制限はなくなり、検索は意味的に行われ、抽出処理はサーバーサイドで実行され、書き込みは MEM0_USER_ID でスコープ制御されます。また、サービスがダウンした際にも組み込みレイヤーが動作し続けるようサーキットブレーカーが機能します。
詳しくはこちら:
mem0
@mem0ai
Hermes Agent にメモリを追加する方法
Hermes Agent は新たに 6 つのメモリプロバイダをサポートしました。Mem0 もその一つです。セットアップはコマンド 1 つで完了し、何か問題が起きてもサーキットブレーカーが作動します。このメモリシステムは、セッションを跨いだストレージ、検索、コンテキスト管理を担当します....
7.
Bedrock AgentCore
AgentCore は AWS が提供するホスト型エージェントプラットフォームです。その Runtime はハーンス層(Managed Agents に対する AWS の対応機能)であり、Memory は管理サービスとして提供されます。Memory は 3 つの非同期抽出戦略(意味的ファクト、嗜好、ナラティブ要約)を実行し、抽出に約 20〜40 秒、検索に約 200 ミリ秒を要します。変更されたファクトは削除されるのではなく「INVALID」としてマークされ、系譜情報が保持されます。発表されたベンチマーク結果:LoCoMo 70.58、PrefEval 79、PolyBench-QA 83.02。
短所。AWS 固有の機能(エコシステムへのロックイン)であり、発表された LoCoMo のスコアは主要なメモリシステムに比べて大幅に劣ります。
8.
Windsurf のメモリは、そのエンジンである Cascade によって生成・管理され、開発者によるワークフローは不要です。ローカル環境で、~/.codeium/windsurf/memories/ に保存されるワークスペーススコープのファイルにより、コードベースのパターンや規約が記録されます。
短所。記録されるのは Cascade の呼び出しであり、開発者のものではありません。メモリはワークスペーススコープ(プロジェクト間では不可視)かつローカル(デバイス間やチームでの共有不可)です。
- Cognition Devin
Devin はメモリを二つに分割します。知識は人間がキュレーションしたトリガー・コンテンツの事実であり、自動記録はありません。DeepWiki は参照ドキュメントで、30 ページ、100 件のノート、各 10,000 文字です。Devin はセッション後に知識を提案しますが、何かが保存される前に人間による承認が必要です。
短所。承認ゲートは品質を高保ちますが摩擦を生みます。レビューを行わないチームは何も蓄積できません。制限は控えめであり、知識は Devin のためにキュレーションされているため、他のツールへ移行することはできません。
メモリベンチマークが弱点である
業界で使われているメモリを測定するためのベンチマークのほとんどは不適切です。過去の会話からの事実の想起を検査しており、ほぼ飽和状態にあり、高いスコアが良い意思決定を予測するものではありません。
LoCoMo は一般的なもののうち最悪です。10 件の会話では比較が信頼できず、多くの質問にはメモリが必要ありません(単純な grep ベースラインで約 74% のスコア)。また、敵対的な質問は対象と表面的な類似性を共有するため、モデルはパターンマッチングによって勝利します。LongMemEval はまだ許容範囲です:5 つの能力(情報抽出、複数セッション推論、時間的推論、知識更新、拒絶)にわたる 500 件のキュレーション済み質問で、150 万トークンまでスケーリング可能。依然として想起中心ですが、実質的なテストです。
より深い問題は、それらのいずれも測定していない点にあります。MemoryArena(arXiv:2602.16313)は、行動を導く必要がある記憶をテストしますが、LoCoMo や LongMemEval に近い飽和状態にあるシステムはそこで失敗します。また、「Agentic Memory の解剖学」(Anatomy of Agentic Memory, arXiv:2602.19320)は、この批判を形式化しました(ほぼ飽和状態で、タスクの有用性ではなく類似度を測定している)。
そして、いずれも本番環境規模でのテストを行っていません。標準的なベンチマークは約 150 万トークンで頭打ちになる一方、本番のエージェントでは 1,000 万トークン以上が使用されます。BEAM(ICLR 2026)だけがその範囲を想定して構築されています。率直な結論として、この分野には新しいメモリベンチマークが必要であり、リーダーボードのスコアは懐疑的に読むべきです。以下に示すスコアも例外ではありません。
研究が示すものは依然として破綻している
安定性と可塑性のジレンマが再配置されました。外部メモリに移行しても、壊滅的な忘却(catastrophic forgetting)は終わっていません。「継続学習がメモリへ移行する時」(When Continual Learning Moves to Memory, arXiv:2604.27003)は、新しい記憶と古い記憶が、かつて重みで競合したのと同じように、検索スロットを巡って競合することを示しています。簡単なタスクからの生データ(raw trajectories)は、より困難なタスクに対してむしろ悪影響を与え(フォワード転移 −9.5%)、結果を悪化させます。
選択的忘却(selective forgetting)は未解決です。「MemoryAgentBench」(arXiv:2507.05257)では 4 つの能力が定義されていますが、システムは検索には対応していても、選択的忘却(古い事実をアンラーニングしつつ、その周囲の構造は保持する)には対応していません。
メモリは攻撃面です。「攻撃者は不要」(No Attacker Needed, arXiv:2604.01350)では、通常の使用下で 57〜71% のユーザー間汚染(cross-user contamination)が測定されました。また、ポイズニング攻撃(poisoning attacks)は 6〜38% で成功しています(arXiv:2601.05504)。
弱点における共通のパターン
同じようなギャップが繰り返される。ストレージは制限され、ローカルに限定されている(Claude Code は 25KB、Hermes は 2,200 文字、Codex のロード容量は 5,000 トークン)。検索機能の多くはキーワードベースである(Claude Code はファイル名で、Codex は grep で、Hermes は FTS5 を使用)。意味的に検索を行う 2 つのシステムは、ローカルかつ圧縮処理に制限されている(OpenClaw)か、クラウドにロックされている(AgentCore)かのいずれか。メモリはハッチスコープ(ハッチ内限定)であるため、Claude Code のメモリは Codex には無関係である。鮮度管理機能はほとんど存在しない(Copilot を除く)。そして分離性は後付けの考えであり、その結果が汚染数の多さとなっている。これらがハッチ境界における限界である。
Mem0
Mem0 は、ハッチ境界が問題の終着点ではないケースのために構築されたものである。そのアーキテクチャはハイブリッド型で、意味的な検索のためのベクトルストア(vector store)、関係推論のための知識グラフ(knowledge graph)、そして高速なメタデータ処理のためのキーバリュー(key-value)を備えている。
v3 アルゴリズム(2026 年 4 月)では、シングルパスの ADD のみによる抽出、マルチシグナル検索(意味検索 + BM25 + エンティティリンクをワンパスで実行)、およびベクトルストア内でのエンティティリンクへと移行し、v2 で使用されていた外部グラフデータベース(graph DB)を廃止した。
これは、クエリあたり約 6,900 トークンと 1.44 秒の処理で達成されており、フルコンテキスト検索における約 26,000 トークンと 17.12 秒と比較して劇的な改善となっている。
ギャップへの対抗策:キャップのない外部ストレージ、表現が異なっていても先月の認証エンドポイントに関する議論を検出するマルチシグナル検索、ユーザーのネームスペース間での漏洩を防ぎ汚染率 57–71% をターゲットとするアイデンティティスコープ付きメモリ。これは理論上の話ではありません。Mem0 は上記すべてのハーンチ向けに提供されており、Claude Code プラグイン、Codex MCP サーバー、ファーストクラスの Hermes および OpenClaw プロバイダー、ネイティブ AWS Strands 統合として機能し、21 のフレームワークと 20 のベクトルストアに対応しています。メモリはハーンチごとの機能ではなく、インフラストラクチャそのものとなります。
現状について
メモリは今やインフラストラクチャです。主要なハーンチのすべてが実装しました。なぜなら、セッション内では能力を発揮しても、セッション間では記憶を失うエージェントは根本的に制限されているからです。
ハーンチネイティブの実装は現実的な進歩を遂げましたが、同じ境界で破綻します。ローカルストレージの制約、キーワード検索、ハーンチスコープ、弱い鮮度処理、そして分離ギャップです。
これらすべてを測定するためのベンチマーク自体も弱く、生産規模(BEAM)を検証する唯一のものについては、多くのシステムが報告していません。
全体として、Mem0 が埋めるために努力しているギャップは以下の通りです。ポータブルで、意味的に検索可能、クロスエージェント対応、かつ生産環境のエージェントが蓄積するトークン量にスケールしたメモリです。
文脈 #11
このブログは「In Context」シリーズの一部であり、AI エージェントのメモリとコンテキストエンジニアリングを扱う連載記事です。
Mem0 は、LLM および AI エージェント向けに設計されたインテリジェントかつオープンソースのメモリレイヤーであり、セッションを跨いで長期にわたるパーソナライズされ、文脈を意識した対話を実現します。
- 無料 API キーはここから取得できます:
- または、以下のリファレンスから Mem0 をセルフホストすることも可能です
References
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
原文を表示
Agent harnesses are where AI software actually runs. Cursor, Devin, Claude Code, Codex: these environments handle context, orchestrate tools, coordinate agents, and increasingly, manage memory. The harness, not the model, is increasingly the product that ships software.
Memory is where harness design gets hard.
Where does it sit? What persists when a session ends? It is a largely unsolved problem, and every major harness is solving it differently.
This post covers what each shipped, where each falls short, and what that gap says about what memory infrastructure has to do.
What Agent Memory Actually Is
Three different things get called memory, and the distinction matters because each has different failure modes.
- Working memory is what lives in the context window during a session. It resets on session end; the compaction problem (what survives when the window fills) belongs here.
- External memory is anything persisted outside the weights: vector stores, knowledge graphs, files. It survives sessions; the weights don't change. This is where essentially all production memory lives in 2026.
- Parametric memory is knowledge encoded into weights via gradient descent, shaped by the training loop the harness feeds. It generalizes by applying rules rather than retrieving examples. Zero production deployments in 2026.
(The cognitive-science split, semantic / episodic / procedural, describes what kind of information is stored; the three tiers above describe where it lives.)
The paper "Contextual Agentic Memory is a Memo, Not True Memory" (arXiv:2604.27707) formalizes the ceiling: retrieval needs Ω(k²) stored examples to match what parametric memory does with O(d) weight updates. Every system below operates within it.
What Major Harnesses Shipped [Overview]
1.
: Claude Code
Two tracks.
is human-authored config (conventions, instructions), read at session start. Auto-memory is Claude-written notes from a background extraction agent, stored under ~/.claude/projects/<repo>/memory/ around a MEMORY.md index capped at 200 lines / 25KB, in four categories: user, feedback, project, reference.
Retrieval shapes the limits: each turn Claude Code makes a separate call to a smaller model with a manifest of filenames and descriptions, and the model picks which files load. No embeddings, max five files per turn, and silent truncation past the cap (a dropped file gets no warning because it never loads).
Shortcoming. Selection is by filename, not semantic search, so a relevantly-named file wins over a relevant one. Team sharing exists behind a TEAMMEM flag, but underneath it's local, repo-scoped markdown with no semantic index.
Read more here:
mem0
@mem0ai
I read Claude Code’s memory source code. This one limit silently deletes your agent’s memory
I read through Claude Code's memory source code.
200-line index cap. 5 files per turn. No embeddings.
Here's exactly what's happening when Claude says it remembers you, and how to fix it.
The leak...
2.
: Managed Agents
Managed Agents is Anthropic's hosted agent runtime, not a local product like Claude Code. A session is an append-only event log that is never mutated, so rollback and audit are architectural, not bolted on. Memory stores mount at /mnt/memory/ as a filesystem (up to 8 per workspace, ~100KB each); every write is an immutable version, and multiple agents can share one store concurrently with an auditable history rather than conflicts.
Shortcoming. It's built for multi-agent coordination at workspace scale, not long-term personal memory. The 100KB-per-store ceiling and workspace scoping mean cross-session personal context needs a pattern built on top.
3.
Codex
Codex's memory is one directory of markdown, ~/.codex/memories/ (no SQLite, no embeddings): memory_summary.md read first, MEMORY.md grepped on demand, plus raw_memories.md, skills/, and rollout_summaries/. It's off by default behind a features.memories flag.
The write path is two-phase. Phase 1, per-rollout: after a session is idle six hours, Codex extracts against a strict schema, redacts secrets, and writes to a local state DB (not the memory dir yet). Phase 2, global: under a lock, a consolidation sub-agent merges, patches, or drops and writes the diff. It's bounded (256 rollouts), age-pruned (30 days), and rate-limit aware. The read path is non-semantic: the summary is truncated to a fixed 5,000-token budget, and anything else is found by grep over MEMORY.md.
Shortcoming. The 5,000-token summary truncates silently; grep is substring-only, so paraphrased facts are invisible; the six-hour idle gate means back-to-back sessions may never consolidate; state is local-only; and at launch the feature was unavailable in the EEA, UK, and Switzerland.
Read more here:
mem0
@mem0ai
How Memory Works in Codex CLI
Codex CLI ships a generated, async-summarized memory store at ~/.codex/memories/
It's a first-party feature:
documented at developers.openai.com/codex
and fully open-sourced at github.com/openai/codex....
4.
Copilot
Copilot's distinctive move is just-in-time citation verification. Memory items are structured objects (subject, factual content, a file-and-line citation, reasoning), and before use the agent validates citations against the current branch, rewriting a memory that the code now contradicts. Memories also auto-expire after 28 days.
This is the only deployed staleness mechanism with published outcome data: A/B tested (p<0.00001), PR merge rate rose from 83% to 90% with memory on, with code-review precision +3% and recall +4%. That 7-point lift is the only published real-world production metric on memory in a coding agent; everyone else reports benchmarks.
Shortcoming. The citation schema can't cleanly hold ungroundable or preference-based facts ("prefers minimal abstraction"), and it's strictly repo-scoped.
5.
OpenClaw's native memory is more capable than it looks: markdown in ~/.openclaw/workspace (a curated MEMORY.md plus dated daily logs) backed by a per-agent SQLite index with embeddings and hybrid retrieval (70% vector, 30% BM25). So it has semantic search natively.
The problem is what survives. When the window fills, OpenClaw fires a "silent internal turn" that asks the model to write important content to disk before clearing. What gets written is whatever the model decides in that one turn, so long-term memory is selective and inconsistent. The Mem0 plugin (
) removes that dependency: Auto-Recall injects relevant memories before each turn and Auto-Capture persists each exchange after it (new facts stored, stale ones updated, duplicates merged), scoped by session run_id and long-term userId. The 247,000-star adoption was driven substantially by this gap.
Read more here:
6.
: Hermes Agent
Hermes (135,000 stars, 200+ models) ships three built-in layers plus eight pluggable providers. Layer 1, working memory: MEMORY.md (2,200 chars) and USER.md (1,375 chars), ~1,300 tokens combined, §-delimited with a utilization gauge and consolidation at 80% capacity. Writes land on disk but the system prompt holds a frozen snapshot until next session, to preserve the prefix cache. Layer 2, skills: procedural docs written after 5+ tool-call tasks, curated on a schedule. Layer 3, session search: SQLite FTS5 over all sessions, summarized on demand.
Shortcoming. The cap is tiny (~800 tokens of durable memory), FTS5 is keyword-only ("429 errors" won't match "rate limiting"), and it's local. Which is why Hermes ships a provider slot: with Mem0 the cap is gone, retrieval is semantic, extraction runs server-side, writes are scoped by MEM0_USER_ID, and a circuit breaker keeps the built-in layers working if the service is down.
Read more here:
mem0
@mem0ai
How to Add Memory to Your Hermes Agent
Hermes Agent just added 6 memory providers. Mem0 is one of them. Setup takes one command. Circuit breaker if anything fails. The memory system handle storage, retrieval, and context across sessions....
7.
Bedrock AgentCore
AgentCore is AWS's hosted agent platform: its Runtime is the harness layer (AWS's analog to Managed Agents) and Memory is its managed service. Memory runs three async extraction strategies (semantic facts, preferences, narrative summary), ~20–40s to extract and ~200ms to retrieve; changed facts are marked INVALID rather than deleted, preserving lineage. Published: LoCoMo 70.58, PrefEval 79, PolyBench-QA 83.02.
Shortcoming. It's AWS-specific (ecosystem lock-in), and its published LoCoMo sits well below leading memory systems.
8.
Windsurf's memory is generated and managed by its engine, Cascade, with no developer workflow: local, workspace-scoped files at ~/.codeium/windsurf/memories/ capturing codebase patterns and conventions.
Shortcoming. What's captured is Cascade's call, not the developer's; memory is workspace-scoped (invisible across projects) and local (no cross-device or team sharing).
9.Cognition Devin
Devin splits memory in two. Knowledge is human-curated trigger-content facts (no auto-capture); DeepWiki is reference docs (30 pages, 100 notes, 10,000 chars each). Devin suggests Knowledge after sessions, but a human approves before anything is stored.
Shortcoming. The approval gate keeps quality high but is friction: teams that don't review accumulate nothing. Limits are modest, and Knowledge is curated for Devin, so it doesn't transfer to other tools.
Memory Benchmarks Are the Weak Link
The benchmarks the field uses to measure memory are mostly bad. They test recall of facts from past conversations, they're near-saturated, and a high score doesn't predict better decisions.
LoCoMo is the worst of the common ones. Ten conversations make comparisons unreliable, many questions don't require memory (a trivial grep baseline scores ~74%), and adversarial questions share surface similarity with their targets, so models win by pattern-matching. LongMemEval is still okay: 500 curated questions across five abilities (information extraction, multi-session reasoning, temporal reasoning, knowledge updates, abstention), scaling toward 1.5M tokens; still recall-centric but a real test.
The deeper problem is what none of them measure. MemoryArena (arXiv:2602.16313) tests memory that must guide action, and systems that near-saturate LoCoMo and LongMemEval fail at it; Anatomy of Agentic Memory (arXiv:2602.19320) makes the critique formal (near-saturated, measuring similarity not task utility).
And none test at production scale: standard benchmarks cap near 1.5M tokens while production agents hit 10M+. BEAM (ICLR 2026) is the only one built for that range. The honest conclusion: the field needs a new memory benchmark, and leaderboard scores should be read skeptically, including the ones below.
What Research Shows Is Still Broken
The stability-plasticity dilemma relocated. Moving to external memory didn't end catastrophic forgetting. "When Continual Learning Moves to Memory" (arXiv:2604.27003) shows new and old memories compete for retrieval slots exactly as they once competed for weights; raw trajectories from easy tasks hurt harder ones (forward transfer −9.5%).
Selective forgetting is unsolved. MemoryAgentBench (arXiv:2507.05257) names four competencies; systems handle retrieval but not selective forgetting (unlearning a stale fact while keeping the structure around it).
Memory is an attack surface. "No Attacker Needed" (arXiv:2604.01350) measured 57–71% cross-user contamination under normal usage; poisoning attacks succeed at 6–38% (arXiv:2601.05504).
The Pattern in the Shortcomings
The same gaps recur. Storage is bounded and local (Claude Code 25KB, Hermes 2,200 chars, Codex's 5,000-token load). Retrieval is mostly keyword (Claude Code by filename, Codex by grep, Hermes by FTS5); the two that search semantically are local-and-compaction-limited (OpenClaw) or cloud-locked (AgentCore). Memory is harness-scoped, so Claude Code's memory means nothing to Codex. Staleness handling barely exists (Copilot aside). And isolation is an afterthought, hence the contamination numbers. These are the limits of the harness boundary.
Mem0
Mem0 is built for the case where the harness boundary isn't the end of the problem. Its architecture is a hybrid: a vector store for semantic retrieval, a knowledge graph for relational reasoning, and key-value for fast metadata.
The v3 algorithm (April 2026) moved to single-pass ADD-only extraction, multi-signal retrieval (semantic + BM25 + entity linking in one pass), and entity linking inside the vector store, dropping v2's external graph DB.
It does this at ~6,900 tokens and 1.44s per query, against ~26,000 tokens and 17.12s for full-context retrieval.
Against the gaps: an external store with no cap; multi-signal retrieval that finds last month's auth-endpoint discussion even when the phrasing differs; identity-scoped memory that one user's namespace can't leak across, targeting the 57–71% contamination rate. And it isn't theoretical: Mem0 ships for every harness above, a Claude Code plugin, a Codex MCP server, first-class Hermes and OpenClaw providers, native AWS Strands integration, across 21 frameworks and 20 vector stores. Memory becomes infrastructure, not a per-harness feature.
Where Things Stand
Memory is now infrastructure: every major harness shipped it, because an agent that's capable within a session but amnesiac across them is fundamentally limited.
The harness-native implementations made real progress, but they break at the same boundary, bounded local storage, keyword retrieval, harness scoping, weak staleness handling, and isolation gaps.
The benchmarks meant to measure all this are themselves weak, and the one that tests production scale (BEAM) is the one most systems don't report.
Overall, these are the gaps Mem0 is working hard to fill: memory that is portable, semantically searchable, cross-agent, and scaled to the token volumes production agents accumulate.
In Context #11
This blog is part of In Context, a
blog series covering AI Agent memory and context engineering.
Mem0 is an intelligent, open-source memory layer designed for LLMs and AI agents to provide long-term, personalized, and context-aware interactions across sessions.
- Get your free API Key here:
- or self-host mem0 from our
References
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
関連記事
あなたのハネス、あなたのメモリ
エージェント構築の主流であるAgent harnessは、メモリと密接に関連する。クローズドなハネスを使用すると、サードパーティにメモリの制御を委ねることになり、強力なロックインを生む。そのため、ユーザーが自身のメモリを所有できるよう、ハネスとメモリはオープンであるべきだと主張する。
LLMエージェントのための適応型メモリ許可制御
研究者らが、LLMベースのエージェント向けに、長期記憶の内容を制御する適応型メモリ許可制御手法を提案した。これにより、幻覚や陳腐化した事実を含む大量の会話内容の蓄積や、高コストで監査困難な不透明なメモリポリシーへの依存を解決する。
EVA-Bench Data 2.0:3 ドメイン、121 ツール、213 シナリオ(9 分読了)
TLDR AI が公開した EVA-Bench データセットの第 2 版は、3 つのドメインにわたる 121 のツールと 213 のシナリオを含む評価データを提供し、AI ツール利用能力の評価基準を強化します。