How do you redesign the way work gets done when AI is now part of it?
Section 3.1 introduced AI as a dimension of the operating model, alongside people, process, and technology, and made the conceptual case for it. If AI is a dimension of the operating model, what does it look like to actually design an operating model that includes it? What are the building blocks the leadership team will be choosing from, and what patterns do they form?
The answer has two parts, in sequence.
The first part is the ingredients. Before you can design an operating model that includes AI, you have to understand what the elements are. All of them, the AI elements and the rest. The humans and what they bring. The AI in its various forms. The data and knowledge the company holds. The connected systems that already run the business. The standards and governance that hold everything together. Five categories of ingredients. The leadership team will be making choices within each.
The second part is the sketches. With the ingredients understood, the section walks through five different operating model designs that emerge when AI joins. They are not the archetypes from Section 2.2, which name what kind of AI-Native company you are; these name how the ingredients get assembled. Each sketch combines the ingredients differently and reflects a different priority. None of them is the right answer. Each one is a worked example of how the ingredients can be combined into a coherent design. The point is to see the variety, understand the trade-offs, and use the sketches as starting points for your own design work.
There are well-established operating model frameworks the leadership team may already know. The MIT CISR archetypes from Ross, Weill, and Robertson. Galbraith's Star Model. The Operating Model Canvas. These remain useful and the work in this section does not replace them. What AI changes is that the design space expands. New designs become possible because AI as a dimension of the operating model produces options that did not exist before. The sketches that follow show several ways to assemble the expanded set of ingredients. Read them as additions to the older frameworks rather than as substitutes.
The five categories below are how I have come to organize the elements that go into any AI-Native operating model design. Other organizations of the same elements are possible. The five-category structure has held up in the workshops I have facilitated because it covers the design space without becoming overwhelming.
Category One. The Human Layer.
Start with the people who do the work: what they know, what they are responsible for, and how they work together. Their experience should help shape where and how AI enters the job.
What individual humans bring includes their skills and expertise, the deep knowledge they have developed through years of doing the work. It includes their judgment, which is what they apply when the rules and frameworks do not cover the situation in front of them. It includes their relationships, with colleagues, customers, suppliers, regulators, the network of people who make the work flow. It includes their creativity, the capacity to frame problems in new ways. It includes their accountability and ethical responsibility, the willingness to own outcomes. It includes their tacit knowledge, the unwritten know-how that sits in their heads and that the company would lose if they walked out the door. Section 5.3 explores this in more detail.
How humans are organized for work is a separate set of choices. The reporting hierarchies and management layers. The functional departments. The cross-functional teams. The decision authority and escalation paths. The communication rituals, the standups, the all-hands, the one-on-ones. These structures shape how human capability gets applied to the work. The same humans, organized differently, produce different outcomes.
The leadership team designing an AI-Native operating model will be making choices about both. Which human capabilities are most valuable in this company, where in the organization they sit, and what structure surrounds them. The role-design section in Stage 5 shows how to carry these choices into the responsibilities, authority, and working relationships of a particular function.
Category Two. The AI Layer.
The AI layer is the toolbox of AI capabilities available to the company. The toolbox is wider than most leadership teams initially recognize. Talking about "AI" as one thing is the first mistake that produces bad design.
The AI layer includes individual AI assistants: personal-level systems that can be given scoped memory of an employee's work, adapt to preferences, and take authorized actions on that person's behalf. Enterprise offerings from OpenAI, Anthropic, Microsoft, and others contain early forms of this pattern. The mature form, and the governance required to make it safe, is still being built.
It includes function-specific AI agents, scoped to a particular role or workflow rather than to a person. A sales-development agent. A code-review agent. A recruiting agent. A customer-service tier-one agent. These are different from individual assistants because they exist to do a specific kind of work and serve whoever needs that work done.
It includes AI features embedded in other tools: the AI inside the document editor, email client, project-management software, or specialized professional application. For many knowledge workers, these embedded features may become the primary way they interact with AI because the capability appears inside work they already do.
It includes systems of agents: coordinated components purpose-built for domains such as supply chain, customer service, or recruiting. Vendors increasingly describe products this way, though some are genuinely multi-agent systems and others are workflows behind an agent label. The leadership team must look past the category name, decide which capabilities to buy or build, and understand how coordination, evaluation, authority, and failure handling actually work.
Each form of AI is a different kind of participant in the work. Treating them as one thing collapses real design choices into invisibility. The leadership team that recognizes the AI layer as a toolbox rather than a single tool has the first thing it needs to design well.
Category Three. The Data and Knowledge Layer.
AI is constrained by what it can reliably access, interpret, and act on. The data and knowledge layer is what the company has accumulated that can inform the system. This category includes structured and unstructured material, explicit records, and tacit knowledge that must be elicited rather than assumed.
The structured operational data lives in the existing systems. The transactions in the ERP. The customer records in the CRM. The personnel records in the HR system. The sensor data in the manufacturing systems. The order history. The financial ledgers. This is the data the company already has and that most AI initiatives begin by trying to make available.
The unstructured documents are the contracts, reports, decks, emails, meeting transcripts, technical specifications, training materials, and other documents the company has generated over years. Modern AI systems can ingest or extract content from many of these formats, but reliable use remains difficult because authority, recency, permissions, definitions, and relationships are often unclear. Section 4.1 covers how retrieval, knowledge graphs, and related architectures make this material more usable.
The historical knowledge is the company's accumulated record. The decisions made and why they were made. The customer interactions and their outcomes. The product launches and how they went. The hires and how they performed. This is the institutional memory in a literal sense, the record of what has happened.
The reference materials are the procedures, playbooks, policies, and training content the company has produced for its own use. These are the codified knowledge, the part of institutional knowledge that someone took the trouble to record.
The institutional knowledge in people's heads can be among the most valuable and is often the hardest to access. The senior plant manager who knows why a specific line behaves the way it does. The relationship manager who anticipates what a customer will ask. The veteran engineer who knows which corners of the codebase demand care. Section 8.2 names the failure mode of trying to capture this knowledge after its holders have been signaled out of relevance. Useful capture depends on their willing participation and validation; extraction without trust produces silence, compliance theater, or shallow artifacts.
The shared memory architecture is what holds all of this together. Knowledge graphs. Vector databases. Document repositories. Data lakes. The collaboration surface where AI work happens visibly to the organization. These are the substrate on which the data and knowledge layer is built. Section 4.1 and Section 4.3 cover the architectural choices.
Category Four. The Connected Systems Layer.
The connected systems layer is the technology infrastructure the company already runs. The systems of record. The systems of engagement. The systems of operation. The AI is being added to these systems, and the design problem includes how the integration happens.
Map the systems that hold financial, customer, workforce, and operational records, including the specialist systems your industry requires. For each, identify the authoritative data and the actions AI may take.
Beyond the systems that hold business data and process, there is the infrastructure that supports the work. Security and identity systems, the Active Directory or Okta that controls who can access what. Communication infrastructure, email and messaging. Data processing systems, the analytics platforms and BI tools.
The connected systems layer is where most companies have spent the last twenty years of technology investment. The AI architecture has to integrate with this layer because this is where the actual operational data and process lives. The integration is not optional. The leadership team's choices include which systems the AI architecture connects to first, what data flows in which direction, and which integrations are deep, meaning read and write, versus shallow, meaning read only or one-way.
Section 2.3 introduced MCP and Agent2Agent. Here the design task is to specify which systems connect, what each connection permits, and how the team will test an upgrade.
Category Five. The Standards and Governance Layer.
The standards and governance layer is what holds everything else together. It is the agreements about how data is structured, how requests are made, how decisions are recorded, who is allowed to do what. Without shared standards across the other four layers, the system fragments. With them, the system coordinates.
Data standards are the schemas, taxonomies, and ontologies that define how information is structured. What counts as a customer. How an account is named. What the fields of an order are. The same standards that have always mattered for data integration matter more in an AI-Native operating model because more parties (humans, agents, systems) are consuming the data and they need to agree on what it means.
Process standards are how work flows. The steps in the procurement process. The handoffs in the customer service workflow. The escalation paths for exceptions. Process standards have been the substance of operational excellence work for decades. AI changes what they enable rather than eliminating the need for them. Agents can work inside ambiguity, but predictable operation still requires explicit state, boundaries, handoffs, and exception paths.
Decision-making standards are who decides what, with what input, at what threshold. Who approves a vendor contract. Who escalates a customer complaint. What signals trigger a price change. These standards have always existed informally. AI-Native operating models make them explicit, because agents acting on behalf of humans need explicit authority rules.
Authorization and access standards are the rules about what each party can do. Which agents can read which data. Which agents can write to which systems. Which humans approve which actions taken by agents. The authorization model for agents is a separate problem from the authorization model for humans, and both have to be designed.
Audit and compliance standards govern the record of what happened: which system or agent took which action, under whose authority, against which data, using which version, and with what result. In regulated or high-consequence work, traceability may be mandatory or operationally indispensable. The applicable obligations vary: HIPAA rules for protected health information in the United States, PCI DSS for payment-card environments, GDPR for covered personal-data processing in Europe, sector-specific regulation, contractual controls, and assurance programs such as SOC 2. Logging alone does not create compliance, and sensitive logs create risks of their own. Traceability, retention, access, and deletion need to be designed together from the start.
The standards and governance layer is the connective tissue. Section 8.2 names the case of a company that built governance on prohibition and produced shadow AI everywhere. The lesson from that case applies here. Standards work when they make work easier.
Each sketch below combines the ingredients differently and reflects a different priority. Each is a worked example of an emerging operating model design that becomes possible when AI joins.
Sketch One. The Coordination-Centric Operating Model.
This is the multi-agent nervous system. The AI is primarily organized to handle coordination work that used to be done by humans through meetings, email, and middle management.
The architecture builds from the bottom up. Employees whose work benefits from it have individual AI assistants with permissioned context about their work. Those assistants can coordinate across teams and departments to identify duplication, surface dependencies, and route information, but only within explicit identity, disclosure, and authority rules. At the enterprise level, they integrate with connected systems and domain-specific agent services.
The ingredients this sketch emphasizes: individual AI assistants as the foundation. The knowledge graph and collaboration surface as the shared memory. Agent-to-agent protocols as the connective tissue. Standards for how agents communicate and what authority each one has.
The ingredients this sketch treats as secondary: function-specific agents (the assistants handle most of what would be done by function-specific agents). The customer-facing surface (the architecture is internally focused).
The kind of company this fits: knowledge-work-intensive businesses where coordination loss is the primary inefficiency. Professional services firms. Consulting firms. Companies whose work depends on cross-functional collaboration. Companies where the middle management layer has thickened over time and decision speed has slowed.
The trade-offs: significant investment in individual assistant infrastructure before any visible business outcome. Heavy reliance on standards being established at the individual level before team and department coordination becomes possible. Vulnerable to the failure mode where individual assistants are built without the shared memory substrate, producing fragmented experience rather than coordination.
Sketch Two. The Workflow-Native Operating Model.
This sketch organizes around end-to-end workflows rather than around individuals or teams. The leadership team maps the company's major workflows explicitly. Order-to-cash. Hire-to-retire. Design-to-build. Lead-to-customer. Service-to-resolution. Each workflow is then redesigned with AI inserted at the points where translation, integration, or judgment is needed.
The architecture is process-driven. Function-specific agents handle portions of each workflow; accountable people or teams still own the process and its outcomes. Agents are workflow participants with defined roles and clear handoffs. The handoffs between agents and humans are explicit, with decision standards determining when a system may act and when it must escalate.
The ingredients this sketch emphasizes: function-specific AI agents tied to workflows. The process standards that define how work moves. The connected systems layer, which is where most workflows already live. Authorization standards that govern when agents act on their own.
The ingredients this sketch treats as secondary: individual AI assistants (less central than in Sketch One because the workflow is the primary unit). The knowledge graph (still present, but as workflow context rather than as the central asset).
The kind of company this fits: businesses where operational excellence is the value driver. Manufacturing companies. Financial services firms. Logistics businesses. Healthcare delivery organizations. Any company whose work is process-intensive and where consistency of execution matters more than coordination flexibility.
The trade-offs: requires enough workflow mapping to identify state, ownership, exceptions, and controls, though discovery and limited AI investment can proceed together. Risks producing a rigid architecture if workflows are mapped without flexibility for unusual cases. Can become brittle when business conditions require changes faster than the architecture can adapt.
Sketch Three. The Knowledge-Centric Operating Model.
In this sketch, the knowledge graph or its equivalent is the central asset of the operating model. Humans, agents, and systems all orient around contributing to and consuming from the shared memory. The architecture privileges institutional knowledge as a durable competitive asset.
The architecture is memory-first. The knowledge graph represents selected parts of how the company works: decisions, customer relationships, product knowledge, operational details, and supplier relationships. Agents and people interact with it through governed interfaces rather than writing unchecked assertions directly into shared truth. Connected systems feed it with provenance, while authoritative systems of record remain authoritative where they should.
The ingredients this sketch emphasizes: the data and knowledge layer, especially the knowledge graph. The standards for how knowledge is captured and structured. Audit and compliance controls can become more consistent when access moves through common architecture, although centralization also concentrates operational and security risk.
The ingredients this sketch treats as secondary: individual assistants and function-specific agents (still present, but subordinate to the knowledge architecture).
The kind of company this fits: businesses whose competitive position depends on deep expertise. Professional services firms with strong knowledge management cultures. R&D-intensive companies. Pharmaceutical companies. Engineering firms. Regulated industries where audit trails and explainability are non-negotiable.
The trade-offs: a broad knowledge graph can be expensive and slow to build, while a use-case-led graph can start smaller. Either way, the architecture depends on identity, provenance, recency, and the quality of what enters it, which makes the institutional-knowledge case in Section 8.2 especially relevant. The architecture is most powerful where relationships and accumulated knowledge are genuinely strategic, and less differentiated where they are not.
Sketch Four. The Customer-Surface Operating Model.
This sketch organizes outside-in. The customer interaction layer is the design driver. AI is most heavily invested at the customer-facing surface, and the internal architecture (data, systems, agents) is organized to make the customer-facing AI work.
The architecture is customer-facing. The AI that interacts with customers is the most visible and carefully designed piece. Behind it, agent systems and the data layer feed the experience with customer history, preferences, current context, and product knowledge, but only to the extent permitted by consent, purpose, policy, and law.
The ingredients this sketch emphasizes: systems of agents oriented around customer-facing work. The data layer, especially customer data and product data. The standards that govern how customer interactions are recorded and routed.
The ingredients this sketch treats as secondary: internal coordination among employee assistants (less central because the design driver is customer-facing rather than internal).
The kind of company this fits: businesses whose primary value is in the customer relationship. Consumer brands. Retail. Hospitality. Direct-to-consumer companies. Some financial services. Companies where the customer experience is what drives revenue.
The trade-offs: requires sophisticated customer data infrastructure to do well. Vulnerable to brand and reputation damage if the customer-facing AI produces poor experiences. Underinvests in internal employee tooling, which can produce friction inside the company even when the customer-facing experience is strong.
Sketch Five. The Federated Operating Model.
This sketch acknowledges that one architecture across a large diverse company often does not fit. Each major function or business unit designs its own AI architecture, suited to its specific work. Lightweight standards govern cross-domain coordination, but the design is not unified.
The architecture is distributed. The manufacturing organization might run a workflow-native sketch. The customer-service organization might run a customer-surface sketch. The R&D organization might run a knowledge-centric sketch. The corporate functions might run a coordination-centric sketch. The variations are tolerated because forcing one architecture across all of them would produce worse outcomes than the variation does.
The ingredients this sketch emphasizes: the standards layer, especially the cross-domain standards that allow the federation to function. The data layer, where shared definitions become essential.
The ingredients this sketch treats as variable: nearly everything else is configured differently by domain.
The kind of company this fits: large diverse enterprises. Multi-business-line conglomerates. Companies whose units operate in significantly different industries or with significantly different customer bases. Companies where attempts at unified architecture have failed in the past.
The trade-offs: requires strong central capability to manage the standards across the federation. Risks fragmentation if the standards are too light. Can become expensive because the same capability is being built multiple times. The companies that do this well treat the federation as a deliberate choice rather than as a failure to unify.
The sketches are starting points. The leadership team doing AI-Native design work studies them, identifies what fits and what does not, and produces a design that is their own.
A few notes on how to use the sketches in actual design work.
First, the sketches can be combined. Most real designs will draw from more than one. A company might use the coordination-centric sketch for its corporate functions and the workflow-native sketch for its operations. Another company might run knowledge-centric at the top and customer-surface at the front. The combinations are constrained by coherence rather than by the sketches themselves. The standards layer is what makes the combinations hold together.
Second, the sketches change over time. A company that begins with one pattern may evolve toward another as the technology matures and the company learns what works. Treat a single architecture as final and you get rigidity. Establish regular review points, plus triggers for material changes in models, regulation, risk, or business strategy, and adaptation becomes part of the design.
Third, the technique of analogical sketching is useful in workshop conversations about which patterns might fit. Pick a company that has built a recognizable operating model and ask how that company would approach the same problem. What would Amazon do if it were designing this? What would Apple do? What would a hospital system design? What would a small consulting firm design? The point of the exercise is to free the leadership team from its existing assumptions long enough to see options it would not otherwise see.
Fourth, the sketches need to be tested before anyone commits to them. The Alignment Sprint in Section 9.2 gives the team a setting for comparing candidate designs against the company's actual conditions. The comparison may produce a choice or identify the evidence needed before choosing. The design that emerges from the test is almost always different from the design that entered it.
The point of the sketches is to show that designing the AI-Native operating model is design work. There are choices to be made. The choices have consequences. Done deliberately, with the ingredients understood and several sketches considered, the design work produces an operating model that fits the company. Skipped, whether by copying a sketch wholesale or by letting the architecture emerge by accident, it produces one of the failure cases Section 8.2 will catalog.
No leadership team knows the right answer in advance. The work is to design with the ingredients you have, test the design against the conditions you face, and revise as you learn.
The Leader's Five-Part Mandate
The design conversation just described requires a leadership team that owns the work. By default, few do. They delegate parts of it to the CTO, parts to the consultant, parts to whichever function happens to be loudest. Distribution is not the problem; fragmentation without integration is. When nobody owns the trade-offs across those parts, the transformation becomes incoherent.
I want to be specific about what the CEO and senior leadership team remain accountable for in an AI-Native transition. There are five mandates. The work within each can and should be distributed to qualified owners; accountability and integration cannot be outsourced. Neglect one, and the transition becomes vulnerable in a recognizable way.
First, set the operating-model direction. Name the archetype the company intends to become. Name the time horizon. Name the architectural commitments that follow. The leader owns the decision, but the vision should be informed by the people who understand the work, technology, customers, and consequences. When this mandate is missing, the company can produce a wall of separated pilots with no shared direction: the pilot graveyard from Section 1.2.
Second, make the build, buy, and partner calls. Decide which layers of the stack are proprietary, which are bought, which are partnered. This is the moat decision, the cost decision, and the speed decision rolled into one. When this mandate is missing, vendor accidents become the strategy.
Third, resource the architectural work. Fund the foundations the chosen use cases require (the knowledge architecture, collaboration surface, integrations, evaluations, security, and integrity mechanisms), even when there is no announceable win in the current quarter. When this mandate is missing, the company can default to chat-everywhere: useful for individuals, but rarely sufficient as an enterprise strategy.
Fourth, lead the human reckoning. Acknowledge what the transition is asking of the workforce. Construct the covenant. Honor the institutional knowledge. The leader has to be honest before the workforce can be. When this mandate is missing, institutional knowledge walks out the door (Section 8.2 names this case).
Fifth, sustain the practices. Develop your own AI practice (Section 5.1 names this work). Protect time for the team's practices. Measure short-term outcomes and the capabilities that compound beyond a quarter. The workforce calibrates on what leaders do rather than what they say. When this mandate is missing, the transition can remain in slogans rather than operations.
The five mandates are standing categories of accountability for the CEO and senior leadership team throughout the transition. Holding all five does not guarantee success; neglecting one creates a predictable weak point. The purpose of the list is not to keep all work in the executive suite. It is to keep the parts connected under leadership that can resolve trade-offs across the company.
The next section, on the collaboration surface, returns to one specific architectural piece that nearly every design will need. The section after that addresses the disciplines that keep the design honest as the AI work scales. The architecture is the substance. The design conversation is the work.