The AI Adoption Ladder

3 numbers from the 2026 Product Focus survey of product managers belong next to each other, although the report lists them pages apart.

97% say AI improved their personal productivity. 64% say it improved their product outcomes. 71% say they still do not spend enough time with customers and the market.

The first number is effectively everyone. By the second, 1/3 of the room has dropped out. The third has barely moved in years, and that is the one worth sitting with: whatever AI gave product managers, it did not give them more contact with the people they are building for.

I do not think the missing third is a model problem. The same survey catalogues what goes wrong, and the list is not about intelligence: fabricated or stale research, unreviewed drafts hardening into official documents, confident recommendations with no evidence underneath. Those are not failures of reasoning. They are failures of what surrounded the reasoning.

That surrounding thing is what this piece is about. I have spent the past year building one, and comparing notes with teams doing the same, so read me as interested rather than neutral.

The thing around the model

Call it a harness: everything you build around the model so it does useful work on your product instead of generic work on a prompt.

Make it operational and it becomes 5 questions with testable answers.

• What context should the agent load before it starts?
• Which tools is it allowed to use?
• Which workflow should it follow?
• What state counts as done?
• Which checks run before the result reaches a person?

A team with good answers to those 5 can use a mid-tier model more consistently than a team with no answers and the best model available. The percentage measures the model. The 5 questions measure the harness.

Most teams have never written an answer to any of them down. The answers exist, but they live in one person's head, one person's folders, and one person's habits, which is fine right up until a second person needs the same answer.

The industry started naming it

The useful signal of the last year is not that agents got better. It is that the work around agents acquired a name and a literature.

OpenAI now publishes on harness engineering. The post comes from a team that spent 5 months shipping a real internal product with no manually written code. The useful part is how they describe the work around the agent: designing environments, specifying intent, and building feedback loops that make repeated work more reliable. Those are 3 different jobs, and none of them is prompting.

Cursor calls the same shift the third era of AI software development, and ships Automations, where a workflow is a trigger, a sandbox, configured models and connectors, a verification step, and memory. Claude Code now presents scheduled routines and dynamic parallel workflows. Codex supports durable repository guidance, MCP, reusable skills and plugins, parallel work, and scheduled tasks. Anthropic published a privacy-preserving analysis of roughly 400,000 Claude Code sessions, enough activity to expose recurring ways people delegate and review work.

Read those together and the direction is consistent. It runs from a person directing one agent in a chat window, toward a team operating an environment that can repeat work, verify it, and revise its own operating instructions.

One boundary before I go further, because it matters for how you use the rest of this. The 6 rungs below are our synthesis from the field, not an industry standard and not a certification. Nobody grades you on them. They exist so a team can locate itself and pick a next move.

Below the hinge: the context lives in a person

The bottom 3 rungs are not weaker versions of each other. They fail in different ways, and the differences are the useful part.

0 · Reused prompts

A chat box and a handful of prompts that worked once. ChatGPT, Claude, Gemini, whichever the person opened first, maybe a connector or two.

People who have left this rung dismiss it too fast. It costs nothing, it starts today, and it genuinely removes the blank page from drafting, summarizing, and first-pass analysis. Everyone should have it.

What it cannot do is accumulate. Every conversation starts near zero, so the good result one person got on Tuesday is not available to anyone on Wednesday, including them. Speed here is bought with quality, and nothing in the setup will tell you the price.

The tell is that 2 people ask the same model the same question, ship different answers, and nobody notices, because there was never a place where the 2 answers would have met.

Off this rung: take the 2 or 3 tasks your team genuinely repeats and write down the inputs, the constraints, and what done means. Not all of them. The ones that recur.

1 · Shared context

The prompts become objects other people can open. A Claude Project, a Gem, a custom GPT, a prompt library, a shared skill.

The gain is real. Consistent starting points across a team, less blank-page setup, and often the first prototype that survives being shown to a customer.

The flaw is hiding inside the word shared. What got shared was a snapshot. It holds what a few people knew on the afternoon they wrote it, it averages their views rather than reconciling them, and it has no way of noticing that it has aged. Standards written this way are still suggestions: nothing checks the output against them.

The tell is quiet. People stop opening the shared Project. They do not announce it. They drift back to private prompts, and the team goes on believing it has a standard.

Off this rung: give people agents that act on real work rather than assistants that answer in a window. Before you do, put an owner and a review date on the shared thing, or rung 1 follows you up the ladder.

2 · Agents for all

Claude Code, Codex, Cursor, or the equivalent, in the hands of everyone willing to use them. Files, repositories, terminals, APIs, MCP servers, the design system. Non-technical people get read access to the codebase. The agent stops drafting and starts doing.

This is where most teams I speak with are sitting, and where most of them will stall. The reason is worth being precise about, because it is not a capability problem and it does not get better with a smarter model.

Context is still per-person, and now it has horsepower behind it. Each laptop holds different folders, permissions, instructions, and half-remembered decisions. Worse, no agent can read every conversation your company has ever had, so it reasons from whatever slice it happened to see. Then it agrees with you, because agreeing is what these systems do under pressure.

Thin evidence plus a model inclined to agree produces the most expensive artifact in product work: a confident, well-sourced, wrong conclusion. 2 people can ask the same product question and get 2 of them, each citing something real, pointing opposite ways. Nobody can adjudicate without rebuilding the evidence by hand, which costs more than the answer saved.

The tell is a meeting where 2 people arrive with conflicting answers, each cites their agent, and the meeting stops being about the product.

Off this rung: stop keeping context per person. Build a shared product context layer that records the evidence, decision, constraints, and learning the next person or agent will need.

The hinge

Everything below rung 3 makes individuals faster and lets the team drift apart. Everything above it costs real money and makes the team converge.

That is the whole model. It is also why I resist calling this an AI adoption curve, as though the variable were how much AI you use. Rungs 0 to 2 are a distribution problem: getting capability into more hands. Rung 3 onward is a discipline problem: deciding what is authoritative, who owns it, how it stays fresh, and what happens when two sources disagree.

Different projects, different bills. The second one is the one teams skip, and skipping it is why the 97 and the 64 are not the same number.

Above the hinge: the context lives in one place

3 · The business harness

One structure holds the context the agents need. Usually a meta-repository or something like it, carrying product, market, customer, brand, design, and engineering context alongside the code, plus shared skills and guidance on which tool to reach for, not only which connector to call.

The gain is coverage. An agent can help from discovery through delivery to performance review, because the connections between those activities are finally visible to it rather than living in somebody's head. Guidance changes through a reviewed commit instead of a private habit, which is the first time the team's operating knowledge behaves like code.

The risk is a document attic. Without curation, a shared structure fills with duplicated instructions, stale research, contradictory rules, and documents nobody trusts enough to open. Centralizing context does not make it current. And a harness with confident, outdated instructions will repeat a bad decision very efficiently.

The tell is a sawtooth: excellent for 2 weeks after a cleanup, degrading until the next one.

Off this rung: turn the most repeated parts into maintained tooling, so it stops depending on one person's discipline.

4 · The multiplier harness

The team builds its own. Maintained CLIs and APIs called directly instead of rented utilities, internal plugins, agent-run QA on first-pass work, batch ingestion of calls from Gong or Zoom or Granola, and enough DevOps that a product manager or designer can push a branch and get back a working URL with synthetic data on it.

This is where the team multiplies rather than the individual. Prototypes get built on the real components and the real rules, so the merge diff at the end is survivable. Checks run without a person starting them.

It is also the rung where the bill arrives. You now own maintenance, permissions, automation debt, and failure recovery. A badly designed workflow scales a bad decision faster than a person could. A check that passes every time has usually stopped measuring the thing it was written to protect. Utility sprawl is a real operating cost and nobody budgets for it in advance.

The tell is that the tooling is excellent and only runs when somebody remembers to run it. Freshness is a function of attention, and attention is the resource you were trying to save.

Off this rung: give the harness a heartbeat. Define the trigger, the bounded action, the check that is allowed to fail, and who resolves it when it does.

5 · The evolving harness

The harness runs on its own schedule. Research refreshes. Calls are processed on arrival and in full, kept as source records rather than reduced to a summary that discards the detail you will need in 6 weeks. Instructions, prompts, and evaluations change in response to observed failures rather than remembered ones. Delivery results return to the place the evidence came from.

The benefit is that impact compounds without anyone starting the cycle. The cost is a different hiring plan: deep DevOps and full-stack work, and then evaluation work to tell whether the changes the system makes to itself are improvements or overfitting to last week. That last skill is expensive right now.

The honest failure mode at this rung is that self-improving becomes an unreviewed claim. Memory preserves mistakes as faithfully as it preserves lessons. Scheduled work generates noise on a schedule. A system can get measurably better at a proxy while getting worse at the thing the proxy stood for.

This is the frontier, and it is what we are building. Zentrik Context keeps customer evidence, the decision, the test, delivery, and the learning attached to the same piece of product work, so a team and its agents stop rebuilding the story at every handoff.

The 2 systems worth keeping apart

Here is the distinction that decides whether any of the climbing was worth it, and the one I see collapsed most often.

An execution harness answers the 5 questions from earlier: what to load, what it may use, which workflow, what done means, which checks run. It repeats a bounded task and stops when a check fails. That is the layer teams configure around AI builders before they start work.

A product learning loop answers a different set of 5. Which customer and problem are we choosing? What evidence supports that? What is still uncertain? What is the smallest honest test? What changed, and how should that change the next move?

The clearest way to see the gap is in a team that has done the harness work well. They run a weekly job pulling every call transcript into local storage, and it works. Now there is a folder holding tens of thousands of markdown files, fully searchable. Then somebody asks an ordinary question: in the area we are working on this quarter, what are customers telling us that we have not acted on?

The answer may well be in 3 of those 10,000 files. Finding it by search means already knowing the words those 3 customers used, which are not the words you would think to type. Nothing was processed, so nothing can be found by meaning.

What went missing is not the data. It is the reason. Somewhere between the call where a customer said the thing and the branch where an engineer built something, the why came unattached from the what, and no amount of harness puts it back.

Build to learn got easier. Build to earn is still a different job.

That gap is the reason Zentrik exists, so let me be concrete about what closing it looks like rather than leaving it as a claim. A call arrives and is kept as a source record instead of a summary. The signals inside it stay attached to the insight they support, the insight to the opportunity it makes legible, and the idea to the initiative that carried it into Jira.

What ships returns as evidence for the next decision. The quarterly question above then has an answer you can open, follow back to the sentence a customer actually said, and argue with.

That last part is the one that matters. A chain you cannot inspect is a confident agent with better formatting.

5 moves on one workflow

The mistake is trying to climb everywhere at once. Pick one recurring decision and do these 5 things to it. They are deliberately tool-agnostic, and they work whether you are on rung 1 or rung 4.

1. Name one recurring decision and its owner. Not "adopt AI across product." A decision your team makes again next week, with a person who can approve, narrow, or stop it.
2. Separate the source from the instruction. Keep the call, ticket, or research note attached to the work. A summary is compression, not evidence, and you cannot re-examine a decision from a summary.
3. Version the operating contract. Inputs, constraints, tool guidance, and what done means, in a shared place where changes get reviewed.
4. Make 1 quality gate deterministic. A test, a rubric, a source check, an eval that can actually fail, and a named person who resolves it when it does. A check that cannot change the next action is decoration.
5. Write the learning back. What changed the decision, what is still unproven, and where that lands so the next run reads it.

Then use the table to find your rung and the move that follows it.

A team can sit at rung 4 for release checks, rung 2 for discovery, and rung 0 for customer research, in the same week. That is normal, and it is why a single company-wide score is worse than no score at all.

Where this is going

2 things follow from the direction of travel, and I would plan for both.

The first is that the scarce skill moves from asking to specifying. It is worth noticing that the OpenAI team above landed on the same word from the opposite direction: they were optimizing for engineering velocity and concluded that their scarce resource was human attention, and that specifying intent was where it should go. When an agent can execute most of what you describe, the constraint becomes your ability to say what good looks like in a form something else can check. Anthropic's own guidance on evals makes the point sharply: the people closest to the product requirements should be the ones defining success, and product managers can contribute eval tasks as pull requests. That is a genuinely new line in a product job description, and it is a better use of a PM's afternoon than another prompt library.

The second is less comfortable. Harnesses are becoming ordinary. The tooling that felt like an edge this year is being absorbed into the platforms, and within a couple of cycles most serious teams will have a competent one. When everybody has a harness, the harness stops being the advantage. What remains is whether it is pointed at something worth doing.

That is not an infrastructure question, and no amount of scheduling solves it. It is the same question the 71% have been failing to answer for years, now with much faster machinery attached. A system can refresh, retrieve, prepare, and route. It cannot tell you which customer deserves the next quarter. AI structures the evidence and prepares the work. People still own the judgment, and I would be suspicious of anyone selling you a version where they do not.

Which is the whole reason we build what we build. The customer reason should survive every product handoff, and right now it usually does not survive the first one.

Start smaller than you want to

If the 3 numbers at the top of this piece describe your team, the fix is not a platform decision and it is not this quarter's tooling budget.

Take one decision your team will make again next week. Name who owns it. Attach one real customer source to it. Write down the single check that is allowed to stop the work. That is a rung, and it is available on Monday.

Do that 4 times and you will have something most companies do not: a workflow where you can say what the agent knew, why the call went the way it did, and what changed as a result. Whether you build it yourself or use what we built, that is the thing worth having.

If you want help with the one move rather than the whole climb, we run short working sessions: 25 minutes, one decision, one source, and you leave with it running. Ask for one here.

I write these as I go. Tell me which rung you are on and what the tell was. Those replies are the most useful thing I get. LinkedIn is the easiest place to find me.