年度 AI Review 的第一頁，數字比去年漂亮很多。

Production Agents: 47
Shared Skills: 83
Active Workflows: 26
Monthly Active Users: 2,184

Platform Lead 翻到下一頁：Customer Case Summary、Security Alert Triage、Vendor Review Assistant、Meeting Decision Extractor、Access Request Classifier。

每一個都有 Usage、Owner 和效益說明。

「明年是不是該規模化？」有人提議 Production Agent 破八十；有人要更多部門自己 Build；也有人建議把全部能力搬進新的 Enterprise Agent Portal。

坐在角落的 Operations Lead 問：「可以先做一個很奇怪的假設嗎？假設明天這個 Portal 關掉。」

第一個被拿掉的是平台名稱

他把五個能力寫上白板，再把 Enterprise Agent Portal 劃掉。

Customer Case Summary 的輸入輸出有固定 Schema，測試案例在 Git，CRM API 也不專屬於 Portal。換掉前端很麻煩，但能力不會消失。

Security Alert Triage 也差不多。必要 Evidence、不能自動判斷的情況和人工 Fallback，都寫在正式 Runbook。平台可換，規則不會跟著消失。

Meeting Decision Extractor 則不同。Production Prompt 只存在 Portal 裡，沒有版本紀錄；幾條例外規則是一位 PM 半年慢慢調出來的，也沒有 Regression Case。

「Prompt 可以 Export。」那位 PM 說。

「但這幾個例外為什麼這樣寫，我現在也不一定講得完整。」

白板上的五個名字，第一次不再代表同一種已完成資產。

接著，他們把兩個人的名字擦掉

Operations Lead 又說：「再假設兩個主要 Builder 下個月離職。」

Customer Case Summary 問題不大。客服主管知道 Business Rule，Capability Owner 能排 Priority，另一位 Builder 能找到測試與介面。

Vendor Review Assistant 就卡住了。Linda 知道供應商文件缺哪些欄位、哪些可直接補件、哪些必須送 Privacy Review；這些判斷分散在她的 Prompt、Email 和每次 Review 的口頭補充裡。

工具還在，帳號也還在。下一個人卻不知道從哪一條規則開始接。

平台沒有被關掉，能力已經先失去可接手性。

真正能留下來的不是 Agent 名稱

這場測試不是要否定平台，也不是要求每個 Agent 都有一套厚重文件。它只把「能執行」和「能留下」拆開。

一項能力若要在平台換掉、Builder 離開、需求調整後仍能存在，至少要留下四樣東西：

工作邊界：它替誰完成哪一步。
判斷依據：哪些資料、規則與例外會改變結果。
驗證方式：下一個人怎麼知道它仍在正確運作。
接手權限：誰能修改、停用或決定不再做。

這不是另一套 Framework。它只是一個很不客氣的 Capability Survival Test：

把平台名稱和主要建造者拿掉後，這項工作能力還能不能被找到、理解、驗證並接手？

不能，就代表組織目前擁有的不是能力；只是某個人暫時能操作的一組設定。

年度目標沒有再加一個 Agent Count

會議最後沒有決定先蓋新 Portal。

Platform Lead 把明年的第一條目標改成：每一項 Shared Capability 都要通過 Survival Test，否則不算完成平台化。

Customer Case Summary 很快通過。Vendor Review Assistant 沒有。

Linda 沒有被要求再做一個更漂亮的 Agent。她和 Security、Privacy、Procurement 把第一筆真實工作一路攤開：哪些文件可由系統檢查、哪些缺口要退回供應商、哪些例外必須人工決定；再留下測試案例和交接人。

幾週後，新加入的 Reviewer 處理第一件 Vendor Review。她沒有問「Linda 的 Prompt 在哪裡」，而是打開工作規格，知道自己何時能往下送、何時要停下來。

年度簡報最後一頁不再多放一個新 Agent Logo。

只留下一句：

平台能換，人會離開；留下來的，才叫能力。