# 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 ═══════════════════════════════════════════════════════════════ DECK CONTENT ═══════════════════════════════════════════════════════════════ ── Slide ?? ── ## Durable AI Adoption 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. ── Slide 02 ── ## Contents 01. More than a tool (page 03) Why AI is a paradigm shift, not a software upgrade, and why adoption needs two mirror tracks. 02. Adoption Maturity Levels (page 09) Five maturity levels from Shadow to Planetary, each paired with its cultivated counterpart. 03. Getting started with AI adoption (page 17) Readiness check, plan after play, and the four-stage path workflows take into governance. 04. The path to durable AI adoption (page 22) Bottom-up discovery, top-down scale, and the six functions that hold the operating tension. 05. How the Protocol Institute adopts AI (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 (page 32) Maintaining the cultivated and governed handoff as the terrain keeps shifting. 07. About & Resources (page 35) The Protocol Institute, the Protocols for Business SIG, source materials, and ways to engage. ── Slide 03 · Chapter 1 ── # More than a tool ── Slide 04 · Chapter 1 · 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 → ── Slide 05 · Chapter 1 · More than a tool ── ## 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. ── Slide 06 · Chapter 1 · The path so far ── ## 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 ── Slide 07 · Chapter 1 · More than a tool ── ## 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. ── Slide 08 · Chapter 1 · More than a tool ── ## 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. ── Slide 09 · Chapter 2 ── # Adoption Maturity Levels ── Slide 10 · Chapter 2 · 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. ── Slide 11 · Chapter 2 · Adoption Maturity Levels ── ## 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. ── Slide 17 · Chapter 3 ── # Getting started with AI adoption ── Slide 18 · Chapter 3 · 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. ── Slide 19 · Chapter 3 · Getting started with AI adoption ── ## 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. ── Slide 20 · Chapter 3 · Getting started with AI adoption ── ## 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. ── Slide 21 · Chapter 3 · Getting started with AI adoption ── ## 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 ── Slide 22 · Chapter 4 ── # The path to durable AI adoption ── Slide 23 · Chapter 4 · 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. ── Slide 24 · Chapter 4 · The path to durable AI adoption ── ## 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. ── Slide 25 · Chapter 4 · The path to durable AI adoption ── ## Success patterns hold the tension between AI adoption tradeoffs ▦→▣ Kit harvesting over central design (success) Tag: Wait for variation before standardizing. Body: 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) Tag: Plan from what play surfaces. Body: 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) Tag: Buffer the mismatch instead of throttling. Body: 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) Tag: Compile constraints into the runtime. Body: 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 ── Slide 26 · Chapter 4 · The path to durable AI adoption ── ## Failures collapse the tensions, losing the balance between operational needs ⊘ Premature optimization (failure) Tag: Standardize before practice earns it. Body: 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) Tag: Production outpaces understanding. Body: 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) Tag: Output stacks at the slowest neighbor. Body: 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) Tag: Permissions and interventions lag production. Body: 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 ── Slide 27 · Chapter 4 · The path to durable AI adoption ── ## 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. ── Slide 28 · Chapter 4 · The path to durable AI adoption ── ## 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 node — Context Stabilization: Curate the context AI systems depend on and keep it stable across models, tools, and agents. Loop node — Risk Stewardship: Maintain the AI risk register and the technical interlocks that bound what AI is allowed to do. Loop node — Evals: Define what "good" means for each AI workflow and build the test harness that measures it. Loop node — Platform Operations: Run the shared AI infrastructure that domain teams build on. ── Slide 29 · Chapter 5 ── # How the Protocol Institute adopts AI ── Slide 30 · Chapter 5 · 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. ── Slide 31 · Chapter 5 · How the Protocol Institute adopts AI ── ## 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. ── Slide 32 · Chapter 6 ── # The new nature of work ── Slide 33 · Chapter 6 · 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. ── Slide 34 · Chapter 6 · The new nature of work ── ## 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. ── Slide 36 · Appendix · Case Studies ── ## 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 ── Slide 37 · Appendix · Case Studies ── ## 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. ── Slide 38 · Appendix · Case Studies ── ## 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. ── Slide 39 · Appendix · Case Studies ── ## 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. ── Slide 40 · Appendix · Case Studies ── ## 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. ── Slide 41 · Appendix · Case Studies ── ## 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. ── Slide 42 · Appendix · Case Studies ── ## 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. ── Slide 43 · Appendix · Case Studies ── ## 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. ── Slide 44 · Appendix · Case Studies ── ## 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. ── Slide 45 · Appendix · Case Studies ── ## 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. ── Slide 46 · Appendix · Case Studies ── ## 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. ── Slide 47 · Appendix · Case Studies ── ## 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. ── Slide 48 · Appendix · Case Studies ── ## 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. ── Slide 49 · Appendix · Case Studies ── ## 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. ── Slide 50 · Appendix · Case Studies ── ## 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. ── Slide 51 · Appendix · Frameworks ── ## Every node and every edge of how work moves is now AI-mediated ── Slide 52 · Appendix · Frameworks ── ## 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: Vibe-Coding Adoption Guide — e.g., electricity, the internet. AI: Commoditized Generative Software Implementation Roadmap — e.g., Figma. AI: Helpdesk Chatbot Deployment Plan — e.g., Microsoft Office. AI: Claude Code ── Slide ?? · Appendix · AI Adoption Assessment ── ## AI Adoption Assessment 24-question diagnostic that places your organization on the maturity ladder and surfaces your dominant archetype. AI Adoption Assessment — 24-question diagnostic Places your organization on the maturity ladder (L1–L5) and surfaces a dominant archetype. Questions (each a binary choice — answer the statement that better describes your organization): 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. 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. 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. 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. 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. Archetype outcomes (10): The Vanguard Quote: "Someone has to go first. We'd rather learn hard than wait safe." Core 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). Profile: 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. 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. The Traveller Quote: "We didn't add AI to our business. AI is why the business exists." Core 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. Profile: 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. 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. The Architect Quote: "We're not chasing the latest model. We're building the platform our teams will run on for years." Core 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). Profile: 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. 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. The Integrator Quote: "We're not first. We're not lost. We adopt where it pays and redesign when it matters." Core 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. Profile: 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. 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. The Tinkerer Quote: "We don't know what will work until we try it. So we try a lot of things." Core 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. Profile: 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. 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. The Ratifier Quote: "We don't surf the first wave. We ship the one that lasts." Core 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. Profile: 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. 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. The Warden Quote: "Our industry doesn't move until the regulator does. That's the job." Core 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). Profile: 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. 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. The Broker Quote: "We know what we need. Someone else is better at holding the tools." Core 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. Profile: 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. 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. The Folkway Quote: "AI showed up through our teams before leadership noticed. We're still figuring out what that means." Core 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. Profile: 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. 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). The Guild Quote: "Our best people figured it out themselves. The rest of the org doesn't know yet." Core 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. Profile: 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. 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.