Source: [McKinsey’s AI operating system: start with one decision your business needs to make — Skills for Business]() [← All articles](https://skillsforbusiness.ai/blog/) Workplace adoption · Analysis # McKinsey’s AI operating system: start with one decision your business needs to make What McKinsey’s AI operating system means for business, where its evidence stops, and how to design a first workflow with clear decision rights. [Skills for Business](https://skillsforbusiness.ai/blog/editorial/)30 October 20267 min read On this page 1. [What McKinsey means by an AI operating system](https://skillsforbusiness.ai/blog/mckinsey-ai-operating-system-business-decisions/#what-mckinsey-means-by-an-ai-operating-system) 2. [A second framework points toward organizational work](https://skillsforbusiness.ai/blog/mckinsey-ai-operating-system-business-decisions/#a-second-framework-points-toward-organizational-work) 3. [Start with a decision that crosses a boundary](https://skillsforbusiness.ai/blog/mckinsey-ai-operating-system-business-decisions/#start-with-a-decision-that-crosses-a-boundary) 4. [Build shared meaning before adding more agents](https://skillsforbusiness.ai/blog/mckinsey-ai-operating-system-business-decisions/#build-shared-meaning-before-adding-more-agents) 5. [Give reusable skills a specific job](https://skillsforbusiness.ai/blog/mckinsey-ai-operating-system-business-decisions/#give-reusable-skills-a-specific-job) 6. [Teach people to challenge recommendations](https://skillsforbusiness.ai/blog/mckinsey-ai-operating-system-business-decisions/#teach-people-to-challenge-recommendations) 7. [Use a bounded rollout to test the architecture](https://skillsforbusiness.ai/blog/mckinsey-ai-operating-system-business-decisions/#use-a-bounded-rollout-to-test-the-architecture) 8. [Sources](https://skillsforbusiness.ai/blog/mckinsey-ai-operating-system-business-decisions/#sources) What to take away - Treat the AI operating system as an organizational design proposal, not a product category with proven returns. - Start with one decision that crosses teams, then define its inputs, owner, permissions and feedback. - Reusable agent skills can preserve a procedure; they still need current data, working integrations and accountable owners. An AI operating system is a useful idea when it forces a business to connect its knowledge, decisions and actions. The practical starting point is one recurring decision that currently gets stuck between teams. Define the evidence it needs, who can decide, what an agent may do, and how the result will be checked. That is our proposed way to apply a broad management concept. It is not a claim that buying a platform will produce a particular return. For a smaller business, the first implementation could be a controlled workflow using existing systems. For an enterprise, it could become a shared foundation used across several departments. Both need clear boundaries before they need an ambitious name. ## What McKinsey means by an AI operating system In its [13 October 2026 article](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-ai-operating-system-a-new-way-for-ceos-to-run-the-enterprise), McKinsey describes an AI OS as a management layer combining business context, analytical tools, agents and interfaces. Its proposal goes beyond answering questions: connect information to decisions, actions and feedback across functions, while keeping institutional knowledge portable as technology changes. This is a management and architecture proposal, not a software operating system you install on a laptop. It also should not be confused with an individual agent framework using a similar name. McKinsey reports substantial gains from early deployments, including planning cycles accelerated by up to ten times. Those are consultancy-reported experience claims, not an independently validated forecast for your organization. The article does not provide a reproducible evaluation protocol establishing that adopting the architecture causes those gains. Its survey figures about adoption and financial impact likewise do not demonstrate that an AI OS closes the gap. A description of a business problem and a proposed remedy are different kinds of evidence. Read the article as a strategic hypothesis worth testing. ## A second framework points toward organizational work The [World Economic Forum’s white-paper overview, published on 23 June 2026](https://www.weforum.org/publications/the-ai-first-operating-system-a-blueprint-for-operating-and-business-model-innovation), introduces a related framework developed with Kearney. It draws on insights from more than 50 organizations and identifies five elements: intelligence engines, adaptive technology stacks, operations redesign, human–AI teaming and new value creation. For this article, we inspected the public overview rather than the complete white paper. Its case-study descriptions are not a controlled comparison of companies adopting and rejecting a common architecture. Nor should the two publications be treated as independent experimental confirmation of one another. Our reading of their shared emphasis is that technology choices and organizational choices belong in the same discussion. Neither publication supplies a universal procurement specification. A leadership team still has to decide which work matters, which sources are authoritative and who remains responsible when an automated recommendation fails. ## Start with a decision that crosses a boundary Consider a hypothetical service company deciding whether it can accept a new customer project on the requested date. Sales knows the promise made to the customer. Delivery knows capacity. Finance knows the margin requirements. A manager has to approve exceptions. A chatbot connected to documents might retrieve each team’s information. The harder problem is deciding what counts as available capacity, whether an unconfirmed booking should count, and which margin rule applies. Those are business definitions and decision rights. A fluent answer cannot resolve a disagreement the organization itself has left unresolved. Write a short decision record before choosing an orchestration tool: | Question | Example answer for the hypothetical project workflow | | --- | --- | | What is the decision? | Accept the requested start date, propose another date, or escalate | | Which records are authoritative? | Approved project scope, current capacity plan and active pricing policy | | Who owns the decision? | Delivery manager, with finance approval for margin exceptions | | What can the agent do? | Assemble evidence, identify conflicts and draft options | | What must stop execution? | Missing scope, stale capacity data or conflicting approval rules | | How is the outcome recorded? | Approved option, reasoning, source versions and later delivery result | These are proposed design choices, not a tested customer implementation. Their value is that a colleague can inspect them and explain why an action is allowed. ## Build shared meaning before adding more agents Suppose sales uses “available” to mean a person has no confirmed booking. Delivery uses it to mean that person has the relevant skills and enough uninterrupted time. Both systems may contain accurate records, yet the resulting recommendation can still be wrong. Make the definition explicit and assign someone to maintain it. Record exceptions. Include an effective date where a rule changes over time. If two departments disagree, keep the disagreement visible until an accountable person resolves it. This work can start with a small governed table of terms and rules. A larger implementation may need formal data models and relationships. The first question is whether the system can reliably apply the definitions required by the chosen decision. The size of its knowledge representation is secondary. Keep ownership close to the business process. Technical teams can build retrieval and validation, but they should not silently decide what a profitable project or an acceptable delay means. Those choices affect commitments to customers and colleagues. ## Give reusable skills a specific job An agent skill can describe how to assemble a project-readiness brief: required inputs, approved sources, calculations to request, uncertainties to preserve and output checks. That makes the procedure inspectable and easier to maintain. Our [guide to SKILL.md files](https://skillsforbusiness.ai/blog/skill-md-files-as-team-work-instructions/) explains the distinction between a reusable instruction package and a saved prompt. For this example, the skill would be one component of the workflow. It would not contain the live capacity database, grant access to finance records or authorize a customer commitment. Separate three things in the design: the procedure, the current business state and the permission to act. Version the procedure. Retrieve the current state through approved connections. Enforce permissions in the execution environment. A useful skill should also define stopping behavior. If the source records disagree, the expected result might be a brief explaining the conflict and naming the responsible owner. Generating a confident recommendation in every case would be the wrong success criterion. ## Teach people to challenge recommendations Workforce preparation should follow the actual responsibilities in the workflow. A salesperson needs to understand which commitments remain provisional. A delivery manager needs to challenge capacity assumptions. A technical owner needs to detect failed retrieval and integration errors. Use exercises built around those decisions. Give participants a brief with a stale source, a missing approval or an apparently sensible option that violates a rule. Ask them to explain what they would accept, reject or escalate. This is an editorial training proposal. We are not claiming a measured improvement from this exercise. Its purpose is to make learning observable: participants should demonstrate judgment on a concrete case, rather than simply complete an introduction to prompting. Protect time for that work. If reviewing recommendations becomes a new responsibility, someone must have capacity to perform it. HR can help clarify roles and learning needs, while process owners define the acceptable decision and technical teams explain system limits. ## Use a bounded rollout to test the architecture Begin in observation mode: produce recommendations alongside the existing process and compare them with actual decisions. Keep the same input snapshot when investigating differences. Otherwise a change in capacity between runs can look like a reasoning error. Record missing evidence, conflicting definitions, reviewer corrections and decisions that required escalation. Track access failures separately from poor recommendations. Each problem points toward a different remedy. Only expand permissions after the workflow meets criteria agreed in advance. An agent might eventually create an internal draft task while final customer communication still requires approval. Permission should grow around specific actions, with a clear way to pause or reverse them. Measure the full route to an accepted decision, including preparation and review. Our [workplace adoption guide](https://skillsforbusiness.ai/blog/workplace-ai-adoption-measure-completed-work/) provides a method for accounting for that effort. A faster recommendation is useful only if the resulting decision remains acceptable. For a small company, one workflow owner and a modest set of representative cases may be an appropriate start. Larger organizations should include cross-functional ownership and controls proportionate to the consequences. Neither scale justifies skipping a record of why the system acted. The next useful step is to choose one decision that repeatedly crosses a team boundary. Bring its owners together and document a normal case, an exception and a case that must stop. Those three cases will reveal more about what your first AI operating system needs than another catalog of agent features. ## Sources & further reading Sources checked for this article. Research findings and vendor claims are distinguished in the text. 1. [The AI operating system: A new way for CEOs to run the enterprise](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-ai-operating-system-a-new-way-for-ceos-to-run-the-enterprise)McKinsey / QuantumBlack · Accessed 30 October 2026 2. [The AI-First Operating System: A Blueprint for Operating and Business Model Innovation](https://www.weforum.org/publications/the-ai-first-operating-system-a-blueprint-for-operating-and-business-model-innovation)World Economic Forum, in collaboration with Kearney · Accessed 30 October 2026 Produced with AI-assisted research and writing. Examples and recommendations are our editorial synthesis unless attributed. This article does not claim independent product testing or human expert review. [Read our editorial policy.](https://skillsforbusiness.ai/blog/editorial/) ## Keep reading [Workplace AI adoption: measure completed work, not logins](https://skillsforbusiness.ai/blog/workplace-ai-adoption-measure-completed-work/)[Give coding agents a reproducible bug and a clear acceptance test](https://skillsforbusiness.ai/blog/coding-agent-bug-report-acceptance-tests/)