共有コンテキストレイヤーについて話しましょう。多くの場合「会社のブレイン（company brains）」と呼ばれます。

会社についての難しい質問に答えるには、たとえば：
「Xについて何が真実で、いつからそうで、誰によれば、そしてどこでアカウント同士が食い違っているのか？」

必要なのは、すべてのコミュニケーションやドキュメントの上に成り立つ、導出された引用可能な事実（ファクト）レイヤーです。

それは、組織が「知っている」ことについての記録（システム・オブ・レコード）であり、実務として行われた作業の出力を含む別の記録システムとは異なります。

たとえば、会計のJackは、POと一致しないベンダー請求書がなぜ支払われたのかを知っていますが、会計システムにはPOと支払いというデータ要素しか含まれていません。

つまり、「なぜPOに書かれている金額とは違う金額を支払ったのか」を知りたければ、Jackに聞きに行く必要があります。

ただし、Jackがビジネスマネージャーと確認し、注文が変更され、支払いが承認されたことを示すSlackおよびメールのスレッドに接続された共有コンテキストレイヤーがあるなら話は別です。

共有コンテキストレイヤーを有用にするには、それが証拠に根ざし、矛盾を浮かび上がらせ、古い真実を新しい情報で上書きできなければなりません。

それは次に答える必要があります：
- この人物は誰？ 会計のJackであって、EngineeringのJackではない
- 現在の状態は？ POと請求書が一致せず、解決されるまで支払えない
- どこでアカウント同士が食い違う？ 元のPOはメールでJaneが承認したが、変更注文はSlackでBobが求めた
- 何が変わった？ Bobは追加のグループを含めるために席数を増やす必要があった

検索ベースのシステムでは、これらの質問には信頼性がありません。テキストを見つけるのには向いていますが、「請求書がPOと一致していないのに、なぜ支払われたのか」といった主張の解決にはそれほど得意ではありません。

適切に機能する共有コンテキストレイヤーのアーキテクチャには、次の点を考慮する必要があります：
1. 証拠 - もとになった生データ
2. 事実 - 会社内のエンティティと主張
3. 判断 - 証拠と事実をまたいだ推論
4. アクセス - AIが推論できる範囲の証拠と事実

もちろん、信頼できる共有コンテキストレイヤーを構築するにはかなり複雑な場合があるため、これは単純化した分解ですが、これを正しくできれば、ワークフロー自動化の土台になります。

会計のJackは、請求書を支払うべきかどうかを判断するためにJaneやBobを追いかける必要はありません。エージェントがそれを行い、Jackは計画や分析といったより戦略的な活動に集中できます。

要するに、ワークフローを自動化し、パイロットの先のところまでエージェントを展開するなら、まず共有コンテキストレイヤーに注力し、エージェントが行動するための信頼できる情報を持てるようにする必要があります。