Cover: AI-generated conceptual illustration, not a real client event.
By Ahmad Al Shami | Strategy, Enterprise Architecture & AI Transformation
When an AI agent can retrieve information, recommend a decision and update a business system, a technology deployment becomes a question about how the organization works.
Who owns the customer outcome? Who can authorize an exception? Which team maintains the agent after launch? How do employees develop judgment when software takes over some of the tasks through which they previously learned?
These questions belong in the operating-model design. My recommendation is to organize the first implementation around one business outcome, with an accountable business owner and a team able to change the workflow, technology and human responsibilities together.
Why this is a leadership issue now
McKinsey’s 5 October 2026 article argues that realizing agentic AI’s broader opportunity requires organizational redesign alongside technology adoption. It discusses cross-functional delivery, accountable leadership and changes to roles and learning. This supports a practical leadership question: which organizational decisions must accompany the next AI investment? [1]
Microsoft’s multi-agent guidance addresses complementary implementation concerns: least privilege, defined task contracts, auditability and human approval for high-impact actions. These controls need owners and working routines. [2]
The framework below is my proposed approach. It is not a prescribed McKinsey or Microsoft methodology, and the example is hypothetical.
Define the outcome before the agent team
“Deploy a customer-service agent” describes a solution. “Resolve eligible service enquiries accurately with less customer effort” describes a business outcome that can guide design choices.
The outcome owner should agree the scope, baseline, quality requirements and economic assumptions. Decide which requests are eligible, which require specialist judgment and which actions carry commitments the agent cannot make independently.
Business architecture helps connect that outcome to capabilities, information and the work required. Enterprise architecture connects the design to services, applications, data and infrastructure. Neither requires a one-to-one mapping between capabilities and agents. A deterministic workflow, one agent or several coordinated agents may fit different parts of the work.
Make the operating decisions explicit
| Design decision | What leaders need to agree | Evidence to maintain |
| Outcome and economics | Who owns the result, funding and benefit assumptions? | Baseline, scope, benefit hypothesis and full cost model |
| Work and handoffs | Which tasks change, and where does work pass between people and software? | Workflow, task contracts and exception routes |
| Decision authority | Which actions are automatic, reviewed or reserved for an authorized person? | Permission rules, approval conditions and delegation records |
| Human roles and learning | What judgment remains with employees, and how will they develop it? | Role expectations, coaching and assessed practice |
| Data and technology | Who owns source information, integrations and deployed components? | Data contracts, access scope, versions and dependencies |
| Service operation | Who responds when an agent produces an incorrect result or a tool fails? | Monitoring, incident ownership, recovery and fallback procedures |
| Value and improvement | What evidence justifies continuing, changing or expanding the workflow? | Outcome measures, evaluations, costs and release decisions |
A role name in a diagram is insufficient if its owner lacks the time, authority or information to perform the responsibility.
A service-enquiry example
Imagine a property-services organization receiving maintenance enquiries. Its objective is to route eligible requests correctly and reduce avoidable back-and-forth while preserving service quality.
An intake agent could extract the request and identify missing information. A knowledge agent could retrieve the relevant service policy and property information. A scheduling service could offer valid appointment options. A service coordinator would handle uncertain eligibility, disputed obligations or exceptions.
The operating model must define the boundaries between these activities:
- The service owner defines eligible request categories and owns the customer outcome.
- The information custodian maintains approved property and service records, with access appropriate to each request.
- The agent and platform custodians maintain versions, integrations, evaluations and recovery procedures.
- The authorized coordinator approves exceptions or commitments outside the agreed rules.
- Quality reviewers examine samples and failures, then feed findings into workflow and training changes.
These responsibilities may be combined in a small organization. Combining roles should still leave each responsibility identifiable.
A request involving a safety concern, uncertain identity or a disputed contractual obligation should follow an explicitly designed escalation route. The particular triggers must be agreed with the responsible business specialists; an agent should not invent them.
This is an illustrative design, not a claim about an implemented client system or its results.
Design the human work as carefully as the automation
If software handles routine intake, the coordinator’s work may shift toward resolving exceptions and explaining decisions. That requires access to the evidence behind a recommendation, sufficient time to review it and a practical way to reject or correct it.
Avoid treating a human approval step as an unlimited safety mechanism. Define the reviewer’s authority, the information presented, the response time and what happens when nobody responds. For sensitive actions, a missing approval should leave the action unexecuted.
Learning also needs deliberate design. Where junior staff previously learned through routine casework, consider supervised case reviews, simulations, shadowing and coached exception handling. Evaluate whether those activities build the required judgment. Automation does not remove the organization’s responsibility to develop expertise.
Connect funding to a service that can be operated
An AI workflow needs ongoing ownership after the pilot. Assign a service or product owner responsible for backlog priorities, quality, cost and changes to business rules.
A cross-functional delivery team can bring business, architecture, engineering, data and control specialists together. Its composition should match the workflow; creating a large central team is not a prerequisite.
Fund the ability to operate and improve the service, including integrations, testing, human review, monitoring and incident response. Account for implementation and continuing costs when assessing value. Token charges alone are an incomplete cost model.
Use a proportionate review process: business owners approve the outcome and authority boundaries; technical and control specialists verify relevant design requirements; operational owners confirm readiness to support the service.
Measure the work that changed
Establish the baseline before the pilot. For the service-enquiry example, useful measures could include time to correct routing, repeated customer contacts, appointment accuracy, unresolved exceptions and review effort.
Track operating cost, service quality and control failures alongside speed. A faster response that creates a wrong booking or transfers work to another team may not improve the overall outcome.
Distinguish estimated benefits from observed results. Do not equate output volume, tool calls or staff usage with realized business value. Expand autonomy only when the evidence meets agreed criteria, and retain a route to reduce scope or restore manual handling.
A practical first-cycle plan
The following sequence is a planning proposal, not a fixed delivery promise:
- Define the outcome and authority. Select a bounded workflow, record its baseline, appoint owners and agree exception boundaries.
- Design the work and roles. Map human and agent tasks, required information, handoffs, learning needs and operational responsibilities.
- Build and test the service. Validate permitted actions, realistic failures, recovery, review capacity and end-to-end performance.
- Run a controlled pilot. Review outcome evidence with business and operational owners, then decide whether to expand, redesign or stop.
An AI operating model becomes concrete when a team can explain who owns the result, how people and agents perform the work, what authority each participant holds and how the organization learns from the evidence.
Strategy → business capability → workflow and decision rights → human and agent execution → measured value.
Continue the discussion
Which workflow in your organization would benefit most from redesigning human and agent responsibilities together?
Explore the related articles on the agent control plane and EA repository readiness, or discuss your transformation.
Sources
[1] McKinsey, AI is changing work. Now it has to change the organization, 5 October 2026. https://www.mckinsey.com/capabilities/people-and-organization/our-insights/ai-is-changing-work-now-it-has-to-change-the-organization
[2] Microsoft Learn, Multi-agent patterns, updated 6 July 2026. https://learn.microsoft.com/en-us/agents/architecture/multi-agent-patterns