By Ahmad Al Shami · Strategy, Enterprise Architecture & AI Transformation
An agent can complete a task successfully while the customer’s problem remains unresolved. Designing the whole service is what connects local automation to a business outcome.
Consider a tenant reporting a recurring cooling fault. An assistant captures the request, another component schedules a visit, and a notification confirms the appointment. Each step may work. Yet the technician could arrive without the right history, the fault could return, and the tenant could have to explain the problem again.
The opportunity is to redesign the service from the first report through verified resolution, including the exceptions that make the work difficult. That requires business ownership, connected information, appropriate tools and clear authority. It is an architecture and operating-model challenge as much as an AI challenge.
Start with a domain that has an outcome and an owner
Chapter 3 of Rewired, second edition, frames transformation around business domains: coherent end-to-end processes or journeys whose connected improvements can deliver meaningful value. Its domain architecture links value levers to solutions and use cases, supported by data and technology foundations. [1]
For our illustrative example, the domain is Tenant Service and Resolution. Its boundary begins with an issue or actionable feedback and ends with a verified outcome—or a clearly recorded unresolved, disputed, declined or withdrawn state. A closed ticket is an administrative state; it is not sufficient evidence of satisfaction.
The domain owner would agree the service outcome, investment priorities and decision rights. The team would examine maintenance coordination, complaint handling and supplier dependencies together. This does not require replacing every application or changing everything at once. It creates a common direction for a bounded first implementation.
Distinguish task assistance from workflow transformation
Chapter 5 distinguishes four forms of application: individual augmentation, task automation, agentic workflows and agentic systems operating across multiple workflows. The distinction helps leaders understand the different integration and organizational demands. It is not a requirement that every service progress to maximum autonomy. [1, Exhibit 5.1, p. 82]
Drafting a tenant response can help an employee. Automatically recording an approved appointment can remove a repetitive task. Coordinating a complete service case adds questions about shared context, exceptions, authority and recovery. Optimizing maintenance, procurement and resource scheduling together introduces further trade-offs and cross-domain accountability.
Choose the smallest scope that can demonstrate an important outcome. Expand autonomy only where the evidence, permissions and operating support justify it.
Design the work before assigning agents
The proposed maintenance journey below is my original application of these ideas. It is a reference design, not a report of an implemented client system.
For a routine request, the system could retrieve authorized history, ask for missing information and propose a service plan. A technician remains responsible for physical diagnosis and repair. Urgent safety concerns require a defined route to qualified people; an AI response must not delay emergency handling. Spending, supplier selection and compensation follow the actual delegation of authority.
For a recurring fault, the design should preserve earlier repair evidence and involve a specialist rather than simply issue another visit. For a disputed resolution, a person with the appropriate independence reviews the evidence and remedy. These paths determine whether the service improves in practice.
Use the right mechanism at each step
Rewired’s claims-handling exhibit combines rules-based systems, analytical AI, generative AI and agentic AI within one workflow. Its lesson is useful beyond insurance: assigning every step to an agent is unnecessary. [1, Exhibit 5.3, p. 92]
| Work to perform | Appropriate design choice |
|---|---|
| Check fixed eligibility, permission and spending thresholds | Explicit rules and authorized business-system controls |
| Predict recurring faults or detect unusual patterns | Validated analytical models where suitable data exists |
| Summarize case evidence or draft an explanation | Grounded generative AI with source traceability |
| Plan the next steps when context changes | A bounded agent with scoped tools, observable actions and escalation |
| Approve exceptions, perform repairs or judge a dispute | The appropriately authorized or qualified person |
A workflow can therefore be agent-enabled without making every activity autonomous. The design decision depends on variability, consequences, verification and cost.
Where business architecture and EA contribute
My architectural interpretation is to preserve a traceable connection from outcome → capability → workflow → role and decision → application service and data → operating evidence.
Business architecture defines the domain boundary, stakeholders, required capabilities and value expectations. Process models make handoffs, approvals and exception paths explicit. Enterprise architecture connects the process to information ownership, application services, integrations and technology dependencies.
An EA repository should distinguish the proposed design from the deployed implementation and from observed performance. A model showing an approval does not prove that a runtime permission check exists. That requires implementation evidence and testing. Likewise, a diagram of an agent does not demonstrate that it has reliable data, an accountable owner or a supported recovery path.
McKinsey’s current guidance also emphasizes reusable data foundations, governed interfaces and coordinated changes to technology and the operating model. [2] For delivery teams, the implication is to identify which foundations can be shared while retaining the domain-specific meaning and access restrictions each workflow needs.
Evaluate the service and the agent separately
Chapter 5’s E.ON Next example illustrates how orchestration depends on integrations, guardrails, evaluation, human handover and training—not merely a conversational interface. Its reported results concern that case and should not become targets or promised benefits for another organization. [1, pp. 85–88]
For the tenant example, business measures could include verified resolution time, repeat faults, reopened cases, unresolved work, tenant feedback and full cost per resolved case. Technical measures could include urgency classification, retrieval quality, unsupported claims, permitted tool-use success, appropriate escalation and latency.
A safe, necessary escalation is not automatically a failed service outcome. Distinguish autonomous completion from successful completion with human intervention. Establish baselines before setting targets, and separate released capacity from actual reductions in expenditure.
Explore the design in practice
I have developed an interactive Domain Reimagination reference example to make these connections easier to explore. Compare routine requests, recurring faults, safety concerns and disputed resolutions; examine the proposed human–agent responsibilities and capability requirements.
Explore the tenant service journey →
Then visit the Modelling Studio Process Library to explore supporting workflow models. The reference designs support discussion and modelling; opening them does not deploy operational agents or establish organizational readiness. The AI drafting workspace is private to Ahmad.
For leadership teams, the practical first step is a domain workshop: agree the outcome and boundary, identify the accountable owner, walk through difficult cases, and prioritize the capability gaps that prevent a credible pilot.
Discuss a domain reimagination workshop →
References and perspective
[1] Rewired, second edition: selected supplied extracts from Chapter 3, pp. 49–61, and Chapter 5, pp. 79–95; particularly Exhibits 3.2, 5.1, 5.2 and 5.3. Page references follow the photographed edition. The selection omits p. 89. This article paraphrases selected concepts; the maintenance example and architecture interpretation are Ahmad Al Shami’s own.
[2] McKinsey, Building the foundations for agentic AI at scale, 2 April 2026.
Independent commentary. No McKinsey endorsement or certification is implied. Illustrative service design; no client performance or readiness claim.