AI does not scale by itself. Redesign the work.

Access to an AI model does not tell a business how to use it well. That decision also depends on the work, the information available, the people responsible and the way results will be measured.

An impressive pilot can answer whether a task is technically possible. It cannot, by itself, establish whether the organization should change its operating model around it. For that, the business needs a clearer account of what will improve, what must change and what could invalidate the plan.

McKinsey's June 2026 article reports a substantial gap between AI experimentation and enterprise-wide scale. Its operational-excellence survey collected 1,000 responses from managers and executives at 696 companies, with financial analysis covering 677. The sample focused on large organizations. McKinsey reports associations between stronger operating practices, AI deployment and financial performance, while explicitly distinguishing correlation from causation. [1]

That research is a reason to examine the organization around AI, not a promise of return on investment. ETHORITY's practical interpretation is to start with the business work and measure the proposed change, rather than treating tool deployment as the result.

Consider a fictional service team that wants customers to receive useful answers sooner. “Introduce an AI agent” is a technology direction. It is not yet a definition of the problem.

Where do requests wait? Which answers require a search across systems? Which cases come back because the first response was wrong? What does the team know about resolution time, rework and escalation? The answers may reveal a role for AI. They may also reveal an outdated knowledge base or an approval step that should be fixed first.

A missing baseline is not a reason to invent a saving. It is a reason to make measurement part of the plan. Choose an objective whose progress a business owner can observe, and record which baseline facts are known, supplied by the customer or still required.

Different steps in the same workflow can need different tools. Our design principle is to use the simplest sufficient execution mode for the task.

A routing rule may remain deterministic. A scoring or detection task may suit analytical AI. A draft or summary may use generative AI. A bounded investigation that needs several tools may justify an agent. Human judgment and authority are not the last rung of this ladder; they remain decisions about responsibility across the whole workflow.

For the service team, preparing an answer and executing a refund should not inherit identical permissions. The operating plan needs to say what each component may do, what information it needs and when a person takes over.

This is not an argument against ambitious automation. It is a way to make the ambition testable.

A proposed system needs more than a model selection. It needs usable source information, documented interfaces, access boundaries, ownership and a way to handle exceptions.

Suppose the assistant cannot find an approved answer. Should it ask a question, offer a limited response or escalate? Suppose two sources disagree. Which one is authoritative, and who resolves the conflict? Suppose a tool times out after a customer action. How will the team know whether the action completed?

These are operating-design questions. They belong before broad rollout because they shape both the service customers receive and the work people must do to maintain it.

A useful plan identifies the unresolved conditions rather than hiding them behind an architecture diagram. It can recommend an investigation or a narrower pilot when the evidence does not yet support a deployment decision.

A dashboard can show that something happened. It does not decide who is allowed to change the process, restrict a tool or stop an unsafe operation.

The operating design should identify the accountable owner, permitted actions, approval points and escalation path. It should specify the conditions for adjusting, stopping or expanding the system. Capability and authority remain different: an AI component's ability to act does not grant permission to act.

For our service example, that could mean draft-only assistance during an initial trial, review of rejected and escalated cases, and a separate decision before granting transactional permissions. This is a design scenario, not a prescription for every organization or a description of an existing customer deployment.

The cheapest model call is not necessarily the cheapest completed task. A business case should account for the components relevant to its workflow: integration, retrieval, model and tool usage, retries, human review, corrections, support and maintenance.

Keep observed costs separate from assumptions. Keep expected consequences of errors visible rather than mixing them into an apparently measured result. And say what happens to any time released. More capacity, better quality and lower cash expenditure are different outcomes; one does not automatically establish another.

A planning artifact can show what would need to be true for an initiative to make economic sense. Realized value requires subsequent observation and a defensible explanation of what contributed to the result.

A company can buy more capable models without increasing the throughput of its work. If a document still waits for an unavailable approver, faster drafting may simply create a longer queue. If source data is incomplete, a more fluent answer can make the defect harder to notice. Start by locating the constraint in the whole process rather than assuming the model is the limiting component.

Map a small number of representative cases from request to accepted result. Record waiting, preparation, checking, correction and handover. Ask the receiving team where work returns and why. The result may point to an AI opportunity, a data-maintenance problem or a simpler change in responsibility. A useful discovery process should be able to recommend any of those.

Define the next decision in advance. Are you deciding whether to automate a step, introduce assistance, improve the source material or stop an unsuitable experiment? This keeps the exercise focused. Without a decision, process mapping can become a new documentation programme whose outputs nobody uses.

Consider a hypothetical supplier-onboarding process. Checking whether a mandatory field is present may need a deterministic rule. Estimating demand may need an analytical model. Summarising a supplier's documents may benefit from generative assistance. Updating an approved record may require a bounded workflow action. Those activities should not be collapsed into one agent simply because they appear in the same process.

Human authority remains separate from the technical method. A deterministic system can make a consequential decision, while a sophisticated model can remain in a draft-only role. The appropriate permission follows the action and its consequence, not the fashionable label attached to the technology. Decide which tasks need review and who can change the outcome.

Use the simplest method that can meet the acceptance rule. Complexity has a maintenance cost: more dependencies, more failure states and more explanations required during recovery. An agent is useful when its flexibility serves the work and its authority can be bounded. It is not automatically the next stage of every automation.

The people who consume the output should help define the test. A sales team may like a fast proposal draft while delivery finds that its assumptions cannot be supported. A procurement team may receive a fluent supplier comparison that leaves the decisive data-region question unanswered. Acceptance must reflect the recipient's actual needs.

Select ordinary and difficult cases. Include incomplete inputs, conflicting documents and cases that should remain manual. Keep a baseline and document changes to staffing, demand or policy during the test. Otherwise a result can be attributed to the tool when several parts of the operating system changed together. Explain the observation without claiming more causal certainty than the design supports.

Measure review effort and rework. If staff must check every factual statement, include that time. If a result is rejected, include the cost of completing the task another way. Averages should not erase important differences between case types. A tool may be useful for one class of work and inappropriate for another; that is a useful selection rule rather than an embarrassing result.

Suppose two hypothetical configurations each process 1,000 requests for €500 in direct usage costs. One produces 800 accepted results and the other 500. Their direct cost per accepted result is €0.625 and €1 respectively, before review, support and implementation. The arithmetic does not establish which is better overall; it reveals why equal request prices can conceal different work economics.

Now add the review minutes and the cost of failed cases. Check whether the accepted results are comparable in quality and consequence. If one configuration handles only easy requests, its acceptance rate cannot be compared directly with a system handling the full queue. Keep the denominator and scope stable before declaring a cost advantage.

Use the calculator to explore such scenarios. Label assumptions and distinguish potential capacity from realised financial value. A result can justify a better service even without a reduction in payroll. What matters is that the claimed benefit follows a credible mechanism and the organisation knows what it intends to do with the improvement.

Name the owner of each dependency: documents, permissions, integrations, provider terms and user support. Establish how changes reach the workflow owner and when they require another test. A pilot supported by its developers can appear reliable while depending on manual interventions that the future operating team does not know about.

Rehearse failure and recovery. Can people continue if the model is unavailable? Can an uncertain external action be reconciled without duplication? Can staff identify the last accepted configuration? Preserve the evidence and working instructions needed to recover. The ability to pause one affected action while retaining useful read-only work can be more valuable than an ambitious all-or-nothing design.

Expansion should check whether the successful conditions exist in the next setting. A different language, data source or consequence can change the result. Carry forward the method and learning, but test the new assumptions. Scaling is a sequence of related operating decisions, not copying an interface across departments.

Use the Good AI Prism to explore relevant options after defining the task. An AI Business Blueprint can structure a concrete business question. A proposal-based Enterprise AI Opportunity Case is relevant when the investment case and operating conditions require deeper work. A bounded AI Trust Pilot addresses a particular use case rather than promising organisation-wide transformation.

Choose the smallest piece of work that resolves the next uncertainty. Bring a real process, a baseline, the receiving team and the decision that the evidence must support. The goal is not simply to deploy more AI. It is to make useful work more reliable, economical and accountable, then preserve what was learned when the organisation grows.

ETHORITY's operating loop is DISCOVER → CREATE → RUN → IMPROVE → GROW. As a planning discipline, that means preserving the objective, evidence, assumptions, operating conditions and reasons for the next action. The loop describes our strategic direction, not a claim that every operating feature is publicly active.

When the model, source data, workflow or customer need changes, the team should be able to revisit the decision without reconstructing it from scattered documents. Decide what to measure, what would justify expansion and what would require a different approach.

An AI-first organization is not necessarily the one with the most AI tools. The stronger ambition is a repeatable ability to identify useful work, select an appropriate approach, establish the conditions for operating it and learn from the result.

The next question is therefore not only “Which AI should we buy?” It is “What must change around it for this business objective to become achievable?”

Sources and scope [1] McKinsey & Company, “Putting AI to work: The operational excellence imperative,” 19 June 2026; source checked 26 September 2026: https://www.mckinsey.com/capabilities/operations/our-insights/putting-ai-to-work-the-operational-excellence-imperative The opening research paragraph summarizes the source. The subsequent design recommendations are ETHORITY's interpretation and existing planning method, not findings attributed to McKinsey. The service-team example is a scenario. No customer savings, causal effect, model superiority or external endorsement is claimed.