Something changed in who benefits from AI. The latest models, and the products built on them like Claude and Codex, take instructions in plain language. No programming knowledge, no coding background. Which means the productivity gains are no longer reserved for technical people. Anyone with access to these tools can claim them.
I feel this myself, every day, at work and in my personal projects. I no longer feel limited by my own technical capability, and I no longer depend on designers or developers to make an idea real. I can prototype a product without waiting on engineers to build it or designers to design it. I built and shipped an MCP server completely on my own. And beyond bridging that technical-skills gap, I have handed most of my daily work to AI: extracting and analyzing data, summarizing meeting notes, maintaining org-wide visibility on priority projects. The list keeps growing.
Once you experience this yourself, you want everyone around you to have it too. So I got curious about how other companies have led AI transformation across their organizations, not one enthusiast at a time but company-wide. I read a lot of case studies. Five stood out, because they document what the company actually did rather than what it bought: Stripe's knowledge platform, Ramp's internal AI coworker, Zapier's "Code Red," Howie Liu's account of refounding Airtable, and Will Larson's working notes from Imprint. I read them closely, followed their links, read the internal memos they published, and checked their numbers against outside sources.
One note before we start. These are all software companies, and every account was published by the company itself or its leader. That shapes what they can say. I have kept to what the accounts document and what could be verified independently, and I will tell you which numbers are measured and which are reported.
The four decisions
Strip away the product names and every one of these companies made the same four decisions. They just made them differently.
- Who owns the transformation. A team, a role, or a person.
- What every employee gets on day one. Access, accounts, and setup.
- How one person's breakthrough reaches everyone else. The unit of sharing.
- Where guardrails sit in the sequence. Before distribution, after it, or nowhere visible.
Hold those four questions in mind as you read each case. The interesting part is not that the companies disagree. It is that each one is confident, and no two answers match.
Each case below follows the same structure, so you can compare them directly: what the company is, what triggered the transformation and the philosophy behind it, how they executed, and what the case teaches. The cases run from the largest company to the smallest, roughly 9,100 employees down to 270, because size turns out to explain more of the differences than strategy does.
Stripe: the second transformation is harder than the first
The company
Stripe sells payments infrastructure and processes roughly $1.9 trillion a year, equivalent to about 1.6% of global GDP. Around 9,100 employees, the largest company in this set by a wide margin. In July 2026 its engineering blog described Kai, the internal knowledge-work platform, written by the team that owns it.
The trigger and the philosophy
Stripe's trigger is the one nobody plans for: their first AI transformation worked. Coding agents had already remade engineering. That success split the company into people whose work had been rebuilt and people watching it happen. The article says it plainly: sales reps, finance analysts, and account managers "felt left behind."
Two fixes failed before the one that worked. A no-code agent builder let anyone create their own agents; over 4,000 got built, of wildly varying quality, and the estate became impossible to monitor or maintain. Then non-engineers started using coding agents as a workaround, which created security exposure and dropped a support burden on teams that had never supported non-engineers.
Those failures produced the philosophy. Knowledge work is not shaped like code work: every task needs different tools, different data, and a different definition of done, so neither one monolithic agent nor a thousand self-built ones can serve it. From that, three requirements: scale expertise without centralizing it, meet people inside the tools where they already work, and supply the guardrails that code gets for free. Compilers reject bad syntax, tests catch regressions, version control makes mistakes reversible. Knowledge work has none of that, so the platform has to provide it.
The execution
Notice where the guardrails sit: at the foundation, not bolted on later. Stripe reused the security substrate it had already built for its customer-facing product agents, on the reasoning that internal work touches the same sensitive data and deserves the same bar. The rest is a federated model. The central team owns the platform; each domain team builds and governs its own agents and skills through a control plane called AgentStudio, so the people who know what good looks like in finance or legal own the agents for finance and legal.
The sharpest line in any of these five accounts is one sentence about access control:
"The isolation boundary isn't 'what can this person access based on their authorization token?', but instead 'what should this task be allowed to view given this context?'" (Stripe engineering blog: Anna Mason, Sharadh Krishnamurthy, Anupam Upadhyay)
Identity-based access was always a rough proxy for "should this be combined." It held because humans rarely combine everything they can reach. An agent will. Stripe is the only company in this set that noticed the proxy breaking and moved the unit of authorization from the person to the task.
The learnings
Stripe's own stated lesson is the diagnosis itself: extending AI leverage beyond engineering means treating knowledge work as structurally different, with distributed expertise and none of code's free guardrails. Their account also names its unfinished work openly, from managing state across long sessions to the fact that what one person learns in a session is still locked there.
What the case shows beyond that: be precise about the numbers, because they are the best in the genre and still limited. The impressive ones live inside sales, the one function that had a scoreboard before AI arrived. Account executives, compared against themselves in weeks they did not use Kai, showed 2x sales activity and closed 39% more deals. Outside sales, the claims go qualitative. Stripe did not solve measurement for knowledge work. They deployed first where measurement already existed, which is a sensible sequencing decision and a different thing.
Ramp: fix the harness, not the people
The company
Ramp sells corporate cards and spend management software to finance teams. Around 3,200 employees, roughly tripled over the two years before this story was written, which matters: a company growing that fast has a constant stream of new people who have never seen a good AI setup. In April 2026, Seb Goddijn, who led Internal AI at Ramp, published the account of Glass, their internal AI platform.
The trigger and the philosophy
The trigger was their own success metric turning on them. Ramp pushed AI tools company-wide and hit 99% adoption. Then they noticed most people were stuck anyway. The tools were adopted; the work had not changed. Goddijn's diagnosis is the most quotable admission in any of these accounts:
"We'd created urgency without providing enough infrastructure, and it limited the true upside of AI to people who already knew how to configure it." (Seb Goddijn, Internal AI, Ramp)
I wrote about this exact gap in Access Is Not Adoption. Ramp is the cleanest large-scale example I have seen: a company can reach near-total adoption and produce no visible capability change, because adoption was never the thing being measured.
Out of that diagnosis came three stated principles. Don't limit anyone's upside: reject the instinct to dumb the tools down for non-technical users, and make complexity invisible instead of absent. One person's breakthrough should become everyone's baseline. And the product is the enablement: a targeted nudge inside the tool beats any workshop. Goddijn compresses all three into one line: "We don't believe in lowering the ceiling. We believe in raising the floor."
The execution
Two things in this sequence deserve attention.
First, the foundation came before the features. Goddijn calls single sign-on and one-click tool setup "the unsexy foundation that makes everything else possible." Keep that phrase in mind; it comes back in every other case.
Second, look at what a "skill" is: a markdown file that teaches the agent one task, versioned and reviewed like code. Ramp's real move was to change the unit of enablement from a person to a file. A person's expertise walks out the door at 6pm. A file compounds. Once skills were files, everything else followed: a marketplace to share them (Dojo), a recommender to surface the right five out of 350 (Sensei), and review gates so quality survives scale.
The learnings
Ramp's own stated lesson: the people who got the most value were not the training attendees, they were the ones who installed a skill on day one and got a result. The product taught faster than the training did.
What the case shows beyond that: the numbers Ramp reports are activity numbers, 99% adoption and 350+ skills shared, and the strongest outcome claim is an observation rather than a measurement. What Glass demonstrably solved is distribution. Nobody's individual skill improved because Glass shipped; one person's working configuration became copyable. That is a real and valuable thing, and it is a different thing from proving the work got better.
Zapier: the mandate that shipped with its machinery
The company
Zapier sells workflow automation, connecting apps so non-developers can build multi-step processes without code. Roughly 1,480 employees, and famously capital-efficient. Its account differs from the others in two ways: it is told by the CEO, Wade Foster, and it published the actual internal artifacts, including the original memo.
The trigger and the philosophy
The trigger was a model release aimed at their own moat. GPT-4 could read and write code, including API integrations, which is uncomfortably close to what Zapier sells. Ten days after the launch in March 2023, Foster declared a company-wide "Code Red," writing internally that "we can no longer assume everything we thought about our moats and advantages are true," and going further than most CEOs will about their own product:
"It's hard to imagine a future where configuring a Zap through our existing editor is the ideal user experience for workflow automation." (Wade Foster, CEO, Zapier, internal memo, March 2023)
The philosophy that followed: communicate urgency transparently, including the risks of doing nothing. Repeat the message constantly, because a single announcement changes nothing. Tolerate mess and duplication while people learn. And leaders show up building, at the hackathons, not just sponsoring them.
The execution
The published memo is the single best primary document in this set, because it is the only one that treats transformation as a question of decision rights rather than tooling. It names who arbitrates AI inside the product and who arbitrates outside it. It commits the executive team to a 48-hour turnaround on resource requests. It grants explicit permission to pull people off existing work. It assigns the CFO to track the new spending. It even sets the daily reporting cadence, including a permitted null update: "the status quo remains."
Note the two arrows leaving the memo. The hackweek created the demand and the foundations absorbed it, in parallel, in the same few weeks: legal-led guidelines on which tools and which data, an expedited procurement path, an enablement hub, and named champions. In late 2025 Zapier made the ownership answer permanent by creating a Chief People and AI Transformation Officer, the only company in this set to locate the problem in the people function.
The learnings
Zapier's own stated lessons: don't wait for a fully baked strategy; make it a company initiative because the best unlocks come from the edge; invest in enablement because people won't just figure it out; and keep the ritual going, since a one-off hackathon decays but a recurring one builds the muscle.
What the case shows beyond that comes in two parts. First, two honest qualifiers: the adoption figures are self-reported survey answers rather than system telemetry, so the trend line (63 to 77 to 97) means more than any single level, and Zapier now sells AI-transformation consulting, so its story is also its marketing. Neither fact makes the account wrong, and the operational detail is the richest of the five. But you should know where the numbers sit.
Second, the reason Zapier matters to the set. Ramp mandated urgency and reports that it backfired. Will Larson at Imprint, whose case closes this set, argues against mandates entirely. Zapier mandated hard and reports it working. The difference is visible in the memo: the urgency arrived with the machinery attached. Named owners, a resourcing SLA, legal guardrails, procurement, training, and a hackweek date, all within weeks of the declaration. The variable across these companies was never mandate versus no mandate. It is whether the urgency ships with the means to act on it.
Airtable: the case with an ending
The company
Airtable is a no-code app platform: tables, views, and automations that non-developers assemble into business apps. Its story is the one we can see all the way through. The company peaked at an $11.7 billion valuation in December 2021, then cut over 40% of its staff across two rounds in 2022 and 2023, from roughly 1,250 people down to a low of about 640, while a viral tweet declared it dead using revenue figures that public reporting later showed were low by well over 2x. By the time of the interview it had rebuilt to an estimated 870 or so employees. Against that backdrop, co-founder and CEO Howie Liu ran what he calls a refounding, described in an August 2025 interview on Lenny's Podcast.
The trigger and the philosophy
The trigger was existential in both directions at once: a public narrative of decline, and a technology wave aimed at the product's own reason to exist, since agents that generate software compete directly with a platform for building apps without code.
Liu's philosophy starts from the claim that AI is not a one-time platform shift like desktop to mobile. Every new model capability implies new product forms, so every software product has to be refounded. His test for whether the incumbent should be the one to do it is the cleanest formulation I have seen, and he states its consequence without flinching:
"If you were literally founding a new company from scratch with the same mission, how would you execute on that mission using a fully AI native approach? If you can't, then you should find a buyer." (Howie Liu, co-founder and CEO, Airtable)
His answer was that Airtable's building blocks, the tables and views and automations, were worth more as tools an agent could use than as features a human clicks. An agent assembling reliable primitives beats an agent generating everything from raw code. That bet is what made refounding the right call in his judgment, rather than selling.
The execution
The organizational change is the part I have not seen anywhere else. Instead of changing what the org has, Liu changed the speed it runs at, splitting product development into two groups named after Kahneman's two systems:
The fast-thinking group ships near-weekly and is explicitly benchmarked against AI-native startups: Liu's standing question is how a company like Cursor would execute, and whether Airtable is matching that pace. The slow-thinking group owns the bets that cannot ship in a week, like a data layer for very large datasets. Liu himself went back to being a hands-on user and builder, on the argument that a leader can no longer judge the product from screenshots: "It's actually now also hard to taste the soup without participating in at least some part of creating the soup." The June 2025 relaunch made an agent the default interface to the whole product.
The learnings
Liu's own stated lessons: leaders must use the tools constantly, and play with them rather than check the box; teams should share prototypes instead of decks; every product role needs baseline competence in the neighboring ones; and for genuinely new form factors, start with open-ended experimentation before locking in formal evaluation, because rigor applied too early constrains you before you know what good looks like.
What the case shows beyond that is why both of his clock speeds are needed, and it doubles as the best diagnosis in this set of why AI-native startups stall: fast shipping buys attention and new use cases at the top of the funnel, and the slow, unglamorous bets are what turn that attention into deployments that stay. Speed gets you tried. Depth gets you kept.
And then the ending. In August 2026, a year after that interview, Airtable agreed to be acquired by Bending Spoons at an enterprise value of $1.285 billion. Roughly a ninth of the peak valuation, at about 2.7x revenue.
Resist the easy reading. Public reporting puts Airtable's revenue near $480 million with over $100 million in free cash flow: a real business, run well, transformed with more conviction than almost any company its age. The refounding did not fail. It also did not restore what the 2021 price implied. Both of those things are true at once, and I will come back to what that means.
Imprint: what the same problem looks like at 270 people
The company
Imprint is a fintech of roughly 270 people that designs and runs co-branded credit card programs for consumer brands. Will Larson, its CTO, published working notes in December 2025 on 18 months of internal AI adoption. His post makes no outcome claims at all, and that restraint is exactly what makes it useful: it is the one account in this set with nothing to sell and the most detail about what broke.
The trigger and the philosophy
There is no crisis in this story, no failed mandate and no viral tweet. Larson treats internal AI adoption as simply part of the job now, "at minimum, a side-quest for every engineering leader in the current era."
His philosophy came in two parts. The first is personal: before setting strategy, the leader earns an opinion. Larson built his own tool-using agents, three small projects of a few hours each, before drafting anything with the exec team.
"Tool use is, in particular, something that seemed like magic until I implemented a simple tool-using agent, at which point it became something extremely non-magical that I could reason about and understand." (Will Larson, CTO, Imprint)
The second part is the strategy itself, three pillars drafted with the executive team: pave the path by removing obstacles, especially having to ask for access; treat adoption as everyone's opportunity, not an engineering perk; and have senior leadership lead from the front, staying close enough to the details to know whether the work is genuinely useful rather than just well-measured.
The execution
Three of Larson's choices carry the whole piece.
He treats non-adoption as information. "Folks who aren't adopting tools are rational non-adopters," he writes, and spending time understanding their resistance beats a mandate. When someone is not using the tool, the tool is the suspect.
He splits governance by blast radius. Prompts live in Notion, open for anyone to edit, deliberately not behind Git because that would lock out non-engineers. Tool permissions live in a typed, code-reviewed repository behind automated checks. A bad prompt produces a bad message. A bad tool grant spams the company or leaks data. Different consequences, different controls. None of the larger companies states this principle, and it resolves a contradiction we will get to shortly.
And his feedback loop costs one line: nearly every prompt ends with an instruction to include a link to itself in the output. Whoever sees a mediocre response is one click from the editable artifact that produced it. Ramp built a recommender for this job. Stripe built quality dashboards. Larson appended a URL.
The learnings
Larson's own stated lessons: we are early, so rate of learning beats everything else; anyone leading an AI initiative must be building with the tools themselves, not just chatting with them; and real adoption is a blend of domain context, experience with AI tooling, and unglamorous IT work. He is, in his words, deeply skeptical of any initiative that does not anchor on all three.
What the case shows beyond that: the absence of outcome claims here is a choice, not a gap. Larson uses usage data to generate questions, asking power users what makes the tools useful and non-adopters what is in their way, rather than to prove impact. And his deadpan summary of the whole endeavor doubles as the first cross-case finding:
"To the surprise of no one who's worked in or adjacent to IT, a lot of revolutionary general AI adoption is… really just account provisioning and access controls." (Will Larson)
What all five agree on
Three findings hold across every case, at every size, which is what makes them worth trusting.
The first real step is boring. Larson says it deadpan. Ramp calls SSO "the unsexy foundation that makes everything else possible." Stripe leads with day-zero availability. A one-person build, a six-person team, and a full platform organization converged on the same answer: before culture, before training, before any platform, the work is accounts, access, and provisioning. If your transformation plan does not start there, it starts later than it thinks.
The unit of enablement is a file, not a person. Ramp's skills are markdown files. Stripe's skills are governed assets owned by domain teams. Larson's prompts are Notion pages anyone can edit, each one linked from its own output. In every case, the thing that actually spread capability was making one person's working method into an artifact someone else can open, copy, and improve. Training moves knowledge person to person and decays. Files compound. This is the piece of the playbook that costs almost nothing and transfers to any company at any size.
The platform is a cost of scale, not the achievement. Larson names the three ingredients real adoption needs: someone who knows the domain, someone who knows the AI tooling, and someone who can do the IT work. At 270 people those can be one person. At Stripe's size they are three different organizations, and, in his words, coordinating them "is just objectively hard." Line the five companies up by headcount, 270, 1,480, 3,200, 9,100, and the machinery grows in step: a 3,000-line service, a retargeted hackweek ritual, a six-person platform team, a federated control plane. The larger companies were not smarter. They were paying a coordination cost the small one did not have. Copy the ingredients, not the machinery.
There is a fourth agreement worth a sentence: nobody dumbed anything down. All five rejected the instinct to give non-technical people a simplified tool, and instead worked to make full capability safe to hand over. Complexity got made invisible, not absent.
Where they flatly disagree
The same number is a triumph in one company and a crisis in another. Ramp presents 350+ shared skills as its flywheel working. Zapier cites thousands of internal agents as proof of maturity. Stripe describes 4,000+ agents as the failure that forced a rebuild. Three companies, the same artifact, opposite verdicts, and no account names who prunes the estate. Larson's blast-radius principle is the only frame that reconciles them: the count is not the risk. What the artifacts are permitted to do is the risk. A thousand open prompts are a library; a thousand ungoverned tool grants are an incident report with a date to be determined.
Who finds the right skill: the human or the model? Ramp built a recommender that shows each person a handful of relevant skills. Stripe loads nothing by default and lets the model choose from more than a thousand. Opposite answers to the identical problem, both reported as working, neither acknowledging the other exists. This one is genuinely unsettled.
Who owns the whole thing? Five companies, five answers. A dedicated internal team at Ramp. Platform engineering at Stripe. The CTO personally at Imprint. A Chief People and AI Transformation Officer at Zapier. The CEO himself at Airtable, as what Liu calls the chief taste maker. There is no consensus and no convergence in sight. Ownership is currently a bet each company places on where its own transformation will bind, on tooling, on people, or on product taste.
The measurement gap
Now the finding I did not expect when I started reading.
Across all five accounts, the total stock of outcome evidence, meaning a measured change in the work rather than in tool usage, is one comparison: Stripe's sellers against themselves in non-Kai weeks, in the one function that had a scoreboard before AI arrived. Everything else is activity. Adoption percentages, skill counts, agent counts, session counts. Ramp reports usage. Zapier's headline number comes from a survey question. Airtable's account offers no adoption metric at all. Larson declines to publish outcomes on principle, and says the quiet part in one line:
"My biggest fear for AI adoption is that they can focus on creating the impression of adopting AI, rather than focusing on creating additional productivity." (Will Larson)
I do not read this as an indictment of these five companies. They are the ones who published enough detail to check, and the pattern is the same everywhere else, just less visible. I read it as a fact about where we are: sales has a scoreboard, support has a clock, and most knowledge work has neither, so the numbers that exist get reported and the question that matters goes unmeasured. The companies in this set that impressed me most are the ones that were honest about which kind of number they were showing you.
For product leaders, this is the actual assignment. Anyone can buy the tools and hit an adoption number; Ramp proved you can hit 99 and still be stuck. The scarce work is instrumenting the outcome: deciding what "the work got better" means in your organization and building the scoreboard where one does not exist. The transformations above succeeded at distribution. Measurement is still open, which means it is still an advantage available to whoever does it first.
What success was supposed to mean
End where the evidence ends, with the one story that has a conclusion.
Airtable did, visibly and early, nearly everything the other four accounts recommend. The CEO went back to the details. The organization was rebuilt for speed. The product was refounded around an agent before most of its peers had shipped one. The business reached profitability at meaningful scale. And the company sold for a fraction of what investors once believed it was worth.
Hold that outcome next to Liu's own test: refound or find a buyer. He ran the refounding well, and the buyer came anyway. The 2021 price was a bet on a version of the future that the AI era repriced, and no quality of execution inside the company could argue with that repricing. The transformation was real. It just answered a different question than the valuation had asked.
That is the clarifying lesson of the whole set. An AI transformation can make your organization faster, your tools compound, and your business durable, and those are exactly the things the five accounts show how to do. What it cannot do is guarantee that the transformed company is worth what the old story said it was. Execution decides whether you are strong when the repricing comes. It does not decide the price.
So run the boring provisioning first. Turn your best people's methods into files. Match the machinery to your size, govern by blast radius, and ship urgency only with the means to act on it. Then measure the work, not the usage, because on the evidence of the five best-documented transformations in software, almost nobody does, and that is the part that is still up for grabs.
Sources: Seb Goddijn, "We Built Every Employee at Ramp Their Own AI Coworker" (April 2026); Anna Mason, Sharadh Krishnamurthy, and Anupam Upadhyay, "Meet Stripe's Knowledge AI Platform", stripe.dev (July 2026); Will Larson, "Facilitating AI adoption at Imprint", lethain.com (December 2025); Wade Foster, "How Zapier rolled out AI org-wide and drove 97% adoption", zapier.com (updated January 2026), including the published internal Code Red memo (March 2023); Howie Liu on Lenny's Podcast (August 2025). Company figures from public reporting, including CNBC, Forbes, TechCrunch, Sacra, and the Bending Spoons investor announcement (August 2026).