12.1 From conversation to standing mission
Most deployments today are conversational. An engineer opens a session, asks, approves, and closes the tab. That works, but it’s capped by human attention: the agent only works while someone watches. The unit that removes the cap is the mission: a standing objective with its own triggers, a bounded set of allowed actions, and a verification check built into the loop. “Help me with Kubernetes” isn’t a mission. These are:- Review every pull request for infrastructure impact.
- Keep image vulnerabilities below a set threshold.
- Hold this service to its SLO.
Chat doesn’t disappear. It becomes the exception surface: where you question a mission’s work, not where the work happens.
12.2 Vertical missions: autonomy through narrowness
Chapter 7 showed that on open-ended incident resolution, agents on current models resolve roughly one SRE benchmark scenario in seven. That doesn’t mean autonomy is years away. It means autonomy is earned per mission, and narrower missions earn it sooner. Shrink the objective, bound the actions, and make verification cheap, and the same models become production-grade because the harness can check their work.
The last column is the one that matters. Each mission closes on a check the machine runs itself: a rescan, a plan-diff, a CI gate, an SLO probe, a billing line. That gives you the promotion rule in one sentence:
A mission earns autonomy when its verification is cheaper than its supervision.
12.3 Engineers on the loop, not in the loop
“Human in the loop” hides a ceiling. If a person must click yes on every action, you’ve built a slower engineer. Per-action approval is a stage, not the destination. The destination is “on the loop”: engineers set the controls and handle what the controls can’t decide.
Promotion is per mission and based on evidence, the same way you promote code. A mission starts read-only. Next, it proposes changes that a person approves. Then specific, reversible actions run unattended within policy. Each step needs passing eval scores and a clean incident history (the gates from Chapter 7), and a mission can be demoted the same way.
Oversight stops being a meeting and becomes a control plane of policies, budgets, queues, and audit views. Supervising ten missions this way is a part-time job. Doing those ten missions by hand is ten jobs.
12.4 Five conditions, honestly stated
This future is conditional. Each condition is a chapter of this book. Use the table as a readiness check before you let any mission run unattended.
Teams that hold all five run operations as intent plus exceptions. Teams that hold none find that “autonomous” was only a label.
12.5 Building the future
The shift arrives one mission at a time, in roughly this order:- Code review goes unattended first, as advisory comments, because verification is nearly free.
- Cost missions follow, because every action is reversible.
- Security and incident response graduate one failure class at a time. Back each promotion with a golden set (Chapter 7) and three months of clean sampled audits.
In practice: missions on CloudThinkerCloudThinker runs these missions on one shared set of connections, one Approvals system, and one audit log.
The promotion ladder in settings
Every write passes your Rules first, then the Approval mode — though Rules decide only once CloudThinker turns on Rule enforcement for your workspace. Automations default to Auto · Rules + AI · Refuse: Rules decide first, then AI judgment allows a safe write that no Rule covers, and anything still undecided is refused, because no one may be online to answer. See the four Auto choices.The on-the-loop controls
Audit Logs and Credit limits need a Scale, Scale Plus, or Enterprise plan.