CIOs must define what AI agents can do

A working AI agent leaves delegation decisions unresolved

An AI agent can be ready to act while the organization is still unprepared to authorize its decisions. For chief information officers (CIOs) moving agents into operational work, deployment therefore means deciding what software may do, which instructions it will follow and who will supervise the consequences. Technical success leaves those responsibilities with the organization.

The stakes rise when agents interpret uncertain situations, make decisions and act without a person participating at every step. These autonomous workflows let software carry out work independently. As organizations move from experiments to delegated operational decisions, most leaders are only beginning to address the responsibilities that independent action creates.

IBM, which has a commercial interest in organizations adopting AI, reported findings that show the extent of this readiness gap. In one study, just 11% of CIOs and chief technology officers (CTOs) considered themselves fully prepared for the scale of agent deployment anticipated over the following 12 months. More than three-quarters of organizations in the same study reported that AI adoption was exceeding their ability to govern it. The first finding measures executive preparedness; the second identifies an organizational shortfall in setting and enforcing rules for AI use.

Define what an agent may do

Closing that gap starts with deciding which actions an agent may take. An agent may be able to send an email, change a record, initiate a workflow or escalate an incident, yet each action raises a different authorization question. CIOs therefore need to move from “Can it do that?” to “Should it be able to, and under what conditions?” The answer sets the limits of the agent’s discretion.

Those limits must reflect the business setting of each action. The organization needs to identify what the agent can do, decide whether each action is permissible and specify any conditions or human approval requirements. The result is three categories: work that can proceed autonomously, work requiring human review and work that excludes agent participation. Each gives the agent a clear rule when it chooses and executes an action.

An illustrative incident-management agent shows how these categories can work within one process. An organization could authorize the agent to assess an alert and route it to the appropriate team independently, because those activities establish what needs attention and where it should go. Its independent authority would end before it changed the affected service. Remediation, meaning action to resolve an incident affecting customers, would require human authorization because it changes the operational situation.

Communication would need a separate rule within the same workflow. The agent might be able to compose and send a message about the incident, but external communication would require human sign-off under this illustrative policy. Assessment, routing, remediation and communication would therefore have distinct approval requirements, even if the agent could technically perform all four. Organizations could choose different boundaries; each would need to establish them before relying on autonomous execution.

The same responsibility applies when an organization acquires an externally developed agent. Its functions still need to operate within the organization’s permission framework, since those functions cannot determine the authority appropriate to a particular business. CIOs remain responsible for setting those limits alongside system performance. Buying the technology leaves the organization to decide how it may be used.

Document the work before asking agents to execute it

Applying those permissions requires a clear account of the work itself. Some workflows depend on knowledge held by particular employees, unwritten habits and informal transfers of responsibility between teams. People may understand enough of that context to keep work moving, while an agent needs explicit instructions and decision boundaries. Even a sophisticated model with effective prompting cannot supply an organization’s missing agreement about how its process should operate.

Making that agreement explicit begins with documenting the steps and how responsibility passes between participants. The organization then needs to standardize the work enough for software to follow it consistently. This gives the agent both context for its decisions and limits on its behavior. Clear instructions support faster, more dependable execution because the required process is already established.

Consistency matters more as deployment expands and the work repeats. Where teams rely on different unwritten interpretations, expansion carries those differences into the implementation. Organizations with documented processes can therefore gain an advantage over competitors whose work remains less consistently defined. Process design deserves attention comparable to technical architecture because it determines whether the organization can explain the work clearly enough for software to execute it.

Preparing that explanation can also expose operating weaknesses that have existed for years. Agent deployment gives organizations a reason to resolve unclear responsibilities and informal handoffs that employees have managed through experience. Closing those gaps improves the process for the people who continue to perform and supervise the work. Documentation thus supports reliable agent execution and improves operations through the preparation itself, although deployment still requires suitable capabilities, permissions and supervision.

Faster delivery makes this preparation more urgent. Major systems projects could take 18 months, with benefits difficult to quantify, while agentic initiatives can be launched and refined within a quarter, with results visible almost immediately. Shorter cycles let teams observe and improve operational use sooner, but they also leave less time to settle process and governance questions during implementation. Organizations therefore need to establish the workflow and its permissions early enough to guide those first operational decisions.

Set autonomy according to the business consequences of failure

A documented workflow establishes what should happen; the consequences of failure determine how much freedom the agent should receive within it. CIOs need to identify where independent action offers value and weigh that value against the effects of error. This takes detailed knowledge of business operations, because technical capability alone cannot reveal how much disruption a decision could create.

An incorrect recommendation in an internal workflow may cause inconvenience, while an incorrect judgment during a severe customer incident can damage trust, interrupt operations and create substantial business exposure. Even with equivalent capabilities, those consequences justify different permissions. In the incident-management example, this explains why remediation affecting customers and communication outside the organization require separate authorization. Oversight should match the risk attached to the assigned work.

Judging that risk makes business understanding increasingly important to CIO leadership. CIOs must understand operations well enough to determine where autonomy produces value and where the risks outweigh it, while continuing to provide dependable infrastructure, secure systems, sound technical architecture, service stability and predictable delivery. Governance depends on reliable systems, and those systems still need clear limits on their authority. Together, these responsibilities connect technical performance to the business consequences of software exercising judgment.

Prepare employees for oversight and exception handling

Those limits create work for employees whenever an agent must wait for approval or needs help with an exception, a situation requiring intervention outside routine execution. As agents take over routine steps, people spend more time monitoring results and handling these cases. Employees therefore need to understand what the agent was expected to do and recognize when an outcome needs attention. Autonomous execution changes where human responsibility sits within the workflow.

That shift can constrain a deployment even when the technology works correctly. An agent may depend on employees reviewing decisions or responding to exceptions, yet those employees may be unprepared for their new duties. Technical delivery therefore needs to proceed alongside change management and workforce preparation. Teams need time to adapt during implementation so that the people responsible for intervention are ready when operational use begins.

Preparing those teams means treating every approval requirement as an ongoing operational duty. Employees must be able to supervise outcomes, handle situations requiring intervention and fulfill their assigned responsibilities when the agent reaches a decision boundary. Establishing a human-review rule commits the organization to providing people capable of carrying it out throughout the agent’s operation.

Key highlights

• Define agent permissions: CIOs need to classify actions as autonomous, subject to human approval or excluded from agent participation. Apply these boundaries to internally built and externally acquired agents before operational use.
• Document workflows before deployment: Process owners need to make steps, handoffs and decision boundaries explicit so agents can execute consistently. Faster deployment cycles make resolving unclear responsibilities early essential.
• Match autonomy to business risk: CIOs need to assess the consequences of error for each assigned action. Customer-facing remediation and external communication warrant different approval requirements from internal assessment and routing.
• Prepare employees for oversight: Every human-review requirement creates an ongoing operational duty. Prepare the employees responsible for approvals, outcome monitoring and exception handling alongside technical implementation.