星期四下午，AI Demand Review 開到第十二個需求。

Request: Customer Complaint Summary Agent
Expected Users: 18
Monthly Volume: 35 cases

資料已經在 CRM，摘要格式也不複雜。平台主管看完說：「這個兩週應該做得出來。」

PM 正要把卡片移到 Approved，架構師問：「我們不是已經有 Customer Case Summary 了嗎？」

現有 Capability 支援 Technical、Billing 與 Escalation Case，有 218 位活躍使用者。新的 Complaint Use Case 輸入幾乎一樣，只多三個欄位：Complaint Category、Customer Expectation、Follow-up Owner。

「這比較像加三個欄位，不像需要另一支 Agent。」

PM 把卡片從 Build New Agent 改成 Merge into Existing Capability。

那場 Review 最後處理了十五個需求：Build 5、Merge 4、Reject 3、Need More Evidence 3。大家都覺得效率不錯。

直到季度成果報告出來。

報告裡只剩五件事

All Hands 的投影片寫著：

5 New Agents
3 New Skills
2 Production Integrations
1,420 Monthly Active Users

五個上線專案都有名字、Screenshot、Owner 和節省工時估算。兩個 Builder 還被特別點名。

架構師坐在台下，沒看到四個被 Merge 的需求，也沒看到三個被 Reject 的需求。

其中一個原本要做 Meeting Action Item Agent，後來發現既有 Meeting Capability 已能產生結構化 Action。另一個 Policy Translation Agent 每月只有十幾次需求，最後改成既有 Translation Service 加固定 Template。第三個名為 Release File Validation Agent，流程拆完後只剩 deterministic checks，最後做成 Script。

這些決定都省下後續開發與維護，但季度報告裡沒有地方可以放。

因為沒有東西被做出來。

Build 開始變成阻力最小的選項

下一季，新的 Review 收到二十多張卡。

第一張是 Finance Report Agent。有人問它和既有 Report Generator 差在哪；看起來有不少重疊，但若要 Merge，就得找 Capability Owner、確認 Scope、估修改影響。

直接 Build 一個 Prototype，大概兩週。

PM 看了看後面十九張卡，說：「那先做 PoC 吧。」

第二張也是類似狀況。第三張原本可能只需要一支 Script，但要證明這件事，得先把流程拆清楚；先建一版 Agent，至少專案可以開始。

慢慢地，Build 變成會議裡阻力最小的選項。

不是大家突然不會判斷，而是不同決策得到的回報完全不同：

Build：有專案、有 Demo、有 Launch、有成果可報。
Merge：看起來只是改了舊東西。
Reject：什麼都沒有。
Retire：Dashboard 上的 Agent Count 還會下降。

最合理的個人選擇，開始和最合理的 Portfolio 選擇分開。

組織會得到它所獎勵的東西

許多企業 AI 團隊知道，不是每個需求都值得做，也知道重複 Agent 會帶來維護問題。它們會建立 Intake Review、Architecture Review、Use Case Gate。

但成果最後若只算 New Agent、New Skill、New Use Case 和 Launch Count，治理流程其實在對抗自己的 Incentive。

一個團隊花兩週做出新 Agent 很容易被看見；另一個人花兩小時發現公司已有相同 Capability，讓這支 Agent 根本不要出生，資產清單上得到的是 +0。

從 Portfolio 角度，這個零可能很有價值。每增加一個 Production Capability，通常不只多一份 Code，還會多 Owner、Access Control、Test、Monitoring、Incident、Documentation、Change、Support 和 Retirement。

真正昂貴的不是 Build 的幾週，而是它成為正式資產後，每一年都要有人照顧。

AI 把 Build 拉得越快，需求選擇反而越重要。便宜的 Creation，不代表便宜的 Ownership。

他們沒有替拒絕數訂 KPI

有人提議追 Reject Rate，很快被否決。Reject 越多越好，只會製造另一種奇怪 Incentive。

問題不是要多做或多拒絕，而是 Portfolio 做過的選擇，不能只看得見其中一種。

團隊最後只留下 Portfolio Decision Log：

Request: Complaint Summary Agent
Decision: Merge
Target: Customer Case Summary
Reason: Same data source and task boundary
Avoided: 1 new production capability

另一筆則寫：

Request: Release File Validation Agent
Decision: Reject Agent / Build Script
Reason: Deterministic validation rules
Avoided: Agent runtime, prompt maintenance, model regression testing

Retire 也記錄：

Capability: Old FAQ Agent
Decision: Retire
Reason: Fewer than 5 monthly uses for 3 consecutive months

不需要精準算出每一次拒絕省了多少錢。先讓 Build、Merge、Reject、Retire 四種決策都存在於同一份成果紀錄，就足夠讓季度回顧不再只剩 Addition。

新 Agent 少了七個

下一季的成果頁，第一個數字不如上一季：

New Agents
Q3: 5
Q4: 3

但下面多了一段：

Portfolio Decisions
Build: 3
Merge: 5
Reject: 4
Retire: 2

其中五個需求併進既有 Capability，四個被確認不值得建立新的長期資產，兩支幾乎沒人用的 Agent 正式下線。

最後一行寫著：

Avoided 7 additional long-term maintenance assets.

三個月前，那七個位置都有專案名稱。這一次，它們沒有被做出來；第一次，這件事也被算成了成果。