ケン・W・アルジャー(Ken W Alger)はJuly 28, 2026、「Building the AI Memory Stack」シリーズのPart 2を公開し、エージェント型AIシステムには永続記憶とコンテキストウィンドウの間にActive Working Memoryと呼ぶ層が必要だと論じた。アルジャーによると、この考えはPart 1の執筆中に生まれたもので、用語集、「Memory as Infrastructure」、Context Hydrationのメモ、SDK仕様、Architecture Decision Records、GitHub、記事草稿を行き来していた。どの情報源も単独では完全な答えを持たず、それらが合わさって、1つの作業に必要な一時的な作業セットを形成していた。

アルジャーはコンテキストウィンドウをCPUキャッシュになぞらえる。高速で、一時的で、実行中の作業の間だけ利用できるものだ。キャッシュが自力で埋まらないのと同じく、コンテキストウィンドウも自動では満たされない。アルジャーのモデルでは、Active Working Memoryは推論が始まる前に作られる実行状態であり、文書の取得、ツール実行、状態復元、ポリシー評価、応答の正規化を経て組み立てられる。

中心的な区別は「Models reason. Applications assemble.」という一文にある。アルジャーは、モデルは文書を取得せず、どのGit commitが重要かを選ばず、ツール応答が古いかどうかも知らないと述べる。それらを担うのはアプリケーションである。Python SDK更新の例では、エージェントがパッケージ境界を説明するArchitecture Decision Recordを取得し、Active Working Memoryの用語集定義を読み込み、GitHub上の現在の実装を確認し、その後で初めてプロンプトを構築する。

アルジャーは、モデルの失敗とされる多くの事例は実際にはコンテキスト組み立ての失敗だとする。誤った証拠が取得された可能性があり、古い文書が優先された可能性があり、制約が作業セットに入らなかった可能性もある。推論は、アプリケーションがモデルに何を見せ、何を見せないかを決めた後にしか始まらないため、これらはモデルの問題である前にアーキテクチャの問題だという位置づけだ。

提案された記憶スタックは4層で構成される。Durable Memoryは知識を保持し、ストレージまたはアプリケーションが所有する。Active Working Memoryはタスク状態を組み立て、オーケストレーターが所有する。Context Windowは選ばれた情報を提示し、ランタイムが所有する。Modelは推論を実行し、LLMが所有する。アルジャーは、どの層も別の層の代替にはならないと述べる。より大きなコンテキストウィンドウは不適切な選択を直せず、より良いモデルも受け取っていない証拠については推論できないからだ。

アルジャーは検索とコンテキスト組み立てを分けて考える。検索はどんな情報が存在するかを問う。一方、コンテキスト組み立ては、あるタスクにどの情報を一緒に置くべきかを問う。同じモデル、同じコンテキストウィンドウ、同じ知識ストアを使う2つのシステムでも、一方が簡潔で関連性の高い作業セットを組み立て、もう一方が loosely related な素材でモデルをあふれさせれば、結果は異なる。

アルジャーによれば、Active Working Memoryを実在する層として扱うことで、コンテキスト組み立てはプロンプトエンジニアリングからシステムアーキテクチャへ移る。情報は、関連性、権威性、鮮度、形式、優先度についての判断を通過した後にだけ、その境界を越える。不要な文書はすべてContext Taxを増やし、冗長なツール応答はすべて注意を奪い合い、欠落した情報源はすべて、モデルがコンテキストウィンドウの内側から検知できない死角を生むという。

締めくくりでは、一時的な作業セットと永続記憶が区別される。アルジャーは、執筆中に組み立てた作業セットは記事の完成後に消えたが、記事そのものは残ったと述べる。エージェント型システムも同じ選択に直面する。何を今日の作業セットだけに属させ、何を明日の記憶にするのか、という選択である。

ケン・W・アルジャー(Ken W Alger)はJuly 28, 2026、「Building the AI Memory Stack」シリーズのPart 2を公開し、エージェント型AIシステムには永続記憶とコンテキストウィンドウの間にActive Working Memoryと呼ぶ層が必要だと論じた。アルジャーによると、この考えはPart 1の執筆中に生まれたもので、用語集、「Memory as Infrastructure」、Context Hydrationのメモ、SDK仕様、Architecture Decision Records、GitHub、記事草稿を行き来していた。どの情報源も単独では完全な答えを持たず、それらが合わさって、1つの作業に必要な一時的な作業セットを形成していた。

アルジャーはコンテキストウィンドウをCPUキャッシュになぞらえる。高速で、一時的で、実行中の作業の間だけ利用できるものだ。キャッシュが自力で埋まらないのと同じく、コンテキストウィンドウも自動では満たされない。アルジャーのモデルでは、Active Working Memoryは推論が始まる前に作られる実行状態であり、文書の取得、ツール実行、状態復元、ポリシー評価、応答の正規化を経て組み立てられる。

中心的な区別は「Models reason. Applications assemble.」という一文にある。アルジャーは、モデルは文書を取得せず、どのGit commitが重要かを選ばず、ツール応答が古いかどうかも知らないと述べる。それらを担うのはアプリケーションである。Python SDK更新の例では、エージェントがパッケージ境界を説明するArchitecture Decision Recordを取得し、Active Working Memoryの用語集定義を読み込み、GitHub上の現在の実装を確認し、その後で初めてプロンプトを構築する。

アルジャーは、モデルの失敗とされる多くの事例は実際にはコンテキスト組み立ての失敗だとする。誤った証拠が取得された可能性があり、古い文書が優先された可能性があり、制約が作業セットに入らなかった可能性もある。推論は、アプリケーションがモデルに何を見せ、何を見せないかを決めた後にしか始まらないため、これらはモデルの問題である前にアーキテクチャの問題だという位置づけだ。

提案された記憶スタックは4層で構成される。Durable Memoryは知識を保持し、ストレージまたはアプリケーションが所有する。Active Working Memoryはタスク状態を組み立て、オーケストレーターが所有する。Context Windowは選ばれた情報を提示し、ランタイムが所有する。Modelは推論を実行し、LLMが所有する。アルジャーは、どの層も別の層の代替にはならないと述べる。より大きなコンテキストウィンドウは不適切な選択を直せず、より良いモデルも受け取っていない証拠については推論できないからだ。

アルジャーは検索とコンテキスト組み立てを分けて考える。検索はどんな情報が存在するかを問う。一方、コンテキスト組み立ては、あるタスクにどの情報を一緒に置くべきかを問う。同じモデル、同じコンテキストウィンドウ、同じ知識ストアを使う2つのシステムでも、一方が簡潔で関連性の高い作業セットを組み立て、もう一方が loosely related な素材でモデルをあふれさせれば、結果は異なる。

アルジャーによれば、Active Working Memoryを実在する層として扱うことで、コンテキスト組み立てはプロンプトエンジニアリングからシステムアーキテクチャへ移る。情報は、関連性、権威性、鮮度、形式、優先度についての判断を通過した後にだけ、その境界を越える。不要な文書はすべてContext Taxを増やし、冗長なツール応答はすべて注意を奪い合い、欠落した情報源はすべて、モデルがコンテキストウィンドウの内側から検知できない死角を生むという。

締めくくりでは、一時的な作業セットと永続記憶が区別される。アルジャーは、執筆中に組み立てた作業セットは記事の完成後に消えたが、記事そのものは残ったと述べる。エージェント型システムも同じ選択に直面する。何を今日の作業セットだけに属させ、何を明日の記憶にするのか、という選択である。