Adopting AI Is Easy. Delegating to It Is the Redesign.

Most AI adoption ladders rate people. This one rates decisions: what an organization hands to an agent, and the five prices it pays before each climb.

AI Agents 13 Nov 2026 10 min read

The delegation ladder: rungs 0 to 4 plus a ceiling, and the five prices paid before each climb.

The first time I let agents run a loop end to end, it was my own content and blog pipeline. I gave it an idea. The agents took it from outline all the way to publishing. It was fun, and a couple of pieces went out that way, under my name.

Then I pulled it back and added controls and a review step. The pipeline was clunky, parts of it failed, and what it published was AI slop with no clear point of view. The agents had everything except what I think. I was the missing definition.

Solo, that correction is cheap. The owner, the user, and the keeper of the definitions are the same person. In an organization, those three jobs belong to different people. That split is the whole problem.

In early November, someone in a product leaders' Slack asked whether anyone had seen an organizational AI adoption curve. The popular one is Dan Shapiro's ladder, from "spicy autocomplete" to "dark factory." It covers engineering. It says nothing about what product and design look like at each stage.

Klaviyo's co-CEO said every employee had to reach the company's level 3 by June, PMs and designers included (SaaStr's write-up). Ramp has a four-level ladder and a leaderboard. Zapier has a four-level fluency rubric that shapes how it hires and develops people. Every one of them measures a person. None of them measures what the organization hands over to the machine.

The curve I care about tracks what you delegate, one decision at a time. A decision can climb only as far as a named person owns it and its definitions sit where the system reads them. I've climbed that curve, and I've come back down it.

You can adopt without redesigning

You don't need to rebuild your org to get value from AI.

In a 2023 controlled study, developers using GitHub Copilot finished a bounded coding task 55.8% faster than a control group (Peng et al.). In 2025, METR studied experienced developers working in their own repos. They were 19% slower with AI. They believed they were faster. Either way, nothing about the org had to change. That's adoption.

It becomes an org-design problem the moment judgment, coordination, or action moves from a person to a system. That's delegation, and you can't delegate without redesigning.

The ladder that matters: what you delegate

Here's the curve I'd offer back to that thread. It builds on the delegate-or-coordinate table I wrote for role operating systems earlier this year. Instead of rating people, it rates one class of decisions inside a workflow. Scheduling a follow-up and defining a patient cohort can sit in the same workflow at very different rungs.

Before you climb at all, ask whether a plain rule or a saved query would do the job. Often it would.

Rung	What the system does
0. Assist	A person drives it, turn by turn.
1. Propose	It recommends. A person decides.
2. Act, reversible	It acts on a class of cases you can undo. A person spot-checks a sample, and anyone can stop it.
3. Act, wider	It acts on a wider class. The authority expires and gets renewed on evidence.
4. Propose process changes	It suggests changes to how it works. The owner approves them. (Rare today.)
Ceiling	It never changes the rules of its own authority.

"We're at L3" isn't a sentence a company can say.

The ceiling comes from Stuart Winter-Tear, who writes about how AI changes the design of organizations (A Management Theory for the Age of AI, p. 126). He also gave me the other two ideas on this chart: authority granted per class of cases, and authority that expires unless someone renews it. His line for anyone building in healthcare: "Capability does not grant permission" (p. 20).

Before a decision class moves up a rung, someone pays five prices:

An owner. A named person who signs for the output and re-checks the definition when it changes.
A definition in the build. Written where the system reads it, not in a doc next to it.
A test set. Known questions with known answers, rerun after every change. From rung 2 up, someone other than the owner writes or reviews it.
An outcome measure with a baseline. Cost per completed case, counted with the review and rework included. Renewal at rung 3 depends on this number, not on how much the tool gets used.
A refuse rule and a way down. When the system hands a case back, and what sends it down a rung. A failed known-answer check is the simplest trigger.

The cleanest ladder I've built in public is a release agent for InstaDoc, the clinical-care startup I co-founded. It reviews code changes before they reach staging, and its README opens with "Authority: none." It started at rung 0, logging every verdict for a person. It moves to rung 1, commenting on changes, only after my co-founder signs off. Clinical or emergency copy always goes to my co-founder, whatever the score. The way down is one deleted environment variable. And it uses no language model at all. The best example in this essay about delegating to AI runs on a plain scorer, so the "would a rule do?" answer was yes.

My blog pipeline climbed to publishing on its own, then came back down. Every other example here sits at rung 0 or 1. Rungs 2 and up are where the evidence thins, in healthcare most of all, and that's the reason to name the price before anyone climbs.

Definitions before delegation

In healthcare data, price number two is where most climbs stall.

"Active patient" means one thing to the care team, another to billing, and a third to the research group. "Adherent" depends on the window you pick. People reconcile those differences in meetings all the time (I wrote about three definitions of one metric in an earlier piece). An agent can't sit in that meeting.

When I was building an analytics agent for a healthcare data product, we tested it internally first. One test was a plain request: Build a cohort of patients with two co-occurring conditions. It used SNOMED codes first. The definition the team worked from was a custom mapping built on ICD-10. Same words. Different patients.

Testing caught it before a client saw it. A wrong answer that looks right is the risk in this field, and it isn't only a clinical one. Notion ran into it building a data agent for its own staff. Its team wrote that a query "could run cleanly and still answer the wrong question."

My own mistake was the order. The mapping existed, but in documents, not in the build, so the agent couldn't read it. I fixed the order.

Excalidraw diagram: the same cohort request goes two ways. The agent uses SNOMED codes first; the team's definition is a custom mapping built on ICD-10. The two patient sets are not equal. Definitions in documents mean the agent can't read them.

In practice, "definitions in the build" means three things:

A glossary file the agent loads on every run. It defines "active patient," names the owner, and points to the source table.
A governed metric the agent has to query through, instead of writing its own SQL against raw tables.
A set of known-answer questions, rerun after every change. Start with twenty.

If that sounds like a semantic layer, it's close. Two things are new. Cohort and code-set definitions don't live in a metric layer. And the agent has to be blocked from the raw tables, not only asked to avoid them.

I built a small public version of the test set. dpm_os, my open-source operating system for a data product manager, has a grader with 28 known-answer questions on synthetic OMOP data (a common standard for health records). A specialized agent setup ships only if it does better on its own questions and still gets every question right that the default setup gets right.

One setup, built for cohort work, counted a condition's more specific subtypes. It went 8 for 8 on its own questions, broke nothing, and shipped. Another, built for analysts who study hospital visits, limited the study population to patients seen between 2010 and 2018. That's a reasonable choice for those analysts. It went 7 for 7 on its own questions and broke 8 answers the default got right. The grader rejected it.

That's the "active patient" problem, in code. One team's sensible local definition breaks everyone else's answers, and the test catches it before a client does.

Klaviyo shows both sides. The level 3 mandate measures people. Its analytics team did the delegation work. Amy Peirce, who worked on that team, wrote that "the governance has to come before the agent." Her result was that

"two people asking the same question get the same number."

A definition in the build still needs a person who answers for it when it changes. That person is the owner.

It's a tool, not a person

You'll hear agents described as teammates, digital employees, a new hire on the org chart. An agent is a tool with a long loop. It has an owner. It doesn't have a seat. Brex's CEO pushes the employee framing hard and still keeps a person on the hook. In Peter Yang's interview with him, each \"AI employee\" gets a job, a budget, and a human manager who answers for its work.

A person signs the chart. Authority can be delegated to a system. Accountability can't. Winter-Tear is blunt about it: "'The AI did it' is not an answer" (p. 24).

The quieter risk runs the other way. Real authority drifts to the system while a person keeps the title (Winter-Tear, p. 124). On paper, a human decides. In practice, the human has a title, an approve button, and no hours. Under volume, Intercom's engineers wrote, "humans start rubber-stamping." Their answer looked like a rung 3 climb with the prices paid. The agent only approves small changes, every approval is logged, and any engineer can ask for a human.

Ask who owns the output, and whether they have the hours to own it.

Everybody was building in single player

The owner problem shows up in the order teams do the work. I've watched teams change the product and the build process first and the structure later. Nobody set expectations. Nobody agreed on what good looked like. AI products got wired into workflows with no owner and no eval program, the fixed set of test questions above.

At one company this year, the artifacts were everywhere: decks, plans, prototypes, a skill that told an agent how to format slides. None of them pointed to a policy, a best practice, or a shared picture of good. Even the brand was a small version of the problem. A style guide existed, on the last slide of an agency template from 2024. Each new AI-made artifact drifted a few color values from it, and the design-system page that was supposed to settle it had been written without anyone knowing the template existed. Two sources of truth, and no introductions. The definition was there. It wasn't anywhere the work could read it.

That's single player. It works until single-player work has to become team work. Then it needs a shared quality bar.

The order I'd use now:

The outcome. What gets better for the product, measured how.
Definitions and context. In the build.
The build. Prototype fast.
The team. Who owns what and who manages it, once you know what you're owning.

Sharing standards has a trap. A shared glossary, a registry of agents and specs, and a shared test set are evidence for owners. The central group publishes them, along with capacity limits. It can stop a climb only when a shared test breaks, the way the dpm_os grader did. The owner decides the climb, on evidence. From rung 3 up, the person who staffs the exceptions has to agree too, because they absorb the cases the agent hands back. If the central group starts deciding which agents get built, you've rebuilt a PMO with a new name.

Excalidraw diagram, who decides a climb: the owner decides on evidence; the central group publishes definitions, test sets, and capacity limits and can stop a climb only when a shared test breaks; from rung 3 up, the person who staffs the exceptions has to agree too.

What to do Monday

That split between the owner, the central group, and the person who staffs the exceptions has a name in Winter-Tear's work. He splits it into adoption, deployment, and absorption (p. 116). A VP Product can get a workflow to deployment. Absorption needs whoever controls staffing and targets. It's my pipeline problem at org scale: The owner, the user, and the keeper of the definitions are different people, and one of them holds the budget.

So start where you have authority. Pick one decision class in one workflow. Pay the five prices for it. Count the exceptions, the cases the refuse rule hands back.

You're done when the test set runs on every change and you can name the call you made: delegate within scope, keep a person's sign-off, narrow the task, repair a missing dependency, or decline (Winter-Tear, p. 134). In healthcare, repair and decline are often the right answer.

Bring whoever staffs the exceptions the test set and the exception count, not a demo. It's the same value-and-evidence gate I'd use for anything else you build.

AI and agents are one part data science and one part infrastructure. They're still tools on a hype curve. What has to change is how the work and the teams around them are put together.

So, back to that Slack thread. Rate the decision, and name who pays for the next rung.

I help healthcare data and software leaders make the production call on one agent workflow. If you want a second read before yours climbs, that's the work I do.