Chapter 9 · The Implementation Roadmap

A staged, evidence-driven adoption path: ninety days to first value, twelve months to a new operating model. This chapter covers what to fix before you start, how to run the first 90 days, how to scale, and when to wait. Section 9.6 maps each pilot phase to CloudThinker settings.

9.1 Readiness: what agents need from you

Agents amplify the environment they inherit. Check five foundations before the first deployment.

Foundation	What “ready” looks like	If it’s missing
Observability	Centralized logs, metrics, and traces with reasonable coverage of the target domain	Agents can’t reason over signals that don’t exist. Fix this first.
Access architecture	Scoped, short-lived credentials you can issue per agent	If everything runs on one admin key, fix that before any agent can act. In CloudThinker, credentials are per connection: give each pilot connection its own read-only role, as in the AWS, Azure, or Google Cloud setup.
Source of truth	Infrastructure as code (IaC) for the systems agents will touch, even partially	Agents lack a safe change mechanism, and you lose a diffable audit trail.
Documented intent	SLOs, runbooks, architecture notes. Imperfect is fine.	Agents have no context about how your systems should behave.
An accountable owner	A named senior engineer who sets autonomy policy and has the standing to bring the on-call rotation along	The program stalls at advice-only or drifts into ungoverned action.

9.2 The 90-day pilot

The autonomy levels in this table come from §3.2: L0 observes and reports, L1 investigates and recommends, L2 prepares a fix and waits for sign-off, and L3 runs pre-approved action classes and tells people afterward.

Phase	Weeks	What you do	Exit criteria
Baseline and scope	1–2	Capture MTTR, alert volume, page counts, and toil hours. Pick one bounded domain, such as one product’s incident response or cloud cost for one account.	Signed baseline, scoped domain, agreed success metrics
Observe (L0–L1)	3–6	Connect telemetry and tools with read access. Agents investigate every incident alongside your engineers, and on-call grades each analysis.	At least 70% of root-cause analyses marked right by on-call
Approve (L2)	7–10	Agents propose complete fixes with evidence. A person approves each one. Track acceptance and rollback rates.	At least 80% acceptance, zero harmful actions, MTTR visibly improving
Graduate (L3)	11–13	Pre-approve the 5 to 10 safest, most repeated action classes. Agents act, then notify. Review every action weekly.	First autonomous resolutions in production, with a documented MTTR change against the baseline

Don’t start with your hardest problem. The pilot’s job is to produce evidence and trust. A boring domain with frequent, repetitive incidents builds statistical confidence fastest. Good candidates: Kubernetes pod restarts, disk pressure, certificate expiry, and cost anomalies. The hyperscalers advise the same shape. AWS’s best practices for DevOps Agent say to start with a focused scope and expand based on investigation results. If a vendor tells you to skip these phases, ask why.

9.3 Scaling: months 4 to 12

Move	What it means
Expand domains, not just autonomy	Add one area at a time, such as databases, security, or cost. Each goes through the same observe, approve, graduate sequence.
Make governance enforceable	Move autonomy policy from a document into enforced configuration. Add an oversight layer, and feed agent actions into change management with automatic evidence.
Build the memory layer	Curate what agents know: topology, conventions, past incidents, team knowledge. Over time this is what makes your deployment hard to copy.
Restructure on-call	As autonomous resolution rises, consolidate rotations, move reclaimed senior time to prevention work, and formalize the agent-operations and autonomy-policy roles from §7.2.
Report every month	Publish the dashboard from §8.2 to engineering and the business: MTTR trend, autonomous resolution rate, pages avoided, money saved. Funded programs are measured programs.

9.4 How the canceled 40% die

Gartner predicts more than 40% of agentic AI projects will be canceled by the end of 2027. It names three causes: escalating costs, unclear business value, and inadequate risk controls. In operations, those show up as five concrete failures.

Failure	Gartner cause	What happens	Antidote
The pilot that never graduates	Unclear value	Advice-only forever feels safe and proves nothing. The renewal arrives with no MTTR change to show.	Sign graduation criteria on day one, and honor them on schedule.
Autonomy before evidence	Inadequate risk controls	One confidently wrong action at 3 a.m. costs more trust than a hundred good ones earn.	Never skip phases. Let acceptance and rollback rates set the pace.
Tool sprawl without orchestration	Escalating costs, unclear value	Five disconnected point agents bring back the swivel-chair problem with extra licenses. §10.3 traces the same problem across single-cloud agents.	One orchestrator, one audit trail, one dashboard.
Unbounded model spend	Escalating costs	Frontier reasoning on every noisy signal erases the return before the first renewal.	Two-tier sensing and per-incident cost tracking from day one (§8.4).
Treating it as a tool purchase	All three	The gap between experiment and production from Chapter 1 is an operating-model gap, not a technology gap.	Budget for role changes, policy work, and the trust ladder, not only the license.

9.5 When not to deploy

Some cases call for waiting. Each one below is something to fix first, not a permanent verdict. Deploying through any of them buys an expensive disappointment.

Disqualifier	Why it blocks you	Fix first
No signal to reason over	With sparse or fragmented observability, the agent reasons confidently from noise. Amplifying a blind spot produces a confident blind spot.	Centralize logs, metrics, and traces for the target domain.
One shared admin credential	You can’t bound an agent’s blast radius or contain a compromised one.	Issue scoped, short-lived credentials per agent (in CloudThinker, per connection) before allowing any autonomous action.
No owner for autonomy policy	The program stalls at advice-only or lurches into ungoverned action.	Name the owner before the pilot starts. It isn’t a role to fill later.
Change management has no path for machine-initiated change	Agent actions either bypass governance, which a regulated environment can’t accept, or get blocked entirely.	Add a path for machine-proposed, human-approved changes with an audit trail.
The first target is your most critical, least reversible system	Starting where a wrong action is catastrophic inverts the trust ladder.	Wait for, or deliberately carve out, a bounded and reversible domain.

One more disqualifier has nothing to do with infrastructure. If the organization is buying only a license, and can’t fund the role redesign, the policy work, and the trust ladder, it will land in the canceled 40% however ready its systems are.

9.6 Running the pilot in CloudThinker

If you run the pilot on CloudThinker, each phase maps to settings you can check.

Phase	In CloudThinker
Baseline and scope	Set the Approval mode to Manual first (Approvals in the sidebar, Approval mode tab), and under Run types override Automations to Manual too, since that row doesn’t follow the workspace. Then add connections for one bounded domain only, such as one AWS account or a staging Kubernetes cluster, with read-only credentials. Export the last 90 days of MTTR and pages from your paging tool for the baseline: CloudThinker can’t measure the period before you connected it (§8.2).
Observe	Stay on Manual. Reads always run, and every write waits for a person, as long as no run type, Automation, or chat has picked a looser mode of its own. Have on-call mark each diagnosis right or wrong under Was Resolve’s diagnosis right? on the incident. Grading needs the workspace Admin role, so give graders that role or have an Admin record on-call’s verdicts.
Approve	Stay on Manual, and add Approvers groups on the Approvers tab so proposed fixes reach the right people. Approval cards show in chat and also work in Google Chat. Slack and Microsoft Teams link back to the web app to approve. Turn on Agent approvals in Notifications to send requests by email or chat. Track Fix acceptance on Resolve → Insights → Accuracy & trust.
Graduate	Accept Approval Rules that Allow the specific operations that cleared about 95% approval without changes and no rollbacks (§8.2), on specific connections. Then switch Workspace mode to Auto · Rules · Ask me: Allow Rules only run writes alone under Auto, and with AI judgment off, every write no Rule allows still waits for a person. Allow Rules decide only once CloudThinker turns on Rule enforcement for your workspace, so stay on Manual until it’s on.
Report	Pull MTTR, auto-resolved share, and noise numbers from Resolve Insights. §8.6 lists where each KPI lives.

About CloudThinker maps the rest of this field guide to product features. Next: Chapter 10 · The Road Ahead covers the shifts coming next and how to choose between hyperscaler-native agents and one platform across every cloud.

Learn

Workshops

Scenarios

Chapter 9 · The Implementation Roadmap

9.1 Readiness: what agents need from you

9.2 The 90-day pilot

9.3 Scaling: months 4 to 12

9.4 How the canceled 40% die

9.5 When not to deploy

9.6 Running the pilot in CloudThinker

​9.1 Readiness: what agents need from you

​9.2 The 90-day pilot

​9.3 Scaling: months 4 to 12

​9.4 How the canceled 40% die

​9.5 When not to deploy

​9.6 Running the pilot in CloudThinker

9.1 Readiness: what agents need from you

9.2 The 90-day pilot

9.3 Scaling: months 4 to 12

9.4 How the canceled 40% die

9.5 When not to deploy

9.6 Running the pilot in CloudThinker