The Human-Agent Operating Model: How CIOs Should Redesign IT for AI-Augmented Work

TL;DR

The CIO’s AI operating model cannot stop at selecting models, deploying copilots, or funding agent pilots. It must define how a human-agent workforce makes decisions, executes work, owns outcomes, operates platforms, handles exceptions, and responds when an AI-enabled process fails.

The durable model is centralized control with federated business ownership. Employees retain judgment, accountability, and exception authority. AI agents receive bounded execution responsibilities, not organizational accountability. Application owners remain accountable for service outcomes. Platform teams provide reusable identity, tool, policy, evaluation, observability, and cost controls. Security defines non-negotiable boundaries and independently verifies them. Executive sponsors own value realization, funding, and risk acceptance.

The most important operating-model rule is simple:

An AI agent may perform work, but it cannot own the consequences of that work.

Introduction

Enterprise AI is moving beyond individual productivity tools. Employees are beginning to delegate research, analysis, drafting, ticket handling, software tasks, operational investigation, workflow coordination, and limited system actions to AI agents.

That changes the problem facing the CIO.

The question is no longer only how to deploy an AI platform. The CIO’s AI operating model now has to explain how a human-agent workforce will be organized, which decisions remain human, which tasks may be delegated, who owns the underlying platforms, and who is accountable when an agent’s work reaches a customer, employee, regulator, production system, or financial ledger.

Recent industry research points to the size of the organizational gap. An IBM Institute for Business Value survey reported that two-thirds of surveyed CIOs and CTOs were accountable for AI systems they did not fully control, while only 11 percent considered themselves fully prepared for the expected scale of agent deployment. Microsoft’s 2026 Work Trend Index similarly found that organizational readiness often trails individual AI capability, with only about one-quarter of surveyed AI users reporting clear and consistent leadership alignment.

These are vendor-sponsored surveys and should be treated as directional evidence rather than universal truth. Even so, they describe a recognizable enterprise problem: employees and business teams can adopt AI faster than the organization can redesign ownership, controls, support processes, and decision rights.

Installing an agent platform does not close that gap.

An operating model does.

The Existing IT Operating Model Is No Longer Enough

Traditional IT operating models assume that work is performed by a reasonably well-understood set of actors:

• Employees make business decisions.
• Application teams build and support services.
• Platform teams operate shared infrastructure.
• Security teams establish and verify controls.
• Automation executes predetermined workflows.
• Executives fund services and accept material risks.

AI agents do not fit cleanly into this structure.

An agent may interpret an objective, select a tool, retrieve data, generate an intermediate plan, call an API, retry a failed action, request approval, hand work to another agent, and retain state for later execution. It may act on behalf of an employee while authenticating through a separate workload identity. Its behavior may also change when its model, instructions, tools, retrieval sources, memory, or surrounding context changes.

This creates an actor that can perform variable work without becoming a legal employee, accountable manager, service owner, or risk owner.

The mistake is trying to force that actor into the organization chart.

The better approach is to place the agent inside the work system while keeping accountability attached to human and organizational roles.

What a Human-Agent Operating Model Actually Defines

A human-agent operating model is the set of decision rights, work-allocation rules, platform services, controls, ownership boundaries, and operating processes governing how employees and AI agents perform work together.

It should answer six questions:

1. Who owns the business outcome?
2. Which work may be delegated to an agent?
3. What authority may the agent exercise?
4. Which shared platform controls must surround that authority?
5. Where must human judgment interrupt the workflow?
6. Who operates, supports, measures, and retires the resulting service?

This is broader than AI governance.

Governance defines policies, oversight, risk tolerance, and decision authority. The operating model turns those policies into daily execution. It connects business ownership to application ownership, platform delivery, identity, tool access, security, observability, incident response, workforce training, and financial management.

It is also broader than human-in-the-loop design.

Human approval is one control inside the model. The operating model decides which human should participate, what information that person needs, what authority they hold, how long a decision remains valid, and what happens when the person does not respond.

The Human-Agent Operating Model at a Glance

The diagram below separates the three planes that CIOs need to establish. The business accountability plane owns outcomes and risk. The work execution plane combines employee judgment with agent capacity. The control and platform plane determines what is technically permitted, observable, supportable, and reversible.

The important boundary is between execution and accountability.

The agent can be assigned work inside the execution plane. It may retrieve information, generate recommendations, prepare an action, or execute a bounded transaction. It does not approve its own authority, accept business risk, redefine policy, or become accountable for the service.

Those responsibilities remain above and around the agent.

Responsibilities Across the Human-Agent Workforce

A useful AI organization design does not create an isolated “AI team” that owns every decision. It distributes responsibilities while making the boundaries explicit.

Role	Accountable for	Responsible for	Must not own alone
Executive sponsor	Business outcome, investment, risk tolerance, strategic priority	Removing organizational barriers, resolving ownership conflicts, reviewing value	Technical implementation details or daily agent operations
Application or workflow owner	End-to-end service outcome, process design, user impact, service levels	Requirements, release decisions, workflow quality, incident participation, retirement	Enterprise-wide platform controls or independent assurance
Employees and domain experts	Decisions requiring professional judgment, customer context, exceptions, and accountable sign-off	Directing agents, reviewing outputs, correcting errors, reporting failure patterns	Hidden technical controls they cannot inspect or enforce
AI agents	No organizational accountability	Bounded research, generation, classification, coordination, or action defined by policy	Risk acceptance, self-approval, policy modification, disciplinary decisions, or unrestricted authority
AI platform team	Shared AI platform reliability, standard patterns, and control implementation	Model access, agent runtime, tool registry, identity integration, telemetry, evaluations, quotas, deployment patterns	Business-process outcomes or application-specific risk acceptance
Security, privacy, and risk teams	Security policy, assurance requirements, material control exceptions	Threat modelling, control validation, data protection, monitoring requirements, incident support	Daily business ownership or every application release decision
Data owners and stewards	Authorized use, classification, quality, lineage, retention, and access conditions	Approving data connections, reviewing retrieval boundaries, resolving data-quality issues	Agent runtime operations or application reliability
Finance and FinOps	Spending policy, allocation model, financial transparency	Budget controls, showback, unit-cost measurement, anomaly review	Quality, safety, or business-value decisions based solely on cost

This model avoids two common extremes.

The first is excessive centralization, where a central AI office becomes responsible for every use case, application decision, prompt change, and business result. That creates a bottleneck and separates accountability from the people who understand the workflow.

The second is uncontrolled federation, where each business unit selects its own models, creates agents, grants credentials, connects tools, and invents a separate support model.

A sustainable model centralizes reusable controls while federating product and business accountability.

Agents Can Receive Responsibility but Not Accountability

Responsibility and accountability are often treated as interchangeable. They are not.

Responsibility describes who or what performs an activity. Accountability identifies who must answer for the result, make the final decision, provide remediation, and accept the consequences.

An agent may be responsible for:

• Summarizing an incident timeline.
• Drafting a change request.
• Classifying a support case.
• Comparing configuration state against policy.
• Preparing a customer-response draft.
• Executing an approved, parameter-bounded runbook.
• Monitoring a queue and escalating defined exceptions.

The agent cannot be accountable for:

• Whether the business process is appropriate.
• Whether the risk should be accepted.
• Whether a regulated decision is defensible.
• Whether the customer should receive the final communication.
• Whether the service should remain in production.
• Whether an incident has been adequately contained.
• Whether an employee or customer was treated fairly.
• Whether the organization should pay for the capability.

This is more than semantics. When accountability is vague, failures are attributed to “the AI,” even though the authority came from a human-designed workflow, an application owner, a platform configuration, a security decision, or an executive mandate.

“The agent did it” is not an operating model.

Allocate Work by Judgment, Authority, and Reversibility

Organizations should not decide where agents fit by asking whether the model appears intelligent enough. They should classify work using three more operational criteria:

• Judgment: How much contextual, ethical, interpersonal, or professional judgment is required?
• Authority: What data, money, systems, or external commitments can the task affect?
• Reversibility: Can an incorrect result be detected and safely undone?

These criteria produce five useful work modes.

Work mode	Best fit	Human role	Agent role
Human-led	Ambiguous, sensitive, high-impact, or difficult-to-reverse decisions	Decides and acts	Supplies research, options, and evidence
Agent-assisted	Analysis, drafting, investigation, summarization, and preparation	Reviews, edits, and submits	Produces a recommendation or draft
Shared execution	Multi-stage work with material decision points	Approves defined transitions and handles exceptions	Executes low-risk stages and pauses at control gates
Agent-executed	Repeatable, bounded, measurable, reversible work	Monitors policy and outcome metrics	Executes within a predefined authority envelope
Prohibited delegation	Self-approval, unbounded privilege, hidden impersonation, policy rewriting, or unacceptable impact	Retains control or rejects the design	No execution authority

Human-led work

Human-led work should remain the default when the task involves competing values, incomplete policy, material workforce impact, legal interpretation, public commitments, employee discipline, significant financial exposure, or irreversible production consequences.

The agent can still be useful. It may organize evidence, identify precedent, calculate options, or draft an explanation. The human owns the decision.

Agent-assisted work

This is the most broadly applicable starting point. The agent accelerates the work while a human remains responsible for the final artifact or action.

The danger is allowing the review step to become ceremonial. A reviewer who lacks time, context, authority, or visibility into the evidence is not providing meaningful oversight.

Shared execution

Shared execution is appropriate for long-running workflows where most stages are bounded but specific transitions carry more risk.

For example, an operations agent might collect telemetry, correlate changes, identify a likely cause, prepare a remediation plan, and generate a dry run automatically. A human then approves the exact payload before the tool broker executes it.

Agent-executed work

Full agent execution should be limited to tasks with known boundaries, measurable success, strong identity controls, explicit tool contracts, reliable telemetry, and a practical recovery path.

The organization should be able to explain not only what the agent is allowed to do, but also what prevents it from doing anything else.

The Application Owner Remains the Service Owner

One of the easiest ways to create ownership confusion is to treat an agent as a shared platform feature rather than part of an application or business service.

A model endpoint may be shared. An agent runtime may be shared. The identity plane, tool gateway, evaluation service, and observability pipeline may all be shared.

The resulting workflow still needs an application or service owner.

That owner should be accountable for:

• The business process being augmented.
• The user population.
• The intended and prohibited uses.
• Service-level expectations.
• Workflow-specific quality criteria.
• Required human review.
• Dependency and data-source selection.
• Release and rollback decisions.
• Incident participation.
• User communication.
• Decommissioning.

The platform team should not become the default owner simply because the service uses a platform capability.

Platform teams operate the paved road. Application owners decide where the road should lead.

The AI Platform Team Becomes a Shared Control Provider

The platform team’s role expands substantially in a human-agent operating model.

It is not enough to provide model API access. The platform should expose reusable controls that application teams would otherwise implement inconsistently.

A mature enterprise AI platform should provide:

• Approved model and provider access.
• Agent and workload identity.
• Tool registration and ownership metadata.
• Tool brokers or gateways for sensitive actions.
• Prompt, workflow, and agent version management.
• Evaluation harnesses and release gates.
• Data-access and retrieval integration patterns.
• Approval workflow integration.
• Trace, log, metric, and cost telemetry.
• Rate, concurrency, and spending limits.
• Secrets management.
• Network and egress controls.
• Circuit breakers and disablement paths.
• Incident evidence and replay support.
• Standard deployment and retirement patterns.

The platform team should package these capabilities as services, templates, and policies that product teams can consume without negotiating every control from scratch.

This is where platform engineering and AI organization design intersect. The platform creates safe leverage. It helps teams move faster because critical controls are already implemented, not because governance has been removed.

Security Must Define Boundaries and Verify Reality

Security should not be reduced to a final architecture review or a list of prompt-injection mitigations.

Agentic systems combine several security domains:

• Human identity.
• Workload identity.
• Delegated authority.
• Tool and API permissions.
• Data access.
• Memory and retained context.
• Third-party models and services.
• Network paths.
• Software and model supply chains.
• Approval systems.
• Logs and incident evidence.

Security’s responsibility is to establish the non-negotiable boundaries, define assurance evidence, and verify that the deployed system matches its approved design.

That does not mean security should approve every agent interaction. Mature controls should automate routine decisions and escalate only meaningful exceptions.

Security should be able to answer:

• Which agents exist?
• Which identities do they use?
• Whose authority is being represented?
• Which tools and data sources can they reach?
• Which actions require approval?
• Where is execution denied by default?
• Can privileges be revoked without rebuilding the agent?
• Can operations reconstruct a complete run?
• Can the agent be isolated quickly?
• Who owns the incident after isolation?

Joint government guidance on agentic AI published in 2026 emphasizes incremental deployment, explicit accountability, rigorous monitoring, human oversight, and continuous reassessment against evolving threats. Those are operating-model requirements as much as technical controls.

Executive sponsorship cannot mean approving an AI budget and asking the CIO to “make the organization AI-first.”

The sponsor should own a defined business outcome.

Examples include:

• Reducing the time required to resolve priority incidents.
• Increasing the percentage of support cases resolved without rework.
• Shortening application delivery lead time.
• Improving architecture-review throughput.
• Reducing manual reconciliation effort.
• Improving compliance-evidence preparation.
• Reducing customer-response latency without reducing quality.

The executive sponsor should also define the acceptable risk envelope. The sponsor does not design tool scopes or logging fields, but must understand the implications of granting an agent access to customer data, production systems, financial workflows, or employee decisions.

The CIO owns the enabling technology and operating system.

The business sponsor owns whether the use case is worth operating.

Decision Rights Across the AI Service Lifecycle

Ownership should remain visible from idea through retirement. It should not disappear after a successful pilot.

Lifecycle decision	Accountable role	Primary delivery role	Required assurance
Select the business problem	Executive sponsor	Application or workflow owner	Business baseline and named outcome
Decide whether AI is appropriate	Application owner	Domain experts and architecture	Non-AI alternative considered
Define human and agent work	Application owner	Domain experts and process designers	Judgment, authority, and reversibility classified
Approve data use	Data owner	Application and platform teams	Classification, purpose, retention, and access review
Define agent authority	Application owner and security risk owner	Platform and application teams	Identity, tools, approval, and rollback controls
Approve production release	Application owner	Engineering and platform teams	Evaluations, operational readiness, and recovery test
Operate the shared platform	Platform owner	Platform engineering	Availability, capacity, cost, lifecycle, and telemetry
Operate the business service	Application owner	Product, operations, and support teams	Service levels, quality, user feedback, and incidents
Accept a material exception	Named risk owner	Security and application teams	Expiry, compensating controls, and evidence
Expand autonomy	Executive and application owners	Platform and workflow teams	Proven outcome and control performance
Retire the agent	Application owner	Platform, security, and data teams	Access revocation, data disposition, and dependency removal

This model prevents the pilot team from becoming the permanent, informal owner of a business-critical service.

Define an Operating Contract for Every Production Agent

A production agent should have a machine-readable and human-reviewable operating contract. The contract should connect organizational ownership to enforceable runtime controls.

The YAML below is an implementation-neutral example. It is not intended to be pasted directly into one vendor platform. The application, platform, identity, security, workflow, and observability teams would translate it into their respective controls.

human_agent_operating_contract:
  service_id: it-incident-investigation-agent
  business_purpose: Reduce priority-incident investigation time

  ownership:
    executive_sponsor: cio
    application_owner: enterprise-operations
    platform_owner: ai-platform-engineering
    security_owner: cyber-risk
    data_owners:
      - observability-platform
      - configuration-management

  workforce_design:
    human_decisions:
      - declare_incident_severity
      - approve_production_remediation
      - close_major_incident
    agent_responsibilities:
      - collect_approved_telemetry
      - correlate_recent_changes
      - generate_probable_causes
      - prepare_remediation_plan
    prohibited_agent_actions:
      - change_own_tool_permissions
      - approve_own_recommendation
      - modify_identity_policy
      - close_major_incident

  authority:
    default_action: deny
    allowed_tools:
      - read_metrics
      - read_logs
      - read_change_records
      - create_incident_note
    approval_required_tools:
      - execute_bounded_runbook
    blocked_tools:
      - modify_iam
      - modify_network_policy
      - delete_evidence

  human_oversight:
    approval_role: incident_commander
    approval_ttl_minutes: 10
    stale_evidence_requires_recalculation: true
    timeout_action: deny_and_escalate

  operational_controls:
    max_run_duration_minutes: 20
    max_tool_calls_per_run: 40
    max_cost_per_run_usd: 5
    require_complete_trace: true
    require_correlation_id: true
    kill_switch_owner: ai-platform-on-call

  success_metrics:
    - mean_time_to_probable_cause
    - recommendation_acceptance_rate
    - operator_rework_rate
    - cost_per_successful_investigation
    - policy_denial_rate
    - incident_escape_rate

  review:
    authority_review_days: 30
    owner_attestation_days: 90
    exception_expiry_required: true

The fields that must be changed are the named owners, allowed tools, decision boundaries, timeouts, spending limits, metrics, and review intervals. The contract should reflect one real workflow rather than a generic organization-wide agent.

Successful implementation means the organization can trace each contract element to an enforcement point or operating process. An allowed tool maps to a registry and authorization policy. An approval requirement maps to a workflow. A cost limit maps to runtime enforcement. A kill-switch owner maps to an on-call procedure. A review interval maps to a scheduled attestation.

A document with no enforcement mapping is a policy statement.

A runtime configuration with no accountable owner is an orphaned control.

The operating contract connects the two.

Measure the Work System, Not Only the Model

Model quality remains important, but it is not enough to determine whether an AI-augmented operating model is working.

CIOs should measure six dimensions.

Measurement area	Example metrics	Question answered
Business throughput	Lead time, cases completed, incidents investigated, cycle time	Is the work system producing more useful output?
Quality	Rework, correction rate, outcome accuracy, customer escalation	Is speed being purchased by creating downstream errors?
Human capacity	Time returned, review burden, approval latency, exception load	Is the agent reducing work or merely moving it?
Agent reliability	Task success, tool errors, retry rate, unsupported actions	Can the agent complete its assigned responsibilities consistently?
Control effectiveness	Policy denials, unauthorized attempts, approval bypasses, trace completeness	Are the authority boundaries working?
Economics	Cost per successful task, idle platform cost, cost of rework	Does the operating model create sustainable value?

Avoid measuring success through adoption alone.

A high number of active users may indicate value. It may also indicate that employees are correcting weak outputs, moving sensitive data through an unapproved tool, or using AI because leadership made usage a target.

Likewise, a high level of agent autonomy is not evidence of maturity.

The useful metric is not how much work the agent can do without a human. It is how much valuable work the combined system can complete within its quality, risk, cost, and resilience requirements.

Redesign Management Practices Alongside Technology

A human-agent workforce changes the role of managers.

Managers will need to decide:

• Which tasks employees should delegate.
• Which capabilities employees must retain personally.
• How AI-assisted work is reviewed.
• How performance is evaluated when output is jointly produced.
• How employees report unsafe or unreliable agent behavior.
• Whether productivity gains reduce backlog, improve quality, or change staffing.
• How junior employees develop judgment when agents perform more first-pass work.
• How knowledge is preserved when agent-generated work becomes common.
• How employee monitoring and agent telemetry are separated.

This is where HR, legal, employee-relations teams, learning teams, and workforce representatives become relevant. They do not operate the agent runtime, but they help define acceptable work redesign, training, transparency, performance management, and employee-impact practices.

The CIO should not treat these as communications tasks to be handled after deployment.

They are design inputs.

A Practical 90-Day CIO Implementation Plan

The first objective should not be enterprise-wide autonomy. It should be an enforceable operating model proven through a small number of real workflows.

Days 1 to 30: Establish ownership and inventory

• Inventory known copilots, agents, AI-enabled applications, scripts, and autonomous workflows.
• Name an application or workflow owner for each production use.
• Record executive sponsor, business purpose, users, model provider, runtime, data sources, tools, identities, and environment.
• Classify each use case by judgment, authority, reversibility, and impact.
• Identify agents that have production access without a complete ownership record.
• Select two or three workflows with measurable baselines.

Exit criteria: Every pilot has a named sponsor, application owner, platform owner, security contact, data owner, and documented work-allocation model.

Days 31 to 60: Build the shared control path

• Define approved agent patterns.
• Establish workload identity standards.
• Create a tool registry with named owners and risk classifications.
• Implement a tool broker for sensitive integrations.
• Define trace and audit requirements.
• Connect approval workflows to existing change, incident, or business systems.
• Create the production operating-contract template.
• Define unit-cost and outcome metrics.
• Train application owners and managers on their responsibilities.

Exit criteria: The selected agents can run only through approved identities, tools, policies, telemetry, and approval paths.

Days 61 to 90: Prove the model under operational pressure

• Run agents in shadow, recommendation-only, or read-only mode first.
• Evaluate representative and adversarial scenarios.
• Test approval expiry and exception routing.
• Exercise the kill switch.
• Simulate a tool compromise or unexpected agent action.
• Confirm that operations can reconstruct a complete run.
• Compare outcome, quality, human effort, and cost against the baseline.
• Hold a joint value and risk review before increasing authority.

Exit criteria: The organization can demonstrate business value, technical control, human accountability, incident readiness, and a defensible decision about whether authority should expand.

Common Operating-Model Failures

Treating the agent like an employee

An agent does not have professional duty, organizational loyalty, legal accountability, employment consequences, or independent authority. Human workforce language can be useful as a metaphor, but it becomes dangerous when it hides the actual identity, software, platform, and ownership model.

Making the CIO accountable for every business outcome

The CIO should provide the enterprise platform and control model. Business sponsors and application owners must remain accountable for the processes they choose to automate or augment.

Otherwise, every business unit receives the benefit while IT inherits the risk.

Creating a central AI team that owns everything

Central teams are useful for standards, platforms, assurance, enablement, and portfolio governance. They should not become permanent owners of every business workflow.

The people closest to the process must own whether it works.

Federating adoption without a paved road

Allowing each team to innovate independently may accelerate the first pilots. It also creates duplicated platforms, inconsistent identity models, invisible agents, unmanaged data access, fragmented spending, and incompatible audit evidence.

Federation without shared controls becomes shadow AI by design.

Using human approval as blame transfer

A vague approval request does not make the human accountable for hidden payloads, missing evidence, stale context, or unexpected tool behavior.

The approval system must make the action specific, enforceable, time-bounded, and traceable.

Measuring activity instead of outcomes

Prompt volume, active users, agent count, and token consumption describe usage. They do not prove value.

Measure the useful work completed, the quality achieved, the human effort required, and the risk introduced.

Expanding autonomy before proving operations

A successful demonstration proves that an agent can complete a path.

Production evidence must prove that the organization can observe, contain, recover, support, fund, and govern that path when conditions are less favorable.

The CIO’s Core Design Principle

The most durable human-agent operating model can be summarized as:

Centralize the controls. Federate the outcomes. Keep accountability human.

Centralize the capabilities that should be consistent:

• Identity.
• Approved tools.
• Policy enforcement.
• Model access.
• Evaluation.
• Telemetry.
• Cost controls.
• Incident evidence.
• Disablement.
• Platform lifecycle.

Federate the responsibilities that require business and domain context:

• Use-case selection.
• Process design.
• Outcome ownership.
• Workflow-specific quality.
• Human decision points.
• User support.
• Value measurement.
• Service retirement.

Keep accountability attached to people who have the authority to make decisions, correct the system, accept risk, and answer for the outcome.

That is the difference between deploying agents and redesigning IT for AI-augmented work.

Conclusion

The human-agent workforce will not be created by adding agents to the organization chart. It will be created by redesigning how work, authority, accountability, platforms, and controls fit together.

CIOs should resist two misleading ideas: that AI agents are simply digital employees, and that a central AI team can own every consequence of enterprise adoption. Agents are software actors operating through delegated authority. They can perform useful work at speed and scale, but accountability must remain with executive sponsors, application owners, employees, platform owners, security leaders, and data owners.

The target AI operating model should centralize reusable platform controls while keeping business outcomes federated. It should assign work according to judgment, authority, and reversibility. It should make human oversight specific rather than ceremonial. It should measure the complete work system rather than model performance or adoption alone.

The practical CIO question is not:

How many AI agents should we deploy?

It is:

Can we prove who owns the outcome, what work has been delegated, which authority the agent holds, where human judgment enters, how the service is operated, and what happens when the system is wrong?

When those answers are explicit, AI agents can become a controlled source of organizational capacity.

When they are not, AI augmentation becomes invisible organizational debt.

External References