A role can retain its name while its work, decisions and required skills change substantially. Enterprise leaders need to design that transition as carefully as they design the AI.
McKinsey’s latest Chart of the Week, featured in its 17 October 2026 newsletter, is a useful prompt for a different transformation conversation: what will people actually do when agents take on parts of a workflow?
What the chart tells us
McKinsey Global Institute’s September 2026 US research projects that more than 70% of workers could need some reinvention of their work. About 25% could have over 30% of task time reallocated. These are modelled possibilities through 2035, not observed outcomes or forecasts for an individual employer.
Read the horizontal axis as likely automation adoption and the vertical axis as reduced labor demand attributable to automation. Color represents the extent of task-time reallocation; bubble size represents current full-time-equivalent employment. The plot separates adopting automation from reducing demand for people. It also shows that reinvention extends beyond the most disrupted occupations.
That distinction matters. The chart does not say that 70% of jobs disappear. Nor does a point on the chart prescribe a staffing decision. Its US-wide modelling should prompt local investigation, not be copied into a UAE workforce plan as a target.
My interpretation: make the future work visible
My recommendation is to treat workforce reinvention as part of business architecture. An application inventory tells you which systems exist. A job-title list tells you which positions exist. Neither, on its own, explains how a customer outcome will be delivered after agents begin acting.
The missing connection is the work itself: activities, decisions, handoffs, information and accountability. Before approving a new agent, a leadership team should be able to describe the human role that remains alongside it.
A service coordinator example
Consider a proposed tenant-maintenance workflow. Today, a coordinator may gather case history, check availability, contact suppliers, update the tenant and chase closure. An agent could retrieve permitted records, propose scheduling options and prepare updates. Those are design options, not evidence that the service can run autonomously.
The coordinator’s future role might emphasize recurring faults, disputed completion, supplier coordination and reviewing uncertain recommendations. Technical diagnosis and physical repair remain with qualified people. Spending exceptions remain with the designated approver. Someone must still own whether the tenant’s problem was resolved.
This is an original illustrative design, not a client case or a quantified productivity claim. It exposes the question a pilot must answer: are we removing effort, moving it elsewhere, or creating additional review work?
Five architecture decisions to make before scaling
| Decision | Evidence the team should produce |
|---|---|
| Which outcome are we improving? | A defined service boundary, accountable owner, baseline and acceptance criteria. |
| What changes in the work? | A current and proposed task map, including exceptions, handoffs and work newly created by oversight. |
| Who can decide and act? | Explicit approval limits, tool permissions, escalation responsibilities and recovery routes. |
| What must people learn? | Role-specific practice in evidence review, exception handling, domain judgment and supervised use of the tools. |
| How will value be verified? | Service outcomes, full costs, workload distribution, quality and observed adoption—not only agent activity. |
In the EA repository, connect the business capability to the process, human role, decision, application service and information needed to perform it. Add the agent’s owner, permitted actions, verification evidence and fallback. Keep the proposed design distinct from the deployed arrangement.
Build learning around real decisions
A generic prompt-writing course is unlikely to prepare a coordinator for a disputed repair or an ambiguous supplier recommendation. Training should follow the decisions the person will face.
Use realistic practice cases. Ask the employee to identify missing evidence, challenge an unsupported recommendation, explain when to escalate, and recover from a failed action. Assess whether the person can make a sound decision with the tool, rather than whether they completed a tutorial.
Leaders should also budget time for learning and review. A role overloaded with exceptions can become harder even when routine tasks become faster. That possibility belongs in the operating-model design and pilot evaluation.
Start with a bounded domain pilot
Select one service journey, agree its owner and map the existing work with the people doing it. Design the proposed human–agent arrangement, test difficult cases and compare the resulting service with the baseline. Include review, integration, support and training costs.
If capacity is released, agree how it will be used: improved service, reduced backlog, greater throughput or a verified change in expenditure. Do not count the same released hour as several different benefits.
The leadership decision is then grounded in evidence: which work should change, what support people need, and whether the outcome justifies expansion.
Explore a reference journey
My Domain Reimagination example lets you examine tenant-service scenarios, proposed capabilities and human–agent responsibilities. The Modelling Studio provides supporting workflow views. These are reference designs for discussion, not operational agents.
Discuss a workforce and agentic-workflow design workshop →
Source and perspective
McKinsey Global Institute, Workforce in motion: Skills and pathways to future jobs in the United States, 29 September 2026; featured in Chart of the Week, 17 October 2026. The chart and research belong to their respective owners. The enterprise architecture recommendations and tenant-service example are Ahmad Al Shami’s independent interpretation. No McKinsey endorsement is implied.