一篇於 2026 年 8 月 18 日上載至 arXiv 的研究，將 mission-critical infrastructure 裏的 Agent harness 視為一個資源配對問題。Harness 決定 Agent 可以看到哪些資訊、使用哪些工具和採取哪些 action；研究團隊指出，很多系統會對每個任務提供同一套完整 harness，但任務未必需要全部能力，這會增加資源消耗和不必要的暴露面。
作者先按底層系統的數學表示，把 mission-critical tasks 分類，再按資訊數量和類型為不同 harness 排序。任務與 harness 的 mapping 來自兩個來源：研究文獻整理，以及受控 Agent execution 的量度。這個方法把「要不要把所有上下文塞給模型」改寫成一個可以測量的匹配問題。
研究提出 map-guided escalation 演算法。它不是先開啟 full provision，而是從 task-specific harness 開始；只有 Agent 的 self-check 失敗，才擴大資訊和工具供應。這個思路與 least privilege 相近，但多了一個 workflow 動態：權限和上下文不是永遠固定，而是可以根據任務需要和失敗訊號逐步增加。
作者在兩個代表性任務評估方法。Liquid cooling 實驗中，map-guided provisioning 的 Agent accuracy 由 full provision 下的 0.652 提升至 0.715，並以比 Reflexion 少 48% 的 tokens 達到相近效果。Power grid 實驗則顯示 full provision 仍然是 accuracy-optimal，但基於 mapping 的配置提供較低成本的選項。這些數字是論文的實驗結果，不是所有 mission-critical domain 的保證。
研究把結果總結成一條 domain-dependent 的 accuracy-cost Pareto frontier，而不是一個適用所有任務的最佳 harness。對 AI workflow 團隊來說，這個結論很實用：Agent 的工具權限、背景資料和 context window 應該跟任務風險、驗證能力和成本一起調校，而不是單純追求最完整的上下文。
實務上，採用這種設計要先處理 self-check 是否可靠。若 Agent 不知道自己缺少關鍵資料，系統可能不會觸發 escalation；若 escalation 沒有限制，Agent 又可能用反覆失敗換取過寬的權限。因此需要明確的任務分類、可觀察的失敗原因、上限、人工升級點和回復策略。這段是根據研究結果作出的工程解讀，不是論文已驗證的通用產品方案。
這篇 preprint 的重點不是叫企業把 Agent 的能力一律縮小，而是提醒團隊把 harness 當成可配置的 workflow layer。對高風險系統，最小必要資訊和工具可以先限制 blast radius；對需要全局上下文的任務，系統也應有證據支持何時值得提供 full provision。
