Six places a rollout stalls. 24 practices, split by who owns each move. Five ways a programme fakes momentum. The numbers that separate real adoption from seat activation. Most of what kills an agent rollout has nothing to do with the model.
A working pilot proves the harness can work somewhere. It does not show whether the other engineers will pick it up. It does not show whether the review queue can absorb five times the diffs. It does not show whether anyone can tell a real improvement from a number measured against no baseline. Most rollouts stall in the gap between a proven pilot and an organisation that runs on it.
The Agentic Delivery Playbook covers the machine: task definition, isolation, stage gates and spend. This page covers what must be true in the organisation around that machine. Without it, the machine produces nothing at scale.
Each surface fails a different way. None of them substitute for each other.
Covers: The problem the rollout must solve, one named accountable sponsor, and a written definition of success. Agree all three before the first licence is bought.
Breaks when: The mandate says "roll out AI" and names no sponsor. When the pilot numbers turn ambiguous, nobody has the authority or the duty to make the call.
Watch: Time between the first licence purchased and a written definition of success
Covers: Choose a pilot team whose workload, codebase health and appetite generalise. Name the exit-from-pilot criteria before the pilot starts.
Breaks when: The pilot team is the platform group's best engineer in a clean, greenfield service. The result then predicts nothing about a legacy team that carries real technical debt.
Watch: Share of exit-from-pilot criteria written down before the pilot's first week
Covers: The sanctioned harness and defaults, sandboxing and repo hygiene. Agent instructions files, tests that gate a merge, and the boundary of what an agent may touch. Enablement built as pairing in the team's own repo.
Breaks when: The rollout ships a licence and a slide deck with no sanctioned default. Every team improvises its own guardrailsGuardrails are the checks that keep an LLM or agent inside acceptable bounds in production. at a different level of care. People then blame the tool for the friction.
Watch: Share of teams that run on the sanctioned harness instead of a bespoke one
Covers: Review capacity, CI throughput and spec quality. Who owns the merge. How the senior engineer's role changes once writing code stops being the bottleneck.
Breaks when: Agents multiply the diffs a team produces and review capacity stays the same. The queue that said "waiting on code" now says "waiting on review", at the same total cycle time.
Watch: Review latency on agent-authored changes against the team's own pre-rollout baseline
Covers: The baseline captured before rollout. Every adoption number paired with a quality number. The split between the median engineer and the power user.
Breaks when: Nobody captured a pre-rollout baseline. A real improvement and a number that merely looks better than a guess are then impossible to tell apart.
Watch: Whether a dated pre-rollout baseline exists for every metric on the scoreboard
Covers: Plateau and regression past the launch spike, and spend per team. Unsanctioned use read as a signal. Retiring pilot scaffolding on schedule. A named platform owner with a refresh cadence.
Breaks when: Adoption plateaus at the enthusiasts within the first month. The rollout reports the plateau as steady-state success, because nobody asked why everyone else stopped coming back.
Watch: Active weekly usage among engineers with tool access, tracked for months past the launch spike instead of only the first one
Filter by how far a practice has to reach (pilot, team, org), then copy the visible list as a Markdown checklist.
Showing all 24 practices
Every agent rollout starts with an announcement. Most skip the part that gives the announcement meaning. That part is one named owner and a written definition of success. Agree both before the first licence is bought. Without these, the rollout runs on borrowed authority. A budget gets approved because a competitor shipped something or a demo landed well. Nobody answers in writing what problem the rollout solves or how anyone will know it worked. The gap does not show at first. It shows months in, when the pilot numbers are ambiguous. By then no sponsor is left to make the call, and no written definition of success exists to judge it against.
The team that pilots an agent rollout decides more about the result than the tool does. Teams get picked for an enthusiastic manager, a clean codebase or unusually well-scoped tickets. Such a pilot looks great and predicts almost nothing about the teams that wait behind it. The best team is the wrong target. Find a representative team. Then name what "worked" means before the pilot starts. This stops the decision to expand from going to whoever tells the best story afterward.
A licence and a link to the vendor's documentation is not a paved road. It is the absence of one, dressed as adoption. An agent works well in a codebase only when four things exist. It needs a sandboxed environment and a repo-local instructions file. It needs tests that gate a merge. It needs a stated boundary of what it may touch. They must exist before a second team is asked to use any of it. Enablement should be a worked example in the team's own repo, done beside a person who knows the harness. It beats a webinar every time, because it is the only version that survives contact with a real ticket.
An agent that writes code faster changes nothing on its own if the team downstream cannot absorb the output. Review capacity, CI throughput and spec quality were sized for the old rate of change. A rollout that does not resize them only moves the bottleneck from writing code to reviewing it, at the same overall speed. The senior engineer's job changes here too, whether anyone planned for it or not. Once code is no longer scarce, judgment about what to build and what to approve becomes the main work. If a team never says so, its senior engineers end up competing with agents at the one task that stopped being the bottleneck.
A number reported after rollout with no baseline before it is an anecdote wearing a dashboard. Most programmes never capture what cycle time, review latency or change-failure rate looked like before the harness arrived. Every improvement claim afterward is then measured against a guess. The fix is procedural. Take the baseline in week one, on every team the rollout plans to compare later. Then pair every adoption number with the quality number that would catch it flattering the programme.
Adoption that plateaus at the enthusiasts looks like success if the only number anyone tracks is whether the licence got used at all. The harder questions come later. Why did the other engineers stop after week one? What do the unsanctioned workarounds say about the paved road? Who owns the harness once the pilot team that built it has moved on? A rollout that never revisits its scaffolding ages into the rigidity it was meant to replace. The same happens if it never sets a cadence to refresh the harness as the underlying tooling changes.
No practices match that combination. Clear a filter to see more.
Every one of these looks like a working rollout right up until the number it was supposed to produce turns out to be hollow.
Looks like: A dashboard shows every engineer with a licence assigned and at least one login. The rollout reports that as adoption.
Costs you: An assigned licence and one login say nothing about whether anyone landed a merged change. The rollout can report full activation while real usage sits with a handful of engineers.
Fix: Report the paired quality number beside every adoption figure. Segment by usage decile so the median engineer's number cannot hide behind the top decile's.
See the practice: Pair every adoption number with a quality number →Looks like: One enthusiastic team lead reports a large personal speedup. The rollout report quotes that number as the expected result org-wide.
Costs you: That number is true for one person who was already motivated to make the tool work. It says nothing about the engineers who have not tried it yet. Expectations set against it make every ordinary result look like underperformance.
Fix: Segment every metric by usage decile and state the median. Show it beside the number that made the best slide.
See the practice: Measure the power user and the median engineer separately →Looks like: Engineers report that the tool feels faster. The rollout counts that as a win.
Costs you: Review may have absorbed the saved time through a bigger queue and more back-and-forth on agent-authored diffs. The change-failure rate may also have crept up. Either way, the time saved never reached a shipped, working outcome. The bottleneck moved downstream where nobody was watching.
Fix: Size review capacity to the new diff volume before rollout. Track cycle time and change-failure rate, because they would catch the trade as it happens.
See the practice: Size review capacity to the new diff volume before it arrives →Looks like: Leadership announces the rollout and a licence budget. It expects teams to work out the rest themselves.
Costs you: Every team invents its own guardrails at a different level of care. Engineers blame the tool for the friction when the harness is what is missing. The mandate's credibility erodes before the paved road ships.
Fix: Ship one sanctioned default harness, piloted and packaged, before the mandate reaches teams beyond the pilot.
See the practice: Ship one sanctioned default harness before asking teams to adopt anything →Looks like: The pilot clears every exit criterion, and the team credits the harness.
Costs you: The real reason it worked may be one platform engineer who fixed broken configs and coached people through failures all quarter. The result then does not survive that person moving on. The second team's onboarding fails in ways the pilot never surfaced.
Fix: Run enablement as pairing and worked examples in the team's own repo. Add a named platform owner who is separate from whoever ran the original pilot.
See the practice: Name a platform owner before the pilot team disperses →Every one of these is measurable today. None of them is trustworthy read alone. Pair it with the number next to it.
No invented survey statistics. This section lists what the site already documents, and how the pieces connect.
The risk-management functions our governance and adoption controls map onto. Retrieved 2026-08-24.
The annual report our adoption page's industry-wide statistics are drawn from. Retrieved 2026-08-24.
A Ship Audit checks the paved road and the absorption math against your specific team before the rollout reaches the next 179 engineers.
What teams ask us before they take an agent programme past the first team.
Change management is the general discipline. This page is the version for an agent rollout. It adds a paved road, review-capacity math and a scoreboard. A generic change programme does not ship with these.
Link to this answer: Isn't this just change management with new labels?A pilot proves the harness can work somewhere. It does not prove the result generalises to a team with a different workload. It also does not prove the organisation can absorb several times the review volume once the rollout scales past the pilot team.
Link to this answer: We already ran a successful pilot. Why isn't that enough?Skip the paved road and ship a licence with no sanctioned default. Every team improvises its own guardrails at a different level of care. People read the friction as the tool being bad. The mandate loses credibility before anyone builds the thing that would have made it work.
Link to this answer: What's the fastest way to kill a rollout without meaning to?Pair every adoption figure with its quality counterpart. Check the median engineer beside the top decile. Activation with no merged output and no movement in review latency is the seat-activation trap. On a dashboard that reports only the average, it looks identical to real adoption.
Link to this answer: How do we know adoption is real, rather than seat activation with nothing behind it?Both, at different points. Leadership owns the mandate and the definition of success. The platform team owns the paved road and its upkeep once the pilot ends. A rollout that lacks either one stalls in a different place, depending on which is missing.
Link to this answer: Who should own this, the platform team or engineering leadership?Yes. Most of what breaks a rollout shows up after the pilot succeeds. This includes absorption capacity, the median-versus-power-user gap and unsanctioned use. Revisit the surfaces above at the scaling stage, even if the mandate and first-team work already happened.
Link to this answer: Does this still apply once we're past the pilot and scaling org-wide?Source: https://customlabs.io/adoption/