しばらくの間、「prompt engineering」は大規模言語モデルから良い結果を引き出す技術に与えられた名前だった。初期にはそれで理にかなっていた。ほとんどの人が one-shot のインタラクションを使っており、主要なレバーは実際に言い回しのように感じられた。より明確に尋ね、例を追加し、形式を制約すれば、モデルはより良く振る舞った。
\nだが、その枠組みはもはや本当の問題に対して小さすぎる。
\nAIシステムが本番で失敗する際、問題は通常、モデルがシステムプロンプトにもう一つ賢い文が必要だったということではない。問題は、モデルが正しい情報を見ていなかったり、無関係な情報を見すぎていたり、正しい情報を誤った形式で見ていたり、あるいは一つのステップから次へと正しい状態を引き継げなかったりすることにある。言い換えれば、問題はプロンプトだけではなかった。問題はコンテキストパイプライン全体だったのだ。
\nだからこそ、context engineeringという言葉が広まったのだ。この言葉がAIの主流の議論に登場したのは2025年半ばで、Tobi Lütke と Andrej Karpathy が「prompt engineering」は信頼性の高いLLMシステムを構築する際の本当の作業を過小評価していると主張したときだった[1]。しかし、その根底にある学問は名前よりも古い。RAG、tool calling、memory system、summarization、evaluation loop を構築したことがあるなら、すでに context engineering の一部を行ってきたことになる。変わったのは、ついにその全体像を表す名前を手に入れたことだ。
\n最もシンプルな図式が欲しいなら、context engineering は外部世界とモデルのワーキングメモリの間にある層だ。
\nflowchart TD\n U[\"User request\"] --> CE[\"Context engine\"]\n\n I[\"Instructions and policies\"] --> CE\n R[\"Retrieved knowledge\"] --> CE\n M[\"Memory and saved state\"] --> CE\n T[\"Tool definitions and results\"] --> CE\n H[\"Recent conversation history\"] --> CE\n\n CE --> W[\"Model context window\"]\n W --> L[\"LLM reasons and acts\"]\n L --> O[\"Answer or tool call\"]\n O --> S[\"New memory, logs, and state\"]\n S --> CE\nこれが全てだ。
\nモデルは推論エンジンだ。コンテキストエンジンは、モデルが何を推論の対象とするかを決定する。
\nこの言葉が共鳴を呼ぶ理由の一つは、別々に進化してきたいくつかの流れを結びつけるからだ。
\nRetrieval-Augmented Generation（RAG）は、モデルが推論時に外部知識へのアクセスを必要とすることを教えてくれた[2]。ReAct は、モデルがツールを呼び出し、結果を観察し、そこから継続できるときに、推論と行動がより良く機能することを教えてくれた[3]。Memory の研究は、長時間稼働するアシスタントには、終わりのないトランスクリプトの蓄積ではなく、インデックス作成、retrieval、reading strategy が必要だと教えてくれた[4]。Long-context evaluation は、単により多くのトークンをモデルに詰め込むことが、より良いワーキングメモリを与えることと同じではないことを示した[5][6][7]。
\nこのように見ると、context engineering はこれらのアイデアの代替ではない。それらの上にある傘なのだ。
\nその傘が重要なのは、現代のAIシステムはもはや孤立したプロンプトではなく、次のステップのために指示、ドキュメント、構造化データ、ツールの出力、そして以前の状態を一時的なコンテキストウィンドウに組み立てる動的システムだからだ。LangChain は、context engineering を「LLM がそのタスクを実行可能に完了できるよう、適切な形式で正しい情報とツールを提供する作業」と定義したが、これは的を射ている[8]。
\n「plausibly complete the task」という言葉は、そこで大きな役割を果たしている。これが正しいテストなのだ。
\nエージェントが失敗した場合、最初の問いは「どうすればプロンプトをより賢くできるか」であるべきではない。
\n最初の問いは「モデルが成功するために必要なものを、実際に与えただろうか」であるべきだ。
\nPrompt engineering は依然として重要だ。それは単に、より大きな学問のサブセットになっただけだ。
\n古いメンタルモデルはこうだった：
\n| Prompt engineering | \nContext engineering | \n
|---|---|
| より良い指示を書く | \n情報環境全体を構築する | \n
| 単一のリクエストに焦点を当てる | \nマルチステップシステムに焦点を当てる | \n
| ほぼ静的 | \n動的でステートフル | \n
| 言い回しを最適化する | \n選択、構造、メモリ、ツールを最適化する | \n
| 単一のモデル呼び出しを改善する | \nループ全体を改善する | \n
この違いは、エージェントを構築した瞬間に明らかになる。
\nエンタープライズソフトウェアのサポートエージェントを構築しているとしよう。ユーザーが「なぜ私たちのAPIリクエストがタイムアウトするのですか」と尋ねたとする。
\nプロンプトの観点だけで考えるなら、言い回しを改善するかもしれない：
\nこれらは良い改善だ。しかし、不十分だ。
\n本当のシステム上の問いはもっと難しい：
\nこれが context engineering だ。
\nプロンプトはその中の一行項目に過ぎない。
\n実際には、context には推論時にモデルが見る全てのものが含まれ、単に見えるプロンプトだけではない[8][9]。
\nこれは通常、以下を意味する：
\nだからこそ、「コンテキストウィンドウを埋める」という言葉がこれほど中心的になったのだ。コンテキストウィンドウは、テキストが入る場所だけではない。それはモデルの一時的なワーキングメモリだ。そこに入る全てのものが注意を競い合う。
\nそして競争がキーワードだ。
\n余分なトークンは、単なる追加情報ではない。それは追加のノイズでもある。
\n現在のAI市場で最も一般的な誤解の一つは、大きなコンテキストウィンドウが context engineering の重要性を低下させたというものだ。
\n研究は逆の方向を指している。
\n『Lost in the Middle』は、モデルが長いコンテキストを不均等に使用し、関連情報が先頭や末尾付近にあるときは性能が良く、重要な情報が中間にあるときは性能が悪くなることを示した[5]。Databricks の long-context RAG study は、より多くの retrieved documents を追加することは役立つが、64k トークン以上で強い性能を維持したのはごく一部の最先端モデルだけだったと発見した[6]。Chroma の『Context Rot』レポートはさらに踏み込んで、入力長が増えるにつれ、単純なタスクであっても信頼性が低下し、特に曖昧性やノイズが導入されると顕著になると述べている[7]。
\nこれは多くのチームが苦い思いをして学ぶ部分だ。
\n大きなウィンドウは選択の必要性を排除しない。それらは、悪い選択のコストを最初は目立たなくし、後になってより痛みを伴うものにする。
\n長いプロンプトは、少なくとも4つの異なる方法で失敗しうる：
\nだからこそ、context engineering はトークンの最大化ではない。コンテキストウィンドウ内のsignal densityを最大化することなのだ。
\nここに、最近の最も優れたアイデアの一つが登場する。
\nJason Liu は、古典的な chunk-based RAG の次のステップは、「最も類似したパッセージ」だけを考えるのをやめ、search space の形状を考え始めることだと主張した[10]。彼の枠組みは特に有用で、多くのチームがすでに進んでいる進化を描き出しているからだ：
\n最初の3つは、retrieval されるものの改善だ。
\n4番目はより興味深い。それは、エージェントがコーパス自体について学ぶものを改善する。
\nFacets はモデルに周辺視のようなものを与える。上位の数チャンクだけを返すのではなく、システムは集約されたメタデータも返すことができる：
\nこれは重要だ。なぜなら、similarity search は検証が最も重要なものではなく、マッチングが最も容易なものに偏るからだ[10]。Retrieval system は、よく文書化された解決済みのインシデントを過剰に浮上させ、希薄で未だ未解決のインシデントを過小にする可能性がある。法的検索では、署名済みの契約を過剰に浮上させ、実際に注意を必要とする未署名のものを隠してしまう可能性がある。Facets はエージェントに、「何がマッチしたか」だけでなく、「近くに何が存在するか」を見るのを助ける。
\nこれは大きな概念的転換だ。
\nRAG は主に retrieval についてだった。
\nContext engineering はますますnavigationについてになっている。
\nContext engineering を具体化する最も簡単な方法は、それが実行する実際の仕事に分解することだ。
\n最初の仕事は、何がウィンドウに入るに値するかを決定することだ。
\nこれには retrieval、ranking、filtering、source choice、freshness check が含まれる。当たり前のように聞こえるが、ここで大量の品質が勝ち取られたり失われたりする。BRIGHT のようなベンチマークは、現実的な retrieval は表面的なセマンティックマッチングが示唆するよりもはるかに難しいことを示している[11]。Retrieval quality が弱い場合、下流でのプロンプトの磨き上げをどれだけ行っても、結果を完全に救うことはできない。
\nSelection は「関連するチャンクを見つける」だけではない。それは：
\n優れたシステムは、単純なシステムよりも少ないものを retrieve するが、より意図的に retrieve する。
\n2番目の仕事は、選択されたコンテキストがどのように表現されるかを決定することだ。
\n同じ情報でも、フォーマット次第で役に立つことも無用なこともある。Anthropic の tool-use guidance はこれについて明確に述べている。tool descriptions と interfaces はモデルの振る舞いを強く形作る[9]。Long-context prompting guidance も、XML tagging、source labeling、明確に分離されたドキュメントセクションについて同様の推奨を行っている[12]。
\n実際には、structure は以下を意味する：
\n短く、適切にラベル付けされた結果は、巨大な JSON blob をしばしば凌駕する。
\n3番目の仕事は、重要なものを破壊せずにコンテキストを削減することだ。
\nここが、多くのエージェントシステムが大幅に改善するか、大幅に悪化するかの分かれ目だ。
\nCompression は以下を意味しうる：
\nOpenAI の prompt caching ドキュメントは、プロンプトの順序が認知的な面だけでなく経済的な面でも重要であることを示している。静的な共有プレフィックスは先頭に置かれたときに安価で高速になり、cache hits は正確なプレフィックスの再利用に依存するからだ[13]。OpenAI のより新しい Responses API における compaction の取り組みは、長時間稼働するエージェントの履歴を、ウィンドウが一杯になる前によりトークン効率の良い表現に圧縮すべきものとして扱うことで、この考えをさらに推し進めている[14]。
\nCompression はオプションではない。唯一の問いは、それを意図的に行うか、コンテキストウィンドウが独自に劣化するのを任せるかだけだ。
\n4番目の仕事は、現在のターンを超えて何が持続すべきかを決定することだ。
\nここで多くのチームが同じ間違いを犯す。memory を transcript retention と混同するのだ。
\nしかし、良い memory は「全てを永遠に保持する」ことではない。LongMemEval は long-term memory を3段階の問題として捉える。indexing、retrieval、reading だ[4]。これが正しい考え方だ。Memory system は、モデルが完全な過去に溺れるのではなく、適切な瞬間に適切な過去の事実を回復するのを助けるべきだ。
\nこれは有用な区別をもたらす：
\n全てが working memory に留まれば、モデルは気を散らされる。全てが追い出されれば、モデルは連続性を失う。
\nContext engineering は、それぞれの層に何が属するかを決定する。
\n5番目の仕事は、ツールをモデルにとって判読可能にすることだ。
\nこれはこの学問の過小評価された部分だ。Tool surface は単なるソフトウェアAPI設計ではない。それは context design でもある。
\nモデルは以下を理解する必要がある：
\nだからこそ、tool descriptions はこれほど重要なのだ[9]。また、Jason Liu が tool results を強調しているのも重要だ[10]。ツールの出力は、単に現在のクエリに答えるだけではない。それはエージェントに、次のクエリについてどう考えるかを教えるのだ。
\nTool surface が MCP のようなプロトコルによって標準化されると、これはさらに重要になる。MCP はツール、リソース、プロンプトをLLMアプリケーションに接続することを容易にするが、どの情報を提示すべきか、どのようにフィルタリングすべきか、次のモデル呼び出しにどれだけ注入すべきかを決定しない[15]。プロトコルは配管だ。Context engineering は依然として職人技なのだ。
\n6番目の仕事は、いつコンテキストを共有すべきでないかを決定することだ。
\nこれは、おもちゃのデモと本番のエージェントの間で最も大きな違いの一つだ。
\n時々、正しい答えはより大きな共有プロンプトではない。分離されたスコープを持つ複数の小さなプロンプトなのだ。
\nAnthropic の multi-agent research system は強力な例だ[16]。彼らのサブエージェントは、別々のコンテキストウィンドウで並列に実行され、これにより問題の異なる分岐を探索できる。すべての中間的な詳細で互いを汚染することなく。LangChain は「isolate」の下で同様のパターンを説明している。エージェントの信頼性を向上させる最良の方法は、コンテキストを蓄積するのではなく分割することであると[17]。
\nこれは重要だ。なぜなら、共有コンテキストには隠れたコストがある。それは path dependence を生み出す。単一の悪い分岐が次のステップに、そしてその次に、そしてその次に影響を与えうる。
\nIsolation は blast radius を制限する方法だ。
\n2025年には、context engineering は主に人々がすでに感じていた問題に対する有用な名前だった。2026年には、それはアーキテクチャとして固まり始めている。
\n最初の大きな変化は、ビルダーが durable state を生のコンテキストウィンドウの外に移動させていることだ。Anthropic の context editing と memory tool は、ワーキングウィンドウに留まるものと、セッションを超えて持続すべきものを明示的に分離する[18]。OpenAI の2026年1月の personalization に関する cookbook は、異なる形で同じ動きを行っている。実行を超えて持続し、各実行の開始時に意図的にワーキングメモリに注入される構造化された state objects だ[19]。OpenAI の Responses API は、ネイティブな compaction でこれをさらに一歩推し進め、長時間稼働するエージェントループが、すべてのチームがゼロからカスタムの summarization サブシステムを構築する必要がないようにしている[14]。
\nAnthropic の Managed Agents は、根底にあるパターンを異常に明確にしている。セッションはモデルのコンテキストウィンドウではないのだ[20]。これは2026年の重要なアイデアだ。ウィンドウは一時的なワーキングメモリだ。セッションログは durable object だ。Harness は、その durable context を次のモデル呼び出しにどのようにスライス、圧縮、再水和（rehydrate）するかを決定する。
\n2番目の変化は、retrieval がよりjust in timeになり、よりインターフェイスネイティブになっていることだ。あらゆる可能性のある関連トークンを前もって読み込むのではなく、チームはエージェントに、彼らがすでに操作方法を知っている retrieval surfaces を与えている。Mintlify の ChromaFs は良い例だ。ドキュメントの retrieval のために完全なサンドボックスを起動するのではなく、ls、cat、grep でナビゲート可能な仮想ファイルシステムとしてドキュメントを提示し、p90 のセッション作成を約46秒から約100ミリ秒に短縮した[21]。Turso の AgentFS は、同じ直感を一般的なエージェント実行に向けて推し進める。copy-on-write のファイルシステム抽象化で、ポータブルな単一ファイルストレージと組み込みの監査機能を備えている[22]。
3番目の変化は、context graphsが比喩ではなく実装の方向性になりつつあることだ。Foundation Capital の thesis はこの言葉を可視化したが、より強い主張はアーキテクチャ的なものだ。エージェントが実行パスに位置するとき、彼らは最終出力を発するだけでなく、decision traces を durable artifacts として捉えることができる[26][27]。Graphiti のようなオープンソースシステムや Zep のような商用プラットフォームは、これを validity windows、provenance episodes、semantics、keywords、graph structure を横断する hybrid retrieval を持つ temporal context graphs として実用化している[23]。TrustGraph は関連するアプローチを取り、コンテキストをバージョン管理されたアーティファクトとして扱う。graph、embeddings、evidence、policies を、ビルド出力のように昇格またはロールバック可能なポータブルな「context cores」にバンドルするのだ[24][25]。
\n4番目の変化は、context engineering がプラットフォームのブログだけでなく、実際のソフトウェア実践において可視化されつつあることだ。2026年のオープンソースソフトウェアにおける context engineering に関する MSR 論文は466のリポジトリを調査し、AGENTS.md のようなAIコンテキストファイルが広がっているが、まだ安定したコンテンツ構造はないと発見した[28]。これは重要だ。なぜなら、それは理論から運用アーティファクトへの移行を示すからだ。コンテキストはもはや実行時に推論されるものだけではない。それはソフトウェアライフサイクルの一部として、作成され、バージョン管理され、レビューされ、採掘されている。
2026年のメンタルモデルを一枚の図で表したいなら、こうなる：
\nflowchart LR\n E[\"Session log / events\"] --> A[\"Context assembler\"]\n F[\"Files, docs, and tools\"] --> A\n G[\"Context graph / memory\"] --> A\n P[\"Policies and AGENTS.md\"] --> A\n\n A --> W[\"Working context window\"]\n W --> X[\"Agent action\"]\n\n X --> E\n X --> G\nこれは「prompt + vector search」とは非常に異なるアーキテクチャだ。
\nこの議論が混乱する理由の一つは、人々がcontext engineeringとcontext graphを、同じ意味のように使うからだ。そうではない。
\nContext engineering はより広い学問だ。次のコンテキストウィンドウに何が入るか、何が外に留まるか、何が圧縮されるか、何がオンデマンドで retrieve されるかを決定する作業だ。
\nContext graph は、そのより大きなシステム内の一つの可能な long-term memory substrate だ。
\nこの区別は重要だ。なぜなら、すべての有用なエージェントが context graph を必要とするわけではないからだ。ほぼ静的なコンテンツ上のドキュメントアシスタントは、良い retrieval、tool design、compaction を必要とするかもしれないが、graph は必要としない。コーディングエージェントは、リポジトリの指示、durable session log、ファイルシステムの抽象化で、驚くほど遠くまで行けるかもしれない[20][21][22][28]。
\nContext graphs が説得力を持つのは、問題が4つの特性を持つときだ：
\nだからこそ、私の見解では、context graph の最良の定義は「AI のためのグラフデータベース」ではない。それはprecedent の durable representationなのだ。
\nだからこそ、decision traces はこれほど重要なのだ。Foundation Capital の枠組みはここで有用だ。ルールはエージェントに、一般的に何が起こるべきかを教える。decision traces は、特定のケースで、実際の制約の下で、実際の例外と共に何が起こったかを教える[26]。これらの traces がエンティティと時間を横断してリンクされると、一般的なメモリよりもはるかに価値のあるものが得られる。検索可能な判断だ。
\nもし今日、本気の context-engineering stack を構築するなら、graph から始めない。インターフェースと promotion rules から始める。
\nすべてのアクション、ツールの結果、観察、重要な中間アーティファクトは、append-only のセッションログまたはイベントストアに格納されるべきだ。これがあなたの回復可能なコンテキストオブジェクトだ[14][20]。
\nアクティブなコンテキストウィンドウを source of truth と混同しないこと。
\nウィンドウは推論のためのものだ。セッションは回復、リプレイ、デバッグ、選択的な再水和のためのものだ。
\nAssembler は明示的に管理すべきだ：
\nこれはモデルが今何を見るかを決定する層だ。それは観測可能で、テスト可能で、変更が安価であるべきだ[18][19][14]。
\nまずモデルに軽量なハンドルを与える。ファイルパス、オブジェクトID、URL、クエリテンプレート、チケットID、インシデントIDだ。そして、必要なときだけ詳細を引き出させる[9][18][21]。
\nここが、ファイルシステム、MCP ツール、search API、structured queries が、巨大な top-K dump よりも価値を持つ場所だ。
\nすべてがメモリになるべきではない。
\n私は4つのクラスのアーティファクトを昇格させる：
\nその他の全ては、昇格に値すると証明されるまでセッションログに留まるべきだ。
\nこれは多くのチームが逆にしている部分だ。
\nGraph は、生のトランスクリプトをグラフ形式にしたものであるべきではない。それはセッションの上にあり、リアルタイムのアセンブリの下にある、キュレーションされた層であるべきだ：
\nPromotion のステップを飛ばせば、graph は情報のダンピンググラウンドになる。Promotion を正しく行えば、graph は組織が実際に推論する方法のメモリになる[23][26]。
\n2026年までに、最も有望なアイデアの一つは、コンテキストをバージョン管理されたアーティファクトとして扱うことだ。ソフトウェアプロジェクトでは、これは AGENTS.md やその他のリポジトリ固有のコンテキストファイルとして現れる[28]。Graph-native システムでは、これは context cores として現れる。オントロジー、グラフ構造、embeddings、provenance、retrieval policy のポータブルなバンドルだ[24][25]。
これは重要だ。なぜなら、コンテキストの変更には、コードの変更と同じ運用規律が必要だからだ：
\nコンテキストがアーティファクトになれば、それは統治可能になる。
\n両方が必要だ：
\nこれらは同じものではない。
\n私は知りたい：
\nこれらの問いに答えられなければ、あなたは依然として暗闇の中でプロンプトをデバッグしているのだ。
\n自分のシステムがどこに位置しているかを評価しようとしているなら、この成熟度モデルは抽象的な定義よりも有用だ。
\nシステムプロンプト、ユーザーメッセージ、そしておそらくいくつかの例がある。
\nこれは狭いタスクに対して驚くほど良く機能する。しかし、タスクが新鮮な知識、永続性、またはツールを必要とするとき、すぐに破綻する。
\n実行時にドキュメントを追加する。
\n多くのチームがここで止まる。そして、多くのチームが単純な chunking、ranking、context bloat の限界を見始めるのもここだ。
\nあなたは今、history、tool results、memory、formatting を意図的に管理する。
\nこれは「context engineering」が有用な言葉となる最初のレベルだ。なぜなら、システムはもはやプロンプトに retrieval を足しただけではなく、複数の形態のコンテキストを動的に組み立てているからだ。
\nシステムはタスクに基づいてコンテキストの構築方法を変える。
\nそれは以下を行うかもしれない：
\nこの時点で、コンテキスト構築はアプリケーションのコアロジックの一部だ。
\nシステムはコンテキストをファーストクラスのエンジニアリングサーフェスとして扱う。
\nそれは以下を持つ：
\nこれが最も強力な本番システムが向かっている場所だ。
\nこの学問全体をチェックリストに減らさなければならないなら、こうなる：
\nこれらのどれも華やかなものではない。だからこそ重要なのだ。
\nPrompt engineering が人気になったのは、それが近道のように聞こえたからだ。
\nContext engineering が重要なのは、それが実際の作業を記述しているからだ。
\nAI における重心は移動している。
\nかつてのフロンティアの問いはこうだった。モデルはどれだけ賢いか？
\n応用上の問いはますますこうなっている。モデルが行動する前に、何を見ることができるか？
\nこれは異なるエンジニアリング問題だ。単一のプロンプトよりもシステム設計についての問題だ。言い回しよりも情報フローについての問題だ。One-shot の出力品質よりも、エージェントが時間をかけて信頼性を保てるかどうかについての問題だ。
\nだからこそ、context engineering は学問として成長し続けるのだ。モデルが良くなるほど、残りの失敗はコンテキストの失敗のように見える。Missing state。Wrong tool。Bad retrieval。Bloated history。Poor formatting。Conflicting evidence。Weak memory。Unbounded loops。
\n皮肉なことに、これはAIシステムを、より古典的なソフトウェアのように感じさせる。私たちはパイプライン、インターフェース、ステートマシン、メモリ階層、キャッシュ、observability layers を構築する作業に戻っている。新しさは、これらのすべての部品が、確率的推論エンジンの奉仕のために存在するということだ。
\n名前は新しいかもしれない。方向性はそうではない。
\n信頼性の高いAIシステムは、コンテキストをファーストクラスのプロダクトサーフェスとして扱うチームによって構築される。
\n他の全員は、モデルを不安定だと言い続けるだろう。
\nReferences:
\n[1] Simon Willison. (2025, June 27). Context engineering.
\n[2] Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.
\n[3] Yao, S. et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models.
\n[4] Wu, D. et al. (2025). LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory.
\n[5] Liu, N. F. et al. (2023). Lost in the Middle: How Language Models Use Long Contexts.
\n[6] Leng, Q. et al. (2024). Long Context RAG Performance of Large Language Models.
\n\n[8] LangChain. (2025, June 23). The rise of \"context engineering\".
\n[9] Anthropic. How to implement tool use.
\n[10] Jason Liu. (2025, August 27). Beyond Chunks: Why Context Engineering is the Future of RAG.
\n\n[12] Anthropic. Long context prompting tips.
\n\n\n[15] Model Context Protocol. What is the Model Context Protocol (MCP)?
\n[16] Anthropic. (2025, June 13). How we built our multi-agent research system.
\n[17] LangChain. (2025, July 2). Context Engineering.
\n[18] Anthropic. (2025, September 29). Managing context on the Claude Developer Platform.
\n\n[20] Anthropic. Scaling Managed Agents: Decoupling the brain from the hands.
\n[21] Mintlify. (2026, March 24). How we built a virtual filesystem for our Assistant.
\n[22] Turso. AgentFS.
\n[23] Zep. Graphiti: Build Real-Time Knowledge Graphs for AI Agents.
\n[24] TrustGraph. The context development platform.
\n[25] TrustGraph. Working with Context Cores.
\n[26] Gupta, J., and Garg, A. (2025, December 22). AI's trillion-dollar opportunity: Context graphs.
\n[27] Garg, A. (2026, January 16). Why context graphs are the missing layer for AI.
\n", "source_hash": "sha256:3f3faa38dd809a893509e9f3c2de70a7ec3778cc6cef2fa58967b63bd169d7d9", "model": "moonshotai/kimi-k2.6", "generated_at": "2026-08-07T07:53:33.900442+00:00" }