在 AMCIS 2026 Proceedings 发表的一篇研究，将企业 Agent 的治理问题由「模型是否透明」推向另一个层次：当 Agent 拥有 delegated authority，可以实际执行工作时，谁控制它的自主行动、错误如何传播、合规责任由谁承担？作者认为，这些问题不能只靠模型说明文件或最后一次人工检查解决，还要在 workflow 的架构中设计控制点。
研究的出发点，是企业 Agent 已由 predictive support 走向 execution-capable systems。这个转变令错误、compliance exposure 和 accountability ambiguity 变得更直接，因为 Agent 不只是提出建议，还可能在授权范围内调用工具、更新数据或推动下一步工作。对产品团队而言，治理因此不再是上线后附加的政策页，而是应该跟 autonomy、权限、工作分工和风险一起被设计。
作者提出一个以 kernel theory 为基础的 governance-by-design framework，把 governance configuration 视为一个较高层次的组合，包含 autonomy calibration、human-agent teaming，以及 embedded machine learning guardrails。研究把 autonomy 当作可配置的设计变量，主张监督强度要跟 workflow risk 对齐。低影响、可恢复的工作可以有较少介入；涉及外部承诺、敏感数据或不可逆行动的流程，则需要更严格的控制。
方法上，作者采用 Design Science Research，设计并比较五种 governance configurations。论文摘要表示，架构上的对齐会影响 workflow performance、compliance adherence、appropriate reliance 和 accountability clarity。这些结果应该理解为该研究框架下的比较发现；要把它推广到不同行业、模型和组织，仍需要阅读完整实验设计和进一步验证。
对实际落地来说，这项研究提供一个比「所有 Agent 都要人工批准」更精准的方向。团队可以先按行动风险分级，再决定哪些步骤需要人工确认、哪些工具只能读取、哪些变更要有双重授权，以及每次执行要保存什么 evidence。这不是把人移出流程，而是让人的注意力集中在不可逆、难以恢复和责任敏感的节点。
同样重要的是，治理要能够跟 workflow 一起被测试。除了测模型答案，团队还应验证 Agent 在权限不足、工具失败、上下文不完整和多步骤错误时会怎样停下、升级或恢复。如果控制只存在于文件而不在执行架构内，实际行动路径就可能比规则描述更宽。这一段是基于研究主题作出的工程解读，不是论文摘要直接宣称的产品功能。
这篇 AMCIS 研究的核心提醒，是 agent governance 应该被视为 workflow architecture，而不是单一的安全开关。企业在引入可执行 Agent 前，可以先画出授权边界、数据流、工具流、人工交接和恢复路径，再选择合适的 autonomy calibration。当 Agent 的能力愈接近实际运营，治理设计就愈需要成为流程本身的一部分。
