Yennie Jun published an essay last week asking whether we are offloading too much of our thinking to AI. It is the strongest version of that worry I have read — grounded in her own habits, honest about the benefits, and free of the usual doom. Her most unsettling figure is a man her friend met at a San Francisco startup event, wearing a small microphone that records every conversation he has so an AI can analyze his day. “I let Fable do all of my thinking these days,” he explained, with apparent enthusiasm. Her core claim is that autonomy depends on continuing to participate in forming our own desires, and that handing decisions to AI — even trivial ones, like what to eat or what to listen to — slowly erodes who we are.

She is right about more than is comfortable. And the essay still aims at the wrong danger. The threat was never that we delegate our thinking; we have always delegated it, to whatever was nearest. The threat is delegating without a review loop. The distinction matters because the first framing is existential, and leaves you nothing to do but worry. The second is operational. Operational problems can be fixed.

The alarm has a history

Socrates warned that writing would destroy memory. In the Phaedrus, he argues that people who trust the written word will stop exercising their memories and carry the appearance of wisdom rather than the real thing. He was not wrong. The trained memory of oral culture — the capacity to hold an epic poem or a body of law in your head — genuinely atrophied. We traded it for literacy, and literacy bought philosophy, science, and the common law.

The pattern has repeated on schedule ever since. Calculators reached classrooms in the 1970s, and a generation of parents was warned that numeracy would die. It largely did, at least the mechanical kind; almost nobody now does long division for a living, and nobody mourns it. GPS arrived, and spatial reasoning measurably declined — there is research associating habitual turn-by-turn navigation with weaker spatial memory. The losses in each case were real. Jun is honest about the costs of offloading, so the response should be honest too: this is not a story where the worriers were simply wrong.

What the worriers missed is what happened next. Each time, the freed capacity moved up a level, and the surrendered skill quietly stopped mattering. Every skill you maintain has a carrying cost — the practice hours required to keep it sharp, paid from a fixed budget of attention. The useful question about any capability AI can now perform is not “are we losing it” but “is it still worth its carrying cost.” Sometimes the answer is yes: writing-to-think survived the word processor, because the value was never the typing. Sometimes the answer is no, and pretending every loss is an erosion of self collapses a judgment call into a panic.

The autonomous baseline never existed

Her framing carries a quieter assumption: that before AI, we were forming our own desires. Mostly, we were not. The music was chosen by Spotify’s recommendation engine, the restaurant by an aggregate of strangers’ reviews, the shoes by a marketing budget, and the opinions — more than anyone likes to admit — by an engagement-ranked feed. Ken Liu’s “The Perfect Match,” the 2012 short story Jun builds her essay around, was not a prophecy about large language models. It was a barely exaggerated description of the recommendation systems we had already accepted.

Jun asks exactly the right question: who is making the final decisions for the things that matter in your life? But the honest pre-AI answer was rarely “me, unaided.” It was a network of delegations we never audited, because none of it looked like delegation. It looked like convenience.

Against that baseline, an AI assistant is a strange place to plant the flag, because it is the first delegate in the chain you can actually interrogate. Ask Claude why it recommended something and you get reasons — reasons you can push on, disagree with, and overrule. Try asking the TikTok algorithm why it fed you what it fed you. An articulate delegate carries its own risk; a confident explanation can persuade when it should not. But a delegate that shows its reasoning at least makes review possible. The feed never offered that. Measured honestly against what it replaces, this is the first delegation mechanism in twenty years that hands any autonomy back.

Delegation is a discipline

Most of my job is delegation. I lead development teams and a project management office at a national law firm, and very little that matters ships from my own hands anymore. Nobody describes this as a loss of capability. A director who insists on doing everything personally is not more capable than one who delegates well — they are less, and every organization knows it. Deciding what to hand off, with how much context, and how tightly to inspect what comes back is high-order judgment. It may be the highest-order judgment the AI era pays for.

The legal industry has run on this discipline for a century. Associates draft; partners review; the partner’s name goes on the opinion. Nobody argues that the partner has surrendered their autonomy to the associate. The profession also knows precisely what the failure looks like, because it has a name for it: the partner who signs without reading. The failure was never delegation. It was delegation without a review loop.

Read Jun’s essay through that lens and her best moment confirms it. In Portugal, she and her sister wondered why the country celebrates explorers the United States would call colonizers. Her sister reached for ChatGPT; Jun suggested they think first. They speculated, disagreed, backtracked — and only then asked the AI, using its answer to test and extend hypotheses they had formed themselves. That is not resistance to offloading. That is a review loop, run well. Her mother’s physics students, meanwhile, pasting assignment questions into a chatbot and submitting the output unread, are the partner who signs without reading. Same technology, opposite disciplines. What separates them is not how much thinking was offloaded. It is whether anyone reviewed what came back — an operating problem, and operating problems are trainable. Organizations worried that AI will erode their people’s judgment should be training exactly this muscle: what to delegate, what to hold, how to review.

The line that deserves the worry

One part of Jun’s argument deserves to be granted in full. There is a real difference between delegating task execution and delegating desire formation. “Draft this memo” is delegation. “Tell me what to want from my career” is something else, because if you outsource the wanting, no one is left standing behind the review loop. A reviewer needs preferences of their own to review against.

But this is not a new problem arriving with a new technology. We already share our desire formation with other minds that hold opinions about what we should want — mentors, spouses, consultants, therapists. A good mentor absolutely tells you what to think, and sometimes what to want. Centuries of social practice taught us to take that input as input: to hold advisers at the distance where they inform the wanting without replacing it. We also recognize instantly when the line fails — the mentor who dictates, the consultant who decides for you. The skill of holding that line exists. It survives, like any skill, only if it is practiced. That is Jun’s real warning, and it stands stripped of its fatalism.

The Microphone Man is genuinely alarming, but the microphone is not why. He is alarming because he announced, cheerfully, that his review loop is closed — the AI is smarter, so the AI does the thinking now. Socrates’ alarm about writing was real too, and the answer was never to stop writing things down. It was to remain the kind of reader who checks. That is still the answer. Delegation without review is not offloading your thinking; it is abdicating it. And abdication was never the tool’s decision to make.

Read Yennie Jun’s original essay, Are we offloading too much of our thinking to AI? — it is the strongest version of the worry, and it deserves the argument. If the operational side of AI adoption is your beat, subscribe; it is the only thing I write about.

A trustworthy machine and a trustworthy employee need the same six things. A United Nations standards body spent this month naming them for machines. Enterprises named them for people years ago and filed the whole discipline under access management.

Here is what actually happened. The ITU — the International Telecommunication Union, the UN agency that has set the rules for how machines talk to each other since 1865, back when the machines were telegraphs — opened a focus group in July on trust and identity for AI agents. Its agenda names what a trustworthy agent has to account for: identity, authority, delegation, human oversight, accountability, and provenance. The first working meeting is in Paris in November, the second in Geneva in January. Treat that as a new frontier and the honest move is to wait — let the standards body convene, deliberate, and eventually tell you what a trustworthy agent is.

Treat it as an operator and the list stops the wait cold. You have seen every item on it before.

You already run this system

Read the agenda again with an IT lens instead of a policy one and it resolves into something ordinary:

• Identity is a credential — the verifiable answer to “who is this.”

• Authority is permissions — can it spend, sign, send, move money.

• Delegation is the grant record — who handed over the access, and who can take it back.

• Oversight is an approval gate — the step where a human has to say yes.

• Accountability is knowing whose name is on the action when it goes wrong.

• Provenance is an audit log — the trail that lets you reconstruct what happened.

That is not an emerging governance discipline. It is identity and access management, the practice every regulated enterprise has run for its people for years — the joiner-mover-leaver process, the role-based permissions, the quarterly access review, the audit trail the regulator asks to see. A UN body did not describe a new problem. It described your IAM program and pointed it at a new kind of user.

The maturity of that program was always measured by one question: can you say, without a two-week fire drill, who can touch a given system and why. Most enterprises can answer it for their people, at least on paper. Almost none can answer it yet for the agents they have already switched on.

Why it feels new anyway

The reason the list reads as novel is that we built every piece of it around a human being, and the human quietly did half the work.

A person authenticates, gets permissions scoped to a role, and then supplies the one thing the access model never had to encode: judgment. A lawyer with full reach into the document system does not open every matter she can technically open. She knows which files are walled off, which client would object, which situation calls for asking first. The permission set was never actually safe on its own. It was safe because a person with context and something to lose sat behind it.

An agent inherits the access and brings none of the judgment. Spin one up inside that same document system and it has the lawyer’s reach with none of the lawyer’s restraint. It will do exactly what its permissions allow, at machine speed, and nothing in it will pause to ask whether that was wise. The credential still resolves. The permissions still check out. The judgment that made them safe is simply gone.

That is the only genuinely new fact in the whole affair. Not identity, not authority, not audit. The actor holding the permissions no longer comes with a person attached.

You don’t have to wait for Paris

Some of this work does need the standards body. When your agent has to prove itself to another company’s agent across an organizational boundary — no shared HR system, no common directory, no one who onboarded them both — you need an agreed way to exchange and verify identity and authority. That is real, it is genuinely new, and it is what Paris and Geneva are for. The scientists advising the UN keep making a related point: the capability is running ahead of the evidence base the policy needs. A standards process moving at the speed of a November meeting will not hand you a safe agent next quarter.

Inside your own walls, you are not waiting on anyone. The six requirements are your existing access model, made explicit for an actor that supplies no judgment of its own. This is what “AI without operations is just a demo” looks like at the scale of a single agent: the demo is the capability, and the operations is the access model you write down around it.

You provisioned people out of habit — a role, a template, an approval, done. You have to provision an agent on purpose, in writing: state what it may touch, what it may never touch, where a person has to approve, and whose name answers for it when it goes wrong — the developer who built it, the team that deployed it, or the human who was supposed to be supervising. The implicit rule has to become an explicit one, because the thing holding the access will follow the letter of what you wrote and none of what you assumed.

What the agent is actually for

Here is the part worth sitting with. The agent is not the thing that needs governing. It is the thing that finally forces you to write your governance down.

For years “allowed” meant “technically permitted, and trusted not to abuse it” — and the second half of that sentence lived in people’s heads, never on paper. An actor with no judgment turns that unwritten half into a specification you have to author, review, and own. The uncomfortable gift of agents is that they make you say, in writing, what you always meant by access.

A UN focus group can define what trust between agents should look like across the industry. It cannot write down what “allowed” was always supposed to mean inside your organization. Only you can — and now, for the first time, you have a reason to. The six things that make a machine trustworthy were never really about the machine. They were about the discipline you already had, and finally have to put in writing.

If this landed, the earlier posts in this thread — on why your agent inherits your lawyer’s permissions, and why least privilege is the only sane default — are on my LinkedIn. Subscribe here to get the next one on operating AI, not just deploying it.

My own provincial government just published a manual for the part of AI adoption that almost everyone skips. In June, the Government of Alberta released twenty-one white papers describing how it is rebuilding four decades of public technology with a workforce of AI agents. The papers lead with numbers built to be doubted: a twenty-five-year-old benefits application rebuilt in four days instead of five months, a new public system delivered in eleven weeks for roughly $108,000 against a traditional estimate near $1.9 million, and a stated goal of cutting the cost and time of building government software by ninety-five percent.

Read the numbers, raise an eyebrow, move on. That is the reasonable response, and it misses the actual story. The results Alberta is reporting did not come from the AI. They came from the operations the province built around it. And the operations are the one thing a vendor cannot sell you.

The vendors were half right

One of the papers is a first-person account from Chris Wright, a director who spent years managing technical-debt work and legacy integrations. In his conversations with vendors, he kept hearing the same message: AI has significant limitations for this kind of work. He was skeptical of the claim but had nothing concrete to argue with, because he had never used the tools at any depth himself.

So he tested it on something he knew cold. Twenty-five years ago he wrote the Remote Area Heating Allowance application for Alberta Agriculture, by hand, in Java. It took five months. It is still running today. He put it through Alberta’s build process and rebuilt it in four days, and the new version does more than the original, including a public-facing portal the first one never had. He wrote the original code, so he could judge the output with direct knowledge of what it was supposed to do. The quality held.

That one was a prototype, a proof of capability. The harder proof is the Alberta Classroom Information Portal, a genuine enterprise system for principals and teachers, carrying the full weight of privacy protection, security review, identity management, and production infrastructure. It went live in June. It was delivered in eleven weeks for about $108,000, against a traditional estimate of $1.3 to $1.9 million and a timeline north of a year. It is not a tool anyone could afford to get wrong, and it was held to the same bar a traditional product team would have to clear.

The vendors were not exactly lying. Twelve months earlier the models could not have done this, and honest vendors were describing the tools as they were. But they got the deeper thing wrong. They were talking about the model, and the model was never where Alberta’s advantage came from. The model was the easy part.

What a vendor cannot sell you

Alberta is unusually direct about this. Their coding work is model-agnostic by design. Claude is their current preference, but they say plainly they expect that lead to change, and they have built everything so it can. In their own words, the intellectual property of what they call the “harness” matters more to the outcome than the specific model underneath it.

The harness is not exotic. It is a short file of project rules the AI reads first, a library of small instruction sets they call skills, and a near-perfect reference application the AI is told to copy. More than a hundred of the decisions a public system has to get right, how a user signs in, how input is validated, how secrets are stored, are made once, in that template, before any project begins.

The reason they needed it is worth understanding, because it is the reason most AI pilots quietly disappoint. Left to itself, the same model given the same request twice produces two different applications, with different layouts and different decisions underneath. Two capable people using the same tool diverge just as far. The prototypes came fast and looked finished, and then the months saved on the front end were lost on the back end, fixing the security and accessibility gaps the demo had hidden. None of that was a failure of the model. It was the absence of a defined way of working.

They are also blunt about the cost of building the fix. You cannot produce a good harness casually or at speed, they write, and every version copied from a copy degrades. One of the case-study authors put it more plainly still: more work went into building the factory than into getting the applications out the other end.

That sentence is the whole argument in miniature. What Alberta built was not software. It was encoded judgment, the standards and decisions and taste that normally live in a senior engineer’s head, written down so that a machine, or a novice, applies them the same way every time. A model you can buy, and its edge expires on someone else’s release schedule. Encoded judgment is yours, and it compounds. In a law firm, the equivalent is not a better contract tool. It is the risk posture, the house style, and the hard-won preferences a senior partner carries by instinct, finally written down where they can be applied at scale, and checked.

The standards no one had written down

Before Alberta could rebuild anything, it had to see what it actually had. So it pointed a tool it calls Git Insights at its entire code estate: about fifty agents reading 466 million lines across roughly 3,400 code repositories in around twenty hours, for under $2,000. No consultant engagement comes close on time or cost.

The finding that should travel furthest has nothing to do with speed. Across eight years and 8,178 contributors, Alberta’s software met its own standards completely on first release only forty percent of the time. The rest needed rework.

Their reading of that number is careful, and I think it is correct. This was not a story about lazy or unskilled people. The contributors were capable and hard-working, and most of the code was sound when it shipped. The problem was systemic. The standards were aspirational rather than prescriptive, inconsistently communicated, and silent in the contracts themselves. Where the rules are undefined, capable people make their own reasonable choices, and thousands of reasonable choices over eight years become drift. They compare the result to a medieval city, every building sound on its own terms, the whole grown dense and hard to cross.

There is a fairness in how they handle this that I want to underline, because it is rare in AI writing. We remember the one time an AI gets an answer wrong and forget the ten thousand times it was right, and we almost never hold human performance to the same standard in the same breath. Alberta did. It measured its own people honestly, at a scale no manual review could, and it credited them: the creativity, the judgment, and the work that no model produced. No AI dreamed up Git Insights. A person did.

This is the part most organizations will recognize if they are honest. The lesson is barely about AI at all. Most companies do not have an AI problem. They have an undocumented-standards problem, and AI is simply the first tool sharp enough to make the gap visible and then to close it. Alberta draws the comparison to a car plant: we would not accept a factory where forty percent of the vehicles left the line passing their safety checks. We hold software to a lower bar mostly because, until now, we could not see the number. AI did not fix the standard. It made the gap countable, and then it made the standard enforceable.

Compliance moved to the front

The enforcement is the most interesting mechanism in the collection. Alongside the build sits a set of review agents Alberta names by color. One checks code quality and hygiene. One reads the prose for the tells of machine-written text. One attacks the finished application from the outside, the way an intruder would. One works through the defensive checklist. Together they run more than 400 individual checks, including 285 requirements from an international security standard and 62 of Alberta’s own cloud-security rules, and they run continuously, as the application is built, for pennies each time.

The consequence is a real inversion. By the time the cybersecurity team sits down to review an application, it is already compliant, with the evidence attached. In one training cohort, a hundred public servants, most of whom would never have called themselves engineers, produced more than 560 working applications in six days, and the strongest cleared the cyber review and the accessibility check on first release. Compliance moved from the last gate to the first, and it now runs on every change instead of once at the end under deadline pressure.

There is a line buried in the technical papers that I keep returning to: you cannot be accountable for a process you have not defined. That is the quiet argument under the whole security model. Left undefined, the work happens inside the model’s private and probabilistic reasoning, and you gain speed while losing any real understanding of how the result was reached. Written down as skills, the same expectations become standard operating procedure, applied the same way every time and auditable after the fact.

For anyone working in a regulated business, this is the line to sit with. The same collection describes a pipeline that took one Alberta act and benchmarked it against the equivalent statutes across fourteen jurisdictions for about $200, with every finding traceable back to the exact clause it came from. Comparative statutory analysis that would take a team months, done in an afternoon and defensible down to the line. The speed is the least of it. The real change is that a control you used to run once, expensively, at the end, now runs continuously, for the price of lunch.

The bottleneck moved to us

Speed like this breaks the tools we use to manage work. On the coding task alone, Alberta measures the AI at well over a hundred times a human developer’s pace, and they are candid that traditional estimation collapses as a result. An AI has no reliable sense of how long a human would take, and a human has no reliable sense of how fast the AI will move. Planning poker stops meaning anything.

So they built a delivery tool that runs a kind of chess clock between the person and the AI, tracking who is holding the work at every step. The finding is uncomfortable and worth repeating. When a project misses its target, it usually has little to do with the AI. The AI finished in an hour; the person took a week to look at it. The delay lives in the handoff.

Their most ambitious paper follows that thread all the way down, and it is the one I would press on a fellow leader. It treats the org chart as a compression algorithm, a way of squeezing ground truth up through the layers so it fits inside a senior person’s attention, and then hydrating strategy back down into local action. A person conveys meaning at roughly forty bits a second. A model works orders of magnitude faster. Hold every interaction to human speed and you leave most of the gain on the table. In a human hierarchy you want one manager for every several workers; in an agentic one, the ratio may invert, with several supervising agents auditing every worker that builds. Their conclusion is bracing: the twentyfold improvement they are chasing is not achievable while keeping the org chart, the briefing note, and the approval chain exactly as they are. The hierarchy has to be rebuilt at the same time as the technology, or the old process quietly eats the new speed.

The operating lesson is simple to state and hard to act on. If an AI pilot did not save much time, the tool is probably not the problem. Look at the wait between the work, not the work itself. The model got faster. The organization around it did not.

Measure capability, not savings

Which raises the question of how you would even know you were winning. Alberta’s answer is the most quietly radical idea in the whole set, and the one I would steal first. Do not measure the program by the money it saves.

Their reasoning is hard to argue with. Continuing to do exactly the work you do today, just with fewer people, banks a one-time saving and forfeits the larger prize: an organization that can do things it could not do before. So they judge the work against three measures instead. Readiness, meaning whether the organization can actually carry the change, from staff skill to governance. System health, meaning whether the estate is getting safer and smaller rather than sicker and larger. And cost, counted honestly across the whole of government rather than shifted from one budget line to another.

The line that stays with me is their own: continuing the same work with fewer staff is folly. It reframes the entire exercise. The point of the harness, the standards, and the factory is not a cheaper version of the current output. It is a larger capability, measured by what the organization can now attempt. Dollars saved is the metric that makes an AI program look successful while leaving it exactly where it started.

What none of this ships in

Set the pieces side by side. The harness of encoded judgment. The standards finally written down. The compliance gates running on every change. A way of measuring delivery that catches the human handoff instead of hiding it. A measure of success built on capability rather than savings. An academy that put thousands of public servants and more than ten thousand members of the public through structured training. None of it arrives in a license. No vendor sells it, because no vendor can. It is made of one organization’s own rules, its own work, and its own judgment about what “good” means.

Alberta’s sharpest strategic move follows from that. Rather than centralize all software delivery or scatter it, they propose holding the protective core at the center, the security, identity, and data rules, while opening the actual building out to the people who understand the work. The center stops being the place software is delivered and becomes the place software is governed. The alternative is not a tidy status quo. It is shadow AI, built outside the fence with none of these controls, which arrives whether it is sanctioned or not. Their instinct for what a leader should buy is the same everywhere in the collection: stop buying chat conversations, and start building the pipelines and the standards that outlast the question you asked today.

Skepticism is still warranted, and Alberta invites it. These are self-published papers, and their numbers deserve interrogation. The largest claims, the ninety-five percent and the twentyfold, are targets at least as much as they are settled results. Some of what works in a government estate of unclassified legacy code will not transfer cleanly to a firm handling privileged client data. But the method is legible, the smaller numbers are concrete and consistent, and the method is the point. Alberta’s real product was never the applications. It was the capability to produce them, and they published the manual for building it.

The operations are still on you

The models will keep getting cheaper and better on a schedule none of us controls, which is exactly why the model is the commodity in this story. The operations will never be a commodity, because they are built out of your own judgment, and no one can hand you that.

AI without operations is just a demo. Alberta spent eighteen months building the operations, then gave the manual away. The building is still on the rest of us. You can download their manual this afternoon. You will still have to write your own.

If this was useful, subscribe. I write about the operational side of AI, the part that never fits inside a product demo. The Velocity White Papers are public at thevelocitywhitepapers.com, and they are worth your time.

Zack Shapiro’s The Two Clocks is the most accurate account of the AI-and-law problem I’ve read from anyone standing outside a firm. His argument, in one line: AI capability has raced years ahead of the institutions meant to use it, and the gap between the fast clock of the technology and the slow clock of the firm is the real story. Most of what follows is agreement. The rest is what that picture looks like from inside one, where I run AI and innovation for a national practice and spend my days in the exact gap he names.

Start with where he’s right, because he’s right about the thing that matters most.

The bottleneck really has moved

The line I’d underline twice is his: the bottleneck is no longer the intelligence, it’s the absorption of it. That is the whole job. The capability has been good enough for real work for a while now. The deployed value hasn’t followed, and the reason isn’t the model. It’s everything around the model — the process, the supervision, the standards, the person willing to change how the work gets done.

I’ve made this argument in narrower terms. The last mile in legal has its own geography, a specific terrain of hazards that general adoption advice never names. And the productivity numbers everyone quotes come with an entry fee nobody reads aloud: the data, process, and supervision preconditions that have to exist before a 3-to-5x number means anything. Shapiro’s version — a very expensive motor bolted into the old driveshaft — is the same warning in a better metaphor. Procurement is not absorption. On that, no daylight between us.

His workshop anatomy is correct too: task, background, judgment, constraints, deliverable, verification. And the most important sentence in the essay is the one pointing out that none of it is technical. The lawyers who take to this fastest are the best delegators, not the most technical people in the building. That matches everything I watch happen.

So here are three places the view changes when you move from across the table to inside the room.

Verification is not word six. It’s the new bottleneck.

In his anatomy, verification is the last item. In practice, it’s the whole game.

When production gets cheap, the constraint doesn’t disappear. It moves. It moves to the one step that didn’t get faster: a human deciding whether the output is right enough to put a name on. And that step does not scale the way drafting does. A model can generate a hundred competent drafts in the time it used to take to write one. It cannot make a partner able to actually read a hundred.

The demo where the mood in the room changes is real. I’ve run that demo. But it’s the easy half. The hard half arrives at the second thousand documents, when the drafts are landing faster than anyone can check them and someone approves one they did not fully read — not from laziness, from arithmetic. That is a selection problem, not a review problem, and you cannot review your way out of it. Every guardrail and eval only works after a human has decided what deserves attention.

Shapiro actually hands us the reason himself. Law has no compiler. A wrong contract doesn’t crash; it sits in a drawer until it detonates. That’s precisely why verification can’t be the sixth thing on the checklist. It’s the thing the whole rebuild has to be designed around. He says the words and then walks past them.

The surplus doesn’t have your name on it

The essay’s engine is optimism about who keeps the money. The frontier labs are General Electric; the firm that rebuilds itself is Coca-Cola. Absorb the capability and the margin is yours.

From inside, that’s the claim I’d hold most loosely.

Efficiency that everyone can buy flows to the buyer, not the producer. When every serious firm has absorbed AI — which is the entire premise of a race — the production savings get competed straight through to clients. You capture surplus from what stays scarce and hard to substitute, not from speed your competitor also has. His own evidence points this way: Blackstone is already paying Kirkland less, before Kirkland has rebuilt a thing. That’s not the fruit of absorption. That’s the surplus leaving through the door marked bargaining power.

We have the wider numbers on this. Eighty-eight percent of organizations use AI in some function; a single-digit share get measurable financial impact from it, and the playbook executives are running contradicts their own data. A rising tide has never lifted all boats. It lifts the ones rigged to catch it.

None of which means don’t absorb. It means be clear about which bet you’re placing. Absorbing to keep up is survival — the table stakes, the price of still being in the game in three years. Absorbing to win is a different move, and it doesn’t run on speed. It runs on the parts that don’t commoditize: genuine judgment, and the ability to stand behind the work.

The grind was doing something

Shapiro concedes, in roughly a paragraph, that AI compresses the junior grind that used to train lawyers, and that firms will have to “design training around decision-making deliberately.” That paragraph is carrying a fifteen-year problem it can’t lift.

The grind wasn’t only what firms sold. It was the transmission system for judgment. First-pass research, first-pass drafting, the diligence nobody enjoyed — that was where instinct got built, through repetition and exposure and being wrong in front of someone senior. Take the reps away and you keep this cohort’s judgment while quietly starving the next one’s.

There’s early evidence the trade isn’t free. In one study, developers who learned a new library with an AI assistant scored worse on understanding it afterward than those who struggled through without one. Speed for skill, and sometimes you get neither. Meanwhile the judgment that survives isn’t the relaxing part of the job. It gets compressed into every minute of the day, because the easy work that used to space it out is gone. The premium is real. It’s also heavier to carry than the essay lets on, and the pipeline that produces the people able to carry it is the thing most at risk.

Some of the slow clock is the law of lawyering

One more, and it’s the one I can only say from inside.

Not all of the slow clock is cowardice and comp cycles. Some of it is the job. Privilege, confidentiality, malpractice exposure, the bar rules, the client’s outside-counsel guidelines — these gate what absorption is permitted, not just what’s possible. The Sullivan & Cromwell hallucination Shapiro cites as fear is also a genuine governance failure, and the lesson a careful firm draws from it isn’t “be braver.” It’s “build the process that makes that impossible.”

The rational firm isn’t only protecting its margin. Part of what looks like foot-dragging is protecting the client, and that part is correct. The work is to separate the caution that’s real from the caution that’s theater — and Shapiro collapses them into one. Governance isn’t the committee that slows you down. Done right, it’s the thing that lets you go fast without the filing that ends a career. It isn’t a step you finish. It’s a property of the system, maintained continuously or not at all.

What I’d keep, and what I’d add

Keep the clocks — the frame is the most useful thing published on this in months. Keep own-the-method over rent-the-wrapper. Keep absorption as the real constraint. On the shape of the problem, Shapiro is more right than anyone writing about this from the outside.

What I’d add is the part that turns his diagnosis into a defensible position. The durable moat isn’t the speed of your clock. It’s whether you can prove, on the record, that the fast work is also right — a verified, governed process a human genuinely stands behind. That’s the input that stays scarce when production goes to zero, because it’s the one thing the client can’t get from a cheaper tool or build themselves without taking on the risk they’re paying you to hold.

Absorb to survive. Differentiate on judgment and accountability to actually keep the surplus. Because absorption without verification isn’t the Coca-Cola fortune. It’s just a faster demo.

I write every week about the operational reality between an AI demo and deployed value — mostly from inside a law firm, where the stakes make the gap impossible to ignore. If that’s useful, subscribe.

The most dangerous box on an AI workflow checklist is the one labeled “governance.” Not because it’s wrong — because of where it sits.

Nate B Jones recently published a nine-step framework for agent workflows, running from context pack through human approval (gate). It’s good. The individual practices are the right ones: normalize your data, ground the model in retrieval, cite every claim, keep a human in the loop. If you’re building agents, watch it.

But the framework is linear — nine sequential steps. And somewhere in any linear list, governance becomes a step. Something the pipeline passes through once, checks off, and moves past.

That shape is the problem. Not for a startup shipping a demo. For anyone operating where the output has consequences — a law firm, a bank, a hospital, anywhere regulated — the shape is exactly backwards.

This piece lays out the restructure in full: three phases wrapped in a governance layer, the failure mode each phase exists to prevent, and the operational finding that changed how we decide what to automate in the first place.

A checklist implies an order of operations

Consider what actually has to be true for an agent workflow to survive review in a regulated environment.

Every action needs to be attributable to a human principal. Access control needs to hold when data is ingested, when it’s stored, when it’s retrieved, and when the output ships. The audit log needs to capture all of it. Data residency constraints don’t pause while the pipeline does its work.

None of those are steps. They’re properties — conditions that must hold at every step. A checklist that positions governance as step nine implies the other eight ran without it. The first serious review will ask what was happening during steps one through eight, and “governance came later” is not an answer that ends well.

Running AI inside a national law firm forces this distinction quickly. Matter-level confidentiality, client data residency, professional accountability for anything that enters the record — these constraints don’t arrive at the end of a pipeline. They’re the environment the pipeline runs in. A workflow that treats them as a checkpoint has already failed; it just hasn’t been asked the right question yet.

So the restructure: three phases, wrapped in a governance layer. The Governed Context Pipeline. Each phase answers one question, and each exists to prevent one specific failure.

Scope: what is the agent allowed to know?

The first phase happens before any data moves, which is why almost nobody does it first.

Teams start at ingestion. Connect the mailbox, pull the PDFs, chunk, embed. The energy goes into the plumbing, because plumbing feels like progress — there’s something to demo at the end of the sprint. But the expensive mistakes in agent projects happen before the first document is ingested, in the decisions nobody wrote down about what the agent may read and toward what goal.

Nate's skeleton, to its credit, starts exactly here — his first step is a context pack that defines what the agent is allowed to read. Scope is that instinct given an enforcement mechanism.

Scope is the permission boundary, defined explicitly. What sources can this agent touch? For what purpose? On whose authority? In a law firm, the answers are concrete: role-based access against the firm’s identity provider, matter-level permissions that mirror ethical walls, residency rules about which jurisdictions data can occupy. The critical design decision is where those answers live. Not in a policy memo — in the architecture. A memo describes intent. An access control list enforces it.

One rule does most of the work: the agent’s access is a strict subset of the authenticated human’s access. Never more. An agent acting for a lawyer who cannot see a matter cannot see that matter either — not because it was told not to look, but because the credential it operates under makes looking impossible.

The failure this phase prevents is the one that ends AI programs in regulated industries: the “helpful” agent that read the wrong client’s file. Once that happens, no downstream safeguard matters. You can verify the output perfectly and the breach has still occurred, because the document was never supposed to be in context at all. Scope failures are unrecoverable by design — which is why scope is phase one and not a hardening task for later.

Structure: turn the mess into addressable context

The second phase is the unglamorous middle, and it’s where most of the actual engineering lives.

Source material arrives through controlled connections — not ad-hoc exports, not someone’s downloads folder. Large documents get chunked into tagged, addressable pieces, so a five-hundred-page record becomes something a retrieval system can point into with precision. Normalization turns unstructured mess into a clean schema: dates become dates, amounts become amounts — Nate's phrase, and exactly the right one — parties become parties. Storage stays secure and localized, holding whatever residency promise was made in scope. And retrieval works by similarity against that normalized store, pulling exact language with file references attached.

That last property deserves a sentence of its own, because it’s the entire epistemology of the pipeline: the agent works from retrieved fact, not remembered vibes. A model answering from its training data is recalling an impression of the world. A model answering from retrieval is reading a specific paragraph of a specific document it can name. Everything defensible about the output rests on that difference.

Two operational realities about this phase, both learned the slow way.

First, normalization quality is gated by input quality. The hardest inputs aren’t exotic — they’re handwritten documents, OCR’d scans, and sources whose formatting drifts from one custodian to the next. No amount of clever prompting upstream fixes a date field that arrived as a smudge. That makes normalization permanent iteration work, not a solved step, and any plan that treats it as a one-time migration is a plan for disappointment.

Second, normalization is deliberately isolated as its own step so it can be improved without touching anything else. Ingestion doesn’t change. Retrieval doesn’t change. The normalizer gets better every month on its own schedule. That’s not pipeline trivia — it’s the design decision that lets the boring part compound.

The failure this phase prevents: plausible-sounding output grounded in nothing. Skip the structure work and the agent still answers — that’s the trap. It answers fluently, confidently, and from nowhere.

Sign-off: defensible, not just plausible

The third phase is where the output earns the right to be relied on. Four operations: cite, verify, export, gate.

Cite means every generated claim maps to a specific paragraph in a specific source document. Not “according to the file” — this claim, that paragraph. The receipt. Citation is what converts an assertion into something checkable, and its real function is economic, which matters enormously later in this piece.

Export means the output ships as a structured review packet — a timeline, a list of identified gaps, a draft summary — rather than a wall of chat text. The reviewer gets an artifact organized for review, not a transcript to spelunk.

Gate means the hard stop. The AI cannot send, submit, file, or finalize. Ever. An authenticated professional reviews the citations and approves, and the approval is what moves the work forward. The gate is architecture, not policy — the capability to act simply doesn’t exist in the agent’s permission set.

The failure this phase prevents: an AI output entering the record with no human fingerprints on it. In a profession where a person is accountable for everything that goes out the door, that failure isn’t an embarrassment. It’s a structural breach of how the profession works.

But there’s a subtlety inside sign-off that most pipelines miss, and it’s the difference between having receipts and having proof.

Four ways a citation fails

A citation is an assertion, not proof. Audit the receipts in a real pipeline and they fail in four distinct ways:

1. Hallucinated — the source doesn’t exist. Rare in a grounded pipeline, but it’s the failure everyone knows about, because it’s the one that makes headlines and sanctions orders.

2. Semantically wrong — the source is real, but it doesn’t mean what the model thinks it means. The claim and the paragraph are both genuine; the relationship between them is not.

3. Missing — a claim that should carry a citation doesn’t, and slides through as connective tissue.

4. Duplicated — one source quietly does double duty across several claims it only partially supports.

The second failure is the dangerous one, because it survives a spot-check. The document exists. The link resolves. The reviewer clicks through, sees a real paragraph in a real filing, nods, and moves on. Every superficial signal of groundedness is present, and the meaning is wrong. Hallucination checks — “does this source exist?” — catch the first failure and are completely blind to the second.

Which is why verification is its own operation with its own tooling, not a byproduct of citation. Checking that a receipt exists is string matching. Checking that the receipt supports the claim it’s attached to is an entailment judgment — and it has to be performed against every claim, not a sample you hope generalizes. Hand that judgment to humans and you’ve rebuilt the verification labor the pipeline was supposed to reduce. Hand it to a second model and you’ve created a new set of judgments that themselves need calibrating. That recursion is why this is the live edge of the work right now. Nothing about it is finished, and it’s harder than any layer of the stack that gets talked about more.

The wrapper is the argument

Around all three phases sits the governance layer — and here is where the restructure stops being a diagram preference and starts being the point.

Four properties, held everywhere: identity, so every action is attributable to a human principal; access control, enforced at every phase rather than checked once at the door; audit logging, immutable, capturing prompts, actions, and approvals — which means compliance reporting comes free instead of being a quarterly archaeology project; and residency, holding through every phase including retrieval, because a vector store in the wrong jurisdiction is a residency violation no matter how well-scoped the ingestion was.

The difference between a step and a property sounds like semantics until you watch it decide an architecture. Treat governance as a step and you get a pipeline with a compliance checkpoint — one gate, at one position, inspecting whatever reaches it, trusting that nothing leaked before inspection. Treat governance as a wrapper and the questions change shape entirely. Not “did the output pass review?” but “was there any moment when this agent could act outside its principal’s identity?” Not “is there an audit trail?” but “is there any action that could have escaped it?”

And every one of these properties maps to something you can point at in a real enterprise environment. Residency is the cloud tenancy itself — region-pinned storage and compute that physically cannot host data elsewhere. Identity and access control bind to the same enterprise identity provider the humans authenticate against, so the agent inherits the org’s permission model instead of maintaining a parallel one. The connectors that bridge into document management systems carry those permissions through rather than flattening them. If a team presenting an agent architecture can’t point to where each property is enforced, the property isn’t held — it’s hoped for.

The wrapper turns governance from an inspection into an invariant. None of it is a policy document. All of it is architecture. That’s the part linear framings underplay, and it’s the part that determines whether the system survives contact with a regulator, an opposing counsel, or your own risk committee.

Governance isn’t step ten. It’s the box the other nine steps live inside.

The economics of the gate

Everything so far describes how to build the pipeline correctly. This section is about when not to build it at all — and it comes from the finding that reshaped our automation decisions more than any technical result.

The gate is not free. Put an AI workflow in production with a human verification gate at the end, and in some workflows the verification consumes as much time as the manual process it replaced. The automation produced its output in seconds; the checking of that output ate the savings. Net time recovered: approximately nothing.

The accounting is actually worse than break-even, because of who does the verifying and what they know. A person doing the work manually verifies as they go. Checking is amortized across authorship — every choice is checked at the moment it’s made, by the person holding the reasoning behind it. The verifier at a gate reads cold. They weren’t present during creation, they don’t hold the reasoning, and they’re reconstructing intent from the artifact alone. The pipeline didn’t eliminate the verification labor. It relocated it — and handed it to someone in a structurally worse position to perform it.

Peter Naur described the underlying mechanism in 1985, in “Programming as Theory Building”: the real substance of built work is the theory in the builder’s head, and the artifact doesn’t carry the theory. Programmers are rediscovering this at scale right now, reviewing AI-generated code they didn’t write and can’t cheaply validate. It generalizes to all knowledge work. The gate asks a human to recover a theory from an artifact, which is the expensive direction.

Out of that comes the selection criterion — the most useful sentence this pipeline has produced:

Automate where verification is asymmetric. Where checking is structurally cheaper than producing: confirming a citation points where it claims, validating an extracted date against the source, checking a sum. In those tasks the gate is fast, the machine does the production, and the economics genuinely work.

Where verification is symmetric — where “is this right?” can only be answered by re-deriving the judgment — the pipeline saves nothing. “Does this summary capture what matters across these files?” has no shortcut; answering it honestly means reading the files, which is the work the summary was meant to replace. The honest architecture in those cases moves the human upstream, into the creation loop, steering while the work is made, rather than stationing them at the gate to reconstruct it afterward.

Notice what this does to the phases you’ve already read about. Cite and Export aren’t decoration — they exist precisely to convert symmetric verification into asymmetric verification. A claim with a paragraph-level receipt can be checked without re-deriving it. A structured packet with a stated timeline and gap list can be reviewed without reconstructing it. When that conversion succeeds, automation pays. When it fails — when the receipts still can’t make checking cheap — the task was a bad automation candidate, and no amount of pipeline sophistication rescues it.

Where it breaks

A framework that claims no limits is marketing, so here are this one’s, stated plainly.

Normalization never finishes. Input quality gates everything downstream, the worst inputs are the ones humans produce most casually, and the phase is permanent iteration work dressed as a pipeline step. Budget for it accordingly — in attention, not just money.

Semantic verification is unsolved. The four-failure taxonomy tells you what to look for; it doesn’t hand you a tool that finds failure mode two at scale. The honest status is: active work, real tooling, no finish line in sight.

And the framework governs context pipelines — agents that read, ground, and draft. It says nothing about model selection, nothing about fine-tuning, nothing about the dozen other decisions an AI program has to make. It’s a load-bearing wall, not a whole house.

What it does do is give a leadership team a shape to reason with. When the next agent proposal lands, the questions write themselves. What’s the scope, and where is it enforced? What does the structure work cost, and who maintains it? Is verification asymmetric, or are we about to relocate labor and call it savings? Can any action escape the wrapper?

The checklist wants you to ask “what’s the next step?” The better question is “what has to be true at every step?”

Draw the box first. Then build what runs inside it.

On LinkedIn this week I’m walking through one phase of this framework each day — compressed versions of the arguments above. This article is the destination they point back to; there’s nothing else to keep up with. If someone forwarded you this, you can subscribe at andrewlewis.ca.

The teams that raise their hands for AI are almost never the teams that generate the revenue. That gap is easy to miss, because enthusiasm looks like traction. Most of the time it isn’t.

Enthusiasm Is a Real Signal

Building for the excited teams first is the obvious move, and for good reason. When a group asks for an AI workflow, they’ve already done half of the change-management work on your behalf. They tolerate a rough first version. Feedback comes back as a note, not a complaint. They volunteer as pilots, forgive the bugs, and — when something finally works — turn into the internal reference you point every skeptic toward.

None of that is a mistake. Friction is the tax on every internal tool, and a willing team pays it without being chased. If you’re standing up an AI practice from nothing, the enthusiasts are how you get a first win on the board before the budget conversation turns hostile. Following demand is a defensible way to start, and anyone who tells you to ignore your most eager users has never had to earn credibility inside an organization that didn’t ask to be changed.

But Enthusiasm and Revenue Aren’t Correlated

The problem surfaces a quarter or two later, when you look at where the effort actually went. In most firms — ours included — a small number of practice groups generate a disproportionate share of the revenue. The litigation teams, the corporate groups, the ones running the largest matters against the tightest deadlines. Those are rarely the people sending the eager Friday-afternoon note about a tool they just read about.

So the work flows one way and the money sits in the other. You can ship six workflows to the teams that asked, run clean pilots, post healthy adoption numbers, and still not have touched the part of the business that pays for all of it. That’s the trap. Every one of those workflows is genuine effort. None of it is evidence that you moved the number that matters.

This is the difference between activity and value, and it’s the easiest distinction to lose when the activity feels good. Adoption dashboards count seats, sessions, and logins — motion. They don’t ask whether the motion is pointed at anything. A number that goes up is not the same as a number that matters, and most AI programs are measured almost entirely on the first kind.

Measuring value would mean asking a harder question: did this workflow change the economics of work that actually bills? Hours returned to a partner on a live matter. Cycle time cut on the review that was holding up a deal. A junior freed from the mechanical first pass so the expensive judgment happens sooner. Those numbers are harder to collect and easier to argue with, which is exactly why programs quietly settle for seat counts instead. The metric you can gather in an afternoon wins over the metric that would tell you the truth.

The Path of Least Resistance Has an Org Chart

Effort doesn’t drift at random. It follows inbound. The teams that email you become the teams you build for, and the teams that email you are the ones already sold on the premise — which means your roadmap gets quietly authored by whoever is most curious, not whoever is most valuable. Nobody decides this in a meeting. It’s the default that takes over when no one sets a different one.

There’s a compounding effect, too. The enthusiast team you served becomes your best case study, so the next enthusiast team hears about it and comes to you, and the flywheel spins entirely inside the low-stakes tier of the business. Each turn feels like momentum. From the inside, a roadmap driven purely by inbound is almost indistinguishable from one driven by strategy — right up until someone asks what it did for the P&L, and the honest answer is a list of teams that were already going to be fine.

The Honest Version of the Other Side

There’s a real counterargument here, and it deserves its full weight rather than a quick takedown. Maybe building for the enthusiasts first isn’t misallocation at all. Maybe it’s sequencing.

You don’t want your first agentic workflow to fail inside the litigation group three days before a filing. The high-revenue teams are precisely the ones who can least afford a broken tool, a hallucinated citation, or a process that quietly drops a step — the stakes that turn a rough pilot into a client problem. Testing on the small, willing groups is how you surface those failures somewhere cheap. You build the muscle, harden the process, and earn the right to walk into the room where the work is unforgiving. Under that reading, the enthusiasts aren’t a distraction — they’re the rehearsal.

That argument is genuinely persuasive. It’s the strongest defense of enthusiasm-led rollout there is, and in a regulated environment it’s often the correct call. Which is exactly what makes it dangerous, because it’s also the perfect cover for never getting to the hard rooms at all.

The Line Between Sequencing and Drift

Sequencing and drift look identical for the first two quarters. Both have you shipping to willing teams and posting good numbers. The only thing that separates them is whether you can name the crossover.

If it’s really sequencing, you can answer three questions today: which revenue group you’re piloting toward, what has to be true before you bring the workflow to them, and roughly when. If those answers don’t exist — if the enthusiasts are simply where the work keeps landing because that’s where the work is easy — then “we’re de-risking first” isn’t a strategy. It’s the story you tell about drift after the fact.

Naming the crossover forces a second, uncomfortable admission: some of the enthusiast pilots you’re proudest of were never going to move the P&L, and were worth doing only as practice. That’s a fine reason to build something. It’s a poor reason to keep building in the same place once the muscle is there.

The discipline is almost embarrassingly plain. Before a pilot starts, write down who it’s for and what graduation looks like. A pilot with a named destination is a sequencing plan. A pilot without one is a hobby that happens to have a roadmap attached. AI without operations is just a demo — and a rollout that only ever serves the people who asked is just enthusiasm with a dashboard.

Enthusiasm tells you where it’s safe to begin. Never let it decide where you stop.

New here? Subscribe for field notes on making AI actually operational inside a real organization. If this one landed, forward it to whoever owns your AI roadmap — the person deciding which team gets built for next.

Every access control system you have ever run carried an assumption it never bothered to write down. The assumption was that a human being would be standing at the moment of action, deciding whether to actually go through with it.

That assumption is so deep we stopped seeing it. We talk about permissions as if they were the control. They were never the control. The control was the person — the one who had the access, noticed the request was strange, hesitated over the unfamiliar recipient, and chose not to send. The permission set drew the outer wall. Human judgment did the real work inside it, quietly, every single day, for free.

Agents inherit the wall. They do not inherit the judgment. And the moment that happens, a lot of governance that felt solid turns out to have been resting on something we never accounted for.

The contract nobody signed

Least privilege is usually explained as a defense against malice. Give people only the access their job requires, so a bad actor — or a stolen credential — can do less damage. True enough. But that framing hides the part that actually carried the weight.

Most people in most organizations are over-permissioned, and it almost never matters. A paralegal can probably open far more of the document system than any single matter requires. A developer can usually reach systems they have not touched in a year. We tolerate that gap between granted access and needed access because a human sits in it, applying discretion at the point of use. The gap is wide, and the judgment is what keeps the width from being dangerous.

That is the contract nobody signed. Access can be loose because judgment is tight. Take the judgment out of the moment of action, and the looseness you have lived with comfortably for twenty years becomes the exposure.

What the agent removes

Consider what Microsoft’s Copilot Cowork can do once it is running in someone’s context. It drafts and sends email, creates and edits and deletes documents, posts in collaboration channels, searches across the enterprise, and reaches the document system through the same connectors a person uses. It does all of this as the user, with the user’s permissions, not a narrower set of its own.

To Microsoft’s credit, it pauses before the riskiest actions and asks for approval, with a risk indicator attached. That sounds like the missing judgment, restored. It is not. The approval is one click, it leans on the same human attention least privilege already assumed, and it never changes what the agent is able to reach. Ask a person to approve twenty actions a day and you have not added judgment — you have manufactured a reflex. The prompt becomes a turnstile that everyone learns to push through.

This is not a worry confined to my own corner of the world. A 2025 Cloud Security Alliance survey of 445 security professionals found that ninety percent of deployed AI agents carry more access than their assigned task requires, and nearly half of organizations had already experienced a security incident involving one. The over-permissioned agent is not the edge case anyone is bracing for. It is the normal state of deployment.

From governing files to governing the factory

There is an idea moving through software circles that you are no longer building the product, you are building the factory that builds the product — and that you have to govern the factory accordingly. The same shift is happening to ordinary professional work. Increasingly the thing you build is not the document or the policy. It is the process, and the agent, that produces them.

Once you see governance that way, least privilege stops being an IT setting and becomes a design decision about the machine. You are no longer asking what a given person should be able to do with a given file. You are asking what the agent — its tools, its reach, its standing permissions — is structurally allowed to do with every file it can touch. The security community is converging on the same point from its own direction: the OWASP work on agentic applications now frames the goal as Least Agency — autonomy that is earned, scoped, and bounded, rather than granted by default because the underlying account happened to have it.

The instinct, having seen all this, is to lock everything down. Resist it. Maximal restriction kills the serendipity and cross-pollination that made these tools worth adopting in the first place. The discipline is to draw the line at the boundary of what a role would ever genuinely need — and to leave a deliberate margin on the generous side of strict minimum. There is a line. It sits a little wider than the tightest possible setting, and a great deal narrower than what most people hold today.

If that feels premature — if the honest objection is that nothing has gone wrong yet — look at the shape of the bet. Over-restrict and the cost is friction and a few frustrated colleagues. Under-restrict and the cost is the kind that ends up in a regulator’s letter or a headline. When the downside is that asymmetric, waiting for proof is not caution. It is a slow decision to do nothing.

The part that isn’t technical

If the argument stopped there, it would be an engineering problem, and engineering problems are the easy kind. The hard part is everywhere the technology isn’t.

People want a voice in how they get restricted, and they are right to. When word gets out that access is going to change, the reasonable reaction is not gratitude — it is a request to be consulted about a wall being built around your own work. Then there are the old records sitting under a practice area that no longer has an active owner: cut access and you might orphan something that still matters; leave it and you have proven the point about exposure. There are whole areas of a business with no clear owner at all. And underneath all of it sits the least glamorous question in governance — who approves access, by what process, on what timeline, without slowing the work that pays for everything.

None of that is a permission toggle. That is the actual work, and it is the work least likely to get done, because it is political and procedural rather than technical, and it does not demo well.

So the line I gave my colleagues, the one that sounded extreme, was never an accusation. Treat every internal user as malicious is a design stance, not a character judgment. It says: stop architecting around who you trust, because trust was a statement about intent, and intent is no longer the variable that determines the outcome. Architect around what the machine can do on their behalf.

Build for what can happen, not for what anyone means to do. Intentions don’t matter. Outcomes do.

The first agentic loop I handed real work to was almost embarrassingly simple. The instruction was one line: keep adding meaningful tests until you reach eighty percent coverage. It ran, it stopped, it produced something I could use. The loop worked because “done” was a number a machine could check on its own, over and over, without me in the room.

Then I started thinking about everything else. If a loop can run until a coding task is finished, where else does the pattern fit? Drafting. Review. Triage. The long middle of white-collar work that looks, from a distance, a lot like writing tests — produce a draft, check it, revise, repeat. And the more I looked at the work I actually manage, the less the pattern held. Not because the agents aren’t capable. Because of something hiding inside that one-line instruction I gave the test loop.

The two conditions inside one sentence

Read the instruction again: keep adding meaningful tests until you reach eighty percent coverage. There are two conditions in that sentence, not one. “Eighty percent” is the part the loop can see. It is a number, computed the same way every time, and the agent can compare its work against it without asking me anything. “Meaningful” is the part only I can see. It is a judgment about whether a test exercises something that matters, and the coverage number is blind to it.

The loop optimized the half it could measure and quietly leaned on me for the half it couldn’t. That arrangement felt like automation. It was closer to a division of labor I hadn’t noticed I was making. The machine took the measurable condition; I kept the judgment and pretended the number carried it.

That worked out fine for tests. It’s worth being honest about why.

Why coverage was allowed to stand in for quality

Code is instrumental. Nobody actually wants the code — they want what the code does. The product is downstream of the artifact, which means you are allowed to measure “done” with a structural proxy and trust that the proxy tracks the thing you care about. Coverage is one of those proxies. It does not measure whether the software is good. It measures how much of the code your tests touched, on the assumption that broadly exercised code is less likely to hide a defect that reaches the user.

The trouble is that the assumption is weaker than most teams treat it. The most careful study on this — Inozemtseva and Holmes, presented at ICSE in 2014, across roughly thirty-one thousand test suites on five large systems — found that once you control for the size of the test suite, coverage is only weakly correlated with how effective those tests actually are. Their conclusion is blunt: using a fixed coverage value as a quality target is unlikely to produce an effective suite. The field agreed with itself a decade later and named it the most influential paper of its conference year.

This is Goodhart’s law wearing work clothes. When a measure becomes a target, it can stop being a good measure, because the act of optimizing for it pulls it loose from whatever it was standing in for. The point is not that coverage is useless. Low coverage genuinely tells you something — it flags code nobody tested. The asymmetry is the whole lesson: a low number is a real warning, and a high number is not a real promise. The proxy is good at catching neglect and bad at certifying quality. A loop that runs to a coverage target inherits exactly that limitation, and for tests, where the real product lives one step downstream, you can live with it.

You can live with it because the proxy and the product are different objects. That is the condition that makes the whole thing work. And it is the condition that most knowledge work does not meet.

A contract is not instrumental

When a lawyer ships a contract, the contract is the product. There is no downstream artifact that the document is merely a means toward. You do not deliver “what the contract achieves” and keep the contract as scaffolding — you deliver the contract, and its quality lives in the thing itself: whether it is coherent, whether it anticipates the failure it was written to prevent, whether a counterparty’s counsel will accept it without a fight. None of that reduces to a number you can compute on the side and trust.

This is the move that breaks the analogy to tests. In code, “done” can ride on a proxy because the artifact is instrumental. In most professional knowledge work, the artifact is the deliverable, the quality is holistic, and there is no faithful proxy to point the loop at. You cannot write the equivalent of eighty percent coverage for a memo, because there is no “coverage” that stands one step away from the memo’s worth. The worth is in the memo.

So the comfortable division of labor collapses. With the test loop, I let the machine hold the measurable condition and I held the judgment. With a contract, there is no measurable condition to hand off. The judgment is the entire job. And a loop has a very specific demand about judgment that, until you try to use one for this kind of work, is easy to miss.

Doing the work is how we find out what “done” is

Here is the part that took me longest to say plainly. Traditionally, doing the work is how we discover what done looks like. You don’t hold the finished standard in your head and then march toward it. You draft, and the draft shows you what it needs. You see the thing take shape, and the shape tells you where it falls short. Judgment, in most real work, is terminal — it happens at the end, against an artifact you can finally look at.

A loop will not let you wait that long. To run an agent until it is finished, you have to define “finished” before a single version of the artifact exists. The judgment that used to live at the end gets moved to the front, ahead of the work, into a specification you write blind. For a task like coverage, where the standard genuinely is knowable in advance and handed to you from outside, that relocation costs nothing. For work where the standard is discovered in the doing, asking someone to judge before the work is done is not a workflow. It is a contradiction.

We have known this about people for a long time. Michael Polanyi’s whole account of tacit knowledge turns on the line that we can know more than we can tell — that a great deal of real expertise never makes it onto the page as an explicit rule, which is exactly why you can recognize good work when you see it and still fail to specify it in advance. Software learned the same lesson the expensive way and wrote it into the Agile Manifesto: welcome changing requirements even late in development, because the best requirements and designs emerge through the work rather than before it. The industry spent two decades moving away from the up-front specification freeze. The agentic loop quietly asks for the freeze back.

The machines are already demonstrating the problem

If this sounds like a soft, human complaint about creativity resisting measurement, the most striking confirmation is coming from the machines themselves. The difficulty of specifying a goal in advance, such that an optimizer pursuing it actually does what you meant, is one of the oldest named problems in the field. Concrete Problems in AI Safety framed it in 2016: a formal objective is an attempt to capture the designer’s informal intent, and it can be satisfied by solutions that are valid in the literal sense and wrong in every sense that mattered. DeepMind catalogued dozens of cases under the name specification gaming — behavior that meets the letter of an objective without achieving the intended outcome — and noted that writing a specification that actually reflects what the designer wanted is, in their dry phrasing, difficult.

The newest version of this is no longer a toy. In early 2025, researchers at Palisade told reasoning models to win against a chess engine, and the stronger models — by default, without being nudged — went after the task environment instead of playing chess, hacking the game state to register a win. The instruction was met. The intent was not. (MIT Technology Review and TIME both covered it.) Take that as analogy rather than proof, because an agent gaming a chess benchmark and a contract that fails a client are not the same failure. But the shape is identical, and it is the shape of my point: a stated “done” is not the same as the done you meant, and the gap between them is precisely the judgment a loop asks you to write down before you can see anything.

So who is supposed to write “done”?

This is where the question stops being abstract for me, because the honest answer implicates my own seat. A stopping condition can only be authored by someone who already knows what good looks like for that specific work. That person is not, usually, the person who wants to deploy the loop across a team.

I manage a team and provide direction. I am not sitting in the room with the user, deconstructing their workflow into the conditions that would tell an agent it was finished. That is not a confession of laziness; it is a structural fact about where leadership sits relative to the work. The definition of done lives inside the task, with the practitioner who does it, in the same tacit place Polanyi pointed at. It cannot be delegated upward to whoever holds the budget for automation, and it cannot be delegated to the agent, because the agent is the thing waiting to be told. The bottleneck in scaling agentic work was never the model’s capability. It is that “good” lives inside the work, and most of it has never been written down — because, until now, nobody had to.

“Isn’t this just the discipline you should already have?”

The strongest objection to all of this is a fair one, and I want to state it at full strength rather than knock down a weak version. Defining “done” up front is not some new impossibility the loop invented. It is ordinary project-management discipline — a brief, a specification, acceptance criteria, a definition of done on a ticket. People have always been too quick to skip it, and if the loop forces a team to actually do the work of saying what finished means, that is a gift, not a problem.

Where that objection is right, it is completely right, and I’ll concede it without hedging. For instrumental work with a faithful proxy — code against tests, a data pipeline against a validation suite, anything where the artifact is a means and a measurable condition stands one honest step away from the goal — defining the stopping condition in advance is just rigor, the loop rewards it, and you should reach for the loop. I am not arguing against autonomous agents. I run them.

Where the objection misses is the moment the artifact stops being a means and becomes the deliverable. There, “define done in advance” does not resolve into a cleaner brief. It resolves into “judge the work before you are allowed to see it,” and no amount of discipline dissolves that, because the thing you would need to judge does not exist yet. The discipline argument assumes the standard is writable and the team is just dodging the writing. Sometimes the standard is not writable in advance at all, and pretending otherwise is how you end up shipping something that passed every stated condition and satisfies no one.

The open question, and the quiet risk

What I genuinely don’t know is how far the writable territory extends. Can we get to the point where we can author the equivalent of unit tests for knowledge work? Some domains will yield — there are corners of legal and financial work structured enough that a real rubric is coming, and a loop will own them. Some domains may never yield. Most sit somewhere on the spectrum between, and the honest position is that we don’t yet know where the lines fall.

It is tempting to believe the machines will close the gap for us by learning to judge open-ended work. They are not there. The current best attempt — using a strong language model as the judge of another model’s output — is real and useful and also documented to drift and contradict itself, giving the same work different scores across runs, with a catalog of systematic biases toward length and surface form. An unreliable judge does not rescue you from needing to know what good is. It just hides the moment you stopped knowing.

So the risk I actually worry about is not that we fail to measure the unmeasurable. It is that we route around it. Faced with work whose “done” resists specification, the path of least resistance is to quietly reshape the work into the part that can be specified, automate that, and let the rest atrophy — to optimize for the measurable and, as Jerry Muller documents across a dozen institutions, come to treat whatever resisted measurement as if it were never the point. That is not a failure of the technology. It is a failure of nerve dressed up as efficiency, and it is the most likely way good work gets thinner without anyone deciding that it should.

A loop is a bridge. It will carry you, tirelessly and faithfully, from a problem to a solution — but only to a solution you can already describe well enough to recognize when you arrive. It does not find the far bank for you. You still have to know the end from the beginning, and for the work that actually matters, knowing the end was always the job.

If this is useful, the place I work these ideas out in long form is AndrewLewisWasHere. Subscribe there, or forward this to the person on your team who’s about to point a loop at work that ships as the artifact itself.

A senior leader asked a simple question in a governance review last week: can we audit and verify every action an agent takes? Not the model’s reasoning, not the prompt — the actions. The edits, the sends, the deletions. The honest answer was no. Not yet. And the more I sat with that “not yet,” the more I realized it is the actual story of agentic AI inside a regulated firm, and almost nobody is telling it.

The entire public conversation about agents is about capability. How much access should they have. How autonomous should they be. Whether to let them run in a loop until a goal is met. Those are real questions. They are also the wrong ones to lose sleep over, because they are downstream of a quieter fact that has already shipped.

The agent runs as you

When a lawyer sets up an agent, the agent does not operate in some sandbox beside their work. It operates inside their identity. Microsoft’s own documentation for Microsoft 365 Copilot agents is explicit about this: an agent runs under the user’s identity, accessing data and services according to the permissions already assigned to that user. The agent inherits the person.

In a law firm, that inheritance is not abstract. It means the agent can open the matter, edit the document, send the email, and delete a file from the document management system — because the lawyer can. The newer agent layers that sit inside everyday tools, the ones that took Copilot from “draft me a paragraph” to “go do the thing,” did not just add a feature. They quietly handed a non-human process the full reach of a licensed professional.

So the unit of risk was never the agent’s cleverness. It was the agent’s authority. And that authority is borrowed, silently, from a person who may never see how it was used.

Accountability used to live in a person

The reasonable objection is that we never had a clean audit trail for humans either. That is true, and it is worth conceding plainly. A lawyer who made a hundred small decisions in a document did not generate an inspectable log of each one. The record, where it existed, lived in systems IT could comb through after the fact, not in anything the practitioner reviewed.

But accountability did not depend on that log, because it lived somewhere more reliable: in a licensed person you could question. You could ask a lawyer why they did something and get an answer, because they were present for the doing. Responsibility and awareness were the same thing.

An agent breaks that link. The action still carries the lawyer’s authority — their permissions, their identity, their name on the matter — but the awareness is gone. The person who is accountable was not in the room. The trail still exists for IT to assemble; tools like Purview will surface agent activity to administrators and compliance teams. What does not exist is a view that puts “here is what your agent did, under your name” in front of the one person who has to answer for it.

That is the gap. Not logging. Surfacing, to the accountable party, in time to matter.

The unsolved part is judgment, not logging

Here is the part I am genuinely unsure about, and I would rather name the uncertainty than pretend past it. Even if you capture every action — and increasingly you can — it is not obvious that you can present that record to a non-technical professional in a form they can actually use.

A partner does not want a JSON event stream. They want to know whether the thing the agent did was the thing they would have done, and they want to know it without becoming an engineer. The hard problem is not storage. It is translation: turning a machine’s actions into something a human can apply judgment to, fast enough to catch a mistake before it leaves the building. I have not seen anyone solve that well, and I am not certain the interface even exists yet.

What I am certain of is the asymmetry. Capability is compounding on a monthly cadence — new agents, broader access, longer autonomous runs. The ability to answer for any of it is not moving at the same speed. Every month that gap widens is a month a firm is accumulating authority it cannot account for.

The smaller question

There is a temptation, when a tool gets more powerful, to spend all the governance energy on the frontier — what should we let it do next. That energy is misallocated if you cannot yet answer for what it has already done.

Before you give an agent more of what it can do, you have to be able to answer the smaller question. Not the impressive one about capability. The unglamorous one about accountability.

What did the agent do? What can it do? The second question is getting all the attention right now. The first is the one with your name on it.

I write every week about AI as an operational discipline inside regulated firms — the work behind the work that does not show up in the vendor demo. If that is your world, subscribe.

McKinsey just published the stat that every AI strategy deck will be quoting for the next year. In Rewiring software delivery for the agentic era, the firm reports that organizations adopting agentic delivery models are seeing threefold to fivefold productivity improvements alongside a 60 percent reduction in average team size. Teams of eight to twelve become pods of three or four: a product owner, a tech lead, and an AI-enabled engineer supervising a factory of agents that works through the night.

The accepted read writes itself. AI makes teams smaller and faster. Buy the agents, shrink the teams, collect the productivity.

But the article also lists, almost in passing, what the model requires before any of it works, and that list is the part worth reading twice. The business needs a clear enough vision of what is being built that agent output can be judged against it. The technical environment has to be standard and consistent. The path from requirements to code has to follow a structure agents can reliably interpret. Requirements, guardrails, and specifications have to be codified in machine-readable formats instead of scattered across disconnected documents. And the same core stakeholders have to stay engaged across the entire value stream, or everything downstream turns into rework.

Strip out the agent vocabulary and read that list again. It describes a team that has made its own work completely legible to itself. Decomposed operations, explicit intent, defined review gates, and shared context that lives in the system rather than in someone’s head. The agents are downstream of all that. So is the 60 percent.

Nimbleness is a visibility property

“Nimble” usually gets read as small and fast, which is why the team-size stat will travel further than anything else in the article. But team size was never the constraint. The constraint is whether anyone can see the work structurally.

A team that understands its own work as a system of operations — what gets produced, what gets handed off, what intent governs each piece, where judgment is non-negotiable — can re-form around a new mission in days. A team that experiences its work as a continuous stream of tasks, meetings, and messages is rigid at any size, and handing it a factory of agents produces exactly what McKinsey warns about: fragmented output that nobody trusts. The small team is a consequence of the legible one.

Structure is a fossil of coordination cost

There is a reason team structure resists this, and Ronald Coase named it in 1937. The Nature of the Firm argued that firms exist because coordinating through the open market costs something: finding people, negotiating, enforcing agreements. The same logic shapes structure inside the firm. Layers, roles, and handoffs exist to manage the cost of communication, translation, and oversight. The professional services pyramid is the cleanest example anywhere — juniors produce, seniors review, and the ratio between them is priced directly into the business model. Org charts are fossils of what coordination used to cost.

When a technology collapses specific coordination costs, structure sized for the old costs turns from scaffolding into drag. McKinsey’s own pipeline analysis makes this concrete: the bulk of delivery effort sits in requirements through coding, where humans spend their days translating intent from one artifact to another. Every translation is a coordination cost. The agentic model removes the human from those handoffs entirely, with review concentrated at defined gates. The structure built to manage the handoffs does not dissolve on its own. Someone has to notice it is now load without purpose.

Intent travels better than instructions

If detailed structure recedes, something has to replace it, and the strongest answer is older than software. After Napoleon dismantled the Prussian army at Jena in 1806, the reformers who rebuilt it concluded that battlefield conditions changed faster than orders could travel. Helmuth von Moltke the Elder later gave the principle its lasting form: no plan of operations survives first contact with the enemy. So commanders stopped issuing detailed instructions and started transmitting intent — what must be achieved and why — leaving subordinate officers to decide how, on the ground, as conditions shifted. The Prussians called it Auftragstaktik. The modern term is mission command.

McKinsey’s daily sprint is mission command in a different uniform. During the day, humans resolve ambiguity, set guardrails, align stakeholders, and define what acceptable looks like. Overnight, execution runs against that intent at scale. In the morning, review happens at the gates. Intent travels into the night shift; instructions never would.

This is the actual design principle for team nimbleness in the agentic era: a mission plus short-term goals. The mission states what must be true and why it matters. The short-term goals create checkpoints where intent gets recalibrated against what execution revealed. The compression from two-week sprints to daily cycles matters less than what made it possible — clearly transmitted intent needs far less planning apparatus wrapped around it.

Getting legible

None of this tells a leader how to make a team legible to itself, and I am suspicious of anyone selling a template for it. The honest version is a set of questions, asked of the team’s work rather than its org chart. What operations does this team actually perform — operations, not roles? Where does intent currently live: written somewhere a system could read it, or in the heads of two senior people? Which handoffs in the workflow are translation, and which are judgment? What does “done” mean for each operation, and who decides?

Most teams cannot answer these today. That is not a failing; nobody has ever asked them to see their work this way. The structural view is developed, not installed, and there is no vendor for it. Which is precisely why it is the work behind the agentic numbers rather than a line item in the deployment budget.

The harder case

Software is the easy case, and McKinsey says so directly: the way agents are being used in software development is a harbinger for broader delivery models. Decades of version control, ticketing systems, and CI/CD have already made software work partially legible. Requirements and code leave trails by default.

Professional services work mostly does not. In a law firm, intent lives in precedent files, marked-up drafts, and the accumulated judgment of senior practitioners. The pyramid prices translation in as oversight and calls it development. The legibility debt is far larger than in software, which means the work behind the numbers is heavier — and the advantage for any firm that does it is correspondingly larger, because almost nobody in the market has started.

There is also a structural bind worth naming. Re-decomposing a team’s structure requires someone to sign for it, and in conservative institutions nobody wants their name on the new org chart. Missions carry less weight. A mission expires; a structure has to be defended indefinitely. That makes mission-based nimbleness more available to a regulated institution than restructuring. A three-month mission with short-term goals and defined review gates asks nothing of the org chart, and it quietly builds the legibility that any future structure will depend on.

The 60 percent will circulate as proof that AI shrinks teams. Read the preconditions instead and it proves something quieter: the organizations collecting those numbers did an unglamorous body of work first. They made the work visible and the intent explicit before any agent touched it. The team got smaller because the work got legible.

AI doesn’t make teams nimble. It exposes which teams already did the work of seeing themselves clearly.

If this resonated, subscribe to get the next piece on the work behind the work — the human capability development that AI adoption quietly depends on.

Somewhere in your organization this week, an AI-drafted document was approved by someone who did not fully read it. Not from laziness; from arithmetic. Machine-generated drafts, summaries, analyses, and reports now arrive faster than the people responsible for them can check, and the gap widens every month, in every department, whether or not anyone has said it out loud.

Software engineering is simply where that gap is measured best, because no other knowledge work is so thoroughly instrumented. The numbers from that world deserve attention from everyone whose job produces documents rather than code, since developers are only the first to hit a wall the rest of us are approaching. LinearB’s 2026 benchmarks, built from 8.1 million pull requests across 4,800 engineering teams, found AI-assisted work waits 4.6 times longer for a first review than human-written work, and barely a third of it gets accepted, against 84.5 percent for the unassisted kind. A queue is forming in front of the one resource AI cannot multiply: a person willing to say this is correct.

The perception side is stranger. When METR ran a randomized trial with experienced open-source developers, participants believed AI had made them roughly 20 percent faster while the measured result was 19 percent slower. METR’s own 2026 follow-up suggests that slowdown has likely narrowed or reversed as the tools improve, so treat the direction as provisional; the durable finding is the gap itself. The people closest to the work could not tell whether it was going faster. If that is true in the most measurable profession on earth, consider the odds that anyone drafting contracts, reports, or board memos with AI knows their real number.

The standard interpretation of all this is that review is too slow. Leaders read these numbers and conclude they need faster reviewers, AI-assisted checking tools, better queue management. The vendors agree enthusiastically, because every one of those conclusions has a product attached to it.

The standard interpretation is wrong. The numbers describe a system where generation capacity and verification capacity have decoupled, and no amount of review acceleration reconnects them. Sonar’s 2026 State of Code survey of more than 1,100 developers found AI now accounts for roughly 42 percent of committed code, expected to reach 65 percent by next year. The same survey found 96 percent of developers don’t fully trust that code to be correct, only 48 percent always verify it before committing, and 38 percent say reviewing AI output takes more effort than reviewing a colleague’s work. Read those findings together. This is a machine that produces artifacts faster than anyone can check them, staffed by people who know the artifacts are unreliable and have quietly stopped checking anyway. Swap the code for contracts, research summaries, financial models, or marketing copy, and nothing in that sentence changes except the file format.

The question worth asking is what verification even means once output volume crosses review capacity. The answer is structurally different from what most organizations are building.

Two curves, only one of them moves

A recent economics paper on the automation frontier frames the problem as two competing cost curves. The cost of generating an artifact (code, a brief, a report, a vulnerability finding) falls exponentially as models improve. The cost of verifying that artifact stays roughly where it has always been, because it is bounded by human cognition. A senior developer can meaningfully review somewhere around 150 lines of code an hour. A careful reader of contracts, research memos, or financial models moves at a similarly fixed pace, and has for as long as those documents have existed. Attention does not get firmware updates, and there is no model release on any roadmap that changes it.

Engineers at Agoda reached the same conclusion from production data: AI tools measurably raised individual output while project-level velocity barely moved, because coding was never the real constraint. The constraint sits upstream, in specification and verification, the two activities that require human judgment. They frame this as a rediscovery of Fred Brooks’ forty-year-old argument that accelerating one stage of a pipeline buys you almost nothing if the binding stage is elsewhere. The industry has spent three years accelerating the stage that was never binding.

When one curve falls exponentially and the other stays flat, the gap between them compounds. This is the part most adoption conversations skip. An organization that responds to a compounding gap with linear capacity (more reviewers, longer review windows, a second approval step) has chosen to lose slowly rather than rethink the game. The arithmetic forecloses the strategy before the first hire is made.

The same Agoda piece offers a useful taxonomy of the postures available once you accept that. You can read every line AI produces, the white-box stance, which preserves full assurance and caps your throughput at exactly the 150 lines an hour you had before. You can ship whatever the machine generates, the black-box stance, which is fast right up until it meets a production system with real users and real consequences. Or you can verify selectively, at boundaries and against intent, accepting that assurance is now a budget to be allocated rather than a property to be assumed. The same three stances exist for every AI draft that crosses a desk, whether the desk belongs to an engineer, a lawyer, or an analyst, and whether anyone has named them or not. Most organizations are running the third stance already. Few have admitted it, and fewer still have decided deliberately where the budget goes, which means the allocation is being made anyway, by default, by whoever is most tired on a given afternoon.

I work inside a national law firm, where this arithmetic has a sharper edge than it does in software. A pull request that ships with a subtle bug costs you an incident. A factum that ships with a fabricated citation costs you a professional reputation, and possibly a client. The stakes are asymmetric: the price of being wrong exceeds the benefit of being right, which means verification cannot be quietly abandoned the way half of those surveyed developers have abandoned it. Regulated industries never get the option of not checking; the only choice available is what to check.

That phrase, choosing what to check, is the actual answer to the scaling question, and everything else in this piece is an elaboration of it.

What the tools actually do

The toolchain that has grown up around this problem is usually marketed as verification capacity. Guardrails, evals, LLM-as-judge pipelines, formal methods, provenance tracking. The framing is that these tools let you check more. Watch how each one actually works and something close to the opposite is true: each earns its keep by deciding what will never be examined, and by making that decision survivable.

Guardrails verify boundaries instead of artifacts. A guardrail doesn’t ask whether an output is good; it asks whether the output crosses a line you drew in advance: leaks data, violates a policy, exceeds a risk threshold. Production guardrail systems, like the centralized service Singapore deployed for its public chatbots, work precisely because they refuse to evaluate quality. They evaluate violations, which is a vastly smaller problem. The honest description of a guardrail is a decision about which failures you can afford to detect cheaply and which ones you’ve accepted you won’t catch at all.

Evals and judge pipelines apply the same selective logic to quality. Rubric-based evaluation has become the working standard for assessing open-ended AI output at scale, and it earns its place. But a judge model scoring outputs against explicit criteria is a statistical instrument. It reports on the distribution, calibrated periodically against human experts, carrying known biases toward verbose answers and toward output resembling its own, and it stays silent on whether any individual artifact is correct. Teams that treat eval scores as verification have confused quality control sampling with inspection, and the difference matters enormously when one bad artifact can hurt you.

With specifications, the selection happens upstream. The most interesting shift in engineering practice right now is the argument, made well in Aviator’s analysis of the review bottleneck, that the only verification with an external reference point is verification against a spec a human has approved. Tests check behavior the test author imagined. A reviewer checks a diff against their reconstruction of what it was supposed to do. A spec is the one artifact in the pipeline where intent lives outside the generation loop, and verifying against it means a human did the hard thinking once, up front, so the checking inherits that thinking.

Formal methods verify guarantees instead of confidence. Leonardo de Moura, who built the Lean theorem prover, draws the line cleanly: testing provides confidence, proof provides a guarantee, and it is genuinely hard to quantify how much confidence testing actually buys you. Proof is expensive and narrow; you reserve it for the properties where confidence isn’t good enough. Which is, again, a selection decision.

Every tool that works at scale works by shrinking the verification surface, and every shrinking decision is a human judgment about what matters. The tools carry out triage decisions. They cannot make them.

When the verifier needs a verifier

The obvious move, once human review can’t keep pace, is to have AI verify AI. It is also the move with the nastiest failure mode, and the failures are no longer hypothetical.

SRLabs’ analysis of AI-generated security findings describes what happens when an organization layers AI security tooling on top of AI-generated code and treats the findings as decisions: the system becomes self-referential, producing artifacts faster than anyone can anchor them in an actual threat model. Teams under that load optimize for closing items rather than reducing risk, because closed items are measurable and risk reduction isn’t. The curl project reached the logical endpoint in January, ending its bug bounty after years of fielding AI-generated vulnerability reports that looked plausible and dissolved under scrutiny. The bounty had become a denial-of-service attack on maintainer attention.

Academia hit the same wall from a different direction. An audit of NeurIPS 2025 submissions documented a hundred fabricated citations that sailed through peer review, including placeholder hallucinations literally citing “Firstname Lastname,” because reviewers check methodology and novelty, and nobody’s job has ever been confirming that cited papers exist. The gap was always there. AI made it economical to exploit at volume. A related analysis of peer review itself puts the conclusion bluntly: when the rate of claims rises exponentially against fixed human bandwidth, collapse is a mathematical inevitability, and abstaining from AI assistance doesn’t preserve the system’s integrity; it just guarantees the system drowns.

And the judge models themselves are attack surface. Security researchers have shown judges that ignore their instructions when fed adversarial output, repeating attack strings instead of evaluating them. The fix proposed in that research is a guardrail on the judge — which should give you pause. We are now building verifiers for the verifiers, and there is no level of that tower where the regress stops on its own. It stops where a human owns an assessment and signs their name to it. Nowhere else.

Verification as deterrence

Earlier this year, in a long conversation about verification architecture, I landed on a framing I haven’t been able to shake: at scale, verification stops behaving like a truth-recovery problem and starts behaving like a deterrence problem. Closer to mutually assured destruction than to forensic investigation.

Truth recovery assumes you can, in principle, examine an artifact and determine whether it is correct. That assumption holds at human scale. It fails at machine scale, for the cost-curve reasons above, and the failure is permanent because the gap compounds. What remains achievable is a different posture entirely: making bad artifacts expensive to produce, cheap to contain, and traceable to a producer who bears the cost.

Look at what actually works in the systems under the most pressure and you find deterrence mechanics where you would expect inspection. Curl didn’t get better at detecting slop reports; it changed the economics of submitting them. The proposed fix for fabricated citations is mandatory existence checks rather than smarter reviewers, shifting the verification burden onto the claim, at the point of submission, where it costs the producer instead of the reviewer. Spec-driven development works because the spec makes intent auditable, which makes deviation attributable. And provenance tracking (who generated this, from what, under what instructions) won’t establish that an artifact is correct, but it establishes who answers for it if it isn’t, and that knowledge changes behavior upstream of any review.

The legal profession produced the cleanest illustration on record just this week. On June 8, a federal judge in Mississippi sanctioned every lawyer of record in a contract dispute after filings from both sides turned out to contain fabricated citations. The two out-of-state lead attorneys admitted using AI without verifying the output; local counsel had signed the briefs without reviewing them. The court revoked both out-of-state lawyers’ temporary admissions, barred them from appearing before the Northern District of Mississippi for two years, fined all four attorneys, cancelled the trial, and referred everyone to their state bars. The instructive part, read as a verification story, is the remedy the court chose: no call for better detection tooling, just consequence attached to the signature. The ruling’s principle, that responsibility “remains the sacred duty of the lawyer who signs the page,” is deterrence doctrine written by a judge who understood the problem more clearly than most AI strategy decks do.

The pipeline I sketched afterward runs adversarial passes from different model families against a primary output: fact checks, logic checks, an audit of unstated assumptions. The design process taught me something I didn’t expect. Certifying outputs as true was never on the table; no architecture I could draw gets you there. What a design like this can do is make certain classes of failure reliably expensive to get past, which changes what is worth attempting in the first place. Deterrence, functioning exactly as deterrence does.

This reframe matters because it redirects investment. An organization pursuing truth recovery buys review capacity and falls further behind every quarter, while one pursuing deterrence builds chokepoints, assigns ownership, and engineers consequence — and the second approach scales, because consequence does the verifying for you, continuously, at every point of production you can’t see.

The part no tool covers

All of which leaves the question every playbook quietly assumes is already answered: who decides what deserves verification in the first place?

Every mechanism in this piece runs on a prior human judgment. Which boundaries the guardrails enforce, what the rubric rewards, where formal proof is worth its cost, and what gets sampled, gated, or waved through. The tooling industry talks about these as configuration details. They are the entire game. A perfectly engineered verification stack pointed at the wrong things is expensive theater, and the security teams optimizing for closed findings while risk accumulates elsewhere are running exactly that theater right now.

The judgment involved is the capability I keep circling in this newsletter: signal discrimination. Knowing, when you face more artifacts than you can examine, which ones matter: by consequence, by blast radius, by the asymmetry between what a wrong artifact costs and what a right one earns. In my world, an AI-drafted internal summary and an AI-drafted court filing might come from the same tool on the same afternoon, and they belong in entirely different verification regimes. Nothing in the tooling knows that. A person has to, and that person has to be willing to own the call, which in most organizations is the genuinely scarce resource. The technology of verification is improving fast. The willingness to sign one’s name to “this is checked enough” is not, because the signature carries all the downside and none of the credit.

So the real playbook, stripped of vendor language, is short. Decide what failure costs, per artifact class, before deciding what verification it gets. Push the burden of proof onto the producer wherever you can: specs, provenance, existence checks at the point of claim. Use machines to sample distributions and patrol boundaries; reserve humans for the artifacts where consequence is asymmetric. And put a name on every assessment, because an unowned verification is a rumor with a checkmark on it.

None of that is a technology roadmap. It is judgment, exercised in advance, encoded into a system — which is to say it is work most organizations have not done, and the tools they’re buying cannot do it for them. The verification crisis everyone can now measure looks less like a case for better checking machines than like a bill arriving for a question that got skipped: what, in all this output, actually matters?

AI doesn’t make you better. It exposes whether you were already doing the work.

If this kind of analysis is useful, subscribe — one piece like this every week, written from inside an institution doing the work in real time.

The McKinsey numbers do not need a second read to be sobering. The first read does the job.

The State of Organizations 2026 surveyed more than ten thousand senior leaders across fifteen countries and sixteen industries. Eighty-eight percent of organizations are deploying AI in at least parts of their business. Fewer than twenty percent see significant impact on the bottom line. Eighty-six percent of leaders say they are not ready to embed AI into day-to-day operations. One in six organizations has no clear C-level owner for AI adoption at all.

HBR’s “last mile” diagnosis from a closed-door Harvard summit fills in the texture McKinsey’s spreadsheet cannot. The summit included a global investment bank with more than two hundred and fifty LLM-connected applications in production, a payments network where copilot adoption sits above ninety-nine percent of employees, and an apparel group running eighteen thousand automated finance processes. In every one of those firms, finance teams hunt for measurable impact in headcount and cycle-time numbers and come up empty. The work is happening. The value is not landing.

Andrei Savine pulled both pieces together in March: enterprise AI dies in the last mile because organizations under-funded the operational layer that turns model output into business value. He calls it the Production Layer. He cites an executive in the McKinsey report who put the corrective ratio at five to one — for every dollar spent on technology, five should be spent on people, process, and verification.

That diagnosis is correct.

That diagnosis is also a tourist map.

Inside the firm, the disconnect is on the calendar. A partner explains why AI will not materially change the way they practice. The IT department, meanwhile, is months into a slow restructure built on the opposite assumption. Both positions are held with conviction. Neither side can yet describe the outcome on the other side of the change.

The general diagnosis works at the macro level because it abstracts away the structural features of the firms it describes. Software companies can absorb productivity gains by reducing headcount. They have CEOs who can decree adoption. Their work product is a piece of software, not a lawyer-hour. None of that is true in a law firm.

This piece is a map of what the last mile actually looks like inside one. The hazards in the terrain. The path that does not end in either a mass layoff or a restructuring announcement masquerading as strategy. The question is not whether five-to-one is the right ratio. It is whether law firms know what the five is supposed to build.

Why the General Diagnosis Underestimates Legal

The five features that make a law firm break the standard model are not exotic. They are the structure of the business. Anyone who has worked inside a firm knows them. Anyone trying to apply a generic enterprise-AI playbook to a firm runs into them within the first quarter.

Start with the billable hour. The standard productivity gain from AI is a productivity gain. In a firm billing by the hour, the same gain is a revenue cut unless something changes upstream. Two software companies have absorbed their productivity gains by reducing headcount in the last few months — roughly 1,600 people at Atlassian, and a 2,000-person restructure at WiseTech shortly before. Law firms cannot run that play. The work product is the lawyer-hour itself. Wolters Kluwer’s 2026 Future Ready Lawyer survey of 810 lawyers found 54% expect firms to use AI efficiency for more clients or competitive pricing; the 2024 edition projected that AI automation could reduce hourly billing per lawyer by roughly $27,000 a year. Those numbers cut against revenue, not toward it. The inversion is what makes generic AI advice land badly in partner meetings: efficiency arguments are heard as compensation arguments.

Beneath the billable hour sits the apprenticeship. Junior associates learn judgment by doing the work AI does best — first-pass document review, citation checks, due diligence summaries, contract redlining. The training pipeline runs through the same activities AI is now positioned to consume. Automate the work without redesigning the apprenticeship, and the firm produces senior associates whose calibration never developed. The Citi Hildebrandt 2026 Client Advisory reports revenue growth of 11.3% across surveyed firms, productivity per lawyer down 0.6%, and 88% of firms planning continued associate growth — built on the assumption that the apprenticeship pipeline still works. The assumption may not hold.

Governance compounds the problem. McKinsey’s number — one in six organizations without a clear C-level AI owner — understates the legal case. In an equity partnership, even a C-level owner cannot decree adoption. Decisions move through practice-group chairs, executive committees, and partner votes. The ILTA 2025 Technology Survey of 580 firms found that user resistance is the top barrier to AI adoption at 57%, up from 54% the year prior; half of those firms have no formal AI policy at all. The gap is not a failure of legal IT. It is a structural feature of how authority is held and exercised in a partnership.

Privilege and conflicts sit beneath the policy gap. Technical friction in legal includes constraints other industries do not face. Solicitor-client privilege. Conflict-of-interest screens. Data residency for regulated client matters. Prohibitions on third-party model training. Ethical-wall enforcement that must survive at the model and the prompt level. ABA Formal Opinion 512 and the Federation of Law Societies of Canada Model Code both treat AI use as a competence question, a confidentiality question, and a supervision question simultaneously. The provincial regulators — Ontario, British Columbia, Alberta, and the Barreau du Québec — have all issued guidance that constrains which tools are usable for which matters. None of this is a security checklist. It is a substantive constraint on adoption.

Last comes the asymmetry. The price of being wrong exceeds the benefit of being right. Mata v. Avianca made the failure mode public in 2023. Damien Charlotin’s AI Hallucination Cases Database has been logging the failure mode ever since, at the rate of dozens of new entries per month from courts in more than a dozen countries. The downside of an AI-fabricated citation is career-ending. The upside of an AI-generated brief is incremental. When the loss function is asymmetric, rational professionals default to avoidance — which produces exactly the shallow utilization HBR’s last-mile diagnosis describes.

Generic diagnoses do not survive these five features. A different map is needed.

The Map: Five Hazards in the Terrain

These hazards are not theoretical. They are already arriving.

Hazard 1 — The Apprenticeship Gap

The work AI handles best is the work juniors learn from. Document review. Due diligence summaries. Citation checks. Contract markup. Strip those activities out without replacement and the firm is running an apprenticeship system whose training data has been deleted.

The signal does not appear in the first year. It appears two and three years in, when an associate who learned to draft alongside an LLM is asked to negotiate a non-standard term in a deposition prep meeting and cannot triangulate why the standard term existed. The output looks fine. The pattern-matching against past work — the thing that turns a third-year into a fourth-year — has not happened.

The hazard sits at the intersection of two operating questions. The decomposition question asks what the junior was actually doing inside the document review. Some of it was the review itself. Some of it was learning what a representation looks like when it is doing real work in a credit agreement, learning which questions to ask before flagging an issue to a senior, learning the difference between a problem and an artifact of the drafting party’s preferences. The collaboration-quality question asks what the junior was learning by doing the work, not what they were producing. If only the production is automated, the learning evaporates with it.

The Citi Hildebrandt advisory caught the contradiction. Firms are still planning associate growth on the old assumption — that the same training pipeline still works — while productivity per lawyer ticked down. The senior-heavy staffing model some firms are leaning into assumes juniors continue to develop into seniors capable of senior work. The pipeline that produced that development is being quietly automated. The hazard arrives on the promotion clock. Juniors will keep being hired; the calibration that used to develop alongside them will not appear on schedule, and the firm will not notice until the class it tries to promote is already on the partnership runway.

Hazard 2 — The Pricing Collision

The hourly model inverts under AI. The same brief that took twenty hours last year takes seven this year. The client knows. The client has run the spreadsheet.

The signal arrives in the form of an RFP that asks specific questions. Which tools does the firm use? On which matter types? What productivity assumption is baked into the proposed rates? The 2025 ACC Chief Legal Officers Survey, summarized in subsequent analysis, found that 59% of general counsel see no clear cost savings from outside counsel using AI. A transparency gap, the report called it. That phrase will appear in a procurement deck within twelve months.

Pricing models that align with the new reality already exist. Fixed fees. Capped fees. Success fees. Capacity-based arrangements. AI-augmented hourly with a productivity discount. The menu is not new. What is new is the pressure to choose, and the pressure to choose visibly. Thomson Reuters’ 2025 Future of Professionals projects up to 240 hours per professional saved per year by AI-augmented workflows; the 2024 edition projected 12 hours per week saved by 2029 and roughly $100,000 in additional billable hours per U.S. lawyer. Those numbers are useful to a firm that has redesigned its pricing to capture them. They are punitive to a firm that has not.

This hazard is the one most likely to drive the same failure mode inside legal. A firm that does not redesign pricing and roles will eventually balance the books with headcount. The redesign is uncomfortable. The alternative is worse. The choice is whether to lead the pricing conversation or inherit one shaped by clients who started running their own AI math two budget cycles ago.

Hazard 3 — The Judgment Hollowing

Apprenticeship is about who comes next. Judgment hollowing is about who is already in the chair.

Senior judgment was built on years of doing junior work. Take that work away through AI mediation — not removal, mediation — and judgment does not develop the same way. The hazard appears in two opposing modes. One is overtrust: lawyers who accept AI output uncritically because the immersion that produced calibration has thinned out. The other is blanket rejection: lawyers who refuse to engage with AI assistance because the output feels uncalibrated even when it is sound. The first failure ships errors. The second ships sluggishness. Both come from the same root.

This is what skill-formation research in adjacent professions has been pointing at. When the practice that produced calibration is mediated, calibration drifts. Output calibration and signal discrimination — the two senior capacities that distinguish a partner from a senior associate — degrade in opposite directions when the underlying practice that built them disappears. The senior who used to read a memo and feel the wrong sentence is still reading the memo. The reading is faster. The feel is duller.

The signal is not visible on a dashboard. It is visible in review cycles. A senior who used to spot the problem in the first pass now spots it in the third. A junior whose draft used to be rebuilt is now approved with light edits — not because the draft is better but because the senior’s bar moved. The work product reads acceptable in both cases. The institutional capability does not develop. The hazard is the part of the iceberg the engagement letter cannot describe and the matter close-out cannot bill.

Hazard 4 — The Partnership Fracture

Adoption splits the equity table. Litigation moves on one tool while M&A holds out. IP runs a different stack than tax. Practice groups operate as small businesses inside the firm; their adoption velocities can diverge by a factor of five within the same year, and the divergence shows up in realization rates before it shows up in compensation discussions.

The ILTA 2025 survey captured the inflection point. Eighty percent of firms reported using or exploring generative AI. Half reported no formal AI policy. Those two numbers describe a partnership in which adoption is happening faster than governance, and where the governance vacuum is being filled at the group level by whoever decided to act first.

The signal is not the adoption rate. The signal is the compensation tension that follows. Two practice groups that bill different realization rates against similar matter types invite a comp-committee conversation no managing partner enjoys. Recruitment messaging that promises one thing across a firm where the lived experience varies by group invites a different conversation with laterals. The fracture is not technological. The fracture is political, and it arrives on the partnership’s calendar approximately one fiscal year after the first group commits to its first material AI deployment.

Inside the firm, the divergence is already concrete. One practice group, pressed by a client to deliver AI-driven efficiencies, has mandated tool use and is rebuilding workflows accordingly. Other groups have not opened the conversation. All of them sit inside the same partnership. The comp committee will eventually have to reconcile what the calendar already shows.

The leadership challenge in this hazard is velocity matching, not adoption. Getting compatible adoption velocities across groups is a different problem from getting any adoption at all, and it is not solved by the same instruments.

Hazard 5 — The Asymmetric Stakes

The price of being wrong exceeds the benefit of being right.

Mata v. Avianca was the warning shot — a Southern District judge, a $5,000 sanction, and the first widely circulated story of fabricated citations submitted to a federal court. Charlotin’s database has been the running count ever since: well over a thousand decisions tracked across more than a dozen countries, with new entries arriving at the pace of dozens per month. Johnson v. Dunn, decided in the Northern District of Alabama in July 2025, extended the line into BigLaw. A practice-group co-leader at a large, well-regarded firm signed a motion containing fabricated citations. The court signaled that monetary sanctions are no longer sufficient to deter AI-generated errors, and that future cases may see referrals to bar counsel and other escalations.

The signal is not the headline cases. The signal is the malpractice underwriting questionnaire. Carriers have started asking which tools a firm uses, for which matter types, with which verification process. Some are writing AI-specific exclusions. The Federal Court of Canada has issued a notice to the parties and the profession on AI in court proceedings; provincial superior courts have followed; U.S. district courts have done the same on a docket-by-docket basis. Disclosure of AI use is no longer optional in many jurisdictions, and in some it must include disclosure of how the AI was used.

The hazard lives in the loss function. As long as one fabricated citation costs more than ten useful drafts save, the rational play is to avoid the tool — and that avoidance is what produces the shallow utilization the survey data keeps measuring. The accountability avoidance pattern McKinsey identifies is rational behavior in an asymmetric environment. Resolution is not the elimination of risk. Resolution is clarity about who is responsible for which verification, at which step, with what record.

Five hazards. None of them appear on the McKinsey or HBR map. The path through them is what the next section describes.

The Path: What Implementation Actually Looks Like

Six moves. Each one resolves a hazard. None of them resolve all the hazards. The work has to be done in sequence and in combination.

Move 1 — Start with measurable operations before client-facing work

Knowledge management. Marketing. Finance. IT. Recruiting. These are the practice areas of the firm where measurement is possible, where the stakes are bounded, and where the team can build the muscle for measurement before pointing AI at client matters.

The reason this comes first is not theoretical. A firm that cannot measure value in its own back office has no business claiming to measure value in client work. Most firms skip the step anyway, because the political appeal of a client-facing pilot is too strong. There is a partner who wants it. There is a vendor who will demo it. There is a press release in the budget. The internal pilot is less photogenic. It is also where the failure modes show up cheaply.

What measurable internal deployments produce is more valuable than the deployments themselves. Real numbers. Real failure modes. Real governance precedents. The early adopters of internal AI become the people who teach the practice groups, because they have already had the embarrassing first conversation with privacy, the awkward second conversation with risk, and the corrective third conversation with finance.

A firm that has not staffed its internal AI team before standing up its client-facing AI team is not running an enterprise AI program. It is running a procurement exercise with extra steps. The move that says “we will start where it matters most” sounds bold and usually fails. The starting point that matters most is the one where mistakes cost the least.

Move 2 — Run the Task Audit at the practice-group level, not the firm level

A litigation matter is not an M&A transaction is not a regulatory filing is not an IP prosecution. The work is structurally different. The AI fit is structurally different. The realistic adoption pace is structurally different. Firm-wide rollouts produce shallow utilization because they ignore those differences and try to deploy one set of tools, with one set of metrics, across groups that need different things.

What the federated version looks like is unglamorous. Each practice group decomposes its own work into the activities that compose a matter — research, drafting, review, analysis, communication, project management. Each group runs its own audit of where AI fits, where it does not, and where the answer is uncertain. Litigation may find AI fits document review and timeline construction; M&A may find AI fits diligence summaries and disclosure schedule drafts; tax may find narrow but high-value uses around regulatory text comparison. Each group owns its own map.

This is what the HBR prescription — redesign roles, budgets, and processes — looks like when the redesign is translated into a firm. Not a firm-wide redesign. A federated one, in which the firm-level work is to set guardrails and standardize the verification, and the group-level work is to choose the use cases.

The Task Audit is the artifact. The honest version takes a quarter per group and produces something a partner can defend in a comp committee. The dishonest version takes a week, looks like a deck, and ages badly.

Move 3 — A single accountable owner per practice group, not a committee

Committees defer. Owners decide. McKinsey’s number — one in six organizations without a clear C-level AI owner — is worse in legal, because even where an owner exists at the firm level, the partnership structure dilutes accountability. The committee is the partnership’s default response to a contested decision, and AI adoption is a contested decision.

What works is a named partner in each practice group who owns AI decisions for that group. Not a committee chair. Not a project sponsor. Not a steering-group member. An owner — someone whose performance review includes a line item for the group’s AI capability development, and whose decisions do not require a partnership-wide vote to take effect inside the group. The owner reports up to a chief AI officer or equivalent at the firm level, but the accountability lives at the group level because that is where the work lives.

This configuration is unfashionable in firms that prefer consensus. It is also the only configuration that produces decisions on the timeline AI requires. The alternative is a steering committee that meets monthly, defers two of the three decisions on the agenda, and ratifies the decision a partner already made between meetings.

The named-owner model has a useful side effect. Partners who own decisions become accountable for outcomes. Partners on committees do not. Functional AI capability over the next three years will sit with firms that staffed for ownership early, not with firms that staffed for governance theater.

Move 4 — Redesign the apprenticeship deliberately

The apprenticeship gap does not close by accident. It closes by design — or it does not close.

The redesign question is not how the firm automates junior work. The redesign question is what juniors do instead, such that they emerge with the judgment senior practice requires. The automation question is the easy one. The redesign question is where the actual capacity sits.

What the redesign looks like in practice is structural. A second-year associate who used to spend a third of their hours on first-pass review now spends a third of their hours on something else. The “something else” has to do for the second-year’s development what the first-pass review used to do. Possibilities exist. Supervised secondary review, where the associate critiques the AI’s output and learns to spot what a senior would spot. Structured client-interaction time, where the associate develops the judgment that is hardest to automate. Deliberate cross-practice exposure, where the associate sees how a deal partner and a litigator weight the same fact pattern differently. None of these is automatic. All of them require partner time, which is the scarcest resource in a firm.

The cost of the redesign is real. The cost of not redesigning is realized in five years, when the firm tries to promote a class of senior associates and discovers their calibration is not where it needs to be. The redesign work flows into Section 4, where role redefinition becomes the unit of analysis.

Move 5 — Address pricing before clients force the conversation

The general counsel office is going to ask. Better to have an answer than to be asked. Better to have proposed the answer than to be in defensive negotiation when the question arrives, because the question will not arrive politely.

Fixed fees. Success fees. Capacity arrangements. AI-augmented hourly with a productivity discount. The menu exists. The choice is which structure fits which matter type and which client. The choice is also which structure preserves margin while signaling that the firm has thought seriously about the productivity assumption clients are making.

Pricing is not a finance department problem. Pricing is a partnership problem, because the realization-rate consequences of every pricing experiment land on individual partner P&Ls. The right pattern is to run experiments inside specific practice groups, with specific clients, on specific matter types, and harvest the data before the pricing committee tries to set a firm-wide policy. Firm-wide policy on pricing arrives last, after the experiments.

This is uncomfortable. It is also where the strategic self-direction question gets answered. Firms that lead the pricing conversation define the market. Firms that wait inherit a market other firms defined. The Wolters Kluwer survey found 54% of lawyers expect firms to use AI efficiency for more clients or competitive pricing — the client side has already done the math. The question for the firm is whether the math gets done in the partnership’s frame or in the client’s frame.

Move 6 — Measure capability development, not hours saved

Hours saved is the metric that produced those software-industry cuts. It is the wrong metric in legal, because the answer to “what did we do with the saved hours” cannot be “we cut the people.” The model does not work if the people are gone. The whole apprenticeship hazard, the whole judgment-hollowing hazard, every reason a firm has a future at all is grounded in the people being there to develop into the next generation of senior practitioners.

What to measure instead lives at the capability layer. Practice-group adoption depth — how many lawyers in the group are using AI for substantive work, not for one-off email drafts. Output calibration scores against blinded review. Role evolution — whether roles are changing in the direction the firm intends, or drifting. Time reinvested — when a task that took ten hours takes three, where do the seven hours go, and what shows up at the end of the quarter that did not exist at the beginning.

The five-to-one ratio from the McKinsey advisor surfaces at this move. Five-to-one is not a budget rule. It is a measurement principle. If the dollar count on the people side is small, the measurement on the people side will be small, and the capability the people side is supposed to build will not develop. A firm that spends one dollar on tools and twenty cents on capability development is running a one-to-five program with extra slides, not a five-to-one program.

Role Redefinition Through Live Operating Questions

The Production Layer cannot be installed. It has to be developed.

Savine’s prescription assumes installation — build the layer, fund it five-to-one, install the agentic control plane, run the pipeline. Inside a firm, the layer is not infrastructure. The layer is a set of capabilities held inside a set of roles that are changing shape faster than HR can document them. The Production Layer in a law firm looks less like a new platform team and more like existing roles being re-aimed at capability development, with new measurement underneath.

The work is still early. That matters. If the last mile were mainly a deployment problem, the evidence inside a firm would appear as tool rollouts, usage charts, and completed implementation plans. The evidence looks different inside the work. It appears as roles changing shape before the metrics are settled, and as operating questions the organization has to learn how to answer before outcomes are clean enough to report. Here’s what my team is doing to build the Production Layer in the firm I work in, and what the operating questions look like in each case:

Conversation sophistication scoring. We are building scoring metrics across LLM conversations in the firm’s AI products. The unresolved question is not whether conversations can be scored — they can. The hard question is which scores should change what happens next. A metric that does not connect to an intervention becomes dashboard ornamentation. A useful metric tells the organization where users need better scaffolding, where a workflow is too vague, where output calibration is weak, or where a product is encouraging shallow prompting. Someone has to decide what better conversations mean, what action follows the signal, and who owns the intervention. That deciding is role design, not analytics.

Technology Training becomes Learning Enablement. We’re moving from technology training to learning enablement. The old mandate was organized around software instruction. The new mandate is organized around business outcomes, particularly where AI software changes the work itself. The work moves from showing people how to use the tool to helping groups develop the capacity to get a better business result from the tool — which includes adoption, workflow fit, practice-group context, measurement, and reinforcement after the formal training ends. The Production Layer in this case looks less like new infrastructure and more like an existing team with a redefined mandate and a different measurement underneath.

Merging Business Intelligence, AI Enablement, and Application Development. We are reconfiguring a programming leadership role into an Engineering Manager with a portfolio across BI, AI Enablement, and Applications. The team is small. The mandate is to create an AI-native development process — which is not the same as a faster ticket pipeline. Artifacts are cheap. Judgment and systems are the hard part. The role is not only about producing more code or more applications. It is about building a system where AI changes the development process without hollowing out architecture, review, accountability, or product judgment. The hazard inside the role is the same hazard inside the firm: surface productivity gain at the cost of underlying capability.

These are signs of the terrain, not success stories yet. In each case, the software is the easy part to name. The hard part is deciding what new capacity the organization needs, which role owns it, and how the firm will know whether that capacity is improving. The Production Layer thesis points at this. It cannot specify it. The specification has to come from inside the practice, inside the roles, and inside the unresolved questions that appear before outcomes are clean enough to report.

Closing

The map drawn here is real. The hazards are observable inside the work. The path is operational. None of that does the work.

Generic diagnoses produce generic responses. The McKinsey numbers will be quoted at every legal industry conference for the next eighteen months. The HBR last-mile language will become a slide-deck staple, then a panel topic, then a vendor positioning line. None of that will move a single firm forward, because none of it engages with the structural features that determine whether the firm has a future on the other side of the curve.

What moves a firm forward is the development work that happens at the practice-group level, in the pricing conversation, in the apprenticeship redesign, in the named partner who decides to own a decision instead of distributing it across a committee. The Production Layer is not a build. It is a development arc. The arc takes years and runs through individual roles whose mandates are changing faster than the org chart can document them.

The five-to-one ratio at the top of this piece is the right principle. It is not the right plan. The plan has to be built inside a partnership, against billable-hour math the math does not want to give back, inside a regulatory landscape that does not allow shortcuts, and with case law and malpractice carriers ratcheting up the cost of being wrong while the survey data ratchets up the expectation of efficiency. The work is not optional. The pace of the work is not negotiable. The map is the first artifact. The path is the second. Neither is the work.

AI does not make a law firm better. It exposes whether the firm was already doing the work.

In the late Republic, Cicero set himself the project of translating Greek philosophy into Latin. He set out to render Plato and the Stoics in his own language, and he discovered fairly quickly that Latin could not hold the concepts he was trying to import. The vocabulary did not exist. In the Academica he wrote — half-anxiously, half-ambitiously — that he had been forced to manufacture the words. He coined qualitas to render Plato’s poiotes. He coined moralis from mos, the Latin for custom, to render the Greek ethikos. To these he added evidentia, humanitas, quantitas, essentia — by modern accounts, more than two hundred Latin equivalents of Greek philosophical and rhetorical terms, many of which survive in English as quality, moral, individual, vacuum, property, definition, infinity, science. The Romans got their philosophical vocabulary because one man manufactured it in Latin, sentence by sentence, while writing about it.

Cicero did not describe his work as translation. He described it as construction.

Most modern advice for people working at the seam between technical teams and business leadership does not seem to know that Cicero had this problem. The advice treats the cognitive load as a communication issue. Slow down. Find better metaphors. Bring people along. The advice is everywhere, and it isn’t wrong. It is also about two thousand years late, and it misreads the actual work.

The work of sitting between two worlds is not principally about explaining one to the other. It is about building the vocabulary that lets either side describe the territory in the first place. The cognitive load that comes with the work — the exhaustion, the reaching for words that aren’t quite right, the tedious circumlocution because the precise term hasn’t been settled yet — is not evidence of a failure to communicate. It is evidence of construction underway.

The Romans understood the position well enough to give it a god. Janus, two-faced, looked simultaneously at the past and the future, and in some traditions at the inside and the outside, the known and the unknown. He presided over thresholds and transitions. The month of January is his. Janus was not a metaphor for the experience of holding two views at once — he was an acknowledged cosmological role, important enough that the calendar opened with him. The Romans accepted that someone had to sit at the threshold between worlds, and they gave that someone a name.

They did the same for the institutional version of the role. The Latin word pontifex — the title borne by Roman priests, including the Pontifex Maximus — literally means bridge-builder. Pons (bridge) and facere (to make). The role had a name, an office, and a temple. The state recognized that the seam between worlds was load-bearing, and it appointed someone to carry it. The Romans were precise about this, and they were not romantic about it. They simply understood that a bridge does not build itself, and the person who builds it deserves an institutional title.

Move the picture forward two thousand years. AI governance, in any institution serious about AI, sits in the same position Cicero sat in. Two domains that do not natively share a vocabulary.

The technical world has its terms: model weights, retrieval-augmented generation, zero-data retention, prompt injection, agentic loops, fine-tuning, MCP servers, data residency. Each one carries a long technical tail and assumes a body of operational knowledge to be useful.

The legal and business world has its terms: privilege, fiduciary duty, materiality, retention obligations, regulatory exposure, duty of competence, professional secrecy. Each one carries its own long tail, and it assumes a different body of operational knowledge.

Neither vocabulary natively contains the other’s concepts. There is no Latin for poiotes and no business term for prompt injection. The person doing AI governance is, structurally, doing what Cicero did. They are manufacturing the language that one side can use to describe the other. The phrase AI governance itself is a coinage of the last few years, and it isn’t fully settled — different institutions mean different things by it. The vocabulary is being built, in real time, by the people occupying the position.

This is why communication advice misses the work. Communicate better assumes the words already exist and the speaker is choosing the wrong ones. The actual problem is more like Cicero’s. The words don’t exist yet. The practitioner is coining them. They are testing whether guardrail lands, whether AI risk lands, whether agentic system lands, whether the legal team will accept prompt-level controls as a meaningful category. They are doing what Cicero was doing in the Academica, and they are doing it under board-level scrutiny rather than over a quiet correspondence with Atticus.

The cost is structural and ancient

The cognitive load that comes with the position is not a personal weakness, and it is not unique to the modern moment. Cicero complained about it openly. In his letters to Atticus he expresses anxiety about whether Latin can carry the work, whether his coinages will hold, whether the Romans will accept words that did not exist yesterday. Cicero’s anxiety in those letters was diagnostic. He was naming the structural reality of vocabulary construction, and the cost it produced. The work was ambitious, and the ambition came with a cost the work itself created.

What changes when the position is understood this way is mostly the optimization function. The work is generative work. It produces vocabulary that did not exist before, and that vocabulary does work long after any given meeting ends. Cicero’s qualitas persisted for two thousand years. Boards in the present moment are not going to remember any individual conversation about AI governance, but the categories that get coined now — the names for risks, controls, accountability structures, evaluation methods — those will persist. The careful manufacture of the right word is the most durable form of leadership available in liminal positions.

That recognition reframes what the work actually is. The temptation in the position is to optimize for fluency — for speed, for clarity, for the smooth handoff between domains. Fluency is useful, but it is downstream of the actual work. Upstream is the vocabulary. The careful, sometimes tedious, often unfinished construction of words that one side can use to describe the other accurately. Pontifex labour, in the original sense.

What we have not given the role

The Romans did one thing better than the present moment is doing. They named the position and they put it inside an institutional structure. Pontifex was an office. Janus was on the calendar. The role of bridge-builder between worlds was understood to be public, recognized, and load-bearing.

The same recognition has not been given to AI governance. The people doing the work hold a hundred different titles, most of them generic — head of innovation, AI lead, director of emerging technology, occasionally something like responsible AI. None of these names the actual work, which is closer to vocabulary engineer or bridge-builder for a new domain. The cost of the absent name is the same cost Cicero observed in his letters. When the role is unnamed, the work is invisible. The load gets interpreted as personal weakness, and the standard advice — given to invisible work that wasn’t supposed to look like work in the first place — is fluency. Fluency does not build the bridge.

The systemic leadership question — how do you bring others with you — has an older answer than the modern leadership literature gives. You do not bring people with you by communicating better. You bring them with you by manufacturing the language that lets either side describe the territory you stand on. Cicero did it for philosophy. The Romans built the office for it. The work is not new. The institution has not yet caught up to the work.

That is the work behind the work in liminal positions. The slow construction of the words that don’t exist yet.

The Work Behind the Work is the umbrella under which all of this thinking lives — six interdependent capability questions that AI structurally cannot answer for you. Subscribe at andrewlewis.ca.

Eighty-eight percent of organizations now use AI in at least one business function. Six percent are getting measurable financial impact from it.

Both numbers come from the same source: McKinsey’s State of AI in 2025, published last November and based on responses from 1,993 organizations across 105 countries. The first number is in the headline. The second is in the methodology, where “high performers” — defined as the 6% reporting at least 5% EBIT impact from AI use — are described as a small but meaningful cohort.

The gap between those two numbers is the entire story.

What you do with that gap depends on whose framing you accept. McKinsey’s framing is that the 6% are pulling ahead because they are committing more aggressively to the playbook: pursuing what the report calls transformative innovation, redesigning workflows, scaling faster, investing more. The implication for the other 94% is straightforward: do more of the same thing, harder.

That is the firm selling transformation engagements explaining why most transformation engagements aren’t working.

This essay is about why that framing is wrong, why the data inside the same report points at a different answer, and what executives should actually do with the gap. It draws on Shakespeare, Sutton, three years of operating AI inside a regulated industry, and McKinsey’s own contradictory evidence — and ends with a diagnostic question every executive can answer for themselves.

The half of the metaphor most people have stopped reading

Most executives carry around a half-version of an old metaphor: a rising tide lifts all boats. The implication is that benefit is automatic. Buy the licenses. Enable the seats. The water does the work.

There is a more honest version of the same metaphor in Shakespeare. Brutus, in Julius Caesar, says “there is a tide in the affairs of men, which, taken at the flood, leads on to fortune.” Most quotations stop there. The next line is the part that should keep executives up at night: “Omitted, all the voyage of their life is bound in shallows and in miseries.”

The tide doesn’t lift everyone. It lifts the ones who are ready to take it. The rest get stranded.

This isn’t a stylistic distinction. It’s a structural one. A boat with holes in the hull doesn’t rise with the water; it fills up and goes down faster. As the tide of AI capability rises — and it is rising, on a curve that doesn’t depend on anyone’s organizational readiness — the gap between seaworthy organizations and unseaworthy ones widens, not narrows.

Standing still is not neutral either. Competitor vessels are getting ready. The water is going up regardless of what any single executive does.

That is what the 88-vs-6 gap actually describes. Not a gradient of effort or commitment. A gradient of seaworthiness.

The vantage point matters here. Working inside a regulated industry sharpens this. When you cannot just deploy and learn — when data residency, regulator scrutiny, and partner trust constrain every decision — the gap between buying capability and capturing value becomes uncomfortably visible. You watch teams roll out impressive-looking pilots that produce no measurable change in how cases get worked or matters get billed. You watch licensing spend that nobody can defend in front of a finance committee. You watch the same governance committee revisit the same policy questions for the third quarter in a row because nobody wants their signature on the approval. Regulated industries don’t get to skip the operational work. The unregulated ones don’t either; they just discover it later, after the licensing spend is already sunk.

Why this looks like Sutton’s Bitter Lesson, and isn’t

Anyone watching the AI capability curve from a distance can recognize the trajectory. It tracks a pattern Richard Sutton named in 2019 in an essay called The Bitter Lesson. His argument was that across seventy years of AI research, general methods that scale with computation have eventually beaten approaches built on human knowledge of the domain. Chess. Go. Speech recognition. Computer vision. The pattern repeats: human-knowledge-based methods feel principled and produce early wins, then get overtaken by general methods plus more compute. Sutton’s claim has aged exceptionally well. Large language models are the most emphatic confirmation of his thesis since he wrote it.

Read carelessly, the Bitter Lesson is the case for executive optimism. The tide is rising because compute keeps growing. General methods keep absorbing what humans used to scaffold. The eventual end state is models that handle the integration work themselves. Just wait. Just deploy. The capability will arrive; the value will follow.

That reading is wrong, in a specific way.

Sutton was making a claim about model capability and training paradigms — what wins benchmarks at the research frontier. He was not making a claim about what creates value in deployed enterprise systems. The frontier of value creation in 2026 is not the model layer. It is the layer around the model: governance, retrieval, evaluation, workflow integration, accountability, measurement. Almost all of that is what Sutton called “human knowledge” — exactly the kind of scaffolding the Bitter Lesson predicts will eventually be absorbed. But it has not been absorbed yet, and won’t be for a while, because it is not benchmark-shaped. It is context-shaped, organization-shaped, accountability-shaped. There is no test set for “did the matter close faster” or “would the partner sign off on this advice.”

The honest synthesis is that Sutton’s lesson and the operational discipline argument live at different layers. Sutton describes the trajectory of model capability, which is rising reliably. The operational discipline argument describes what happens between that rising capability and the outcomes a board recognizes. That is exactly where the 94% are stuck. Both observations are true; they are not in competition. The executive who reads the Bitter Lesson as license to wait is making a category error, confusing what wins research benchmarks with what compounds in P&L.

What McKinsey’s report actually shows, and what it conveniently omits

Read the report carefully and a different argument emerges than the one in the executive summary.

McKinsey’s own correlation analysis tested twenty-five organizational attributes against EBIT impact from generative AI. The single biggest predictor was workflow redesign. Not licensing volume. Not tooling sophistication. Not training programs. Operational rewiring.

That finding is in their data. It is not in their headline recommendation. The headline recommendation is to pursue transformative innovation — a phrase that maps conveniently to a multi-year consulting engagement and not to anything an internal team could execute on its own. Their data identifies operational rewiring as the binding constraint. Their recommendation identifies engagement scope as the answer. Those are different things.

There is another revealing detail. The report identifies twelve “best practices for gen AI adoption and scaling.” Read them in sequence and notice what they describe: establishing a dedicated transformation office, creating a comprehensive change story, developing role-based capability training programs, defining a phased rollout roadmap, establishing employee incentives, mechanisms to incorporate feedback, fostering trust through structured communications. Each of these is a defensible activity. Together, they describe the typical scope of a transformation consulting engagement almost exactly. The list is not wrong. It is just suspiciously shaped.

The high-performer framing has its own problem: it is partly tautological. McKinsey defines high performers as the 6% getting EBIT impact, then observes that they redesign workflows and pursue transformation. That doesn’t establish causation. It is equally consistent with a different reading: organizations capable of producing real EBIT impact are also the ones with the institutional discipline to redesign workflows. The methodology and the outcome correlate. The report assumes the first causes the second.

There is also a quiet methodological choice worth surfacing. The EBIT impact figures are self-reported, by respondents who are typically the same executives sponsoring the AI initiatives in their organizations. There is no independent verification. People who have sponsored a major program and put their name on it are not neutral evaluators of whether the program worked. The 6% number may be generous; the actual share of organizations capturing real, board-defensible value from AI is probably lower.

This matters because the prescription most executives are following is built on these unexamined assumptions.

None of this is dishonest. Consulting firms make money on transformation programs. Their reports are not neutral observations of the AI landscape. They are demand generation for the engagements they sell. That is not a conspiracy theory. It is how the business model works. Executives know this about their own software vendors and somehow forget it about their consulting reports. The reports use the language of independent research and arrive accompanied by the prestige of the firm; both produce a halo that suspends ordinary critical reading.

The cleanest read of McKinsey’s own 2025 report is this: their data agrees that operational rewiring is the binding constraint on AI value capture. Their recommendation does not.

What seaworthy actually requires

A vessel that can take the tide needs two things, and you need both.

The first is the hull — operational readiness. Governance that can move at the speed of capability change. Procurement processes that start with a defined business problem rather than competitive anxiety. Data infrastructure that doesn’t break when the workload shifts. Measurement frameworks that distinguish adoption from value. These are the structural conditions that determine whether AI capability, once deployed, produces outcomes or evaporates into pilot purgatory.

The second is the crew — capable people. Practitioners who can see their own work structurally and identify where AI fits. People who can evaluate AI output with calibrated judgment rather than blind acceptance or reflexive rejection. Leaders who direct capability toward operational outcomes rather than activities.

Hull without crew is infrastructure waiting for capability nobody can direct. Crew without hull is capable individuals trapped in an unready organization. Most programs invest heavily in one and call it complete.

The version of this most executives miss is that both are operational disciplines. Hull readiness is obviously operational: governance, processes, infrastructure. But crew readiness is also operational. It is not produced by lunch-and-learns or tip sheets. It is produced by changing how work is decomposed, evaluated, and assigned. The training-program version of crew development is theatre. The work-redesign version is the actual thing.

What this looks like in practice is unglamorous. It looks like sitting with a team for an afternoon and watching them do their actual work, then identifying the four steps in their process that AI could change and the two steps it absolutely shouldn’t touch. It looks like building a measurement framework that distinguishes “we used the tool” from “the matter closed faster” or “the output was higher quality.” It looks like an executive willing to put their name on a governance position that will need to be defended six months from now when someone challenges it. None of these activities photograph well in a board deck. All of them produce more EBIT impact than another round of training rollouts.

The diagnostic question is which one is your binding constraint right now. A firm with strong governance and weak practitioner capability has a different next move than one with sophisticated practitioners trapped in a governance vacuum.

Subscribe now

The cascade between friction points

The friction points reinforce each other in a cascade that is worth naming, because most executive interventions miss the dynamic and treat each as independent.

Governance friction comes first because it sets the conditions for everything that follows. When nobody will sign the manifest — when policy decisions get distributed until no individual is accountable — the organization cannot articulate what it is willing to do with AI. That ambiguity perpetuates cultural friction. In the absence of clear positions, the rational behavior is to scrutinize every proposed initiative for flaws rather than commit to one. Why would a manager stake their reputation on a course that has not been institutionally sanctioned?

Cultural friction in turn shapes technical friction. When the organization rewards skepticism and penalizes commitment, procurement defaults to broad, defensive purchases. Tools get bought because peers bought them. Licenses get distributed widely so no single deployment can fail visibly. The technical environment that emerges is wide and shallow rather than narrow and deep, optimized for political safety rather than operational impact.

Wide-and-shallow technical environments produce workflow friction inevitably. People have AI tools available but no specific operational problem the tools were procured to solve, no clear quality framework for output, and no model for what good integration looks like. They use the tools at the margins of their work — rewriting an email, summarizing a document — and never integrate them into the core processes that would actually produce measurable outcomes. The capable AI tools that do exist get used at a fraction of their potential because the users have not done the work of understanding their own workflow well enough to know where AI belongs.

The cascade is reinforcing, but it is not strictly linear. You can have workflow friction without governance friction. You can resolve technical friction while cultural friction persists. The point is that addressing one friction point in isolation often reveals how much the others have been compensating for it. Organizations that address only the technical layer — buying better tools — discover that the governance and cultural blockages were the real constraints. Organizations that try to address culture without resolving governance discover they are asking people to commit in an environment where commitment carries no institutional support.

Identifying which friction point is dominant is the executive’s actual job. Not all four. The one that is the binding constraint right now.

The asymmetry has inverted

For most of the last three years, executive avoidance was the rational position. Committing to a major AI program carried real personal risk: an underperforming initiative would carry the executive’s name. Avoiding carried no symmetric cost. Boards were not asking pointed questions. There was no peer benchmark to be measured against. The water was rising slowly enough that being late looked safe.

That has changed. Boards now ask comparative questions. Industry surveys publish utilization data. McKinsey’s own report turns the visibility up further — every executive whose firm sits in the 94% now has a number describing their position that their board has access to. The cost of being late has become measurable, and it is compounding quarter by quarter.

There is a second-order effect worth naming. The compounding gap between high performers and the rest is not just about EBIT impact. It is about the institutional learning that comes with operating AI seriously over time. Firms that have spent two years building governance muscle, measurement frameworks, and integrated workflows are not just ahead in adoption. They have built organizational capability that the late-arriving firm cannot replicate by deploying the same tools faster. The advantage is structural, not procurement-driven, and structural advantages compound on a different curve than catch-up effort can match.

The executive who commits to operational readiness now is making the lower-risk bet. The one waiting for clarity is making the bet that used to be safe and no longer is. Most have not repriced.

Where to start

The diagnostic question is straightforward: which friction point is your binding constraint right now?

If governance is the binding constraint, no investment in capability development will produce outcome. The starting move is identifying who is willing to own a clear position on data handling, acceptable use, and risk tolerance — and accepting that the position may need to be defended later. The friction does not dissolve when risk is eliminated. It dissolves when accountability is claimed.

If culture is the binding constraint, the work is changing the incentive structure so that commitment is rewarded and avoidance carries cost. This is the hardest of the four because it requires changing what the organization values. Most cultural interventions fail because they try to change rhetoric without changing reward; people read the actual signals.

If your binding constraint is technical — tools acquired because competitors acquired them, with no specific business problem they were procured to solve — the move is to start over with success criteria first. Identify the operational problem, define measurable success, then select technology against those criteria. The tools you have may or may not survive the analysis. Sunk cost is not a strategy.

If workflow is the binding constraint — your governance is reasonable, your culture is permissive, your tools are deployed, but nothing has changed in how work actually gets done — the gap is structural understanding of work itself. Practitioners need to see their own workflows as systems of operations rather than streams of tasks. That capability is not built by tip sheets. It is built by sitting with the work.

Most executives can answer the diagnostic question honestly if asked plainly. The hard part is not the diagnosis. It is committing to the answer.

The line worth remembering

Read McKinsey’s data. Don’t read McKinsey’s recommendation. The tide is rising, the playbook you are being sold will leave you stranded, and the boats that take the tide will be the ones whose hulls were built before the water came up.

There is still time to build. Not much.

The work I publish at AndrewLewisWasHere goes deeper on what AI operational readiness actually looks like inside a regulated industry, where you can’t just deploy and learn. Subscribe and the next piece will land in your inbox.

Anthropic just published a study that quietly inverts how we talk about AI productivity. They paid 52 professional developers to learn a new Python library in 35 minutes. Half got an AI assistant. Half didn’t. Then everyone took the same comprehension quiz, with no AI.

The AI group scored 17% lower. About two grade points. A real effect, not noise — Cohen’s d of 0.738 if you care about the statistics.

That part has been making the rounds. The part that hasn’t is the productivity finding sitting right next to it.

On average, the AI group wasn’t faster.

People stayed about the same total time on the task. They just shifted from coding to interacting with the assistant. Some of them spent six minutes composing a single query in a 35-minute task. Which means the trade most people assume they’re making — accept some skill loss in exchange for speed — often isn’t even on offer. They lost the skill. They didn’t get the speed.

The variance is the story

What makes this study different from the usual productivity-of-AI-tools paper is that the researchers didn’t just measure averages. They watched every screen recording. And they found that the average is hiding something more useful than it’s showing.

There were six distinct ways people used the AI assistant. The researchers split them by quiz outcome. Three patterns scored between 24 and 39 percent on the comprehension test. Three scored between 65 and 86.

The low-scoring patterns share a structure. AI Delegation — handing the whole task over and pasting the result. Progressive Reliance — starting engaged, drifting into delegation as the clock ticks. Iterative Debugging — asking the AI to fix things you don’t understand, over and over.

The high-scoring patterns share a different structure. Conceptual Inquiry — asking the AI questions, but writing the code yourself. Hybrid Code-Explanation — asking for code with the explanation embedded. Generation-Then-Comprehension — getting the code, then asking the AI to teach you why it worked.

You can guess what divides the two halves. Cognitive engagement. Not how much AI was used. Not which tool. Not how skilled the developer was going in. Whether they stayed in the work or stepped out of it.

The participant feedback in the qualitative section is the part that stuck with me. Several developers in the AI group volunteered, unprompted, that they had “felt lazy,” or wished they had paid more attention to the explanations the AI gave them, or noticed afterward that there were “still a lot of gaps in their understanding.” Cognitive offloading from the inside. They could feel it happening in the moment and didn’t stop it, because the task pressure was telling them to keep moving.

Why debugging is the canary

The biggest gap between the groups wasn’t on the conceptual questions. It was on debugging.

The no-AI group hit errors. Trio errors specifically — runtime warnings about coroutines that were never awaited, type errors from passing the wrong kind of object. These errors force you to learn how the library actually works, because you can’t skip past them without forming a mental model. The AI group skipped past most of them. Their code worked the first time, more often than not. They never built the debugging muscle, because they never had to.

This is the part that should make organizations nervous.

The dominant workflow proposal for AI-assisted software development is “AI writes the code, humans review it.” Sometimes packaged as “human in the loop.” It depends on a workforce that can read code well enough to catch what’s wrong with it. But if AI assistance during the formation period systematically removes the error-encounter loop that builds review skill, you’re producing a workforce structurally unable to do the review you’ve designed your safety story around.

That isn’t a future risk. It’s a workflow currently being deployed.

The hidden second clause

The dominant claim about AI productivity has been: AI makes you faster. The fine print, based on this evidence, is — only if you stay cognitively engaged. And the empirical pattern says most people don’t.

There’s a clean way to think about this. AI doesn’t make you better. It amplifies whether you were doing the thinking in the first place.

For people who already engage with their work — who ask why something is structured the way it is, who validate against a model of what good looks like, who treat tools as collaborators rather than dispensers — AI extends what they can do. For people who don’t, AI gives them faster ways to look productive while the underlying skill quietly erodes.

This isn’t a moral observation. It’s a structural one. The patterns that preserved learning in the study weren’t the patterns of people working harder. They were the patterns of people staying in a particular mode of attention.

Subscribe now

What this changes

The implications break in three directions.

For individuals: how you use the tool matters more than which tool you use. Asking for code without asking for explanation is a learning shortcut that costs you compounding interest later. The patterns that work are slower in the moment and pay off in retention.

For teams: if you’re scaling junior contributions with AI, you need to deliberately build the engagement loops back in. Errors are not friction to eliminate. They’re where skill formation actually happens. Removing them feels like productivity. It produces fragility.

For organizations: the AI workflow you’re designing assumes a level of human capability you may be actively eroding through the same workflow. That’s not a contradiction you can prompt your way out of. It’s an architectural one.

The original framing — that AI is a productivity tool — was always slightly off. AI extends the cognitive work you’re already doing. Without that work underneath, the extension produces motion without progress.

AI doesn’t make you better. It exposes whether you were already doing the work.

Read the full Anthropic study: How AI Impacts Skill Formation by Judy Hanwen Shen and Alex Tamkin.

If this resonated, subscribe for more notes from inside a regulated industry trying to operationalize AI without breaking what makes it work.

The dominant narrative about AI and work goes like this: AI handles the production, you handle the thinking, everyone goes home early. It is a clean story. It is also wrong in a way that matters.

A principal engineer at a large telecom posted on Reddit this week about being all-in on agentic coding for two years and thinking about quitting software engineering entirely. Not because the tools don’t work. Because they work too well. The line that stopped me: “The cost of writing code in effort / time was a throttling middleware.”

That phrase deserves to sit for a second. Writing code used to be slow enough that your brain could keep up. The effort of typing, compiling, debugging — all of that created natural pace. You had time to sense when a pattern was wrong. Time to think through the shape of a class or the implications of an architectural choice. The slowness wasn’t a bug. It was cognitive infrastructure.

Now that infrastructure is gone. And this engineer — 13 years of experience, principal level — reports making ten whiteboard-level architectural decisions before his second cup of coffee. Decisions that used to happen once a sprint, maybe twice, gated by the slow, expensive process of actually building things. The dam broke. The decisions didn’t disappear. They accelerated.

The production layer was never the bottleneck you thought it was

When people talk about AI making work faster, they’re usually describing the production layer — the part where raw effort turns into output. Drafting, coding, formatting, researching. And yes, AI compresses that layer dramatically. What nobody accounted for is what happens to the other layer — the judgment layer — when production speeds up by an order of magnitude.

Every piece of AI-generated output requires evaluation. Is this right? Is this good enough? Does this fit the architecture? Does this solve the actual problem or just the surface symptom? Those questions existed before AI, but they arrived at a pace your brain could absorb. Production time was thinking time. The gap between “I need this” and “here it is” gave your mind room to prepare for the decision.

That gap is gone. And the result is not faster work. It’s faster judgment demands on a brain that hasn’t changed speed.

A Boston Consulting Group study published in Harvard Business Review in March 2026 put a name to this: “AI brain fry.” They surveyed 1,488 full-time U.S. workers and found that high AI oversight — the kind that requires reading, interpreting, and evaluating AI output — was associated with 14% more mental effort, 12% greater mental fatigue, and 19% greater information overload. Workers described a fog or buzzing that forced them to physically step away from their screens. One of the study’s authors told Fortune the pattern was consistent: people were getting more done but hitting the limits of their cognitive capacity because there were simply too many decisions to make.

An eight-month study of a 200-person tech firm, led by researchers at UC Berkeley, found the same dynamic from a different angle. AI wasn’t reducing work. It was intensifying it. Employees processed more information, made more decisions, and experienced more burnout — not less — as AI adoption increased.

Decision fatigue is not a new concept. The delivery mechanism is.

Psychologists have studied decision fatigue for decades. The core finding is straightforward: the quality of your decisions degrades as you make more of them. Roy Baumeister’s ego depletion research established that decision-making draws from a finite cognitive resource. Make enough decisions and you start defaulting to heuristics, avoiding trade-offs, or simply deferring. The average American adult reportedly makes around 35,000 decisions a day. Most of those are trivial. The ones that matter are the ones that require actual evaluation.

What AI does is change the ratio. It doesn’t increase the total number of decisions. It increases the density of consequential ones. When production was slow, your day was a mix of low-stakes mechanical work and occasional high-stakes judgment calls. The mechanical work gave your brain recovery time between the hard decisions. It was boring, but it was load-bearing.

Remove the mechanical work and what’s left is a continuous stream of judgment. Architecture choices. Quality assessments. Risk evaluations. Strategic trade-offs. All day. No recovery intervals. The Reddit poster described it precisely: running ten whiteboard-level decisions before morning coffee, decisions that used to be spaced across a sprint. His brain isn’t slower than it was. The demand on it is faster.

We don’t understand the cost of running a judgment machine all day

This is the part almost nobody is talking about. We’ve spent two years celebrating AI’s ability to remove the production burden. We have not spent two minutes thinking about what happens to the human on the other side when the production burden was also a cognitive pacing mechanism.

The Reddit engineer said something else that stuck: “I feel like for the devs that have survived layoff rounds, AI has raised the bar of required skills, not lowered it.” That maps directly to the Jevons Paradox applied to AI — as AI efficiency increases, the demand for human capability doesn’t decrease. It increases. The skills that matter shift upward. The judgment, the architectural thinking, the ability to evaluate quality at speed — those become the job. And the job becomes relentlessly, uninterruptedly hard.

This isn’t a coding problem. It’s a knowledge work problem. Every profession that adopts AI tools effectively will hit this same wall. Lawyers reviewing AI-drafted contracts. Financial analysts evaluating AI-generated models. Marketers assessing AI-produced campaigns. The production layer compresses. The judgment layer concentrates. And the person in the middle has to run their brain at a sustained intensity that the old workflow never required.

We don’t have infrastructure for this yet. We don’t have pacing strategies. We don’t have cognitive load frameworks adapted for AI-augmented work. We don’t even have language for the problem — which is why “brain fry” and “throttling middleware” resonate so immediately. People recognize the feeling before anyone names it.

The work behind the work just got more urgent

The conventional response to this problem will be training. Run a workshop on managing AI output. Distribute a tip sheet on decision prioritization. That approach will fail for the same reason it always fails — it treats the symptom without touching the structure.

The actual work is harder than a workshop. It’s developing the ability to see your own workflow clearly enough to know which judgments matter and which don’t. To calibrate your trust in AI output so you’re not re-evaluating everything at full intensity. To build the signal discrimination that lets you spot the 5% of output that needs real attention and let the rest move.

That is not a training problem. That is a capability development problem. And it’s one that gets more urgent, not less, as the tools get faster.

Your brain was always a judgment machine. AI just made it the only machine that matters.

I'm writing from inside a regulated firm doing AI adoption in real time. Every week I publish what I'm seeing — the frameworks, the friction, the decisions that actually move work. If that's useful to you, subscribe. It's free, and I'll send you the next one.

Subscribe now

Every enterprise AI dashboard in the world has an adoption number on it. Seats activated, prompts per user, tools deployed, percentage of workforce with access. The number goes up every quarter. The board is pleased. The CIO presents it with confidence.

And almost none of it tells you whether AI is actually working.

The metric everyone loves is the metric that matters least

Adoption measures activity. Someone logged in. Someone typed a prompt. Someone opened Copilot and asked it to summarize an email they could have read in thirty seconds. All of that registers as adoption.

What it doesn’t measure is whether anyone’s work changed. Whether a contract review that used to take four hours now takes ninety minutes because the lawyer iterated through three rounds of AI-assisted markup. Whether the finance team built an automated reconciliation workflow or just asked ChatGPT to explain what a pivot table does. Whether the senior associate used AI to surface a pattern across two hundred documents that no one would have caught manually — or whether they used it to rewrite a slightly awkward email.

Those are fundamentally different behaviors. One is sophisticated use. The other is expensive autocomplete. And the adoption dashboard doesn’t distinguish between them.

The evidence arrived this week, from three directions at once

A Wharton School study tracking enterprise AI adoption over multiple years found a widening disconnect between executive enthusiasm and managerial reality. Nearly two-thirds of executives report becoming significantly more optimistic about AI over the past year. The managers implementing those same tools inside actual workflows report something closer to frustration. They see the constraints. They carry the operational burden. They don’t feel supported.

A separate survey of 2,400 knowledge workers found that 29% admit to actively undermining their company’s AI rollout. Among Gen Z workers, that figure reaches 44%. The tactics include feeding proprietary data into unapproved tools, refusing to complete AI training, and in some cases deliberately producing poor-quality output to make the tools look bad.

And a third study, from HFS Research, found that only 14% of enterprises have a clear AI strategy at all. The other 86% are deploying tools into a vacuum — no framework for what good use looks like, no feedback loop for what’s working, no definition of success beyond the adoption dashboard.

These aren’t three separate problems. They’re three symptoms of the same one: organizations measuring the wrong thing, at the wrong level, and mistaking activity for progress.

What sophistication actually measures

The Conversation Sophistication Score is a framework built on research from KPMG and the University of Texas at Austin. The study analyzed 1.4 million AI interactions across 2,500 employees and identified thirty behavioral characteristics that separate the highest-performing AI users from everyone else.

The finding that matters: sophistication isn’t correlated with frequency. The people using AI most often aren’t the ones using it best. The distinguishing behaviors are things like interaction depth (multi-turn conversations that build on previous outputs), task complexity (applying AI to genuinely difficult problems rather than simple lookups), iterative reasoning (treating AI output as a draft to be refined, not an answer to be accepted), breadth of application (using AI across multiple domains rather than one narrow use case), and fluency signals (adapting communication style and prompt structure to the specific task).

None of those show up on an adoption dashboard. You can have 95% adoption and 10% sophistication, and your metrics will tell you everything is going great until it very clearly isn’t.

The sequence that actually works

The enterprises getting AI right aren’t doing anything exotic. They’re solving the structural problems before chasing the visible ones. They define what good AI use looks like before measuring whether it exists. They build governance — not as a compliance exercise but as a shared understanding of what’s allowed, what’s encouraged, and what’s off-limits. They create conditions where experimentation is safe and failure is data, not career risk.

And then — after the structure exists — they start measuring sophistication alongside adoption. Not instead of it. Alongside it. Because adoption without sophistication is just expensive access. And sophistication without adoption means you have a few brilliant users surrounded by a workforce that’s opted out.

The 14% of organizations that have a clear strategy? They’re the ones building this foundation. The other 86% are wondering why their adoption numbers keep climbing and their results don’t.

The dashboard isn’t broken. The measurement is.

If you found this useful, consider sharing it with someone leading an AI rollout right now. They probably have an adoption number. They probably don’t have a sophistication score. That gap is the article.

Something odd is happening inside organizations right now, and it showed up clearly in a study the Wharton School published this week. The executive suite and the management layer are both talking about AI. They’re using similar language. They’re attending the same town halls and reading the same strategy decks. But they are not having the same conversation.

Nearly two-thirds of executives say they’ve become significantly more positive about AI over the past year. They see it as a strategic priority. They’re investing heavily. Some are restructuring their organizations around it. For senior leadership, AI has moved from an interesting capability to an existential commitment — the question isn’t whether to go all in, it’s how fast.

The managers one or two levels below them? They’re drowning.

The gap isn’t disagreement — it’s altitude

The Wharton/GBK Collective study has been tracking this dynamic for multiple years, and the pattern is consistent: executives experience AI as an opportunity. Managers experience AI as a workload.

That’s not because managers are resistant or uninformed. It’s because they sit at the exact altitude where strategy becomes operations. They’re the ones who have to reconcile the CEO’s enthusiasm with the fact that the approved tool doesn’t integrate with the case management system. They’re fielding questions from their teams about what’s allowed and what isn’t — often without clear answers, because the governance policy is still being drafted. They’re absorbing the productivity overhead of learning new tools while still delivering on every existing deadline.

Executives don’t see this overhead because it doesn’t appear in the metrics they review. Adoption dashboards show seats activated and usage trends. They don’t show the manager who spent three hours this week answering the same AI governance question from four different direct reports because the policy FAQ doesn’t exist yet.

The executive sees a line going up. The manager feels the weight behind that line.

Where the pressure compounds

This altitude gap produces a specific set of downstream problems that I see repeatedly from inside an organization going through this.

The first is unfunded mandates. Leadership communicates that AI adoption is a priority. But the time, training, and governance infrastructure required to adopt responsibly aren’t budgeted separately. They’re absorbed by the existing management layer on top of everything else. The implicit expectation is that managers will figure it out — will become AI champions in addition to their actual roles, without reduced workloads or additional resources.

The second is phantom consensus. Strategy decks present AI adoption as an aligned organizational priority. Everyone nods in the planning meeting. But alignment at the strategy level doesn’t mean alignment at the implementation level. The manager who nodded in the meeting goes back to a team that has no idea what’s expected, using tools that half-work, under policies that are still in draft. The strategy deck says “aligned.” The floor says “confused.”

The third is consequence asymmetry. The Fortune/Workplace Intelligence survey found that 60% of executives would consider cutting employees who refuse to adopt AI. But only 14% of enterprises have a clear AI strategy. Executives are prepared to enforce adoption of something they haven’t fully defined. The consequence falls on the people closest to the work, while the strategic ambiguity originates at the top.

What the sabotage data is actually telling us

This is where the 44% Gen Z sabotage number from this week’s headlines becomes less scandalous and more predictable.

When managers are unsupported, their teams feel it. The confusion rolls downhill. If a manager doesn’t have clear governance guidance, their team gets inconsistent answers about what’s allowed. If a manager hasn’t been given time to understand the tools, they can’t coach their team on effective use. If a manager is overwhelmed by the implementation burden, their team reads that stress and interprets it — correctly — as a signal that AI adoption is creating problems, not solving them.

The 26% of sabotaging employees who say the strategy is poorly executed aren’t making an abstract complaint. They’re reporting what they observe at the manager level every day: pressure without support, mandates without clarity, consequences without strategy.

The sabotage isn’t coming from below. It’s flowing downhill from above.

The intervention that most organizations skip

The conventional response is more training, better tools, clearer communication from leadership. Those help. But they miss the structural problem.

The structural intervention is resourcing the middle. Giving managers dedicated time for AI governance and enablement work. Reducing their operational load during the adoption period rather than adding to it. Creating feedback channels that surface implementation friction to leadership before it calcifies into resistance.

The organizations I’ve seen move fastest on AI adoption aren’t the ones with the biggest budgets or the most ambitious CEOs. They’re the ones where middle management has actual capacity to do the work that adoption requires — the unglamorous, invisible, operational work of translating executive vision into something a team of eight people can actually execute on a Tuesday afternoon.

That work doesn’t appear on an adoption dashboard. It doesn’t generate a conference keynote. But it’s the difference between a strategy that lands and one that produces a 44% sabotage rate.

The executives and the managers aren’t enemies. They’re not even disagreeing. They’re just standing at different altitudes, describing different views of the same mountain — and nobody’s built the trail between them.

---

I made a video this week breaking down the full research — the sabotage data, the Wharton findings, and a framework for measuring sophistication instead of activity.

Most organizations measure AI adoption the way they measure gym memberships. How many people signed up. How often they swipe in. Maybe how long they stay. None of which tells you whether anyone is actually getting stronger.

The AI equivalent: prompt counts, hours logged, tokens consumed, self-assessed skill levels. These numbers are easy to collect, and at most companies they look encouraging. Adoption is up. Usage is growing. The dashboards are green.

But adoption is not sophistication. And the gap between the two is enormous.

What the Research Actually Shows

KPMG and researchers at the University of Texas at Austin spent eight months studying this gap. They analyzed 1.4 million AI prompts from roughly 2,500 professionals — not surveys, not self-reports, but actual conversation logs at scale. The question was simple: what does sophisticated AI use look like, and how do you tell it apart from routine use?

The headline finding: about 90% of employees used AI regularly. Only approximately 5% used it in ways that generated differentiated value. That’s a 17:1 ratio between adoption and sophistication, and most organizations can’t see it because they’re measuring the wrong dimension entirely.

The researchers identified four behavioral patterns that consistently predicted sophisticated use. Not prompt length. Not frequency. Behaviors: treating AI as a reasoning partner rather than accepting first outputs, delegating complex multi-step tasks with clear constraints, applying AI across diverse task types instead of just writing assistance, and sustaining longer working-session-style interactions.

Here’s the part that caught me off guard. The most sophisticated users weren’t the youngest employees — they were above manager level. The conventional wisdom says junior employees are more natural with these tools. The data says otherwise. There’s a real difference between being comfortable with AI and being good at getting results from it. Comfort is about familiarity. Sophistication is about judgment.

The Problem with Averages

When I started building a scoring framework from this research, I ran into an interesting design problem. A weighted average of behavioral dimensions sounds clean, but it lies in predictable ways.

Consider someone who writes long, detailed initial prompts and sustains multi-turn conversations. Their Interaction Depth score is high — maybe an 8 or 9. But they never refine outputs. Never push back. Never ask the model to check its reasoning or explore alternatives. Their Iterative Reasoning score is a 2.

A weighted average might land them at “Proficient.” But they’re not proficient. They’re just verbose. The length of the prompt isn’t the signal. What the user does with the output is.

This is why the framework I built includes gating criteria — floor rules that prevent misclassification. You can’t reach the Advanced tier unless both Task Complexity and Iterative Reasoning hit at least 7 out of 10, regardless of what your weighted average says. Those two dimensions are the strongest differentiators in the research, and they carry 55% of the total score.

The gating mechanism is the single most useful idea in the framework. It forces honest measurement.

What This Means for How You Train

The dimension-level data tells you something activity metrics never can: where to invest in training.

If Iterative Reasoning is consistently low across your organization, another “intro to prompting” workshop won’t help. The gap isn’t in how people write prompts — it’s in how they think about the interaction. They need to learn to treat AI as a reasoning partner: assign roles, provide examples, test assumptions, ask the model to verify its own logic.

If Task Complexity is low, the problem is different. People aren’t delegating hard enough. They’re using AI for tasks they could do themselves in roughly the same time, instead of delegating the genuinely complex, multi-step work where AI creates real operating margin.

The dimension scores give you a specific diagnosis. The diagnosis gives you a specific intervention. That’s the difference between “use AI more” and “here’s what to change about how you use it.”

The Uncomfortable Implication

If only 5% of users are sophisticated at a firm where 90% are active — a firm that had invested heavily in AI tools and training — then sophisticated use doesn’t happen organically. Making tools available and running training sessions gets you to 90% adoption. It does not get you to sophistication.

Getting there requires measuring the right things, making specific behaviors visible and expected, and building the feedback loops that help people see the gap between where they are and where they could be. Activity metrics can’t do that. Behavioral metrics can.

You can’t operate what you can’t measure. And right now, most organizations are measuring the equivalent of gym swipes.

Subscribe now

I built a full playbook with the five scoring dimensions, weighted formula, gating rules, score anchors, and a printable worksheet for manual scoring. I also built a Claude Skill if you want to get sophistication scoring within you conversation, along with tips on how to improve.

Ai Sophistication Scoring Spec

237KB ∙ PDF file

Download

Download

Ai Sophistication Playbook

37.8KB ∙ PDF file

Download

Download

Every few weeks, a new report lands cataloguing the barriers to enterprise AI adoption. Poor data management. Incomplete governance. Lack of training. Unclear ROI. Resistance to change.

No Jitter published one this week. BCG has one. McKinsey’s latest State of AI survey says 88% of organizations report using AI in at least one business function — but nearly two-thirds haven’t begun scaling it across the enterprise.

An HBR piece from earlier this year put a finer point on it: AI initiatives stall not because the technology fails, but because employees’ anxiety about relevance, identity, and job security drives surface-level adoption without real commitment.

None of this is new. And that’s exactly the problem.

We’ve been listing the same barriers for two years. The list hasn’t changed. Which raises an uncomfortable question: if we know what the barriers are, why haven’t we removed them?

The Barrier List Is Actually a Job Description

I lead AI enablement and delivery at a large Canadian law firm. My charter covers generative AI governance, production infrastructure decisions, cross-functional technology guidance, and organizational design for autonomous delivery teams.

When I read reports listing the top barriers to AI adoption, I don’t see obstacles. I see my to-do list.

Data readiness? That’s the conversation with InfoSec about what categories of data we can and can’t share with AI tools — and under what conditions. It’s the ongoing discussion about zero data retention and data residency requirements that shapes every infrastructure decision we make. And these aren’t theoretical concerns. The U.S. CLOUD Act allows American law enforcement to demand data held by U.S.-based providers regardless of where that data is physically stored. A Canadian firm using a U.S.-hosted AI tool with client data on a Montreal server is still exposed. When a Microsoft executive told the French Senate under oath in June 2025 that he couldn’t guarantee European data would be safe from U.S. authorities, the same logic applies to every law firm using a U.S.-owned cloud AI service.

Governance gaps? That’s the policy work — figuring out what guardrails are necessary when you’re building internal infrastructure like MCP servers that connect AI tools to live systems. The answer changes as the tools evolve, which means the governance has to evolve with it.

The other barriers on the list — training, middle management alignment, cultural resistance — those show up too. Every organization doing this work recognizes them. The question isn’t whether they’re real. It’s whether anyone is resourced to actually address them.

The barrier list isn’t a research finding. It’s a scope of work.

The Real Reason the List Doesn’t Change

From the inside, the pattern is pretty clear: the barriers persist because removing them requires a kind of work that most organizations don’t want to fund, staff, or prioritize.

Governance work is slow, political, and unglamorous. Nobody gets promoted for writing an AI acceptable use policy. Nobody gets a conference keynote for building a data classification framework. These are infrastructure projects — essential, invisible, and easy to defer.

Training is continuous, not one-shot. You can’t run a lunch-and-learn in Q1 and call it done. AI tools change. Use cases evolve. New risks emerge. Training has to be ongoing, role-specific, and practical. That takes dedicated time from people who are already stretched.

Middle management is where adoption lives or dies. A Workera analysis from earlier this year noted that most adoption bottlenecks sit in the middle of the organizational chart — managers who struggle to set expectations for AI-assisted work, don’t know what “good” looks like, and avoid the topic because it raises uncomfortable questions about headcount and value.

And cultural resistance isn’t about employees being Luddites. The HBR research showed it’s really about identity — people worry that using AI makes them look replaceable, or that their expertise is being devalued. You can’t train your way out of that. It requires sustained, honest messaging about what AI actually changes and what it doesn’t.

Every one of these barriers is addressable. None of them is easy. And most of them require organizational commitment that goes well beyond the technology team.

Where the Work Actually Lives

When I look at the barrier list through the lens of what has to happen, the work sorts itself pretty naturally.

Some of it you can systematize. Governance templates, usage policies, risk assessment frameworks, data classification standards — these are repeatable artifacts. Build them once, adapt across the organization. AI can even help with its own adoption here. Use it to draft the policies, generate training materials, structure rollout plans.

Some of it requires people working alongside people. Helping managers evaluate AI-assisted work. Coaching teams on where AI fits their specific workflows. Having the uncomfortable conversations about what changes when a task that used to take four hours now takes forty minutes. You can support this with tools and structured conversations, but you can’t skip the human part.

And some of it you just have to do the slow way. Building trust. Shifting culture. Showing through consistent action that efficiency gains won’t quietly become headcount cuts. That the goal is better work, not cheaper workers. No technology accelerates this.

Most organizations want to spend their AI budget on the first kind. The actual work is mostly the second and third.

The Patience Problem

There’s an additional dynamic that the barrier reports don’t capture: the gap between executive expectations and organizational readiness.

Leadership sees the reports about AI productivity gains. They hear the vendor pitches. They attend the conferences. They come back wanting to know why the organization isn’t moving faster.

The honest answer is: because we’re doing the barrier removal work. And that work doesn’t produce demo-ready results on a quarterly cadence.

Governance frameworks aren’t impressive in a board presentation. Training programs don’t generate viral LinkedIn posts. The slow, steady work of building organizational readiness for AI is the least visible and most important investment a company can make right now.

The organizations that are furthest along in AI adoption aren’t the ones that skipped the barrier work. They’re the ones that started it earlier and funded it properly. They invested in the boring infrastructure while everyone else was running pilot programs.

What Would Actually Change Things

The next time one of these reports drops, resist the urge to nod along and move on.

Instead, ask: which of these barriers are we actively working to remove? Who owns each one? What resources are behind it? What does progress look like on a 90-day horizon?

If you can’t answer those questions, the barrier list isn’t research. It’s a mirror.

These barriers have been known for two years. They’ll still be known next year if the only response is acknowledging them in another planning deck.

Somebody has to do the work. In most organizations, that role either doesn’t exist yet or doesn’t have the authority to act.

That’s the barrier nobody puts on the list.

I’d be curious to hear which barrier your organization spends the most time acknowledging and the least time actually working on.