讓我們談談所謂「共享上下文層」（shared context layers），常被稱為「公司大腦（company brains）」

為了回答關於你們公司的難題，例如：
「關於 X，哪些是真的、從何時開始、依據是誰，以及帳務彼此在哪裡不一致？」
你需要的是一個由推導而來、可引用的事實層，建立在你們所有的通訊與文件之上

它是公司或組織「知道什麼」的系統化紀錄（system of record），而這與包含工作輸出內容的那些系統化紀錄不同

會計部的 Jack 知道為什麼一張供應商發票被支付了——因為它不符合採購單（PO），但會計系統只包含資料要素：採購單（PO）以及付款

所以如果你想知道「為什麼我們付的金額跟採購單（PO）上的不一樣」，你就得去問 Jack
除非你有一個共享上下文層，能連到 Slack 和電子郵件串，顯示 Jack 已經與業務經理確認：該訂單已變更，且批准了付款

一個共享上下文層要能發揮作用，就必須有扎實的證據支撐，能浮現矛盾，並用新資訊推翻舊的真相

它必須能回答：
- 這個人是誰？會計部的 Jack，而不是工程（Engineering）部的 Jack
- 目前的狀態是什麼？採購單（PO）不符合發票，未解決前不能付款
- 帳務在哪裡不一致？原本的採購單（PO）是由 Jane 在電子郵件中核准，但變更單（change order）是在 Slack 裡由 Bob 提出
- 什麼地方變了？Bob 需要增加座位數，以納入另一個額外群組

基於檢索（retrieval-based）的系統在這些問題上不會可靠：它們擅長找文字，但對於像「為什麼這張發票被支付了，儘管它不符合採購單（PO）」這類需要解決主張（claims）的問題就不太擅長

一個能正確運作的共享上下文層，其架構需要能涵蓋：
1. 證據（Evidence）— 原始資料，且有來源
2. 事實（Facts）— 公司內的實體與主張（claims）
3. 判斷（Judgement）— 將證據與事實之間推理串起來的邏輯
4. 存取（Access）— AI 能夠推理哪些證據與事實

當然，這是一個簡化的拆解，因為建立可靠的共享上下文層可能相當複雜；但如果你把這件事做對，它就會成為工作流程自動化的基礎

會計部的 Jack 不需要去追查 Jane 和 Bob，來判斷這張發票是否該被支付——代理（agent）可以做到，而 Jack 可以把時間放在更策略性的工作，例如規劃與分析

重點是：如果你想自動化工作流程，並在試點（pilots）之外部署代理，你首先就得先聚焦於共享上下文層，讓代理能擁有可靠的資訊來採取行動