A paper in the AMCIS 2026 Proceedings moves the enterprise-agent governance question beyond model transparency: when an agent has delegated authority and can execute work, who controls autonomous action, how can errors propagate, and where does accountability sit? The authors argue that these questions cannot be solved only with model documentation or one final human review. Controls need to be designed into the workflow architecture.
The paper starts from the shift from predictive support to execution-capable systems. That shift makes error propagation, compliance exposure, and accountability ambiguity more immediate because an agent may call tools, update data, or advance the next step within an authorized scope rather than only recommend an action. Governance therefore becomes part of the product and workflow design, alongside autonomy, permissions, role boundaries, and risk.
The authors propose a kernel-theory-grounded governance-by-design framework. Governance configuration is treated as a higher-order construct comprising autonomy calibration, human-agent teaming, and embedded machine-learning guardrails. Autonomy is positioned as a configurable design variable, with structured oversight aligned to workflow risk. Low-impact and reversible work may need less intervention; external commitments, sensitive data, and irreversible actions need stronger controls.
Using Design Science Research, the paper designs and comparatively evaluates five governance configurations. The abstract reports that architectural alignment influences workflow performance, compliance adherence, appropriate reliance, and accountability clarity. Those should be read as findings within the study's framework; applying them across industries, models, and organizations will require the full experimental detail and further validation.
For implementation, the study points toward something more precise than requiring a human approval for every agent step. A team can classify action risk first, then decide which steps need confirmation, which tools are read-only, which changes need dual authorization, and what evidence must be retained for each run. The goal is not to remove people from the workflow, but to focus attention on irreversible, hard-to-recover, and responsibility-sensitive decisions.
Governance also needs to be tested with the workflow. Beyond evaluating model answers, teams should test what an agent does when permissions are insufficient, a tool fails, context is incomplete, or a multi-step plan goes wrong: does it stop, escalate, or recover? If controls exist only in documentation and not in the execution architecture, the real action path may be wider than the stated policy. This is an engineering interpretation of the paper's theme, not a product capability claimed in the abstract.
The paper's central reminder is that agent governance is workflow architecture, not a single security toggle. Before deploying an execution-capable agent, an enterprise can map authorization boundaries, data flow, tool flow, human handoffs, and recovery paths, then choose an appropriate autonomy calibration. As an agent's capabilities move closer to live operations, governance has to become part of the process itself.
