ワーカーエージェントは直接メモリに書き込むべきではない：キュレーター・エージェントパターン

マルチエージェント環境では、共有メモリの汚染はよくある課題です。r/openclawの開発者が、専用のMemory Curatorエージェントを介してすべてのメモリ書き込みをゲートするパターンを紹介しています。これにより、ワーカーエージェントが永続的な事実を直接書き込むのを防ぎます。このアプローチは、組織のトランスアクティブメモリ研究（Ren & Argote）や、MemGPT、MemoryBank、LEGOMem、Generative Agentsなどの既存のエージェントメモリシステムから着想を得ています。

Memory Curatorパターンの動作方法

ワーカーエージェントは決してメモリに書き込みません。代わりに、提案されたスコープとエビデンスを含む構造化されたメモリイベントを発行します。Memory Curatorエージェントは、各イベントを検証、編集、重複排除、4つのスコープのいずれかに振り分けるか、完全に破棄します。

4つのスコープ

• エージェントリポメモリ — 単一エージェントの永続的な設計上の決定（個々の専門家のメモリに相当）
• エージェントチームメモリ — エージェント間の手順、引き継ぎ基準、安全ルール（トランスアクティブチームメモリ）
• プロジェクトメモリ — 1つのエンゲージメントにおける現在の状態、決定、リスク
• セッションスクラッチ — おそらく残すべきではない一時的な観察（短期作業メモリ）

イベントスキーマ

イベントはJSON形式で、タイプタグ（fact、decision、preference、risk、procedure、hypothesis）とエビデンス参照、提案スコープを含みます。キュレーターは提案スコープを上書きでき、永続ストアへの唯一の書き込み可能エージェントです。

未解決の疑問

著者は2つの懸念を挙げています：

1. 過剰発行または過少発行 — イベント要件により、ワーカーがすべてを発行（氾濫）するか、発行をやめてしまう（有用な観察を失う）可能性。
2. 大規模環境でのルーティング精度 — 長いセッションではセッションとプロジェクトの境界が曖昧に、教訓が一般化するときプロジェクトとチームの境界が曖昧に。

リポジトリは github.com/jeongmk522-netizen/agent_memory_curator_agent にあります。開発者は、他の人が事前に書き込みをゲートするのか、後でクリーンアップパスを行うのか興味を持っており、後処理の方が簡単だが、汚染は除去よりも速く蓄積する可能性があると指摘しています。