The AI Adoption Ladder
From a saved prompt to a harness that maintains itself
Learn the 6 stages of AI adoption for product teams, from reusable prompts to agent harnesses that preserve context, verify work, and write learning back.
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, a third 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.
The survey does not establish what causes that gap. But the failures it describes give us places to look: fabricated or stale research, unreviewed drafts hardening into official documents, confident recommendations with no evidence underneath. Some involve the model; others involve the sources, checks and decisions around it. We need to inspect the whole workflow.
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.
That sounds abstract until you make it operational, at which point it becomes 5 questions with real 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?
Those 5 answers make a workflow easier to inspect and improve. If an agent acts on an old decision or cannot tell a draft from an approved plan, a better model may still produce the wrong work. Test the complete setup on tasks you understand before attributing a gain to either the model or the harness. A personal-productivity percentage cannot separate those effects.
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 two people ask the same model the same question, ship different answers, and nobody notices, because there was never a place where the two 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.
Inspect the sources, the current decision and the checks around an agent's answer. Confidence alone cannot tell you which part failed.
The hinge
The hinge is where a team starts maintaining shared context and accepting responsibility for changes to it. That can reduce repeated explanation and conflicting versions. It does not guarantee agreement: two people may read the same evidence and reasonably choose different tradeoffs.
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.
These are different kinds of work with different costs. The survey gives us a reason to investigate the gap; it does not prove that a shared harness closes it.
Above the hinge: someone owns the shared context
3 · The business harness
A shared structure tells agents where to find product, market, customer, brand, design and engineering context, and which records are authoritative for the task. We use repositories for much of this. Another team may keep its records in existing business systems. The requirement is a clear owner and a review path for changes, not one physical store with universal access.
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 maintains repeatable operations: CLIs and APIs, plugins, agent-run QA on first-pass work, ingestion of calls, and a way for a product manager or designer to get a working preview with synthetic data. Some operations can come from existing providers or platform teams. Build the missing pieces where they justify their maintenance cost.
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 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 be spread across a few of those files. Semantic search can retrieve related language without an exact keyword match. What still needs work is the relationship to our decisions: which reports describe the same incident, which interpretation we accepted, and what we have already tried. Retrieval alone does not establish that history.
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. One line from the field says it better than I can: build to learn got easier, and 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, the idea to the initiative that carried it into Jira, and 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.
An execution harness repeats the work. A learning loop decides whether the work is still worth repeating. Connect them. Do not collapse them.
5 moves on 1 workflow
The mistake is trying to climb everywhere at once. Pick 1 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.
- 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.
- 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.
- Version the operating contract. Inputs, constraints, tool guidance, and what done means, in a shared place where changes get reviewed.
- Make one 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.
- 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.
| Rung | Where context lives | What is still broken | The next move |
|---|---|---|---|
| 0 · Reused prompts | Nowhere. One person's tabs | No standard, nothing accumulates | Write down the few tasks that recur |
| 1 · Shared context | Shared, but a snapshot | Goes stale, averages everyone | Give people agents that act |
| 2 · Agents for all | Per-user locals and git | Confident answers that disagree | Put context in one shared place |
| 3 · Business harness | One curated structure | Drifts the moment upkeep lapses | Build your own tooling |
| 4 · Multiplier harness | Managed, engineering-supported | Only runs when someone runs it | Give the harness a heartbeat |
| 5 · Evolving harness | Self-maintaining | The frontier, and the payroll | Pick one workflow, not all of them |
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 percent 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 1 decision your team will make again next week. Name who owns it. Attach 1 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 1 move rather than the whole climb, we run short working sessions: 25 minutes, 1 decision, 1 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.
