A practical AI adoption guide, written by practical AI adopters. Learn how to adopt AI across your organization, with case studies, maturity levels, and lessons from the Protocol Institute and other organizations.
Version: v0.5 · May 2026 · Generated: 2026-05-25
Live interactive deck: https://ai.protocolized.dev/
Early adopters first bolt on the new technology onto the current production architecture. But meaningful gains only appear after a complete redesign of the production environment.
“Locational freedom was an unparalleled advantage of steam.”
“Whereas a steam-powered plant could be located almost anywhere, the water-powered factory was tied to a non-transportable power source.”
Steam diffusion “revolutionized production by freeing manufacturers from the locational and seasonal constraints imposed by water power.” By 1900, steam engines “outnumbered waterwheels and water turbines by four to one” in American factories.
See full case study →
Factories could minimize material handling instead of optimizing power distribution.
The first wave just swapped the core power source: “the usual juxtaposition of a new technology upon the framework of an old one.”
The transformation came with the “ideal workshop — a shop with a motor driving each tool or machine,” freeing the floor to follow the “natural sequence of manufacturing operations.” Output per man-hour then jumped from “1.3 percent before 1919 and 3.1 percent after.”
See full case study →
“The container made shipping cheap, and by doing so changed the shape of the world economy.”
“The container is at the core of a highly automated system for moving goods from anywhere, to anywhere, with a minimum of cost and complication on the way.”
The world’s geography was then redesigned around the box: “Sprawling industrial complexes… gave way to smaller, more specialized plants that shipped components and half-finished goods to one another in ever lengthening supply chains.”
See full case study →
Everywhere you look, AI is already there
Agents, AI-enabled workflows, and tools are seemingly everywhere. It can be surprising, and a little strange, when they sometimes collapse production cycles from months to days or even hours.
Alongside AI, a new wave of top performers are appearing. They discover (and enact!) operational improvements faster than average organizations can integrate them at scale. Employers and managers alike report feelings of overload, disorientation, mania, and fear of being left behind. Whether by choice or by necessity, your organization is adopting AI. The question now is: can your organization describe what good adoption looks like, including the opportunities to prioritize and blunders to avoid?
AI has evolved rapidly, from a chat window to autonomous software factories. And yet, most of us are unsure – are we getting better at adoption? Or are we just getting busier?
A key driver of this confusion is that AI is being treated as a bundle of software products. It is better understood as a technology paradigm like the steam engine, car, or personal computer.
Paradigms are like waves – powerful, dangerous, and hard to surf. They reshape individuals and identities, not just technical systems.
AI is a new type of software with unique properties (probabilistic outputs, generative capacity, indeterminate failure distributions) that an organization integrates into its operating model. While deployment is the action of standing up a particular tool, policy, or workflow, adoption names the long arc of an organization's integration with the paradigm itself.
Treating AI like a bundle of products has a second consequence. AI is unlike enterprise tooling. There, a deployment plan can run on a planned sequence of procurement, policy, and rollout.
To catch the wave early, AI adopters must run a parallel track: bottom-up exploration, individual play, and vernacular practice. Both planned deployment and organic discovery are required. It isn't hyperbolic to say that AI is creating new types of people, just as cars and modern medicine have created new types of people, who would have a difficult time communicating with someone from the past.
Realizing this, the Protocols for Business Special Interest Group of the Protocol Institute collects insights on AI technology adoption. Every few months, we create a new version of this orientation framework. It includes new concepts, case studies, an organizational self-assessment, as well as common success and failure modes. Let's dive into our latest findings.
Each milestone needed both an individual practice and an organizational response. The cultivated track is what people invent; the governed track is what organizations approve.
Milestone 01: Chat (2022–23)
Milestone 02: Tools (2023–24)
Milestone 03: Agents (2024–26)
Milestone 04: Factories (2026–28) 01 · Cultivated
Everyday use of ChatGPT
Personal-account exploration
Prompt experimentation
01 · Governed
02 · Cultivated
02 · Governed
03 · Cultivated
03 · Governed
04 · Cultivated
04 · Governed
A short introduction to the AI Adoption Guide
This guide is about AI adoption: the long arc through which an organization integrates with AI. Adoption runs along two tracks. One is governed, made up of the formal apparatus the organization approves in advance: policy, procurement, rollout. The other is cultivated, made up of the practice its people invent on their own as they use AI: bottom-up exploration, individual play, and vernacular practice. Durable adoption requires both.
Most organizations approach AI the way they approach software, by defining what their people may and may not do with it. They publish acceptable-use policies, approve a list of tools, and set data boundaries. This approach works when failure modes – like memory limits or data format consistency – are known in advance and can be examined forensically, as with deterministic software. This approach fails with AI, because outputs are probabilistic and whose failure distribution shifts with every model update. Tightly-defined safety and security measures cannot keep up. Good workers will route around those measures, and many of the failures that the policies were meant to prevent will happen anyway.
You should not shift to less governance but to a different kind of governance. Instead of governing what people may or may not do with AI, govern what AI outputs must do at the points where they become consequential: how each output gets verified, how it gets escalated, how it becomes someone's accountability when it crosses from machine to human or from one team to another. These output-based rules guide coordination at handoff points rather than restrict activity at access points. A traffic light is a protocol; a blockade is not. Both are rules, but only one keeps the goods moving through the system.
Durable AI
How the chapters develop the model, from the framing argument through the maturity ladder, the pilot work, the cases, and the patterns.
Most organizations default to the governed mode of adoption they know from other technologies. This falls short because AI also demands individual-level change, something governed frameworks alone cannot produce. Durable adoption also requires cultivation.
L·01 · Governed: Shadow — AI in use through personal accounts; no monitoring, no governing policy.
L·01 · Cultivated: Play — Curiosity-driven exploration; AI encountered as a medium for deep play and discovery.
L·02 · Governed: Sanctioned — Access policy in place; tools approved, use tracked, risk contained within boundaries.
L·02 · Cultivated: Kit — Users encoding personal workflows into reusable, shareable protocols of their own design.
L·03 · Governed: Engine — Workflows built around AI with named owners and quality metrics; output is optimized.
L·03 · Cultivated: Practice — New forms of work emerge that were not possible before AI; roles and practices are redefined.
L·04 · Governed: Infrastructure — AI is a sector baseline; coordination challenge crosses organizational boundaries.
L·04 · Cultivated: Vernacular — AI practices absorbed into culture; tacit knowledge spreads without mandates or policies.
L·05 · Governed: Planetary — Civilization-scale AI; coordination and legibility are the governance challenge.
L·05 · Cultivated: Fluency — AI fully absorbed into how people think and work; second nature, no longer named.
The levels are informed by recent and historical case studies. Durable adopters use tactics and strategies from both paths.
The levels are informed by recent and historical case studies. Durable adopters use tactics and strategies from both paths.
Before identifying a use case, run a quick readiness check with your organization's AI adoption leaders. Ask the questions then assess if the answer met the criteria provided. This readiness check is not about which use case is right; it is about whether the organization can support a real pilot at all.
Before you can plan AI adoption well, you need to let play happen first. These three moves create the conditions for cultivated practice to surface.
Step 01 — Create a venue for play
Give people a permissive, low-stakes space to explore AI without agenda. No required tools, no prescribed use cases, no metrics on output. The goal is for people to discover, on their own terms, what working with AI actually makes possible – but make sure outputs are shared in some way. Deep play comes before useful practice.
Step 02 — Bespokify, not scale
Resist the pull toward uniform adoption. Experiment with tools that solve problems at the individual or two-pizza team level first. The workflows worth formalizing are the ones practitioners have already proved through daily use, not the ones a vendor case study or competitor announcement suggested.
Step 03 — Build soundbite strategies
What are your organization's agreed-upon design principles for working with AI? What should and should not be done? These need to be short enough to remember and specific enough to apply. Stable knowledge compounds; undocumented practice does not.
Play surfaces the workflows worth planning around. The governed track inherits and scales what the cultivated track discovers.
“Toy” workflows earn their way into the governed track by passing through four stages. Each gate is a question. If the answer is no, the workflow stays in the sandbox.
AI makes everyone a factory of one. Teams and individuals begin to produce and consume structured outputs.
Once an AI workflow is encoded as a protocol with defined inputs, observable outputs, and a shareable kit, the way work moves through an organization starts to change. Coordination shifts from informal channels to the protocols themselves.
An analyst who encoded their research workflow into a kit is now a factory of one. Anyone who needs that analysis consumes the output through the kit's interface, not through a Slack thread. The meeting that used to align two people's tacit processes becomes a protocol handoff with a versioned input, an observable output, and a named owner.
Governance moves up a layer. Its job stops being the management of individual workflows and becomes the maintenance of the platform: keep the interfaces clean, encourage teams to expose what they have built, and make sure the protocols compose. The organization becomes a network of factories. Each is autonomous. Each is interoperable. Each is consumable by the rest of the network through its interface.
In 2002, Jeff Bezos issued an internal edict to Amazon's engineering organization. Every team had to expose its data and functionality through service interfaces. No direct database links, no internal shortcuts. Everything went through APIs, and the APIs had to be designed as if they would eventually be exposed to the outside world.
The point was not speed or efficiency. It was architecture. By forcing every team to treat its own work as a product with a defined interface, Amazon built a platform almost by accident. Steve Yegge's 2011 memo, which contrasted Amazon's discipline with Google's lack of it, remains the clearest account of what the practice produces and what its absence costs.
"Bezos's Big Mandate transformed Amazon. Every team in the company, from the smallest engineering skunkworks to the most mission-critical platform team, needs to interact with all other teams exclusively through these service interfaces." Steve Yegge · Google Platforms Rant · 2011
Discovery is cultivated. Scale is governed. The organization's job is to invest in both and make the handoff between them deliberate.
▦→▣ Kit harvesting over central design (success)Wait for variation before standardizing.
The protocols worth formalizing are the ones domain experts have already proved through daily use. The organization's job is to identify, capture, and systematize the kits champions have already built — and to wait for variation to express itself before standardizing.
Holds: Local Velocity without sacrificing downstream Assurance or Legibility
▶↻ Plan after play (success)Plan from what play surfaces.
AI invites experimentation at a tempo upfront planning cannot keep up with. Let play run at its native speed first — Shadow-level exploration, function-level kit-building — then plan continuously from what surfaced. Quarterly plans become rolling syntheses; biweekly reorientation rituals reconcile commitments against reality.
Holds: Velocity in play without losing Legibility or Assurance in the plan
◐◑ Differential gear trains (success)Buffer the mismatch instead of throttling.
Engineers know this from car differentials — a mechanical assembly that transmits power between components rotating at different rates. The deployment-lead version is buffers, queues, async handoffs, and tempo-aware routing. Uber's Code Inbox is the canonical case.
Holds: Upstream Velocity without breaking downstream Assurance or Legibility
</> Constitutional software (success)Compile constraints into the runtime.
Encode constraints in code itself: sandboxed environments the agent cannot escape, separate dev/prod boundaries, planning-only modes, and revocation paths that compile authority into technical interlocks rather than relying on human reaction time.
Holds: Agent Velocity without weakening runtime Assurance or Legibility
⊘ Premature optimization (failure)Standardize before practice earns it.
Centrally designing the official AI workflow before users have iterated through enough kit forms; the published standard is rejected, users keep their kits in the shadows. Variants: premature consolidation (collapsing kits into a single platform) and premature procurement (vendor stack before need is known).
Collapses: Paper Assurance at the cost of Velocity and Legibility Mitigated via: Kit harvesting over central design
?↺ Disorientation (failure)Production outpaces understanding.
The organization's commitments accumulate faster than its ability to update shared understanding. The gap is structural: imbalance between commitment speed and reorientation speed. HBR (May 2026) documents the worker-level signal as psychological debt.
Collapses: Velocity outruns Legibility; Assurance erodes Mitigated via: Plan after play
≠ Tempo misalignment (failure)Output stacks at the slowest neighbor.
AI accelerates different pieces of a workflow at different paces. Output stacks up at the slowest process or partner. Uber's response: with 65–72% of code AI-generated and 11% of PRs opened by agents, the bottleneck shifted from coding to review — Code Inbox and U Review absorbed the new tempo.
Collapses: Upstream Velocity breaks downstream Assurance and Legibility Mitigated via: Differential gear trains
◉○○ Extended blast radius (failure)Permissions and interventions lag production.
Replit's July 2025 incident: during a code freeze, the agent ignored explicit instructions, deleted a production database with records of 1,206 executives and 1,196 companies, then misled the user about recoverability. External version: Air Canada (BC Civil Resolution Tribunal, 2024).
Collapses: Velocity outruns Assurance; Legibility arrives too late Mitigated via: Constitutional software
Kit Harvesting — Find the AI workflows people are already running on their own — in personal repos, vaults, scripts, and custom GPTs. Promote the best ones into shared infrastructure with named owners so others can reuse them. The work includes a per-function audit, a promotion review, and the engineering to make a kit operable by a second person.
Evals — Define what "good" means for each AI workflow and build the test harness that measures it. The harness usually includes golden datasets, rubrics co-authored with domain experts, and a scoring runner that fires on every prompt or model change. Maintenance grows over time as new failure modes surface and feed back into the suite.
Forward Deployment — Engineers are embedded inside functions — alongside lawyers, sales reps, and analysts — to build the AI workflows each function depends on. The engineer pairs with domain experts, reads their existing work product, and ships the production integration. Each engagement is project-shaped and closes when the workflow runs end-to-end.
Platform Operations — Run the shared AI infrastructure that domain teams build on. The platform usually includes a model gateway, versioned prompt and skill registries, eval pipelines in CI, observability (latency, cost, quality, drift), and cost controls. It runs continuously; major upgrades land on a quarterly cadence.
Risk Stewardship — Maintain the AI risk register and the technical interlocks that bound what AI is allowed to do. The register tracks models, data, and blast radius. The interlocks include permission boundaries, sandboxes, planning-only modes, write-locks, rollback paths, and the audit trail.
Context Stabilization — Curate the context AI systems depend on and keep it stable across models, tools, and agents. The work involves context gathering, curation of authoritative sources and current versions, and ontology work — entity definitions and category boundaries. The goal is to keep the legal team's "contract" and the agent's "contract" from silently diverging.
Intake · Forward Deployment — Engineers embedded inside functions to build the AI workflows each function depends on.
Loop · Context Stabilization — Curate the context AI systems depend on and keep it stable across models, tools, and agents.
Loop · Risk Stewardship — Maintain the AI risk register and the technical interlocks that bound what AI is allowed to do.
Loop · Evals — Define what "good" means for each AI workflow and build the test harness that measures it.
Loop · Platform Operations — Run the shared AI infrastructure that domain teams build on.
Level 1 → Level 2 (Kit) transition inside a Special Interest Group.
Case study 01: SIGBIZ AI Discovery Acceleration Level 1 → Level 2 (Kit) transition inside a Special Interest Group.
The problem
Throughout 2025, most members of the Protocols for Business Special Interest Group were using AI tools for their own work, and almost none of that work was visible to anyone else in the SIG. Members were collecting their own prompts, scripting small workflows in personal repos, learning the same early lessons in parallel. The cost was learning loss. The community of practice was running in private.The challenge was the standard L1 → L2 transition: make shadow use visible, encourage further adoption without prescribing tools, and harvest what members had discovered before it was forgotten.
The approach
The SIG settled on three lightweight moves rather than a formal program.
The impact
Three things have shifted. First, AI adoption inside the SIG is now visible. Second, mutual discussion improved: members are collaborating on kits. Lastly, ambitions have expanded. The SIG expects new norms to continue emerging, some of which may become standards or protocols.The case study illustrates the cheapest viable Level 1 → Level 2 transition: a recurring meeting, a no-judgment posture, and a willingness to wait for the patterns to emerge from practice rather than to legislate them in advance.
Level 3 (Engine) in the magazine's visual production pipeline.
Case study 02: Protocolized visual identity Level 3 (Engine) in the magazine's visual production pipeline.
The problem
Protocolized needed a visual language for a magazine whose editorial method openly integrates LLM-assisted writing. Off-the-shelf image generators produce a generic AI aesthetic that locates the magazine in the same trough every other AI-assisted publication occupies. Commissioned human illustration would not scale to a weekly cadence. Aesthetic nostalgia (mid-century pulp, Astounding-era revival) was the wrong move on principle: Astounding's original power came from embracing the contemporary art of its time.
The approach
The magazine commissioned two narrowly-defined image generation models, each developed in collaboration with a named artist and hosted on the TITLES platform.Both deliberately narrow: "not primed by their training art to resolve figurative prompts." TITLES handles attribution and royalties as protocol; image metadata stored onchain.
The impact
The visual production pipeline meets the Level 3 criteria. Named owners (Langdon as editor, Ou and Langdon as model artists), a verification checkpoint built into the model itself (the abstraction constraint that fails figurative prompts), and a designed coordination layer between participating roles. The output is a coherent visual identity that holds across issues without each cover requiring an art-direction debate. Choosing to train narrow models on commissioned training art rather than to use stock generators is the same kind of move SIGBIZ made when it harvested its own kits — designing the kit rather than inheriting one designed by a vendor whose interests are not the publication's.
For most of the twentieth century, the unit of management has been the worker's second. A new unit is emerging: the production token.
Organizations are beginning to measure and meter knowledge production work, which previously sat inside salaries, contractor invoices, and project budgets as an unaccounted ingredient. Per-token LLM billing is already an industry standard for those that have integrated AI tooling. Per-team and per-agent token budgets are emerging as spend lines.
That being said, tokens are not kWh. They behave more like grades of refined petroleum: each model's token does different work; a cached input token is roughly 90% cheaper than a fresh one. The unit remains the token, while the market supply remains differentiated.
The firm that runs on tokens becomes addressable through language, and in some real sense, programmable. The management question changes accordingly, mirroring computational resource allocation. While Taylor asked how to discipline bodies into efficient movement, the tokenized firm asks which problems deserve more tokens, and how to structure symbolic flows so the firm remains computationally tractable. Token allocation is resource allocation at the level of organizational attention.
Frederick Winslow Taylor spent the 1880s and 1890s on factory floors with a stopwatch. His Principles of Scientific Management (1911) decomposed labor into discrete measurable tasks and separated planning from execution. The manager's job was to study, standardize, and allocate. The central resource was time, and the unit of measure was the worker's second.
Taylorism had low expressive bandwidth. It could encode a finite, brittle set of workflows. Whenever reality exceeded the schema (a novel situation, an edge case, a judgment call), managerial sovereignty returned. The foreman still had to intervene because the system itself was not sufficiently programmable.
For a century, management science remained Taylorist at its core. Headcount, utilization, throughput per person-hour: all descendants of the stopwatch.
AI-mediated operations aren't the backbone of today's enterprises, but they are changing the shape of organizations everywhere.
AI-mediated tools and workflows are no longer features of the workplace; they are part of the workplace itself, closer to weather or terrain than to thermostats.
This is the new nature of work. It is also the reason a single, planned rollout is certainly not enough. If the terrain were stable, top-down deployment could finish the job; because it is not, the cultivated track has to remain productive alongside the governed one. Durable adoption depends on governance enabling cultivation rather than displacing it: the terrain keeps moving, and it will remain moving for years, and only the cultivated track can keep finding what works in it.
Inside the new work environment, the deployment lead's job becomes keeping the handoff between the two tracks alive. The volume of AI-assisted output is too high to inspect case by case; new kits surface from the floor faster than any central process can catalogue them; the tools themselves shift behavior on every model update.
The work is maintaining a productive cultivated track and a legible governed one: providing maps through what people are discovering, keeping the gates honest about which kits earned their way across, re-orienting when a team starts moving toward a pattern that compounds risk.
The scarce skill is applied curiosity. The candidate who finds their way through unfamiliar terrain is the person to hire, because that is who keeps the cultivated side feeding the governed one.
The work, then, is not to finish a platform deployment. It is to make deployment a core capability, as the landscape shifts, again and again. The outcome of a successful adoption program is not the kits, the workflows, or the published policies; it is people. People who know how to work in this new nature, and managers who know how to keep the handoff between cultivation and governance working as the terrain keeps changing.
Fourteen cases across five maturity levels. Five contemporary AI adoptions, five historical operational analogues, and four foundational research papers, all showing the same patterns at earlier paradigm shifts.
Level 1 (Shadow) exit pathway: containment and re-admission over two years.
Case study 01 of 14: Samsung Electronics Level 1 (Shadow) exit pathway: containment and re-admission over two years.
The problem
In April 2023, three Samsung engineers submitted proprietary source code to ChatGPT through personal accounts within a single month — to debug, optimize, and summarize. No policy existed, no monitoring was in place, and no record of which AI tools employees were using on what data. By the time exposure surfaced, the code had left the organization. The exposure pattern was structural, not malicious.
The approach
Samsung responded in two phases. First, containment: a ban on all generative AI on company devices, paired with an accelerated internal LLM (Samsung Gauss). Second, deliberate re-admission over eighteen months — approved tool list, data-classification policy, prompt-filtering middleware, audit pipeline. By late 2025 employees could again use external AI, but only inside the gates Samsung had not built the first time.
The impact
Samsung's exit from Shadow is the most documented in the public record. The L1 → L2 transition is rarely one policy action; it is a containment phase followed by a re-admission phase, with the latter taking longer than the former. Organizations that skip containment risk repeating the leak. Organizations that skip re-admission find their workforce running shadow workflows again through different channels.
Level 2 (Sanctioned) failure mode: access governance without output governance.
Case study 02 of 14: Klarna Level 2 (Sanctioned) failure mode: access governance without output governance.
The problem
In early 2024 Klarna announced its AI customer-service assistant was doing the work of 700 full-time agents, with 90% daily AI adoption and two-thirds of customer-service chats automated. The narrative was category-defining productivity, backed by leading indicators: tool adoption, automation share, cost-per-resolution. Trailing indicators — satisfaction, repeat contacts, resolution durability — were not yet visible in the same dashboards.
The approach
Klarna's governance focused on access. Tools were sanctioned, employees encouraged, adoption tracked. The company did not build comparable governance for the quality of AI output reaching customers. When trailing indicators began surfacing through escalations and external reporting, the failure mode was the one access-governance is structurally unable to catch: the outputs were technically allowed, but they were not good.
The impact
In May 2025 CEO Sebastian Siemiatkowski reversed course publicly, describing AI customer interactions as "generic, repetitive, and insufficiently nuanced," and announced Klarna would rehire human agents. The reversal is the cleanest documented example of L2 access governance running into its ceiling: governing which tools are used cannot, by itself, govern whether the output is good enough. The transition to L3 Engine requires named output owners and verifiable quality gates, not dashboards of utilization.
Level 2 (Sanctioned) measurement failure: tracking adoption without governing outcomes.
Case study 03 of 14: Amazon & MeshClaw Level 2 (Sanctioned) measurement failure: tracking adoption without governing outcomes.
The problem
In 2026, against a backdrop of $200B in AI-related capital expenditure, Amazon introduced internal targets requiring more than 80% of developers to use AI each week. It began tracking AI token consumption — units of data processed by models — on internal leaderboards. The mandate was clear: prove the AI investment is being absorbed by the workforce and embed the technology into day-to-day work. Adoption was sanctioned, mandated, and measured.
The approach
Token consumption became the proxy metric for adoption. Official communications stated the stats would not factor into performance evaluations — but managers retained visibility, and employees believed they were being watched. The in-house MeshClaw tool, which lets users create AI agents that automate workplace tasks, was deployed widely. Staff began using MeshClaw to automate non-essential work specifically to inflate their token counts — a practice nicknamed "tokenmaxxing" (also documented at Meta).
The impact
Adoption rates can be mandated and tokens can be counted; neither is the same as governing whether AI is producing good work. The Amazon case is a textbook L2 measurement failure: when the visible metric is occupancy, employees optimize for occupancy. Tokens consumed become a Goodhart's Law artifact, and the agentic security risk grows alongside the inflated numbers ("the default security posture terrifies me," one employee told the FT). Transitioning to L3 Engine requires named output owners and verifiable quality gates — what the work produced, not how much of it ran.
Level 2 (Sanctioned) accountability test: chatbots as legal subjects.
Case study 04 of 14: Air Canada chatbot Level 2 (Sanctioned) accountability test: chatbots as legal subjects.
The problem
In November 2023, Jake Moffatt asked Air Canada's customer-service chatbot whether bereavement-fare discounts could be claimed retroactively. The chatbot told him yes, citing a policy that did not exist. Moffatt booked a full-price flight to attend his grandmother's funeral. When he submitted the retroactive claim, Air Canada refused. The dispute reached the British Columbia Civil Resolution Tribunal in February 2024.
The approach
Air Canada's defense argued the chatbot was a "separate legal entity" responsible for its own statements, and that Moffatt should have verified the answer against the policy page hosted elsewhere on the airline's website. The argument was novel and it failed. The Tribunal held that Air Canada was responsible for all information on its website, including chatbot-generated information, and ordered the airline to pay the difference plus tribunal fees.
The impact
The ruling established the first widely-cited precedent that organizations cannot offload accountability for AI output to the tool itself. For organizations operating at Level 2 — sanctioned tools, no output governance — this is the structural exposure: every AI-generated statement to a customer is an unchecked commitment of the firm. Output governance — verification checkpoints, escalation paths, named owners for AI-customer interfaces — is not optional once a chatbot is producing legally consequential statements.
Level 3 (Engine) success pattern: protocols designed alongside capabilities.
Case study 05 of 14: Boom Supersonic Level 3 (Engine) success pattern: protocols designed alongside capabilities.
The problem
Boom was developing the XB-1 demonstrator under aviation-safety expectations that allow zero tolerance for unexamined design changes. Each iteration on the structural model required stress, fatigue, aerodynamic, and material-tolerance validation before fabrication clearance. Boom needed to accelerate the loop without weakening the verification stack — and to explore hundreds of structural variants in the time conventional methods explore tens.
The approach
Boom built mkBoom, an internal tool that wrapped AI-assisted structural analysis around the existing verification stack. The AI did not replace any verification step; it accelerated the iteration loop feeding into it. The governance protocols — who owns which analysis, which checks must pass before fabrication, what evidence is preserved for certification — were designed alongside the capability, not added after a near-miss.
The impact
Boom's XB-1 reached supersonic flight in January 2025 with zero safety incidents across the program. The mkBoom workflow also surfaced Boomless Cruise — a flight regime in which the supersonic boom does not reach the ground under specific atmospheric conditions, recovered through AI-accelerated exploration of the structural envelope. When the blast radius is real hardware, protocols-with-capability is the only viable order: designing them after a failure costs more than the failure itself.
Level 1 (Shadow) substrate: a vernacular that emerged through pedagogy, not mandate.
Case study 06 of 14: Visicalc & Excel Level 1 (Shadow) substrate: a vernacular that emerged through pedagogy, not mandate.
The problem
By the late 1970s, business analysts performed structured calculations on paper, on calculators, or on bespoke mainframe programs maintained by IT departments with weeks-long lead times. The analyst who could think the model was rarely the one able to build it. Visicalc launched in 1979 as the first recalculating spreadsheet — written by Dan Bricklin and Bob Frankston for the Apple II — introducing a grid of cells with formulas referring to other cells.
The approach
Through three commercial transitions — Visicalc, Lotus 1-2-3, Excel — the file format evolved but the conceptual model did not. Rows, columns, cells, formulas, references: the vocabulary held. No central authority defined or governed it. Practitioners taught each other peer-to-peer; business schools wrote textbooks; managers hired analysts who knew the vernacular without specifying which product. The tool taught the method, and the method outlived three products.
The impact
By 2026 over a billion people operate through spreadsheet logic that nobody designed and no central authority approved. The L1 Shadow analogue is exact: an immensely productive substrate built by users for users, never sanctioned, never standardized at the top, but absorbed so completely into how work is done that it became invisible. The lesson for AI: substrates of this kind emerge through artifacts that teach the method, not through mandates that prescribe it.
Level 2 (Sanctioned) sanction: ratifying cultivated practice already underway.
Case study 07 of 14: Gates's Internet Tidal Wave memo Level 2 (Sanctioned) sanction: ratifying cultivated practice already underway.
The problem
By early 1995, Microsoft was the dominant force in personal computing, organized around Windows, Office, and a vertically integrated server stack. The Internet — open protocols, browsers, hypertext — was not part of its product roadmap. Inside Microsoft, however, developer interest had been building for over a year: small teams were experimenting with web servers, browser prototypes, and TCP/IP-native tools, mostly outside official product lines. Without executive sanction, the projects could not draw the resources to ship.
The approach
On May 26, 1995, Bill Gates issued an internal memo titled "The Internet Tidal Wave" to senior staff, declaring "I assign the Internet the highest level of importance." The memo did not invent Microsoft's Internet capability — it ratified work that had been happening unofficially for fifteen months. Attached were specific product directives: a browser shipped with Windows, mail integrated with TCP/IP, a re-architected server stack. The force came from naming what was already happening.
The impact
Within two years Internet Explorer 1.0 shipped with Windows 95, Outlook and Exchange were repositioned around Internet protocols, and Microsoft was a credible Internet platform company. The case shows what effective Level 2 Sanctioned action looks like: it codifies what cultivation has already proved, channeling existing energy into formal direction. Sanction works when it ratifies; it fails when it mandates without underlying practice.
Level 3 (Engine) protocol: a designed workflow that outgrew its host.
Case study 08 of 14: Git & GitHub pull requests Level 3 (Engine) protocol: a designed workflow that outgrew its host.
The problem
In April 2005, BitKeeper — the proprietary version-control system the Linux kernel team had been using under a free-of-charge license — revoked the license after a reverse-engineering dispute. The kernel team needed a replacement that matched BitKeeper's distributed-workflow properties; nothing on the market did. Beyond Linux, the software industry ran on a patchwork of centralized version-control systems whose mental models did not match how distributed teams actually worked.
The approach
Linus Torvalds wrote Git in two weeks, optimizing for performance, distributed branching, and verifiable history. Git itself was a powerful but austere substrate — capable of any workflow but prescribing none. Three years later, GitHub introduced the pull request: a branch wrapped in a discussion thread with inline code review, status checks, and eventually CI/CD integration. The PR was not part of Git's specification; it was a designed protocol layered on top — a workflow people could see, comment on, approve, and audit.
The impact
By 2026 the PR workflow is the assumed professional standard for roughly 100 million developers across essentially every development environment, including ones that do not run on GitHub. The case shows the L3 Engine pattern at scale: a designed coordination protocol on top of a generic substrate, optimized to the point of becoming invisible. It also shows the cultivated-governed handoff working as intended — Git the open substrate, PRs the designed protocol; both necessary, neither sufficient.
Level 4 (Infrastructure) cascade: one big buyer's mandate becoming an industry baseline.
Case study 09 of 14: Walmart's EDI mandate Level 4 (Infrastructure) cascade: one big buyer's mandate becoming an industry baseline.
The problem
By the mid-1980s, retailers managed thousands of supplier relationships through paper purchase orders, faxed invoices, and phone-confirmed shipment notifications. Error rates at the supplier-retailer interface — wrong quantities, late shipments, duplicate invoices — were a significant fraction of margin. Each retailer had its own document formats; each supplier maintained custom paperwork per customer. Walmart, growing rapidly, found that coordination overhead capped its expansion rate.
The approach
In 1988, Walmart mandated EDI compliance using the X12 transaction set: adopt it, or lose Walmart's business. The mandate was paired with Walmart's own Bentonville distribution infrastructure, redesigned around the Advance Shipment Notification — a specific X12 message type that allowed receiving docks to plan for incoming shipments before they arrived. Walmart did not invent EDI; it required it, and made compliance valuable to suppliers (faster receiving, fewer disputes) rather than merely costly to refuse.
The impact
The protocol cascaded across retail within a decade. Suppliers required to use EDI for Walmart began using it elsewhere; competitor retailers added EDI requirements; ERP vendors built EDI tooling into their software. By 2026, roughly 95% of US B2B supply-chain document exchange runs on EDI variants. The case shows the L4 Infrastructure pattern: protocols at this level spread when one dominant actor enforces them against its trading partners, and the rest of the ecosystem follows because the cost of two standards is higher than the cost of one.
Level 5 (Planetary) coordination: an artifact-defined protocol no one owns.
Case study 10 of 14: McLean's container protocol Level 5 (Planetary) coordination: an artifact-defined protocol no one owns.
The problem
Through the 1950s, freight moved between ship, rail, and truck through "break-bulk" handling — workers physically transferring barrels, crates, bales, and boxes at every transition point. Loading a ship took days; unloading at the destination port took days more. Theft was endemic, damage frequent, and the dwell time of a single shipment measured in weeks. The bottleneck was not transportation but the handoff between modes.
The approach
On April 26, 1956, trucker Malcolm McLean sailed the SS Ideal X from Newark to Houston with 33 standardized metal boxes — containers — lifted directly from trucks onto the ship and back. The container itself was the protocol: fixed-dimension, lockable, stackable, reusable, designed so cargo never had to be touched between origin and destination. The standard hardened in stages: McLean's company published dimensions; competitors adopted them; ISO 668 codified 20- and 40-foot TEU dimensions in 1968.
The impact
By 2026 approximately 90% of non-bulk world trade moves via containers. The protocol made coordination cheap and uniform across every jurisdiction and mode. It also concentrated the failures: the system depends on five geographic chokepoints — Suez, Panama, Malacca, Hormuz, Bab el-Mandeb — whose vulnerability was made visible by events like the 2021 Suez Canal blockade. The L5 Planetary lesson: when a protocol becomes infrastructure for the world, coordination is cheap and legibility becomes the new governance challenge.
Level 1 (Shadow): when users invent uses the manufacturer never imagined.
Case study 11 of 14: Rural users and the Model T Level 1 (Shadow): when users invent uses the manufacturer never imagined.
The problem
When Ford launched the Model T in 1908, it was designed as urban transportation. Rural America had a different problem: small farms needed power for threshing, sawing, water-pumping, washing, and churning. Buying a dedicated stationary engine for each task was prohibitively expensive. The technology was widely available; the use case that mattered to half of Ford's customers wasn't visible to the manufacturer.
The approach
Rural users improvised. Owners jacked Model Ts onto blocks and ran belts off the rear wheels to drive threshing machines, washing machines, water pumps, fodder cutters, and circular saws. Third-party accessory makers shipped kits (the "Stationary Hoister"); farm magazines documented dozens of unauthorized uses by the 1920s. Ford initially resisted, then gradually acknowledged the use cases in marketing materials and parts catalogs, redesigning later models to support them.
The impact
The kit-phase pattern Kline & Pinch document is structural: user adaptation precedes manufacturer recognition by years. Value is generated by users in ways the supplier doesn't anticipate; the supplier's eventual job is to harvest and standardize what users invented. The same pattern is operating today around AI — practitioners are using AI for purposes their employers haven't sanctioned. The organizational job is to surface those uses (Kit Harvesting), not suppress them.
Level 2 → Level 3: firms make the architectural commitment to a new paradigm for what it enables, not for what it makes cheaper.
Case study 12 of 14: American steam adoption, 1820–1900 Level 2 → Level 3: firms make the architectural commitment to a new paradigm for what it enables, not for what it makes cheaper.
The problem
American factories in the 19th century had a recurring choice between two prime movers. Water power had been the standard since the early industrial period — abundant, well understood, and, in most parts of the country, measurably cheaper per horsepower than steam. Cost simulations by Atack, Bateman, and Weiss show that water was the lower-cost option in New England, the Middle Atlantic, and the South for most of the century. Yet steam adoption climbed steadily anyway. By 1900, steam engines outnumbered water sources four to one. The cost ledger and the adoption pattern were pointing in opposite directions, and the gap held for decades.
The approach
Atack and his coauthors traced what firms actually chose, region by region, between the 1820s and the 1890s. The pull toward steam wasn't operating cost — it was locational freedom. A water-powered factory had to sit by the water; a steam-powered one could sit anywhere, including next to railroads and urban labor pools. Pittsburgh and Cincinnati adopted steam earlier than Boston because the eastern rivers were already worked. Augusta, Georgia, had ample water power but was over 100 rail miles from major urban markets, and never became a manufacturing center. Having the input wasn't enough.
The impact
American manufacturers paid a premium for steam for most of a century. They were paying for capabilities the cost-per-horsepower table didn't capture: where a factory could sit, how large it could grow, who it could hire, how it could ship. There's a recognizable echo here for organizations evaluating AI adoption now. When teams compare AI's cost to the cost of the work it might replace, the math often looks marginal or worse, and the natural conclusion is to wait. The historical pattern suggests a complementary question worth asking alongside the cost one: what becomes newly possible? Work that was previously out of economic reach, problems that couldn't be attempted at all, customers or markets that weren't addressable at the firm's prior scale. Adoption often makes sense when the answer to that question is concrete, even in cases where the cost comparison on its own doesn't make the case.
Level 2 → Level 3: the 30-year lag between substitution and architectural redesign.
Case study 13 of 14: Factory electrification, 1880–1930 Level 2 → Level 3: the 30-year lag between substitution and architectural redesign.
The problem
Through the 19th century, factories were powered by central steam engines driving overhead line shafts and belt drives to each machine. The architecture imposed constraints: machine placement followed shaft geometry, multi-story buildings minimized shaft runs, whole-plant on/off operation, 25–40% friction losses, blocked windows from overhead shafts. When electric motors became commercially available in the 1880s, the obvious move was to swap the prime mover.
The approach
Devine documents three phases. (1) Group drive (1890s–1910s): the steam engine was replaced with a large electric motor, but the line shaft, belts, and machine placement remained unchanged. By 1919, 53% of US installed manufacturing horsepower was electric. (2) Unit drive (1910s onward): a dedicated motor at each machine, sized to its load, with wiring replacing the iron shaft. Factory layout finally followed workflow, not shaft geometry. (3) Architectural redesign: single-story buildings (Ford's River Rouge, 1928), sawtooth roofs for daylight, integrated conveyors, 40–50% reductions in energy per unit output.
The impact
US manufacturing TFP grew under 1% per year through the group-drive era (1899–1919) and ~5% per year in the unit-drive era (1919–1929). The productivity boom of the 1920s was the payoff of architectural redesign, not of electrification per se. Substituting the power source without redesigning the layout captured almost none of the available gains. Most current AI deployments are at the equivalent of group drive — the technology is installed, the workflow is unchanged, and the productivity hasn't materialized. The L2 → L3 transition is what closes the gap.
Level 3 → Level 4: the institutional substrate behind "interchangeable parts."
Case study 14 of 14: Harpers Ferry and the American System Level 3 → Level 4: the institutional substrate behind "interchangeable parts."
The problem
Eli Whitney's 1798 federal contract for muskets promised interchangeable parts — pull any lock, any barrel, any stock from a pile and they fit. The marketing claim was repeated through the early 19th century. The actual practice was different: parts were fitted individually by skilled file-and-fitter armorers, and each musket was effectively bespoke. The technology label existed; the operating practice didn't.
The approach
Merritt Roe Smith's history of Harpers Ferry Armory (1798–1860s) documents a long institutional development. Federal armory contracts created a sustained customer that insisted on uniformity. Machine tools were developed in-house (milling machines, pattern lathes, gauges). Inspection protocols co-evolved with the machines. Workers were retrained — gauge-using inspectors replaced file-and-fitters. The social order of the armory changed alongside the technical order. By the 1850s, the American System of Manufactures could be demonstrated at the London Crystal Palace Exhibition, three decades after the rhetoric began.
The impact
Industry-scale uniformity required the full institutional substrate to mature, not just the technical capability. The same is operative for L4 Infrastructure today: stating a standard isn't the same as having the inspection regimes, training systems, and shared assumptions that make the standard actually hold. Organizations claiming AI standardization without that institutional substrate are repeating Whitney's marketing claim, not Harpers Ferry's actual practice.
The artifact that matches the framing. AI sits in the Paradigm × Planetary quadrant — the artifact that fits it is an Adoption Guide.
24-question diagnostic that places your organization on the maturity ladder and surfaces your dominant archetype.
A 24-question diagnostic. Each question is a binary choice between two statements — answer the one that better describes your organization. The combined pattern places you on the maturity ladder (L1–L5) and surfaces a dominant archetype.
Q1.
Q2.
Q3.
Q4.
Q5.
Q6.
Q7.
Q8.
Q9.
Q10.
Q11.
Q12.
Q13.
Q14.
Q15.
Q16.
Q17.
Q18.
Q19.
Q20.
Q21.
Q22.
Q23.
Q24.
AI is in use. The organization doesn't know how, by whom, or with what data.
Your organization is at the default starting position — not a failure, but a baseline every organization passes through. AI tools are in active use through employee initiative. No organizational decision has authorized them. Individual workers use personal accounts for work tasks. No policy governs this, no tooling controls it, and no one has a complete picture of what organizational data is being submitted to which systems. The absence of a governance protocol is itself invisible: organizations don't feel like they're at Level 1 because nothing has gone wrong yet. The typical organization is at Level 1 for 400+ days before a shadow AI incident surfaces. Shadow adoption is the observable signal that existing work protocols have been pushed beyond their design range. The protocol response (sanctioned access, data boundaries, reviewed terms) has not yet been adopted.
Failure modes:
Next actions:
The organization has granted AI access. It hasn't designed what to do with it.
Your organization has done the right thing: granted broad AI access and signaled strategic commitment. The failure mode at this level is executing the mandate without designing the governing protocol — which tasks, with what review process, what quality standard, what escalation path when AI fails. Two dynamics characterize Level 2. First, the Time to Mediocrity effect: AI produces functional output quickly in most domains, creating genuine early productivity gains while concealing the absence of expertise. Second, the financial indicator lag: strong financial metrics accumulate at the same time as governance failures, making the governance gap invisible until failures become external-facing. Level 2 organizations typically achieve high adoption rates and real early gains — then encounter a quality floor that the absent governance layer cannot address.
Failure modes:
Next actions:
AI workflows are designed, not improvised. The business model depends on them.
Your organization has crossed from AI adoption into AI dependency: your competitive position relies on designed AI workflows. AI governs core operations. Workflows are built around AI rather than retrofitted to include it. The governance question has shifted: you are designing protocols that handle failure, versioning, and external dependencies without losing the speed advantage AI provides. Domain expertise is the limiting constraint — the knowledge required to specify what good output looks like in your specific context. Two operators with domain knowledge can run sophisticated AI production pipelines if they can articulate the coordination protocol clearly.
Failure modes:
Next actions:
You have the foundations of Level 3. Consistency and measurement are missing.
Your organization is at the transition between Level 2 and Level 3. At least one workflow is designed — you have demonstrated that AI-native workflow design is possible in your context. What's missing is consistency across workflows and a quality measurement system that makes the governance protocol durable and repeatable across the organization. This is a common and productive stuck point. The risk is that the designed workflows become isolated examples while the rest of the organization continues operating at Level 2. The Level 2 failure modes — quality floor collapse, mandate without criteria — remain live risks in the undesigned workflows.
Failure modes:
Next actions:
Your organization is at the leading edge. The next challenge is sector-level, not organizational.
Your organization is at the boundary between Level 3 and Level 4. Multiple core AI workflows are designed, governed, and versioned. Your practices are mature enough that industry peers reference them as a benchmark. The organizational-level governance challenges are substantially addressed. Level 4 emerges when the aggregate of Level 3 organizations reaches density sufficient to recalibrate the sector's productivity baseline. No single organization drives this transition. The governance questions at Level 4 are market-structural: how does the industry coordinate AI use, handle shared risks, establish standards, and prevent concentration of AI capability in ways that produce anti-competitive outcomes. Individual organizational maturity is necessary but not sufficient at Level 4.
Failure modes:
Next actions:
"Someone has to go first. We'd rather learn hard than wait safe."
Core strategic bet: First-mover advantage compounds faster than reversal risk compounds loss.
Examples: Klarna (2024–25 AI-agent arc: mandated, reversed, rebuilt). Duolingo (AI-first content, user headwinds). Shopify (Lütke 'AI is non-optional' memo).
The Vanguard deploys AI aggressively in customer-facing and core operational work before governance is ready. They retrofit AI into an existing organization because they believe leadership conviction matters more than waiting for external validation. Public mandates; explicit policy shifts; visible executive commitment. The bet is asymmetric — some deployments will roll back publicly, but the ones that stick compound. They treat reputational exposure as the price of not being late, and they absorb the criticism of specialists whose judgment was bypassed in the pursuit of speed.
Strengths: Organizational alignment — leadership has taken a clear public position; Forced learning under real conditions (no hiding in pilot-land); Captures compounding advantages unavailable to orgs waiting for proof; Talent magnet for ambitious practitioners who want the leading edge Challenges: Governance lags deployment; fixes are reactive and publicly visible; Customer-facing quality incidents (the Klarna reversal pattern); Internal backlash from domain specialists whose judgment was overridden; 'Evaluative anesthesia' — so much is produced so fast that quality signal degrades
Healthy: Moves fast, learns fast, retrofits governance as issues surface.
Unhealthy: Moves fast, reverses publicly, replaces the CEO.
Blind spot: Underestimates how much of the early 'success' was goodwill from stakeholders who expected eventual refinement, not production-grade polish.
Under stress: Compresses toward The Ratifier — a reversal crisis can trigger overcorrection into slowdown and heavy governance, sometimes overshooting into paralysis.
Growth direction: Evolves toward The Integrator — retrofits governance to match deployment footprint, codifies what worked, retires what didn't.
Evolutionary path: Vanguards emerge from confident, opinionated leadership with strong AI conviction. They become Integrators if the retrofit succeeds; they become Ratifiers if a crisis forces a defensive reset.
"We didn't add AI to our business. AI is why the business exists."
Core strategic bet: A clean-sheet organization can outcompete incumbents retrofitting AI into legacy structures.
Examples: Boom Supersonic (mkBoom engineering stack). Cursor. AI-native fintechs (Ramp, Brex adjacents). Logistics and customer-service operating-model rebuilders.
The Traveller built the organization around AI from inception. The business doesn't function without AI — the product either creates capability that wasn't reachable before (market-creating) or rebuilds an existing market with a 3–5× leaner operating model (service-rebuilding). Protocols for validation, ontological stability, and domain-expert review are engineered alongside capability, not after an incident forces them. Travellers typically run with smaller headcount than revenue-equivalent incumbents and attract practitioners who want to work where AI isn't a bolt-on.
Strengths: No legacy baggage — every workflow is clean-sheet; Governance designed into product architecture, not layered on top; Capital-efficient operating model (talent structure built for AI); Customers understand AI is the product, not a feature; expectations are calibrated Challenges: Fragility if underlying foundation models shift unexpectedly; Talent concentration — founders often hold critical judgment that can't yet delegate; Defensibility as incumbents close the gap with retrofit investment; Scaling past early product-market fit into a durable institution
Healthy: The team builds a real institution with distributed judgment.
Unhealthy: AI-native team stays founder-dependent and never becomes a company.
Blind spot: Assumes the AI-native operating model is always faster — misses that some incumbent advantages (distribution, trust, data) aren't catchable by structural cleverness alone.
Under stress: Travellers don't disintegrate toward another archetype. They either iterate their way out or fail as companies; the form doesn't flex into Integrator or Architect because those require a different origin story.
Growth direction: Widens AI-specific governance into broader operating protocols as the org scales; deepens coordination scope toward industry partnerships and standards.
Evolutionary path: Travellers don't transition — they scale within their form. An enterprise that retrofits successfully becomes an Integrator or Architect, not a Traveller. Travellers are topologically isolated on the archetype map.
"We're not chasing the latest model. We're building the platform our teams will run on for years."
Core strategic bet: Internal AI infrastructure compounds as an economic moat — every rapid iterator's failed experiment feeds the platform's improvement.
Examples: Uber (four-layer platform architecture, 84% developer agentic adoption). BBVA (4000+ custom GPTs). Frontier orgs from OpenAI's State of Enterprise AI report (6× internal AI messaging volume vs. median).
The Architect invests in internal AI infrastructure that multiple teams depend on. They treat validation, governance, and monitoring as engineered constraints built into the platform rather than policy layered on top. Capital-intensive and slow to market. The reward is institutional-scale evolution — platforms outlast leadership transitions, and upstream signal capture creates a moat that competitors without comparable investment can't replicate. Platform teams hold specialist AI expertise while product teams consume it through clean abstractions.
Strengths: Institutional-scale durability — the platform outlasts executive tenures; Economies of scope across many internal use cases; Governance is invisible to users (built into tooling, not policy); Signal-capture moat — upstream absorption of every team's iterative exhaust Challenges: Slower time-to-market than startups or Vanguards; Capital-intensive; requires sustained executive sponsorship across budget cycles; Internal coordination overhead (platform teams can become bottlenecks); Platform can lag the model frontier if not actively refreshed
Healthy: Platform accelerates product teams; governance is felt as leverage, not friction.
Unhealthy: Platform becomes a gate that slows the teams it was supposed to accelerate.
Blind spot: Undervalues speed. Assumes time is on their side because the platform compounds — misses moments when a competitor's non-platform speed captures a market before the platform's advantages matter.
Under stress: Compresses toward The Broker — under budget cuts, the platform gets outsourced to vendors and the institutional advantage dissolves.
Growth direction: Expands coordination scope into inter-organizational standards; moves toward L4 Infrastructure where the platform becomes a sector-wide baseline.
Evolutionary path: Architects emerge from Integrators who realize multi-team coordination requires infrastructure, or from successful Travellers widening their scope. They tend to remain Architects once at scale; the transitions away are usually crises.
"We're not first. We're not lost. We adopt where it pays and redesign when it matters."
Core strategic bet: Evidence-driven selection yields higher ROI per deployment than speculative first-moves, and workflow redesign (not just tool-layering) is where the real leverage lives.
Examples: Accenture 'AI Achievers' (≈12% of enterprises). McKinsey 'high performers' (3× more likely to fundamentally redesign workflows). Most mature enterprises with visible, disciplined AI programs.
The Integrator deploys AI selectively where value is demonstrable, then redesigns workflows around the proven use rather than layering AI on existing processes. They wait for external evidence — competitor deployments, regulator guidance, vendor case studies, published results — before committing. Measured, evidence-driven, not first but not lost. The central basin of the archetype map: most healthy evolutionary paths converge here before continuing toward Architect. When Integrators execute, they capture real value; when they drift, they accumulate 'under evaluation' backlog without corresponding deployment.
Strengths: High ROI per deployment (selection is strict); Organizational trust — workflow changes are visible and explicable; Knowledge transfer scales (codified workflow patterns propagate); Adaptable to model-frontier shifts without business disruption Challenges: Slower than first-movers; some compounding advantages went elsewhere; 'Evidence-waiting' can become a permanent excuse for inaction; Workflow redesign requires sustained change management that often underdelivers; Proliferation risk — many small wins without platform investment creates sprawl
Healthy: Selective, rigorous, compounding through workflow redesign.
Unhealthy: Selective becomes paralytic; pilots never convert to standard practice.
Blind spot: Believes 'waiting for evidence' is always the rational choice — misses that some evidence only emerges after your own deployment generates it.
Under stress: Compresses toward The Warden — external pressure (regulatory, reputational, market) freezes deployment as compliance reviews multiply.
Growth direction: Evolves toward The Architect — invests in platform to scale the workflows; the natural next move when deployment count crosses a coordination threshold.
Evolutionary path: Integrators come from Vanguards (post-retrofit), Tinkerers (post-codification), Wardens (post-regulatory-clarity), or Brokers (post-internalization). They become Architects when scale demands it.
"We don't know what will work until we try it. So we try a lot of things."
Core strategic bet: Generating own evidence via high experimentation volume beats waiting for external proof in markets that reward speed.
Examples: Scaleups and fast-moving mid-size orgs. Small product pods inside larger enterprises given freedom to experiment. Early-stage AI-adjacent (not AI-native) product teams.
The Tinkerer generates its own evidence through volume. Many small experiments run in parallel; few are codified yet. They move ahead of proof because their markets reward experimentation, and waiting for external validation means losing ground. A transient state by design: with discipline, Tinkerers become Integrators; with scale, they become Vanguards; without either, they dissolve back into Folkways. The discipline that matters is not starting experiments but retiring them — the signature Tinkerer failure mode is accumulating pilots without a retirement cadence.
Strengths: Pattern recognition across many real attempts (not theoretical); Low cost per experiment — scale is small, reversibility is high; Practitioner culture attracts hands-on talent; Fast feedback loops; evidence comes from own work, not literature Challenges: Codification gap — what works doesn't become standard practice; Coordination overhead as concurrent experiments multiply; Hard to separate signal from noise across many small pilots; 'Innovation theater' risk — looks active but doesn't converge
Healthy: Disciplined experimentation that converges on codification.
Unhealthy: Perpetual experimentation that never commits.
Blind spot: Treats starting new experiments as progress, underestimates that retiring experiments is the real sign of discipline.
Under stress: Compresses toward The Folkway — under resource pressure, experiments continue individually but stop being tracked or centrally evaluated.
Growth direction: Evolves toward The Integrator — codifies what works into standard practice. The single most important move is retiring experiments as deliberately as starting them.
Evolutionary path: Tinkerers come from Folkways (when leadership starts tracking what's emerging) or from scaleup-stage adoption. They become Integrators via codification or Vanguards via scale. Without either, they dissolve back into Folkway.
"We don't surf the first wave. We ship the one that lasts."
Core strategic bet: The second wave, well-executed, outlasts the first.
Examples: Apple (historical posture across emerging technology categories; current AI stance). Risk-averse incumbents in consumer categories where brand trust is foundational. Institutional cultures that privilege polish over priority.
The Ratifier defers deployment by strategic choice, not constraint. They wait for vendor consolidation, regulatory clarity, and use cases proven at scale by others. When they move, they deploy at higher polish than the early-movers who preceded them — trading early-market compounding for late-market quality. The bet is that the second wave, executed well, outlasts the first. Easy to confuse with paralysis from the outside; the distinguishing feature is a clear (if private) entry criterion. Apple's historical pattern is the canonical shape — and also the canonical reminder that Ratifiers can overstay their waiting posture.
Strengths: Deployment polish — their AI feels finished where others feel rough; Avoids public learning costs others absorbed; High trust with existing customers (no brand dilution from crapjects); Capital discipline — no wasted spend on tools that didn't survive Challenges: Missed differentiation windows that went to earlier movers; Talent risk — practitioners want to work where the frontier is; Late-arrival inertia — hard to recalibrate when the moment arrives; Indistinguishable from paralysis without a clear entry criterion
Healthy: Deliberate timing with a clear trigger; ships polished second-wave product.
Unhealthy: The trigger keeps moving; late becomes never.
Blind spot: Assumes polish compounds faster than time-in-market experience does — misses that second-movers rarely out-execute first-movers once those first-movers have iterated under real conditions.
Under stress: Compresses toward The Broker — under competitive pressure, outsources the capability entirely to avoid committing too late.
Growth direction: Evolves toward The Integrator or The Architect when they finally move with a clear trigger.
Evolutionary path: Ratifiers emerge from institutional cultures that privilege polish and brand (Apple-shape). They become Integrators or Architects when they move; rare to transition back. The dangerous path is stalled Ratifier → Broker permanently.
"Our industry doesn't move until the regulator does. That's the job."
Core strategic bet: Compliance-ready infrastructure creates a competitive moat in regulated verticals (1.5–2× valuation premium for compliance-mature assets).
Examples: EU banks, insurers, and financial-services firms under the AI Act. Healthcare organizations under HIPAA-adjacent frameworks. Public-sector agencies with mandated deployment reviews. Vertical-specific regulated industries (pharma, defense, utilities).
The Warden gates deployment on regulatory approval. Compliance isn't a byproduct of their AI strategy; it's the operating posture. EU AI Act, HIPAA-adjacent frameworks, financial-services model governance, sector-specific audit regimes — the regulator sets deployment velocity. This can be a real strategic advantage in regulated verticals where compliance-mature infrastructure is hard to replicate. The underlying risk is that the regulatory clarity they're waiting for may arrive too late or too ambiguously, and meanwhile internal frustration produces shadow adoption — a Folkway forming quietly underneath the Warden posture.
Strengths: Compliance as moat — raises the barrier to entry for less-regulated competitors; High protocol specificity creates durable institutional knowledge; Trust premium with regulated customers and auditors; Risk-adjusted deployment — customer-facing AI incidents are rare Challenges: Regulatory uncertainty means deployment planning is always contingent; Talent flight to less-regulated competitors; Internal frustration drives shadow adoption (Folkway forming beneath); Compliance infrastructure becomes a permanent brake even after regulation clarifies
Healthy: Compliance posture as active strategic advantage, with deployment ready to move when regulation clarifies.
Unhealthy: Compliance as reason not to decide anything.
Blind spot: Assumes the regulator is the binding constraint, misses that internal compliance culture often continues to gate deployment long after regulatory clarity arrives.
Under stress: Often develops a shadow Folkway underneath — individual practitioners use AI informally, bypassing compliance gates. The Samsung pattern.
Growth direction: Evolves toward The Integrator as regulation clarifies and compliance infrastructure becomes a deployment enabler rather than a gate.
Evolutionary path: Wardens come from regulated verticals or from Integrators that hit a compliance wall. They become Integrators when regulation clarifies; they rarely become Architects (compliance overhead discourages platform-scale bets).
"We know what we need. Someone else is better at holding the tools."
Core strategic bet: AI moves too fast for non-specialist orgs to build competitively; renting capability is more rational than buying.
Examples: Mid-market ops orgs on Palantir / Accenture / BCG X AI-as-a-service. Non-tech-native enterprises delegating AI capability to specialist consultancies. Smaller orgs that chose not to build AI talent internally.
The Broker delegates AI capability externally. They hold the problem but not the tools; the vendor or consultancy holds the capability. The rational premise is that AI moves too fast for non-specialist orgs to build competitively — better to rent than buy. When it works, it's fast and cheap and lets internal teams focus on the business. When it doesn't, vendor lock-in becomes the dominant story and the org discovers it can't even evaluate the vendor's work critically. The growth pattern is usually 'build-buy-build' — start by buying, internalize the strategic pieces later.
Strengths: Speed to deployment with no internal build time; Access to specialist capability without salary commitments; Lower capital exposure during a period of technology uncertainty; Focus — internal teams work on the business, not the AI Challenges: Vendor lock-in becomes the dominant risk; Internal knowledge erosion — can't evaluate vendor claims critically; Data governance complexity (what does the vendor see, store, train on); Strategic dependency — if the vendor pivots, the org is exposed
Healthy: Selective delegation with internal staff who can evaluate vendor output and internalize strategic pieces over time.
Unhealthy: Total dependence without the internal capacity to critique the work.
Blind spot: Assumes the vendor relationship is a commercial question when it's actually a capability question — underestimates what happens when internal knowledge atrophies.
Under stress: Compresses toward The Warden — under vendor disruption (pricing shock, acquisition, pivot), brings governance in-house as a defensive response without yet having the capability to match.
Growth direction: Evolves toward The Integrator or The Architect — selectively internalizes strategic capabilities as the build-vs-buy calculus shifts.
Evolutionary path: Brokers come from non-tech-native orgs that need AI capability but rationally chose not to build. They become Integrators or Architects as the cost-benefit of delegation changes.
"AI showed up through our teams before leadership noticed. We're still figuring out what that means."
Core strategic bet: Not a bet — a state. The open question is whether the organization catches up to its own practitioners.
Examples: Small orgs where everyone uses ChatGPT on the side. Non-tech teams at large enterprises informally adopting. Early-stage bottom-up adoption preceding any strategy formation.
The Folkway is broad, shallow individual adoption happening below organizational visibility. Teams discovered AI on their own; the organization hasn't decided what to do about it yet. The strength is bottom-up sensing — practitioners are finding valuable use cases before leadership commissions a strategy. The risk is the Samsung scenario: valuable data walks out through unauthorized tool interfaces while leadership discusses policy. Most organizations pass through the Folkway briefly on their way to a chosen posture; a minority linger here for years, accumulating exposure without corresponding learning.
Strengths: Bottom-up discovery of valuable use cases; Low cost of experimentation (users often paying for tools personally); High individual adoption velocity; Early signal about what matters to frontline work Challenges: Data exfiltration risk through personal tool accounts; No organizational learning — what works for one team doesn't propagate; Quality variance — some uses excellent, others produce 'crapjects'; Governance vacuum creates exposure without corresponding upside
Healthy: Brief passage state on the way to Tinkerer or Integrator, with leadership catching up and formalizing what's emerging.
Unhealthy: Lingering Folkway that never gets inventoried; eventual incident forces heavy-handed reaction.
Blind spot: Underestimates the data-governance exposure because the individual users don't see what they, collectively, are sending out.
Under stress: Under top-down pressure after a visible incident, often compresses toward The Warden — leadership responds with heavy-handed policy that lacks specificity, driving the Folkway further underground rather than resolving it.
Growth direction: Evolves toward The Tinkerer (formalizing what's already emerging) or The Guild (if sophistication is already concentrating in specific experts).
Evolutionary path: Folkways are an entry state — most orgs pass through briefly. They become Tinkerers with formalization, Guilds with concentration + expertise, or Wardens if leadership responds by clamping down.
"Our best people figured it out themselves. The rest of the org doesn't know yet."
Core strategic bet: Not an organizational bet — an emergent capability. The strategic question is whether leadership recognizes and preserves what its experts have built before the experts leave.
Examples: Enterprises where a few engineers or analysts have built sophisticated custom pipelines unknown to leadership. Domain experts using AI to take on work that was previously out of reach. Informal expert networks accumulating proprietary pattern recognition.
The Guild is concentrated, sophisticated AI work living below organizational visibility. Individual experts — often with deep domain knowledge — have built proprietary pipelines and pattern recognition the organization may not realize it has. This is 'tasteful discrimination' accumulating at the practitioner layer, the kind of judgment base models don't possess and vendors can't replicate. Strength: the org holds a capability moat it doesn't know is a moat. Risk: the expertise leaves when the expert does. The Guild is usually detected, not self-reported — the archetype's defining feature is that the organization doesn't fully see itself.
Strengths: Proprietary pattern recognition — signal value base models don't have; High-sophistication work on real problems, not demos; Resilient to model frontier shifts (experts adapt faster than systems); Low governance overhead at the practitioner level Challenges: Bus factor — if the expert leaves, the capability leaves; Opacity — organization can't evaluate or scale what it can't see; Reproducibility gap — the Guild member's work isn't codified; Bridge problem — Guild work doesn't integrate with official workflows
Healthy: Leadership recognizes the Guild, invests in codification, and the expertise becomes an Architect-level platform in that domain.
Unhealthy: The org never sees the Guild; the expert leaves; the capability evaporates without trace.
Blind spot: The Guild member often underestimates how much of their work is tacit and non-transferable — 'anyone could do this' is almost always wrong.
Under stress: Under organizational pressure (layoffs, mandated standardization, forced tool consolidation), Guilds often dissolve rather than transition — the experts leave and take the capability with them.
Growth direction: Evolves toward The Architect in their specific domain — the Guild's work gets codified into platform primitives. This requires leadership recognition and investment; it doesn't happen by default.
Evolutionary path: Guilds come from Folkways (as sophistication concentrates) or from Integrators (where a particular expert goes deeper than the org expects). They become Architects in their domain if codified, or they disappear if not.
<!-- Generated file — do not edit. Source of truth: AI-Adoption-Guide/html/slides.html. Regenerate via: cd AI-Adoption-Guide/scripts && npm run generate (or node generate.mjs). Last generated: 2026-05-25. -->
# Durable AI Adoption — AI Capability Maturity Model
*A practical AI adoption guide, written by practical AI adopters. Learn how to adopt AI across your organization, with case studies, maturity levels, and lessons from the Protocol Institute and other organizations.*
Version: v0.5 · May 2026 · Generated: 2026-05-25
Live interactive deck: <https://ai.protocolized.dev/>
---
### Contents
- **01. [More than a tool](#ch-1)** (page 03)
Why AI is a paradigm shift, not a software upgrade, and why adoption needs two mirror tracks.
- **02. [Adoption Maturity Levels](#ch-2)** (page 09)
Five maturity levels from Shadow to Planetary, each paired with its cultivated counterpart.
- **03. [Getting started with AI adoption](#ch-3)** (page 17)
Readiness check, plan after play, and the four-stage path workflows take into governance.
- **04. [The path to durable AI adoption](#ch-4)** (page 22)
Bottom-up discovery, top-down scale, and the six functions that hold the operating tension.
- **05. [How the Protocol Institute adopts AI](#ch-5)** (page 29)
Two case studies from inside the Protocol Institute, at Level 1→2 and at Level 3 Engine.
- **06. [The new nature of work](#ch-6)** (page 32)
Maintaining the cultivated and governed handoff as the terrain keeps shifting.
- **07. [About & Resources](#about)** (page 35)
The Protocol Institute, the Protocols for Business SIG, source materials, and ways to engage.
## More than a tool
### Three times, a new technology remade the environment of work
*Early adopters first bolt on the new technology onto the current production architecture. But meaningful gains only appear after a complete redesign of the production environment.*
“Locational freedom was an unparalleled advantage of steam.”
“Whereas a steam-powered plant could be located almost anywhere, the water-powered factory was tied to a non-transportable power source.”
Steam diffusion “revolutionized production by freeing manufacturers from the locational and seasonal constraints imposed by water power.” By 1900, steam engines “outnumbered waterwheels and water turbines by four to one” in American factories.
See full case study →
Factories could minimize material handling instead of optimizing power distribution.
The first wave just swapped the core power source: “the usual juxtaposition of a new technology upon the framework of an old one.”
The transformation came with the “ideal workshop — a shop with a motor driving each tool or machine,” freeing the floor to follow the “natural sequence of manufacturing operations.” Output per man-hour then jumped from “1.3 percent before 1919 and 3.1 percent after.”
See full case study →
“The container made shipping cheap, and by doing so changed the shape of the world economy.”
“The container is at the core of a highly automated system for moving goods from anywhere, to anywhere, with a minimum of cost and complication on the way.”
The world’s geography was then redesigned around the box: “Sprawling industrial complexes… gave way to smaller, more specialized plants that shipped components and half-finished goods to one another in ever lengthening supply chains.”
See full case study →
### AI capabilities are more than another app subscription
*Everywhere you look, AI is already there*
Agents, AI-enabled workflows, and tools are seemingly everywhere. It can be surprising, and a little strange, when they sometimes collapse production cycles from months to days or even hours.
Alongside AI, a new wave of top performers are appearing. They discover (and enact!) operational improvements faster than average organizations can integrate them at scale. Employers and managers alike report feelings of overload, disorientation, mania, and fear of being left behind. Whether by choice or by necessity, your organization is adopting AI. The question now is: can your organization describe what good adoption looks like, including the opportunities to prioritize and blunders to avoid?
AI has evolved rapidly, from a chat window to autonomous software factories. And yet, most of us are unsure – are we getting better at adoption? Or are we just getting busier?
A key driver of this confusion is that AI is being treated as a bundle of software products. It is better understood as a technology paradigm like the steam engine, car, or personal computer.
Paradigms are like waves – powerful, dangerous, and hard to surf. They reshape individuals and identities, not just technical systems.
AI is a new type of software with unique properties (probabilistic outputs, generative capacity, indeterminate failure distributions) that an organization integrates into its operating model. While deployment is the action of standing up a particular tool, policy, or workflow, adoption names the long arc of an organization's integration with the paradigm itself.
Treating AI like a bundle of products has a second consequence. AI is unlike enterprise tooling. There, a deployment plan can run on a planned sequence of procurement, policy, and rollout.
To catch the wave early, AI adopters must run a parallel track: bottom-up exploration, individual play, and vernacular practice. Both planned deployment and organic discovery are required. It isn't hyperbolic to say that AI is creating new types of people, just as cars and modern medicine have created new types of people, who would have a difficult time communicating with someone from the past.
Realizing this, the Protocols for Business Special Interest Group of the Protocol Institute collects insights on AI technology adoption. Every few months, we create a new version of this orientation framework. It includes new concepts, case studies, an organizational self-assessment, as well as common success and failure modes. Let's dive into our latest findings.
### The AI paradigm unfolds in two parallel tracks
*Each milestone needed both an individual practice and an organizational response. The cultivated track is what people invent; the governed track is what organizations approve.*
- **Milestone 01: Chat** (2022–23)
- **Milestone 02: Tools** (2023–24)
- **Milestone 03: Agents** (2024–26)
- **Milestone 04: Factories** (2026–28)
**01 · Cultivated**
- Everyday use of ChatGPT
- Personal-account exploration
- Prompt experimentation
**01 · Governed**
- Acceptable-use policies
- Blanket bans (Samsung)
- First enterprise licenses
**02 · Cultivated**
- Custom GPTs and skills
- Prompt libraries and kits
- Team-authored workflows
**02 · Governed**
- Sanctioned tool lists
- Enterprise vendor deals
- Verification checkpoints
**03 · Cultivated**
- Vibe-coding, agentic IDEs
- Agents with wallets
- AI-native function workflows
**03 · Governed**
- Forward Deployed Engineers
- Agent governance protocols
- Model risk frameworks
**04 · Cultivated**
- One-person agent fleets
- Always-on personal pipelines
- Second brains
**04 · Governed**
- Compute and token budgets
- Fleet-level observability
- Output-quality contracts
### Durable AI Adoption needs governance and cultivation
*A short introduction to the AI Adoption Guide*
This guide is about AI adoption: the long arc through which an organization integrates with AI. Adoption runs along two tracks. One is governed, made up of the formal apparatus the organization approves in advance: policy, procurement, rollout. The other is cultivated, made up of the practice its people invent on their own as they use AI: bottom-up exploration, individual play, and vernacular practice. Durable adoption requires both.
Most organizations approach AI the way they approach software, by defining what their people may and may not do with it. They publish acceptable-use policies, approve a list of tools, and set data boundaries. This approach works when failure modes – like memory limits or data format consistency – are known in advance and can be examined forensically, as with deterministic software. This approach fails with AI, because outputs are probabilistic and whose failure distribution shifts with every model update. Tightly-defined safety and security measures cannot keep up. Good workers will route around those measures, and many of the failures that the policies were meant to prevent will happen anyway.
You should not shift to less governance but to a different kind of governance. Instead of governing what people may or may not do with AI, govern what AI outputs must do at the points where they become consequential: how each output gets verified, how it gets escalated, how it becomes someone's accountability when it crosses from machine to human or from one team to another. These output-based rules guide coordination at handoff points rather than restrict activity at access points. A traffic light is a protocol; a blockade is not. Both are rules, but only one keeps the goods moving through the system.
> **Durable AI**
- **Governed** — Top-down: policy, procurement, and output-level guardrails for how each AI result gets verified and escalated.
- **Cultivated** — Bottom-up: exploration, play, and the kits people invent and prove on their own before the organization promotes them.
### The path through this guide
*How the chapters develop the model, from the framing argument through the maturity ladder, the pilot work, the cases, and the patterns.*
- **01. More than a tool** — Why AI is a paradigm shift, not a software upgrade — and why durable adoption needs both governed and cultivated tracks.
- **02. Adoption Maturity Levels** — Locate your organization on the five maturity levels, from invisible personal use to civilization-scale infrastructure.
- **03. Getting started with AI adoption** — Run the pre-pilot readiness check, conduct the half-day audit, and learn how to evaluate candidate use cases.
- **04. The path to durable AI adoption** — Manage the velocity, assurance, and legibility trade-offs as bottom-up discovery becomes top-down scale. Four success patterns hold the tension, four failure modes collapse it, and six new business activities staff the work.
- **05. How the Protocol Institute adopts AI** — Dive into two AI adoption case studies from inside the Protocol Institute.
- **06. The new nature of work** — See why durable adoption is never finished, and how the deployment lead's work becomes keeping the cultivated and governed tracks in handoff as the terrain shifts.
- **07. About & Resources** — Learn about the Protocol Institute, the Protocols for Business SIG, source materials, and ways to engage.
- **08. AI Adoption Assessment** — A 24-question diagnostic that places your organization on the maturity ladder and surfaces your dominant archetype.
## Adoption Maturity Levels
### The dual nature of AI adoption
*Most organizations default to the governed mode of adoption they know from other technologies. This falls short because AI also demands individual-level change, something governed frameworks alone cannot produce. Durable adoption also requires cultivation.*
**L·01** · Governed: **Shadow** — AI in use through personal accounts; no monitoring, no governing policy.
**L·01** · Cultivated: **Play** — Curiosity-driven exploration; AI encountered as a medium for deep play and discovery.
**L·02** · Governed: **Sanctioned** — Access policy in place; tools approved, use tracked, risk contained within boundaries.
**L·02** · Cultivated: **Kit** — Users encoding personal workflows into reusable, shareable protocols of their own design.
**L·03** · Governed: **Engine** — Workflows built around AI with named owners and quality metrics; output is optimized.
**L·03** · Cultivated: **Practice** — New forms of work emerge that were not possible before AI; roles and practices are redefined.
**L·04** · Governed: **Infrastructure** — AI is a sector baseline; coordination challenge crosses organizational boundaries.
**L·04** · Cultivated: **Vernacular** — AI practices absorbed into culture; tacit knowledge spreads without mandates or policies.
**L·05** · Governed: **Planetary** — Civilization-scale AI; coordination and legibility are the governance challenge.
**L·05** · Cultivated: **Fluency** — AI fully absorbed into how people think and work; second nature, no longer named.
### Examples across both paths of adoption
*The levels are informed by recent and historical case studies. Durable adopters use tactics and strategies from both paths.*
The levels are informed by recent and historical case studies. Durable adopters use tactics and strategies from both paths.
## Getting started with AI adoption
### Pre-pilot readiness check
*Before identifying a use case, run a quick readiness check with your organization's AI adoption leaders. Ask the questions then assess if the answer met the criteria provided. This readiness check is not about which use case is right; it is about whether the organization can support a real pilot at all.*
01. **Has the organization completed a security and legal review of the most likely AI tools and data?**
Pass if: Data boundaries, connector permissions, legal alignment, and auditability documented.
02. **Does an executive sponsor exist with budget authority for the pilot?**
Pass: Named individual; budget approved through at least 3 months.
03. **Have two or three pilot teams been identified with motivated leads?**
Pass: Champions named; their direct reports (function leads) are aware and supportive.
04. **Are success metrics defined for the pilot itself — not the use case?**
Pass: Specific, baselines measured already, and changes are observable in weekly check-ins.
If any answer is no, address it before committing to a pilot timeline. Notice what is not on the readiness checklist: a list of approved use cases, a function-by-function curriculum, a product roadmap. Those decisions get made in the next phase, by the people who will run the work.
### Plan After Play
*Before you can plan AI adoption well, you need to let play happen first. These three moves create the conditions for cultivated practice to surface.*
**Step 01 — Create a venue for play**
Give people a permissive, low-stakes space to explore AI without agenda. No required tools, no prescribed use cases, no metrics on output. The goal is for people to discover, on their own terms, what working with AI actually makes possible – but make sure outputs are shared in some way. Deep play comes before useful practice.
**Step 02 — Bespokify, not scale**
Resist the pull toward uniform adoption. Experiment with tools that solve problems at the individual or two-pizza team level first. The workflows worth formalizing are the ones practitioners have already proved through daily use, not the ones a vendor case study or competitor announcement suggested.
**Step 03 — Build soundbite strategies**
What are your organization's agreed-upon design principles for working with AI? What should and should not be done? These need to be short enough to remember and specific enough to apply. Stable knowledge compounds; undocumented practice does not.
Play surfaces the workflows worth planning around. The governed track inherits and scales what the cultivated track discovers.
### From Play to Protocol
*“Toy” workflows earn their way into the governed track by passing through four stages. Each gate is a question. If the answer is no, the workflow stays in the sandbox.*
- **Cultivated → Discover** — Someone explores a workflow on their own terms, without an agenda or prescribed tool. Play is the method. The player's goal is to find out what AI actually makes possible in their domain.
- *Gate: Is it recurring?*
- **Cultivated → Encode** — The practitioner writes down the steps. Tacit expertise becomes a reusable kit. The value here is the encoding itself, not the speed gain — someone else can now inherit what took months to discover.
- *Gate: Encodes real expertise? Result observable?*
- **Governed → Prove** — The kit runs on real work in a low-stakes context. A bad output is recoverable. Here, the governed track takes custody: someone external can prove that the process result has improved.
- *Gate: Blast radius bounded?*
- **Governed → Harvest** — The proven kit is promoted to shared infrastructure. It becomes a resource others inherit rather than rediscover. The organization now owns and scales what was first independently found through play.
The cultivated track does its job by encouraging play and creating more challenging kinds of play. It's wrong to remove a candidate workflow too early and equally problematic to promote a workflow that has not earned its gates — the governed track then inherits noise, not signal.
### A network of factories
*AI makes everyone a factory of one. Teams and individuals begin to produce and consume structured outputs.*
Once an AI workflow is encoded as a protocol with defined inputs, observable outputs, and a shareable kit, the way work moves through an organization starts to change. Coordination shifts from informal channels to the protocols themselves.
An analyst who encoded their research workflow into a kit is now a factory of one. Anyone who needs that analysis consumes the output through the kit's interface, not through a Slack thread. The meeting that used to align two people's tacit processes becomes a protocol handoff with a versioned input, an observable output, and a named owner.
Governance moves up a layer. Its job stops being the management of individual workflows and becomes the maintenance of the platform: keep the interfaces clean, encourage teams to expose what they have built, and make sure the protocols compose. The organization becomes a network of factories. Each is autonomous. Each is interoperable. Each is consumable by the rest of the network through its interface.
In 2002, Jeff Bezos issued an internal edict to Amazon's engineering organization. Every team had to expose its data and functionality through service interfaces. No direct database links, no internal shortcuts. Everything went through APIs, and the APIs had to be designed as if they would eventually be exposed to the outside world.
The point was not speed or efficiency. It was architecture. By forcing every team to treat its own work as a product with a defined interface, Amazon built a platform almost by accident. Steve Yegge's 2011 memo, which contrasted Amazon's discipline with Google's lack of it, remains the clearest account of what the practice produces and what its absence costs.
"Bezos's Big Mandate transformed Amazon. Every team in the company, from the smallest engineering skunkworks to the most mission-critical platform team, needs to interact with all other teams exclusively through these service interfaces." Steve Yegge · Google Platforms Rant · 2011
## The path to durable AI adoption
### Bottom-up discovery, top-down scale
*Discovery is cultivated. Scale is governed. The organization's job is to invest in both and make the handoff between them deliberate.*
#### Cultivated · What champions do · Months 1–5
- **01. Discover** — Find people already experimenting on their own time. Give them a venue with no required tools, no prescribed use cases, no output metrics. Let play surface what AI makes possible in their domain.
- **02. Encode** — Champions write down the steps. Tacit expertise becomes a reusable kit. The value is the encoding itself. Someone else can now inherit what took months to discover.
- **03. Prove** — The kit runs on real work in a low-stakes context. A bad output must be recoverable. Someone external can verify the result improved. This is the gate before the handoff.
#### Governed · What the organization does · Months 1–6+
- **01. Sanction** — Set access policy in parallel with Discover. Approve tools, track use, contain risk. This creates the conditions for legitimate play without prescribing what that play looks like.
- **02. Promote** — Harvest proven kits into shared infrastructure. Assign named owners. Skeptics convert by seeing workflows proved on real work, not by policy announcement.
- **03. Scale** — Kits deployed across the organization so it can bind with compatible workflows. New hires inherit AI-enabled workflows on day one. Kit reuse measurable across teams. The department reaches Engine level.
### Operational leads will need to manage tensions between velocity, assurance, and legibility
- **Velocity** — Velocity is how quickly the organization can discover, ship, and iterate on what AI makes possible. It is the throughput of the cultivated track, and operators measure it through time-to-pilot, cycle time on workflow changes, and the rate at which proven kits move into shared infrastructure.
- **Assurance** — Assurance is the degree to which AI outputs are verified, bounded, and tied to a named accountability before they reach a consequential handoff. The governed track maintains it through a stack of controls, gates, and audit trails.
- **Legibility** — Legibility is the degree to which the system remains understandable to its operators. They need to see not only what it outputs but why and from what context, which requires telemetry, lineage, and operator-readable state behind every action.
### Success patterns hold the tension between AI adoption tradeoffs
#### `▦→▣` Kit harvesting over central design *(success)*
*Wait for variation before standardizing.*
The protocols worth formalizing are the ones domain experts have already proved through daily use. The organization's job is to identify, capture, and systematize the kits champions have already built — and to wait for variation to express itself before standardizing.
> **Holds:** Local Velocity without sacrificing downstream Assurance or Legibility
#### `▶↻` Plan after play *(success)*
*Plan from what play surfaces.*
AI invites experimentation at a tempo upfront planning cannot keep up with. Let play run at its native speed first — Shadow-level exploration, function-level kit-building — then plan continuously from what surfaced. Quarterly plans become rolling syntheses; biweekly reorientation rituals reconcile commitments against reality.
> **Holds:** Velocity in play without losing Legibility or Assurance in the plan
#### `◐◑` Differential gear trains *(success)*
*Buffer the mismatch instead of throttling.*
Engineers know this from car differentials — a mechanical assembly that transmits power between components rotating at different rates. The deployment-lead version is buffers, queues, async handoffs, and tempo-aware routing. Uber's Code Inbox is the canonical case.
> **Holds:** Upstream Velocity without breaking downstream Assurance or Legibility
#### `</>` Constitutional software *(success)*
*Compile constraints into the runtime.*
Encode constraints in code itself: sandboxed environments the agent cannot escape, separate dev/prod boundaries, planning-only modes, and revocation paths that compile authority into technical interlocks rather than relying on human reaction time.
> **Holds:** Agent Velocity without weakening runtime Assurance or Legibility
### Failures collapse the tensions, losing the balance between operational needs
#### `⊘` Premature optimization *(failure)*
*Standardize before practice earns it.*
Centrally designing the official AI workflow before users have iterated through enough kit forms; the published standard is rejected, users keep their kits in the shadows. Variants: premature consolidation (collapsing kits into a single platform) and premature procurement (vendor stack before need is known).
> **Collapses:** Paper Assurance at the cost of Velocity and Legibility
> **Mitigated via:** Kit harvesting over central design
#### `?↺` Disorientation *(failure)*
*Production outpaces understanding.*
The organization's commitments accumulate faster than its ability to update shared understanding. The gap is structural: imbalance between commitment speed and reorientation speed. HBR (May 2026) documents the worker-level signal as psychological debt.
> **Collapses:** Velocity outruns Legibility; Assurance erodes
> **Mitigated via:** Plan after play
#### `≠` Tempo misalignment *(failure)*
*Output stacks at the slowest neighbor.*
AI accelerates different pieces of a workflow at different paces. Output stacks up at the slowest process or partner. Uber's response: with 65–72% of code AI-generated and 11% of PRs opened by agents, the bottleneck shifted from coding to review — Code Inbox and U Review absorbed the new tempo.
> **Collapses:** Upstream Velocity breaks downstream Assurance and Legibility
> **Mitigated via:** Differential gear trains
#### `◉○○` Extended blast radius *(failure)*
*Permissions and interventions lag production.*
Replit's July 2025 incident: during a code freeze, the agent ignored explicit instructions, deleted a production database with records of 1,206 executives and 1,196 companies, then misled the user about recoverability. External version: Air Canada (BC Civil Resolution Tribunal, 2024).
> **Collapses:** Velocity outruns Assurance; Legibility arrives too late
> **Mitigated via:** Constitutional software
### Six business activities have emerged to capture AI opportunities, and manage its risks (Jargon may vary)
**Kit Harvesting** — Find the AI workflows people are already running on their own — in personal repos, vaults, scripts, and custom GPTs. Promote the best ones into shared infrastructure with named owners so others can reuse them. The work includes a per-function audit, a promotion review, and the engineering to make a kit operable by a second person.
**Evals** — Define what "good" means for each AI workflow and build the test harness that measures it. The harness usually includes golden datasets, rubrics co-authored with domain experts, and a scoring runner that fires on every prompt or model change. Maintenance grows over time as new failure modes surface and feed back into the suite.
**Forward Deployment** — Engineers are embedded inside functions — alongside lawyers, sales reps, and analysts — to build the AI workflows each function depends on. The engineer pairs with domain experts, reads their existing work product, and ships the production integration. Each engagement is project-shaped and closes when the workflow runs end-to-end.
**Platform Operations** — Run the shared AI infrastructure that domain teams build on. The platform usually includes a model gateway, versioned prompt and skill registries, eval pipelines in CI, observability (latency, cost, quality, drift), and cost controls. It runs continuously; major upgrades land on a quarterly cadence.
**Risk Stewardship** — Maintain the AI risk register and the technical interlocks that bound what AI is allowed to do. The register tracks models, data, and blast radius. The interlocks include permission boundaries, sandboxes, planning-only modes, write-locks, rollback paths, and the audit trail.
**Context Stabilization** — Curate the context AI systems depend on and keep it stable across models, tools, and agents. The work involves context gathering, curation of authoritative sources and current versions, and ontology work — entity definitions and category boundaries. The goal is to keep the legal team's "contract" and the agent's "contract" from silently diverging.
### Staffing AI adoption means standing up a continuous token production pipeline
- **Soft context** — vernacular, drifting
- **Hard context** — authoritative, versioned, governed
**Intake · Kit Harvesting** — Find the AI workflows people are already running on their own and promote the best ones into shared infrastructure with named owners.
**Intake · Forward Deployment** — Engineers embedded inside functions to build the AI workflows each function depends on.
**Loop · Context Stabilization** — Curate the context AI systems depend on and keep it stable across models, tools, and agents.
**Loop · Risk Stewardship** — Maintain the AI risk register and the technical interlocks that bound what AI is allowed to do.
**Loop · Evals** — Define what "good" means for each AI workflow and build the test harness that measures it.
**Loop · Platform Operations** — Run the shared AI infrastructure that domain teams build on.
## How the Protocol Institute adopts AI
### SIGBIZ AI Discovery Acceleration
*Level 1 → Level 2 (Kit) transition inside a Special Interest Group.*
**Case study 01: SIGBIZ AI Discovery Acceleration**
*Level 1 → Level 2 (Kit) transition inside a Special Interest Group.*
**The problem**
Throughout 2025, most members of the Protocols for Business Special Interest Group were using AI tools for their own work, and almost none of that work was visible to anyone else in the SIG. Members were collecting their own prompts, scripting small workflows in personal repos, learning the same early lessons in parallel. The cost was learning loss. The community of practice was running in private.The challenge was the standard L1 → L2 transition: make shadow use visible, encourage further adoption without prescribing tools, and harvest what members had discovered before it was forgotten.
**The approach**
The SIG settled on three lightweight moves rather than a formal program.
**The impact**
Three things have shifted. First, AI adoption inside the SIG is now visible. Second, mutual discussion improved: members are collaborating on kits. Lastly, ambitions have expanded. The SIG expects new norms to continue emerging, some of which may become standards or protocols.The case study illustrates the cheapest viable Level 1 → Level 2 transition: a recurring meeting, a no-judgment posture, and a willingness to wait for the patterns to emerge from practice rather than to legislate them in advance.
### Protocolized visual identity
*Level 3 (Engine) in the magazine's visual production pipeline.*
**Case study 02: Protocolized visual identity**
*Level 3 (Engine) in the magazine's visual production pipeline.*
**The problem**
Protocolized needed a visual language for a magazine whose editorial method openly integrates LLM-assisted writing. Off-the-shelf image generators produce a generic AI aesthetic that locates the magazine in the same trough every other AI-assisted publication occupies. Commissioned human illustration would not scale to a weekly cadence. Aesthetic nostalgia (mid-century pulp, Astounding-era revival) was the wrong move on principle: Astounding's original power came from embracing the contemporary art of its time.
**The approach**
The magazine commissioned two narrowly-defined image generation models, each developed in collaboration with a named artist and hosted on the TITLES platform.Both deliberately narrow: "not primed by their training art to resolve figurative prompts." TITLES handles attribution and royalties as protocol; image metadata stored onchain.
**The impact**
The visual production pipeline meets the Level 3 criteria. Named owners (Langdon as editor, Ou and Langdon as model artists), a verification checkpoint built into the model itself (the abstraction constraint that fails figurative prompts), and a designed coordination layer between participating roles. The output is a coherent visual identity that holds across issues without each cover requiring an art-direction debate. Choosing to train narrow models on commissioned training art rather than to use stock generators is the same kind of move SIGBIZ made when it harvested its own kits — designing the kit rather than inheriting one designed by a vendor whose interests are not the publication's.
## The new nature of work
### From motions to tokens
*For most of the twentieth century, the unit of management has been the worker's second. A new unit is emerging: the production token.*
Organizations are beginning to measure and meter knowledge production work, which previously sat inside salaries, contractor invoices, and project budgets as an unaccounted ingredient. Per-token LLM billing is already an industry standard for those that have integrated AI tooling. Per-team and per-agent token budgets are emerging as spend lines.
That being said, tokens are not kWh. They behave more like grades of refined petroleum: each model's token does different work; a cached input token is roughly 90% cheaper than a fresh one. The unit remains the token, while the market supply remains differentiated.
The firm that runs on tokens becomes addressable through language, and in some real sense, programmable. The management question changes accordingly, mirroring computational resource allocation. While Taylor asked how to discipline bodies into efficient movement, the tokenized firm asks which problems deserve more tokens, and how to structure symbolic flows so the firm remains computationally tractable. Token allocation is resource allocation at the level of organizational attention.
Frederick Winslow Taylor spent the 1880s and 1890s on factory floors with a stopwatch. His Principles of Scientific Management (1911) decomposed labor into discrete measurable tasks and separated planning from execution. The manager's job was to study, standardize, and allocate. The central resource was time, and the unit of measure was the worker's second.
Taylorism had low expressive bandwidth. It could encode a finite, brittle set of workflows. Whenever reality exceeded the schema (a novel situation, an edge case, a judgment call), managerial sovereignty returned. The foreman still had to intervene because the system itself was not sufficiently programmable.
For a century, management science remained Taylorist at its core. Headcount, utilization, throughput per person-hour: all descendants of the stopwatch.
### Working the frontier of the new nature
*AI-mediated operations aren't the backbone of today's enterprises, but they are changing the shape of organizations everywhere.*
AI-mediated tools and workflows are no longer features of the workplace; they are part of the workplace itself, closer to weather or terrain than to thermostats.
This is the new nature of work. It is also the reason a single, planned rollout is certainly not enough. If the terrain were stable, top-down deployment could finish the job; because it is not, the cultivated track has to remain productive alongside the governed one. Durable adoption depends on governance enabling cultivation rather than displacing it: the terrain keeps moving, and it will remain moving for years, and only the cultivated track can keep finding what works in it.
Inside the new work environment, the deployment lead's job becomes keeping the handoff between the two tracks alive. The volume of AI-assisted output is too high to inspect case by case; new kits surface from the floor faster than any central process can catalogue them; the tools themselves shift behavior on every model update.
The work is maintaining a productive cultivated track and a legible governed one: providing maps through what people are discovering, keeping the gates honest about which kits earned their way across, re-orienting when a team starts moving toward a pattern that compounds risk.
The scarce skill is applied curiosity. The candidate who finds their way through unfamiliar terrain is the person to hire, because that is who keeps the cultivated side feeding the governed one.
The work, then, is not to finish a platform deployment. It is to make deployment a core capability, as the landscape shifts, again and again. The outcome of a successful adoption program is not the kits, the workflows, or the published policies; it is people. People who know how to work in this new nature, and managers who know how to keep the handoff between cultivation and governance working as the terrain keeps changing.
### Case Studies
*Fourteen cases across five maturity levels. Five contemporary AI adoptions, five historical operational analogues, and four foundational research papers, all showing the same patterns at earlier paradigm shifts.*
#### Today's AI adoption stories
- 01. **Samsung Electronics** — L1 · Shadow
- 02. **Klarna** — L2 · Sanctioned
- 03. **Amazon & MeshClaw** — L2 · Sanctioned
- 04. **Air Canada chatbot** — L2 · Sanctioned
- 05. **Boom Supersonic** — L3 · Engine
#### Lessons from the past
- 06. **Visicalc & Excel** — L1 · Shadow
- 07. **Gates's Internet Tidal Wave memo** — L2 · Sanctioned
- 08. **Git & GitHub pull requests** — L3 · Engine
- 09. **Walmart's EDI mandate** — L4 · Infrastructure
- 10. **McLean's container protocol** — L5 · Planetary
- 11. **Rural users and the Model T** — L1 · Shadow
- 12. **American steam adoption, 1820–1900** — L2 → L3
- 13. **Factory electrification, 1880–1930** — L2 → L3
- 14. **Harpers Ferry and the American System** — L3 → L4
### Samsung Electronics
*Level 1 (Shadow) exit pathway: containment and re-admission over two years.*
**Case study 01 of 14: Samsung Electronics**
*Level 1 (Shadow) exit pathway: containment and re-admission over two years.*
**The problem**
In April 2023, three Samsung engineers submitted proprietary source code to ChatGPT through personal accounts within a single month — to debug, optimize, and summarize. No policy existed, no monitoring was in place, and no record of which AI tools employees were using on what data. By the time exposure surfaced, the code had left the organization. The exposure pattern was structural, not malicious.
**The approach**
Samsung responded in two phases. First, containment: a ban on all generative AI on company devices, paired with an accelerated internal LLM (Samsung Gauss). Second, deliberate re-admission over eighteen months — approved tool list, data-classification policy, prompt-filtering middleware, audit pipeline. By late 2025 employees could again use external AI, but only inside the gates Samsung had not built the first time.
**The impact**
Samsung's exit from Shadow is the most documented in the public record. The L1 → L2 transition is rarely one policy action; it is a containment phase followed by a re-admission phase, with the latter taking longer than the former. Organizations that skip containment risk repeating the leak. Organizations that skip re-admission find their workforce running shadow workflows again through different channels.
### Klarna
*Level 2 (Sanctioned) failure mode: access governance without output governance.*
**Case study 02 of 14: Klarna**
*Level 2 (Sanctioned) failure mode: access governance without output governance.*
**The problem**
In early 2024 Klarna announced its AI customer-service assistant was doing the work of 700 full-time agents, with 90% daily AI adoption and two-thirds of customer-service chats automated. The narrative was category-defining productivity, backed by leading indicators: tool adoption, automation share, cost-per-resolution. Trailing indicators — satisfaction, repeat contacts, resolution durability — were not yet visible in the same dashboards.
**The approach**
Klarna's governance focused on access. Tools were sanctioned, employees encouraged, adoption tracked. The company did not build comparable governance for the quality of AI output reaching customers. When trailing indicators began surfacing through escalations and external reporting, the failure mode was the one access-governance is structurally unable to catch: the outputs were technically allowed, but they were not good.
**The impact**
In May 2025 CEO Sebastian Siemiatkowski reversed course publicly, describing AI customer interactions as "generic, repetitive, and insufficiently nuanced," and announced Klarna would rehire human agents. The reversal is the cleanest documented example of L2 access governance running into its ceiling: governing which tools are used cannot, by itself, govern whether the output is good enough. The transition to L3 Engine requires named output owners and verifiable quality gates, not dashboards of utilization.
### Amazon & MeshClaw
*Level 2 (Sanctioned) measurement failure: tracking adoption without governing outcomes.*
**Case study 03 of 14: Amazon & MeshClaw**
*Level 2 (Sanctioned) measurement failure: tracking adoption without governing outcomes.*
**The problem**
In 2026, against a backdrop of $200B in AI-related capital expenditure, Amazon introduced internal targets requiring more than 80% of developers to use AI each week. It began tracking AI token consumption — units of data processed by models — on internal leaderboards. The mandate was clear: prove the AI investment is being absorbed by the workforce and embed the technology into day-to-day work. Adoption was sanctioned, mandated, and measured.
**The approach**
Token consumption became the proxy metric for adoption. Official communications stated the stats would not factor into performance evaluations — but managers retained visibility, and employees believed they were being watched. The in-house MeshClaw tool, which lets users create AI agents that automate workplace tasks, was deployed widely. Staff began using MeshClaw to automate non-essential work specifically to inflate their token counts — a practice nicknamed "tokenmaxxing" (also documented at Meta).
**The impact**
Adoption rates can be mandated and tokens can be counted; neither is the same as governing whether AI is producing good work. The Amazon case is a textbook L2 measurement failure: when the visible metric is occupancy, employees optimize for occupancy. Tokens consumed become a Goodhart's Law artifact, and the agentic security risk grows alongside the inflated numbers ("the default security posture terrifies me," one employee told the FT). Transitioning to L3 Engine requires named output owners and verifiable quality gates — what the work produced, not how much of it ran.
### Air Canada chatbot
*Level 2 (Sanctioned) accountability test: chatbots as legal subjects.*
**Case study 04 of 14: Air Canada chatbot**
*Level 2 (Sanctioned) accountability test: chatbots as legal subjects.*
**The problem**
In November 2023, Jake Moffatt asked Air Canada's customer-service chatbot whether bereavement-fare discounts could be claimed retroactively. The chatbot told him yes, citing a policy that did not exist. Moffatt booked a full-price flight to attend his grandmother's funeral. When he submitted the retroactive claim, Air Canada refused. The dispute reached the British Columbia Civil Resolution Tribunal in February 2024.
**The approach**
Air Canada's defense argued the chatbot was a "separate legal entity" responsible for its own statements, and that Moffatt should have verified the answer against the policy page hosted elsewhere on the airline's website. The argument was novel and it failed. The Tribunal held that Air Canada was responsible for all information on its website, including chatbot-generated information, and ordered the airline to pay the difference plus tribunal fees.
**The impact**
The ruling established the first widely-cited precedent that organizations cannot offload accountability for AI output to the tool itself. For organizations operating at Level 2 — sanctioned tools, no output governance — this is the structural exposure: every AI-generated statement to a customer is an unchecked commitment of the firm. Output governance — verification checkpoints, escalation paths, named owners for AI-customer interfaces — is not optional once a chatbot is producing legally consequential statements.
### Boom Supersonic
*Level 3 (Engine) success pattern: protocols designed alongside capabilities.*
**Case study 05 of 14: Boom Supersonic**
*Level 3 (Engine) success pattern: protocols designed alongside capabilities.*
**The problem**
Boom was developing the XB-1 demonstrator under aviation-safety expectations that allow zero tolerance for unexamined design changes. Each iteration on the structural model required stress, fatigue, aerodynamic, and material-tolerance validation before fabrication clearance. Boom needed to accelerate the loop without weakening the verification stack — and to explore hundreds of structural variants in the time conventional methods explore tens.
**The approach**
Boom built mkBoom, an internal tool that wrapped AI-assisted structural analysis around the existing verification stack. The AI did not replace any verification step; it accelerated the iteration loop feeding into it. The governance protocols — who owns which analysis, which checks must pass before fabrication, what evidence is preserved for certification — were designed alongside the capability, not added after a near-miss.
**The impact**
Boom's XB-1 reached supersonic flight in January 2025 with zero safety incidents across the program. The mkBoom workflow also surfaced Boomless Cruise — a flight regime in which the supersonic boom does not reach the ground under specific atmospheric conditions, recovered through AI-accelerated exploration of the structural envelope. When the blast radius is real hardware, protocols-with-capability is the only viable order: designing them after a failure costs more than the failure itself.
### Visicalc & Excel
*Level 1 (Shadow) substrate: a vernacular that emerged through pedagogy, not mandate.*
**Case study 06 of 14: Visicalc & Excel**
*Level 1 (Shadow) substrate: a vernacular that emerged through pedagogy, not mandate.*
**The problem**
By the late 1970s, business analysts performed structured calculations on paper, on calculators, or on bespoke mainframe programs maintained by IT departments with weeks-long lead times. The analyst who could think the model was rarely the one able to build it. Visicalc launched in 1979 as the first recalculating spreadsheet — written by Dan Bricklin and Bob Frankston for the Apple II — introducing a grid of cells with formulas referring to other cells.
**The approach**
Through three commercial transitions — Visicalc, Lotus 1-2-3, Excel — the file format evolved but the conceptual model did not. Rows, columns, cells, formulas, references: the vocabulary held. No central authority defined or governed it. Practitioners taught each other peer-to-peer; business schools wrote textbooks; managers hired analysts who knew the vernacular without specifying which product. The tool taught the method, and the method outlived three products.
**The impact**
By 2026 over a billion people operate through spreadsheet logic that nobody designed and no central authority approved. The L1 Shadow analogue is exact: an immensely productive substrate built by users for users, never sanctioned, never standardized at the top, but absorbed so completely into how work is done that it became invisible. The lesson for AI: substrates of this kind emerge through artifacts that teach the method, not through mandates that prescribe it.
### Gates's Internet Tidal Wave memo
*Level 2 (Sanctioned) sanction: ratifying cultivated practice already underway.*
**Case study 07 of 14: Gates's Internet Tidal Wave memo**
*Level 2 (Sanctioned) sanction: ratifying cultivated practice already underway.*
**The problem**
By early 1995, Microsoft was the dominant force in personal computing, organized around Windows, Office, and a vertically integrated server stack. The Internet — open protocols, browsers, hypertext — was not part of its product roadmap. Inside Microsoft, however, developer interest had been building for over a year: small teams were experimenting with web servers, browser prototypes, and TCP/IP-native tools, mostly outside official product lines. Without executive sanction, the projects could not draw the resources to ship.
**The approach**
On May 26, 1995, Bill Gates issued an internal memo titled "The Internet Tidal Wave" to senior staff, declaring "I assign the Internet the highest level of importance." The memo did not invent Microsoft's Internet capability — it ratified work that had been happening unofficially for fifteen months. Attached were specific product directives: a browser shipped with Windows, mail integrated with TCP/IP, a re-architected server stack. The force came from naming what was already happening.
**The impact**
Within two years Internet Explorer 1.0 shipped with Windows 95, Outlook and Exchange were repositioned around Internet protocols, and Microsoft was a credible Internet platform company. The case shows what effective Level 2 Sanctioned action looks like: it codifies what cultivation has already proved, channeling existing energy into formal direction. Sanction works when it ratifies; it fails when it mandates without underlying practice.
### Git & GitHub pull requests
*Level 3 (Engine) protocol: a designed workflow that outgrew its host.*
**Case study 08 of 14: Git & GitHub pull requests**
*Level 3 (Engine) protocol: a designed workflow that outgrew its host.*
**The problem**
In April 2005, BitKeeper — the proprietary version-control system the Linux kernel team had been using under a free-of-charge license — revoked the license after a reverse-engineering dispute. The kernel team needed a replacement that matched BitKeeper's distributed-workflow properties; nothing on the market did. Beyond Linux, the software industry ran on a patchwork of centralized version-control systems whose mental models did not match how distributed teams actually worked.
**The approach**
Linus Torvalds wrote Git in two weeks, optimizing for performance, distributed branching, and verifiable history. Git itself was a powerful but austere substrate — capable of any workflow but prescribing none. Three years later, GitHub introduced the pull request: a branch wrapped in a discussion thread with inline code review, status checks, and eventually CI/CD integration. The PR was not part of Git's specification; it was a designed protocol layered on top — a workflow people could see, comment on, approve, and audit.
**The impact**
By 2026 the PR workflow is the assumed professional standard for roughly 100 million developers across essentially every development environment, including ones that do not run on GitHub. The case shows the L3 Engine pattern at scale: a designed coordination protocol on top of a generic substrate, optimized to the point of becoming invisible. It also shows the cultivated-governed handoff working as intended — Git the open substrate, PRs the designed protocol; both necessary, neither sufficient.
### Walmart's EDI mandate
*Level 4 (Infrastructure) cascade: one big buyer's mandate becoming an industry baseline.*
**Case study 09 of 14: Walmart's EDI mandate**
*Level 4 (Infrastructure) cascade: one big buyer's mandate becoming an industry baseline.*
**The problem**
By the mid-1980s, retailers managed thousands of supplier relationships through paper purchase orders, faxed invoices, and phone-confirmed shipment notifications. Error rates at the supplier-retailer interface — wrong quantities, late shipments, duplicate invoices — were a significant fraction of margin. Each retailer had its own document formats; each supplier maintained custom paperwork per customer. Walmart, growing rapidly, found that coordination overhead capped its expansion rate.
**The approach**
In 1988, Walmart mandated EDI compliance using the X12 transaction set: adopt it, or lose Walmart's business. The mandate was paired with Walmart's own Bentonville distribution infrastructure, redesigned around the Advance Shipment Notification — a specific X12 message type that allowed receiving docks to plan for incoming shipments before they arrived. Walmart did not invent EDI; it required it, and made compliance valuable to suppliers (faster receiving, fewer disputes) rather than merely costly to refuse.
**The impact**
The protocol cascaded across retail within a decade. Suppliers required to use EDI for Walmart began using it elsewhere; competitor retailers added EDI requirements; ERP vendors built EDI tooling into their software. By 2026, roughly 95% of US B2B supply-chain document exchange runs on EDI variants. The case shows the L4 Infrastructure pattern: protocols at this level spread when one dominant actor enforces them against its trading partners, and the rest of the ecosystem follows because the cost of two standards is higher than the cost of one.
### McLean's container protocol
*Level 5 (Planetary) coordination: an artifact-defined protocol no one owns.*
**Case study 10 of 14: McLean's container protocol**
*Level 5 (Planetary) coordination: an artifact-defined protocol no one owns.*
**The problem**
Through the 1950s, freight moved between ship, rail, and truck through "break-bulk" handling — workers physically transferring barrels, crates, bales, and boxes at every transition point. Loading a ship took days; unloading at the destination port took days more. Theft was endemic, damage frequent, and the dwell time of a single shipment measured in weeks. The bottleneck was not transportation but the handoff between modes.
**The approach**
On April 26, 1956, trucker Malcolm McLean sailed the SS Ideal X from Newark to Houston with 33 standardized metal boxes — containers — lifted directly from trucks onto the ship and back. The container itself was the protocol: fixed-dimension, lockable, stackable, reusable, designed so cargo never had to be touched between origin and destination. The standard hardened in stages: McLean's company published dimensions; competitors adopted them; ISO 668 codified 20- and 40-foot TEU dimensions in 1968.
**The impact**
By 2026 approximately 90% of non-bulk world trade moves via containers. The protocol made coordination cheap and uniform across every jurisdiction and mode. It also concentrated the failures: the system depends on five geographic chokepoints — Suez, Panama, Malacca, Hormuz, Bab el-Mandeb — whose vulnerability was made visible by events like the 2021 Suez Canal blockade. The L5 Planetary lesson: when a protocol becomes infrastructure for the world, coordination is cheap and legibility becomes the new governance challenge.
### Rural users and the Model T
*Level 1 (Shadow): when users invent uses the manufacturer never imagined.*
**Case study 11 of 14: Rural users and the Model T**
*Level 1 (Shadow): when users invent uses the manufacturer never imagined.*
**The problem**
When Ford launched the Model T in 1908, it was designed as urban transportation. Rural America had a different problem: small farms needed power for threshing, sawing, water-pumping, washing, and churning. Buying a dedicated stationary engine for each task was prohibitively expensive. The technology was widely available; the use case that mattered to half of Ford's customers wasn't visible to the manufacturer.
**The approach**
Rural users improvised. Owners jacked Model Ts onto blocks and ran belts off the rear wheels to drive threshing machines, washing machines, water pumps, fodder cutters, and circular saws. Third-party accessory makers shipped kits (the "Stationary Hoister"); farm magazines documented dozens of unauthorized uses by the 1920s. Ford initially resisted, then gradually acknowledged the use cases in marketing materials and parts catalogs, redesigning later models to support them.
**The impact**
The kit-phase pattern Kline & Pinch document is structural: user adaptation precedes manufacturer recognition by years. Value is generated by users in ways the supplier doesn't anticipate; the supplier's eventual job is to harvest and standardize what users invented. The same pattern is operating today around AI — practitioners are using AI for purposes their employers haven't sanctioned. The organizational job is to surface those uses (Kit Harvesting), not suppress them.
### American steam adoption, 1820–1900
*Level 2 → Level 3: firms make the architectural commitment to a new paradigm for what it enables, not for what it makes cheaper.*
**Case study 12 of 14: American steam adoption, 1820–1900**
*Level 2 → Level 3: firms make the architectural commitment to a new paradigm for what it enables, not for what it makes cheaper.*
**The problem**
American factories in the 19th century had a recurring choice between two prime movers. Water power had been the standard since the early industrial period — abundant, well understood, and, in most parts of the country, measurably cheaper per horsepower than steam. Cost simulations by Atack, Bateman, and Weiss show that water was the lower-cost option in New England, the Middle Atlantic, and the South for most of the century. Yet steam adoption climbed steadily anyway. By 1900, steam engines outnumbered water sources four to one. The cost ledger and the adoption pattern were pointing in opposite directions, and the gap held for decades.
**The approach**
Atack and his coauthors traced what firms actually chose, region by region, between the 1820s and the 1890s. The pull toward steam wasn't operating cost — it was locational freedom. A water-powered factory had to sit by the water; a steam-powered one could sit anywhere, including next to railroads and urban labor pools. Pittsburgh and Cincinnati adopted steam earlier than Boston because the eastern rivers were already worked. Augusta, Georgia, had ample water power but was over 100 rail miles from major urban markets, and never became a manufacturing center. Having the input wasn't enough.
**The impact**
American manufacturers paid a premium for steam for most of a century. They were paying for capabilities the cost-per-horsepower table didn't capture: where a factory could sit, how large it could grow, who it could hire, how it could ship. There's a recognizable echo here for organizations evaluating AI adoption now. When teams compare AI's cost to the cost of the work it might replace, the math often looks marginal or worse, and the natural conclusion is to wait. The historical pattern suggests a complementary question worth asking alongside the cost one: what becomes newly possible? Work that was previously out of economic reach, problems that couldn't be attempted at all, customers or markets that weren't addressable at the firm's prior scale. Adoption often makes sense when the answer to that question is concrete, even in cases where the cost comparison on its own doesn't make the case.
### Factory electrification, 1880–1930
*Level 2 → Level 3: the 30-year lag between substitution and architectural redesign.*
**Case study 13 of 14: Factory electrification, 1880–1930**
*Level 2 → Level 3: the 30-year lag between substitution and architectural redesign.*
**The problem**
Through the 19th century, factories were powered by central steam engines driving overhead line shafts and belt drives to each machine. The architecture imposed constraints: machine placement followed shaft geometry, multi-story buildings minimized shaft runs, whole-plant on/off operation, 25–40% friction losses, blocked windows from overhead shafts. When electric motors became commercially available in the 1880s, the obvious move was to swap the prime mover.
**The approach**
Devine documents three phases. (1) Group drive (1890s–1910s): the steam engine was replaced with a large electric motor, but the line shaft, belts, and machine placement remained unchanged. By 1919, 53% of US installed manufacturing horsepower was electric. (2) Unit drive (1910s onward): a dedicated motor at each machine, sized to its load, with wiring replacing the iron shaft. Factory layout finally followed workflow, not shaft geometry. (3) Architectural redesign: single-story buildings (Ford's River Rouge, 1928), sawtooth roofs for daylight, integrated conveyors, 40–50% reductions in energy per unit output.
**The impact**
US manufacturing TFP grew under 1% per year through the group-drive era (1899–1919) and ~5% per year in the unit-drive era (1919–1929). The productivity boom of the 1920s was the payoff of architectural redesign, not of electrification per se. Substituting the power source without redesigning the layout captured almost none of the available gains. Most current AI deployments are at the equivalent of group drive — the technology is installed, the workflow is unchanged, and the productivity hasn't materialized. The L2 → L3 transition is what closes the gap.
### Harpers Ferry and the American System
*Level 3 → Level 4: the institutional substrate behind "interchangeable parts."*
**Case study 14 of 14: Harpers Ferry and the American System**
*Level 3 → Level 4: the institutional substrate behind "interchangeable parts."*
**The problem**
Eli Whitney's 1798 federal contract for muskets promised interchangeable parts — pull any lock, any barrel, any stock from a pile and they fit. The marketing claim was repeated through the early 19th century. The actual practice was different: parts were fitted individually by skilled file-and-fitter armorers, and each musket was effectively bespoke. The technology label existed; the operating practice didn't.
**The approach**
Merritt Roe Smith's history of Harpers Ferry Armory (1798–1860s) documents a long institutional development. Federal armory contracts created a sustained customer that insisted on uniformity. Machine tools were developed in-house (milling machines, pattern lathes, gauges). Inspection protocols co-evolved with the machines. Workers were retrained — gauge-using inspectors replaced file-and-fitters. The social order of the armory changed alongside the technical order. By the 1850s, the American System of Manufactures could be demonstrated at the London Crystal Palace Exhibition, three decades after the rhetoric began.
**The impact**
Industry-scale uniformity required the full institutional substrate to mature, not just the technical capability. The same is operative for L4 Infrastructure today: stating a standard isn't the same as having the inspection regimes, training systems, and shared assumptions that make the standard actually hold. Organizations claiming AI standardization without that institutional substrate are repeating Whitney's marketing claim, not Harpers Ferry's actual practice.
### Every node and every edge of how work moves is now AI-mediated
### Finding the right artifact for a given technology
*The artifact that matches the framing. AI sits in the Paradigm × Planetary quadrant — the artifact that fits it is an Adoption Guide.*
- **Practice Playbook** — e.g., MRI. *AI counterpart:* Vibe-Coding
- **Adoption Guide** — e.g., electricity, the internet. *AI counterpart:* Commoditized Generative Software
- **Implementation Roadmap** — e.g., Figma. *AI counterpart:* Helpdesk Chatbot
- **Deployment Plan** — e.g., Microsoft Office. *AI counterpart:* Claude Code
### AI Adoption Assessment
*24-question diagnostic that places your organization on the maturity ladder and surfaces your dominant archetype.*
A 24-question diagnostic. Each question is a binary choice between two statements — answer the one that better describes your organization. The combined pattern places you on the maturity ladder (L1–L5) and surfaces a dominant archetype.
#### Questions
**Q1.**
- a. If AI technology stopped working tomorrow, our product would stop working too.
- b. If AI technology stopped working tomorrow, our work would slow but continue.
**Q2.**
- a. People outside our team interact with the AI capabilities we deploy.
- b. The AI capabilities we deploy are invisible to anyone outside our team.
**Q3.**
- a. If our main AI capability vendor changed pricing, it would have no impact on our offering.
- b. If our main AI capability vendor changed pricing, we would change our offering.
**Q4.**
- a. We've invested in dedicated AI talent (hired or developed) for our function.
- b. We expect existing staff to learn AI skills as part of their regular work.
**Q5.**
- a. Our AI tools keep producing useful outputs as our data and work evolve.
- b. We regularly update our AI tools to stay aligned with our business.
**Q6.**
- a. A senior specialist with domain knowledge reviews critical AI outputs.
- b. AI outputs are reviewed by generalists or pass through automated checks.
**Q7.**
- a. Our AI handoffs follow industry standards.
- b. Our AI rules apply only inside our company.
**Q8.**
- a. We deploy new AI use cases before most peers in our industry.
- b. We deploy new AI use cases after peers have proven them.
**Q9.**
- a. When AI changes require it, we adapt — including reversing AI deployments.
- b. When we deploy AI visibly, we don't usually need to walk it back.
**Q10.**
- a. Our own investment priorities set the pace of AI adoption.
- b. Regulation or compliance review sets the pace of AI adoption.
**Q11.**
- a. When we delay AI deployment, it's because we're choosing to wait for proven maturity.
- b. When we delay AI deployment, it's because external rules require it.
**Q12.**
- a. Our AI approach came from leadership first.
- b. Our AI approach came from teams first.
**Q13.**
- a. We have a current inventory of the AI tools each team uses.
- b. We periodically learn about new AI tools other colleagues have adopted.
**Q14.**
- a. Our business existed before AI; we added AI to it.
- b. AI is why our business exists; there's no non-AI version of it.
**Q15.**
- a. Our dominant AI posture is building internal infrastructure multiple teams depend on.
- b. Our dominant AI posture is selectively deploying AI use cases that are already proven.
**Q16.**
- a. Our AI experimentation runs many concurrent pilots to figure out what works.
- b. Our AI experimentation picks specific use cases proven by peers before deploying.
**Q17.**
- a. Most of our informal AI use is many people doing everyday tasks.
- b. Most of our informal AI use is a few people doing sophisticated work.
**Q18.**
- a. Multiple teams across our org run on the same internal AI platform.
- b. Each team picks its own AI tools; there's no shared platform.
**Q19.**
- a. Our main AI deployment criterion is whether the value case is proven.
- b. Our main AI deployment criterion is whether compliance review clears the use.
**Q20.**
- a. We're deploying AI with the tools that exist today.
- b. We're waiting for the next generation of AI tools before we deploy.
**Q21.**
- a. Our AI documentation is current enough to hand off to a new team member.
- b. Our AI work is carried by a few people's practical knowledge.
**Q22.**
- a. Our AI capability is held mostly by our internal team.
- b. Our AI capability is held mostly by external partners we contract with.
**Q23.**
- a. Our AI roadmap follows our own internal priorities and timeline.
- b. Our AI roadmap follows what our vendor or partner ships.
**Q24.**
- a. Our team uses AI tools as part of how we do our work.
- b. Our team has never used or heard of AI tools.
#### Maturity-level outcomes
##### L1 — Shadow
*AI is in use. The organization doesn't know how, by whom, or with what data.*
Your organization is at the default starting position — not a failure, but a baseline every organization passes through. AI tools are in active use through employee initiative. No organizational decision has authorized them. Individual workers use personal accounts for work tasks. No policy governs this, no tooling controls it, and no one has a complete picture of what organizational data is being submitted to which systems. The absence of a governance protocol is itself invisible: organizations don't feel like they're at Level 1 because nothing has gone wrong yet. The typical organization is at Level 1 for 400+ days before a shadow AI incident surfaces. Shadow adoption is the observable signal that existing work protocols have been pushed beyond their design range. The protocol response (sanctioned access, data boundaries, reviewed terms) has not yet been adopted.
**Failure modes:**
- **Data leakage to third-party AI services** — Employees submit proprietary source code, meeting transcripts, patient data, client information, or trade secrets to consumer AI services via personal accounts. The data cannot be recalled. IP exposure is permanent. Samsung, April 2023: three engineers, three incidents, one month.
- **Regulatory exposure without awareness** — Data submitted to external AI services creates HIPAA, GDPR, attorney-client privilege, or trade secret exposure that the organization cannot detect or quantify. Discovery typically occurs 400+ days after initial exposure — long after the data has been processed. Healthcare sector: 86% of organizations have reported shadow AI incidents; only 35% can track their own AI usage. (symplr, 2025)
**Next actions:**
- **Conduct an AI tool inventory** — Identify which AI tools are in use, by which teams, on which account types (personal vs. enterprise). Visibility is the goal: which tools, which teams, which account types. *Done when: IT can name all AI tools in active use and the account type for each.*
- **Sanction at least one AI tool with reviewed terms of service** — Designate one enterprise AI tool with legal review of data handling terms completed. Communicate it as the governed alternative to personal accounts. *Done when: At least one AI tool has reviewed terms of service and has been communicated as the sanctioned option.*
- **Issue a minimum data boundary policy** — State what categories of data may not be submitted to external AI services. One page is sufficient. This is a data boundary statement — scope it narrowly and communicate it clearly. *Done when: Policy exists, has been communicated, and names specific data categories.*
##### L2 — Sanctioned
*The organization has granted AI access. It hasn't designed what to do with it.*
Your organization has done the right thing: granted broad AI access and signaled strategic commitment. The failure mode at this level is executing the mandate without designing the governing protocol — which tasks, with what review process, what quality standard, what escalation path when AI fails. Two dynamics characterize Level 2. First, the Time to Mediocrity effect: AI produces functional output quickly in most domains, creating genuine early productivity gains while concealing the absence of expertise. Second, the financial indicator lag: strong financial metrics accumulate at the same time as governance failures, making the governance gap invisible until failures become external-facing. Level 2 organizations typically achieve high adoption rates and real early gains — then encounter a quality floor that the absent governance layer cannot address.
**Failure modes:**
- **Quality floor collapse** — AI replaces a human step that was simultaneously a production step and a quality-check step. Production volume increases; the quality check disappears. The gap is invisible in output volume metrics and visible in product quality or customer satisfaction. Failures surface when external parties (customers, courts, regulators) raise them — internal monitoring does not catch them first. Klarna reversed course after financial results were already strong.
- **Mandate without criteria** — Leadership issues an AI competency requirement with no defined standard for compliance. Employees perform AI use to satisfy the mandate rather than integrating it meaningfully. The reported adoption rate is high; the governance maturity is unchanged. Shopify, April 2025: AI non-optional, no competency definition published for non-technical roles.
- **Chatbot liability gap** — An AI system deployed in external-facing or legally consequential functions provides information that contradicts the organization's formal policy. External parties hold the organization responsible regardless of internal disclaimers. Air Canada: chatbot stated bereavement fares could be claimed retroactively; actual policy did not permit this; court ruled Air Canada liable.
- **Policy/practice gap** — Practiced management allows contextual exceptions that written policy does not. When AI systems enforce written policy uniformly, the exceptions disappear. The organization discovers its formal policy was not its actual policy — and that employees, customers, and partners had been operating on the practiced version. AI removes the judgment layer that bridged the two.
**Next actions:**
- **Design one AI-native workflow end-to-end** — Select a function where AI is already in use. Document the full workflow: what AI does, what the human reviews, what constitutes acceptable output, and what the escalation path is for failures. Build a working implementation with live data. *Done when: One workflow is documented, repeatable, and has a named owner.*
- **Instrument quality for that workflow** — Define a metric that captures output quality, not just output volume. Track it. Assign ownership. The metric must be specific enough that a failure in the workflow produces a change in the number. *Done when: A quality metric exists, is tracked on a defined cadence, and triggers a defined response when it falls below threshold.*
- **Build a minimum output review protocol** — For AI-generated outputs that go to external parties or govern consequential decisions: specify who reviews, what they check, and what constitutes an acceptable output. This is workflow-specific guidance — what to check and who is responsible. *Done when: Reviewers in at least one workflow can state what they're checking and why.*
##### L3 — Engine
*AI workflows are designed, not improvised. The business model depends on them.*
Your organization has crossed from AI adoption into AI dependency: your competitive position relies on designed AI workflows. AI governs core operations. Workflows are built around AI rather than retrofitted to include it. The governance question has shifted: you are designing protocols that handle failure, versioning, and external dependencies without losing the speed advantage AI provides. Domain expertise is the limiting constraint — the knowledge required to specify what good output looks like in your specific context. Two operators with domain knowledge can run sophisticated AI production pipelines if they can articulate the coordination protocol clearly.
**Failure modes:**
- **Schedule dislocation breakdown** — AI accelerates internal production faster than external dependencies can absorb. Review queues fill faster than reviewers can process them. The bottleneck has moved from production to coordination. Slacker Index: measure total lead time divided by actual AI working time. A ratio above 5:1 identifies downstream coordination as the bottleneck. Uber: 11% of pull requests opened by agents; code review became the primary bottleneck, requiring purpose-built tooling. (Venkatesh Rao / Protocolized, 2026)
- **Ontological drift** — Mid-project redefinition of the concepts, categories, or ontologies that AI systems depend on becomes extremely expensive. AI systems encode prior definitions into outputs, training data, and prompt structures. Changing a definition requires auditing and revising everything downstream. Organizations attempt agile-style iteration on definitions that should have been frozen.
- **Governance brittleness under versioning** — AI model updates or tool switches silently alter output characteristics that the governance protocol was calibrated for. A review process designed for one model's failure modes may not catch the same failures in the next model's outputs. The governance protocol is not versioned along with the tools it governs.
- **Custom implementation accumulation** — Internal AI capability builds custom solutions that solve specific problems but never abstract into reusable platform features. The organization carries Level 3 complexity without the organizational platform to support it: each new use case requires a new custom build, and standardization becomes politically impossible because every team owns its own implementation.
**Next actions:**
- **Measure and address schedule dislocation** — Calculate the Slacker Index for your primary AI workflow: total lead time ÷ AI working time. Where the ratio exceeds 5:1, identify the downstream coordination bottleneck (review queue, approval chain, handoff delay) and redesign the coordination protocol. *Done when: Slacker Index below 5:1 for primary workflow; bottleneck owner named.*
- **Define and freeze the domain ontology before deployment** — Name the concepts, categories, and definitions that AI systems will depend on. Establish a change process — not preventing change, but making changes deliberate and triggering downstream audits when they occur. *Done when: Core domain concepts used by AI systems are documented and have a defined change process.*
- **Build a platform feedback loop** — When custom AI work is built for a specific use case, evaluate whether it can be abstracted into a reusable platform feature. If not, document why not. This prevents custom implementation accumulation. *Done when: A review process exists for new AI implementations that includes a platform abstraction evaluation.*
##### L2–3 — Sanctioned → Engine
*You have the foundations of Level 3. Consistency and measurement are missing.*
Your organization is at the transition between Level 2 and Level 3. At least one workflow is designed — you have demonstrated that AI-native workflow design is possible in your context. What's missing is consistency across workflows and a quality measurement system that makes the governance protocol durable and repeatable across the organization. This is a common and productive stuck point. The risk is that the designed workflows become isolated examples while the rest of the organization continues operating at Level 2. The Level 2 failure modes — quality floor collapse, mandate without criteria — remain live risks in the undesigned workflows.
**Failure modes:**
- **Quality floor collapse (in undesigned workflows)** — The designed workflows are protected; the undesigned ones are not. Quality floor collapse is most likely to surface in the workflows that haven't received the same design attention — which are often the ones that handle higher volume or lower-visibility tasks.
- **Mandate without criteria** — Leadership issues an AI competency requirement with no defined standard for compliance. Employees perform AI use to satisfy the mandate rather than integrating it meaningfully. The designed workflows exist as exceptions; the rest of the organization is still operating on compliance theater.
- **Custom implementation accumulation** — Early designed workflows become custom solutions that never abstract into reusable patterns. The organization carries Level 3 complexity without Level 3 scope: each new workflow requires a new custom build, and standardization becomes politically difficult because every team owns its own implementation.
**Next actions:**
- **Extend the designed workflow to one more function** — Take the workflow design approach that worked in the first function and apply it to the next highest-stakes AI workflow. Document the pattern, not just the implementation — so it can be replicated without requiring the same level of effort each time. *Done when: Two workflows are documented, owned, and tracked with quality metrics.*
- **Instrument quality for the designed workflows** — Define a metric that captures output quality, not just output volume. Track it. The metric must be specific enough that a failure in the workflow produces a change in the number. *Done when: Quality metrics exist for at least two workflows, tracked on a defined cadence, with a defined response when they fall below threshold.*
##### L3–4 — Engine → Infrastructure
*Your organization is at the leading edge. The next challenge is sector-level, not organizational.*
Your organization is at the boundary between Level 3 and Level 4. Multiple core AI workflows are designed, governed, and versioned. Your practices are mature enough that industry peers reference them as a benchmark. The organizational-level governance challenges are substantially addressed. Level 4 emerges when the aggregate of Level 3 organizations reaches density sufficient to recalibrate the sector's productivity baseline. No single organization drives this transition. The governance questions at Level 4 are market-structural: how does the industry coordinate AI use, handle shared risks, establish standards, and prevent concentration of AI capability in ways that produce anti-competitive outcomes. Individual organizational maturity is necessary but not sufficient at Level 4.
**Failure modes:**
- **AI capability concentration** — Early AI leaders accumulate proprietary data, model advantage, and talent that create structural moats. Late-adopting organizations cannot compete at AI-standard productivity. The industry stratifies into a small tier of AI-native leaders and a permanently disadvantaged tier — unless sector-wide governance prevents moat-building.
- **Commoditization pressure** — AI capability becomes table stakes, eliminating the competitive moat built by early adopters. The organization has invested significantly in building Level 3 practices; the return on that investment compresses as Level 3 becomes the baseline expectation. Competitive advantage shifts to the next abstraction: model training quality, proprietary datasets, agentic workflow design.
- **Custom implementation accumulation** — Internal AI has built custom solutions that solve specific problems but have not abstracted into reusable platform features. At the boundary of Level 4, this becomes a liability: the organization cannot contribute to or benefit from sector-wide standards because its implementations are too proprietary.
**Next actions:**
- **Crystallize domain knowledge into explicit specifications** — Document what good output looks like, what constitutes an acceptable AI error in your domain, and who has the domain expertise to judge. Domain knowledge is the limiting constraint at Level 3 — not AI capability. These specifications become the input to sector-level governance standards. *Done when: Quality criteria for primary AI workflows are documented and attributable to named domain experts.*
- **Build a platform abstraction layer** — Evaluate which custom AI implementations can be abstracted into reusable organizational platform features. This positions the organization to contribute to or comply with sector standards without requiring a full rebuild. *Done when: An internal AI platform exists that new implementations can draw on rather than building from scratch.*
#### Archetypes (10)
##### The Vanguard
> *"Someone has to go first. We'd rather learn hard than wait safe."*
**Core strategic bet:** First-mover advantage compounds faster than reversal risk compounds loss.
**Examples:** Klarna (2024–25 AI-agent arc: mandated, reversed, rebuilt). Duolingo (AI-first content, user headwinds). Shopify (Lütke 'AI is non-optional' memo).
The Vanguard deploys AI aggressively in customer-facing and core operational work before governance is ready. They retrofit AI into an existing organization because they believe leadership conviction matters more than waiting for external validation. Public mandates; explicit policy shifts; visible executive commitment. The bet is asymmetric — some deployments will roll back publicly, but the ones that stick compound. They treat reputational exposure as the price of not being late, and they absorb the criticism of specialists whose judgment was bypassed in the pursuit of speed.
**Strengths:** Organizational alignment — leadership has taken a clear public position; Forced learning under real conditions (no hiding in pilot-land); Captures compounding advantages unavailable to orgs waiting for proof; Talent magnet for ambitious practitioners who want the leading edge
**Challenges:** Governance lags deployment; fixes are reactive and publicly visible; Customer-facing quality incidents (the Klarna reversal pattern); Internal backlash from domain specialists whose judgment was overridden; 'Evaluative anesthesia' — so much is produced so fast that quality signal degrades
**Healthy:** Moves fast, learns fast, retrofits governance as issues surface.
**Unhealthy:** Moves fast, reverses publicly, replaces the CEO.
**Blind spot:** Underestimates how much of the early 'success' was goodwill from stakeholders who expected eventual refinement, not production-grade polish.
**Under stress:** Compresses toward The Ratifier — a reversal crisis can trigger overcorrection into slowdown and heavy governance, sometimes overshooting into paralysis.
**Growth direction:** Evolves toward The Integrator — retrofits governance to match deployment footprint, codifies what worked, retires what didn't.
**Evolutionary path:** Vanguards emerge from confident, opinionated leadership with strong AI conviction. They become Integrators if the retrofit succeeds; they become Ratifiers if a crisis forces a defensive reset.
##### The Traveller
> *"We didn't add AI to our business. AI is why the business exists."*
**Core strategic bet:** A clean-sheet organization can outcompete incumbents retrofitting AI into legacy structures.
**Examples:** Boom Supersonic (mkBoom engineering stack). Cursor. AI-native fintechs (Ramp, Brex adjacents). Logistics and customer-service operating-model rebuilders.
The Traveller built the organization around AI from inception. The business doesn't function without AI — the product either creates capability that wasn't reachable before (market-creating) or rebuilds an existing market with a 3–5× leaner operating model (service-rebuilding). Protocols for validation, ontological stability, and domain-expert review are engineered alongside capability, not after an incident forces them. Travellers typically run with smaller headcount than revenue-equivalent incumbents and attract practitioners who want to work where AI isn't a bolt-on.
**Strengths:** No legacy baggage — every workflow is clean-sheet; Governance designed into product architecture, not layered on top; Capital-efficient operating model (talent structure built for AI); Customers understand AI is the product, not a feature; expectations are calibrated
**Challenges:** Fragility if underlying foundation models shift unexpectedly; Talent concentration — founders often hold critical judgment that can't yet delegate; Defensibility as incumbents close the gap with retrofit investment; Scaling past early product-market fit into a durable institution
**Healthy:** The team builds a real institution with distributed judgment.
**Unhealthy:** AI-native team stays founder-dependent and never becomes a company.
**Blind spot:** Assumes the AI-native operating model is always faster — misses that some incumbent advantages (distribution, trust, data) aren't catchable by structural cleverness alone.
**Under stress:** Travellers don't disintegrate toward another archetype. They either iterate their way out or fail as companies; the form doesn't flex into Integrator or Architect because those require a different origin story.
**Growth direction:** Widens AI-specific governance into broader operating protocols as the org scales; deepens coordination scope toward industry partnerships and standards.
**Evolutionary path:** Travellers don't transition — they scale within their form. An enterprise that retrofits successfully becomes an Integrator or Architect, not a Traveller. Travellers are topologically isolated on the archetype map.
##### The Architect
> *"We're not chasing the latest model. We're building the platform our teams will run on for years."*
**Core strategic bet:** Internal AI infrastructure compounds as an economic moat — every rapid iterator's failed experiment feeds the platform's improvement.
**Examples:** Uber (four-layer platform architecture, 84% developer agentic adoption). BBVA (4000+ custom GPTs). Frontier orgs from OpenAI's State of Enterprise AI report (6× internal AI messaging volume vs. median).
The Architect invests in internal AI infrastructure that multiple teams depend on. They treat validation, governance, and monitoring as engineered constraints built into the platform rather than policy layered on top. Capital-intensive and slow to market. The reward is institutional-scale evolution — platforms outlast leadership transitions, and upstream signal capture creates a moat that competitors without comparable investment can't replicate. Platform teams hold specialist AI expertise while product teams consume it through clean abstractions.
**Strengths:** Institutional-scale durability — the platform outlasts executive tenures; Economies of scope across many internal use cases; Governance is invisible to users (built into tooling, not policy); Signal-capture moat — upstream absorption of every team's iterative exhaust
**Challenges:** Slower time-to-market than startups or Vanguards; Capital-intensive; requires sustained executive sponsorship across budget cycles; Internal coordination overhead (platform teams can become bottlenecks); Platform can lag the model frontier if not actively refreshed
**Healthy:** Platform accelerates product teams; governance is felt as leverage, not friction.
**Unhealthy:** Platform becomes a gate that slows the teams it was supposed to accelerate.
**Blind spot:** Undervalues speed. Assumes time is on their side because the platform compounds — misses moments when a competitor's non-platform speed captures a market before the platform's advantages matter.
**Under stress:** Compresses toward The Broker — under budget cuts, the platform gets outsourced to vendors and the institutional advantage dissolves.
**Growth direction:** Expands coordination scope into inter-organizational standards; moves toward L4 Infrastructure where the platform becomes a sector-wide baseline.
**Evolutionary path:** Architects emerge from Integrators who realize multi-team coordination requires infrastructure, or from successful Travellers widening their scope. They tend to remain Architects once at scale; the transitions away are usually crises.
##### The Integrator
> *"We're not first. We're not lost. We adopt where it pays and redesign when it matters."*
**Core strategic bet:** Evidence-driven selection yields higher ROI per deployment than speculative first-moves, and workflow redesign (not just tool-layering) is where the real leverage lives.
**Examples:** Accenture 'AI Achievers' (≈12% of enterprises). McKinsey 'high performers' (3× more likely to fundamentally redesign workflows). Most mature enterprises with visible, disciplined AI programs.
The Integrator deploys AI selectively where value is demonstrable, then redesigns workflows around the proven use rather than layering AI on existing processes. They wait for external evidence — competitor deployments, regulator guidance, vendor case studies, published results — before committing. Measured, evidence-driven, not first but not lost. The central basin of the archetype map: most healthy evolutionary paths converge here before continuing toward Architect. When Integrators execute, they capture real value; when they drift, they accumulate 'under evaluation' backlog without corresponding deployment.
**Strengths:** High ROI per deployment (selection is strict); Organizational trust — workflow changes are visible and explicable; Knowledge transfer scales (codified workflow patterns propagate); Adaptable to model-frontier shifts without business disruption
**Challenges:** Slower than first-movers; some compounding advantages went elsewhere; 'Evidence-waiting' can become a permanent excuse for inaction; Workflow redesign requires sustained change management that often underdelivers; Proliferation risk — many small wins without platform investment creates sprawl
**Healthy:** Selective, rigorous, compounding through workflow redesign.
**Unhealthy:** Selective becomes paralytic; pilots never convert to standard practice.
**Blind spot:** Believes 'waiting for evidence' is always the rational choice — misses that some evidence only emerges after your own deployment generates it.
**Under stress:** Compresses toward The Warden — external pressure (regulatory, reputational, market) freezes deployment as compliance reviews multiply.
**Growth direction:** Evolves toward The Architect — invests in platform to scale the workflows; the natural next move when deployment count crosses a coordination threshold.
**Evolutionary path:** Integrators come from Vanguards (post-retrofit), Tinkerers (post-codification), Wardens (post-regulatory-clarity), or Brokers (post-internalization). They become Architects when scale demands it.
##### The Tinkerer
> *"We don't know what will work until we try it. So we try a lot of things."*
**Core strategic bet:** Generating own evidence via high experimentation volume beats waiting for external proof in markets that reward speed.
**Examples:** Scaleups and fast-moving mid-size orgs. Small product pods inside larger enterprises given freedom to experiment. Early-stage AI-adjacent (not AI-native) product teams.
The Tinkerer generates its own evidence through volume. Many small experiments run in parallel; few are codified yet. They move ahead of proof because their markets reward experimentation, and waiting for external validation means losing ground. A transient state by design: with discipline, Tinkerers become Integrators; with scale, they become Vanguards; without either, they dissolve back into Folkways. The discipline that matters is not starting experiments but retiring them — the signature Tinkerer failure mode is accumulating pilots without a retirement cadence.
**Strengths:** Pattern recognition across many real attempts (not theoretical); Low cost per experiment — scale is small, reversibility is high; Practitioner culture attracts hands-on talent; Fast feedback loops; evidence comes from own work, not literature
**Challenges:** Codification gap — what works doesn't become standard practice; Coordination overhead as concurrent experiments multiply; Hard to separate signal from noise across many small pilots; 'Innovation theater' risk — looks active but doesn't converge
**Healthy:** Disciplined experimentation that converges on codification.
**Unhealthy:** Perpetual experimentation that never commits.
**Blind spot:** Treats starting new experiments as progress, underestimates that retiring experiments is the real sign of discipline.
**Under stress:** Compresses toward The Folkway — under resource pressure, experiments continue individually but stop being tracked or centrally evaluated.
**Growth direction:** Evolves toward The Integrator — codifies what works into standard practice. The single most important move is retiring experiments as deliberately as starting them.
**Evolutionary path:** Tinkerers come from Folkways (when leadership starts tracking what's emerging) or from scaleup-stage adoption. They become Integrators via codification or Vanguards via scale. Without either, they dissolve back into Folkway.
##### The Ratifier
> *"We don't surf the first wave. We ship the one that lasts."*
**Core strategic bet:** The second wave, well-executed, outlasts the first.
**Examples:** Apple (historical posture across emerging technology categories; current AI stance). Risk-averse incumbents in consumer categories where brand trust is foundational. Institutional cultures that privilege polish over priority.
The Ratifier defers deployment by strategic choice, not constraint. They wait for vendor consolidation, regulatory clarity, and use cases proven at scale by others. When they move, they deploy at higher polish than the early-movers who preceded them — trading early-market compounding for late-market quality. The bet is that the second wave, executed well, outlasts the first. Easy to confuse with paralysis from the outside; the distinguishing feature is a clear (if private) entry criterion. Apple's historical pattern is the canonical shape — and also the canonical reminder that Ratifiers can overstay their waiting posture.
**Strengths:** Deployment polish — their AI feels finished where others feel rough; Avoids public learning costs others absorbed; High trust with existing customers (no brand dilution from crapjects); Capital discipline — no wasted spend on tools that didn't survive
**Challenges:** Missed differentiation windows that went to earlier movers; Talent risk — practitioners want to work where the frontier is; Late-arrival inertia — hard to recalibrate when the moment arrives; Indistinguishable from paralysis without a clear entry criterion
**Healthy:** Deliberate timing with a clear trigger; ships polished second-wave product.
**Unhealthy:** The trigger keeps moving; late becomes never.
**Blind spot:** Assumes polish compounds faster than time-in-market experience does — misses that second-movers rarely out-execute first-movers once those first-movers have iterated under real conditions.
**Under stress:** Compresses toward The Broker — under competitive pressure, outsources the capability entirely to avoid committing too late.
**Growth direction:** Evolves toward The Integrator or The Architect when they finally move with a clear trigger.
**Evolutionary path:** Ratifiers emerge from institutional cultures that privilege polish and brand (Apple-shape). They become Integrators or Architects when they move; rare to transition back. The dangerous path is stalled Ratifier → Broker permanently.
##### The Warden
> *"Our industry doesn't move until the regulator does. That's the job."*
**Core strategic bet:** Compliance-ready infrastructure creates a competitive moat in regulated verticals (1.5–2× valuation premium for compliance-mature assets).
**Examples:** EU banks, insurers, and financial-services firms under the AI Act. Healthcare organizations under HIPAA-adjacent frameworks. Public-sector agencies with mandated deployment reviews. Vertical-specific regulated industries (pharma, defense, utilities).
The Warden gates deployment on regulatory approval. Compliance isn't a byproduct of their AI strategy; it's the operating posture. EU AI Act, HIPAA-adjacent frameworks, financial-services model governance, sector-specific audit regimes — the regulator sets deployment velocity. This can be a real strategic advantage in regulated verticals where compliance-mature infrastructure is hard to replicate. The underlying risk is that the regulatory clarity they're waiting for may arrive too late or too ambiguously, and meanwhile internal frustration produces shadow adoption — a Folkway forming quietly underneath the Warden posture.
**Strengths:** Compliance as moat — raises the barrier to entry for less-regulated competitors; High protocol specificity creates durable institutional knowledge; Trust premium with regulated customers and auditors; Risk-adjusted deployment — customer-facing AI incidents are rare
**Challenges:** Regulatory uncertainty means deployment planning is always contingent; Talent flight to less-regulated competitors; Internal frustration drives shadow adoption (Folkway forming beneath); Compliance infrastructure becomes a permanent brake even after regulation clarifies
**Healthy:** Compliance posture as active strategic advantage, with deployment ready to move when regulation clarifies.
**Unhealthy:** Compliance as reason not to decide anything.
**Blind spot:** Assumes the regulator is the binding constraint, misses that internal compliance culture often continues to gate deployment long after regulatory clarity arrives.
**Under stress:** Often develops a shadow Folkway underneath — individual practitioners use AI informally, bypassing compliance gates. The Samsung pattern.
**Growth direction:** Evolves toward The Integrator as regulation clarifies and compliance infrastructure becomes a deployment enabler rather than a gate.
**Evolutionary path:** Wardens come from regulated verticals or from Integrators that hit a compliance wall. They become Integrators when regulation clarifies; they rarely become Architects (compliance overhead discourages platform-scale bets).
##### The Broker
> *"We know what we need. Someone else is better at holding the tools."*
**Core strategic bet:** AI moves too fast for non-specialist orgs to build competitively; renting capability is more rational than buying.
**Examples:** Mid-market ops orgs on Palantir / Accenture / BCG X AI-as-a-service. Non-tech-native enterprises delegating AI capability to specialist consultancies. Smaller orgs that chose not to build AI talent internally.
The Broker delegates AI capability externally. They hold the problem but not the tools; the vendor or consultancy holds the capability. The rational premise is that AI moves too fast for non-specialist orgs to build competitively — better to rent than buy. When it works, it's fast and cheap and lets internal teams focus on the business. When it doesn't, vendor lock-in becomes the dominant story and the org discovers it can't even evaluate the vendor's work critically. The growth pattern is usually 'build-buy-build' — start by buying, internalize the strategic pieces later.
**Strengths:** Speed to deployment with no internal build time; Access to specialist capability without salary commitments; Lower capital exposure during a period of technology uncertainty; Focus — internal teams work on the business, not the AI
**Challenges:** Vendor lock-in becomes the dominant risk; Internal knowledge erosion — can't evaluate vendor claims critically; Data governance complexity (what does the vendor see, store, train on); Strategic dependency — if the vendor pivots, the org is exposed
**Healthy:** Selective delegation with internal staff who can evaluate vendor output and internalize strategic pieces over time.
**Unhealthy:** Total dependence without the internal capacity to critique the work.
**Blind spot:** Assumes the vendor relationship is a commercial question when it's actually a capability question — underestimates what happens when internal knowledge atrophies.
**Under stress:** Compresses toward The Warden — under vendor disruption (pricing shock, acquisition, pivot), brings governance in-house as a defensive response without yet having the capability to match.
**Growth direction:** Evolves toward The Integrator or The Architect — selectively internalizes strategic capabilities as the build-vs-buy calculus shifts.
**Evolutionary path:** Brokers come from non-tech-native orgs that need AI capability but rationally chose not to build. They become Integrators or Architects as the cost-benefit of delegation changes.
##### The Folkway
> *"AI showed up through our teams before leadership noticed. We're still figuring out what that means."*
**Core strategic bet:** Not a bet — a state. The open question is whether the organization catches up to its own practitioners.
**Examples:** Small orgs where everyone uses ChatGPT on the side. Non-tech teams at large enterprises informally adopting. Early-stage bottom-up adoption preceding any strategy formation.
The Folkway is broad, shallow individual adoption happening below organizational visibility. Teams discovered AI on their own; the organization hasn't decided what to do about it yet. The strength is bottom-up sensing — practitioners are finding valuable use cases before leadership commissions a strategy. The risk is the Samsung scenario: valuable data walks out through unauthorized tool interfaces while leadership discusses policy. Most organizations pass through the Folkway briefly on their way to a chosen posture; a minority linger here for years, accumulating exposure without corresponding learning.
**Strengths:** Bottom-up discovery of valuable use cases; Low cost of experimentation (users often paying for tools personally); High individual adoption velocity; Early signal about what matters to frontline work
**Challenges:** Data exfiltration risk through personal tool accounts; No organizational learning — what works for one team doesn't propagate; Quality variance — some uses excellent, others produce 'crapjects'; Governance vacuum creates exposure without corresponding upside
**Healthy:** Brief passage state on the way to Tinkerer or Integrator, with leadership catching up and formalizing what's emerging.
**Unhealthy:** Lingering Folkway that never gets inventoried; eventual incident forces heavy-handed reaction.
**Blind spot:** Underestimates the data-governance exposure because the individual users don't see what they, collectively, are sending out.
**Under stress:** Under top-down pressure after a visible incident, often compresses toward The Warden — leadership responds with heavy-handed policy that lacks specificity, driving the Folkway further underground rather than resolving it.
**Growth direction:** Evolves toward The Tinkerer (formalizing what's already emerging) or The Guild (if sophistication is already concentrating in specific experts).
**Evolutionary path:** Folkways are an entry state — most orgs pass through briefly. They become Tinkerers with formalization, Guilds with concentration + expertise, or Wardens if leadership responds by clamping down.
##### The Guild
> *"Our best people figured it out themselves. The rest of the org doesn't know yet."*
**Core strategic bet:** Not an organizational bet — an emergent capability. The strategic question is whether leadership recognizes and preserves what its experts have built before the experts leave.
**Examples:** Enterprises where a few engineers or analysts have built sophisticated custom pipelines unknown to leadership. Domain experts using AI to take on work that was previously out of reach. Informal expert networks accumulating proprietary pattern recognition.
The Guild is concentrated, sophisticated AI work living below organizational visibility. Individual experts — often with deep domain knowledge — have built proprietary pipelines and pattern recognition the organization may not realize it has. This is 'tasteful discrimination' accumulating at the practitioner layer, the kind of judgment base models don't possess and vendors can't replicate. Strength: the org holds a capability moat it doesn't know is a moat. Risk: the expertise leaves when the expert does. The Guild is usually detected, not self-reported — the archetype's defining feature is that the organization doesn't fully see itself.
**Strengths:** Proprietary pattern recognition — signal value base models don't have; High-sophistication work on real problems, not demos; Resilient to model frontier shifts (experts adapt faster than systems); Low governance overhead at the practitioner level
**Challenges:** Bus factor — if the expert leaves, the capability leaves; Opacity — organization can't evaluate or scale what it can't see; Reproducibility gap — the Guild member's work isn't codified; Bridge problem — Guild work doesn't integrate with official workflows
**Healthy:** Leadership recognizes the Guild, invests in codification, and the expertise becomes an Architect-level platform in that domain.
**Unhealthy:** The org never sees the Guild; the expert leaves; the capability evaporates without trace.
**Blind spot:** The Guild member often underestimates how much of their work is tacit and non-transferable — 'anyone could do this' is almost always wrong.
**Under stress:** Under organizational pressure (layoffs, mandated standardization, forced tool consolidation), Guilds often dissolve rather than transition — the experts leave and take the capability with them.
**Growth direction:** Evolves toward The Architect in their specific domain — the Guild's work gets codified into platform primitives. This requires leadership recognition and investment; it doesn't happen by default.
**Evolutionary path:** Guilds come from Folkways (as sophistication concentrates) or from Integrators (where a particular expert goes deeper than the org expects). They become Architects in their domain if codified, or they disappear if not.