Anyone who has run more than one Claude Code session at a time on the same codebase already knows the drill. You split the work yourself, decide which session touches which files, track what each one is doing, and then stitch the results together by hand. The model can write good code in parallel. Coordinating that parallel work has been left entirely to humans.
Anthropic is trying to close that gap. On September 17, the company rolled out a redesign of Claude Projects that moves it from a static container for files and chat history into something closer to a project manager: A coordinator that breaks a stated goal into parallel threads, delegates the work, and assembles the results.
The mechanics are straightforward once you see them. A user states a goal and connects the relevant repositories or context, and a coordinator thread scopes the work and spins up worker threads to handle pieces of it. Each of those threads runs as a full Claude Code cloud session on its own branch, and can spawn its own subagents, loops, or workflows for anything complex enough to need them. Anthropic’s own examples give a sense of the target workload: Optimizing checkout latency across a set of endpoints simultaneously, or retiring a deprecated API across every repository that still calls it. Both are the kind of job that’s conceptually simple and logistically annoying — exactly the annoyance this redesign is aimed at.
Merges are handled through standard pull requests, which matters more than it sounds like it should. Anthropic isn’t asking teams to trust a black box to push straight to a branch; it’s asking them to review PRs the way they’d review PRs from a very fast, very literal junior engineer working several threads at once.
The other piece worth paying attention to is memory. Instead of every session starting from zero, context now persists across the threads in a project — deadlines, technical decisions, communication preferences, the fact that the release moved to Friday. Anthropic frames this as cutting down on prompt engineering, and for teams running the same project over weeks or months, that’s a fair description of the actual pain point: re-explaining context to a fresh session every time is tedious and error-prone. A project library rolls uploaded files and Claude-generated artifacts into one place alongside that memory, so the output of one thread is easier for the next one to find and build on.
None of this runs unsupervised by default. Anthropic built in controls for how much autonomy the coordinator gets — how often it checks in, how aggressively it spins up new threads, how much detail it surfaces in updates — and users can work from the main project chat for a high-level view or drop into an individual thread when they need to steer something directly. Projects are also reachable from a phone, which matters less for the coding itself and more for the review-and-approve loop that keeps someone in the chain.
The rollout is staged, which matters for anyone tracking whether this is ready to lean on. The beta starts with Claude Pro and Max subscribers running cloud sessions in Claude Code who don’t already have projects set up on web or desktop. Anthropic says a wider release to chat, Cowork, and Team and Enterprise plans is coming in the following weeks. That’s a reasonable way to ship something that changes how merges happen — test it with the users most likely to notice if a coordinator mis-scopes a task before handing it to people managing production branches.
Mitch Ashley, vice president and practice lead for CIO & Technology Buyers and Software Lifecycle Engineering at The Futurum Group, sees the shift to PR-based merging as the detail that will decide how fast this gets adopted. “Running work in parallel is the easy part to sell,” he said. “The part that actually earns trust is that every thread still lands as a pull request someone reviews. That’s the difference between a tool platform teams can adopt on their own terms and one they have to fight to keep visible.”
That’s the right frame for a DevOps audience to apply here. Multi-agent orchestration has been the direction the whole agentic AI conversation has been heading for the past year, and Anthropic just shipped a version of it wrapped around a workflow developers already know: branches, PRs, review gates. The interesting question isn’t whether Claude can split a task into three threads and run them at once — plenty of tools can already fan work out. It’s whether the coordination logic deciding what to delegate, when to merge, and what counts as done holds up the way a human tech lead’s judgment would, across a codebase messier than any demo. That’s an operational question, not a modeling one, and it’s the one platform teams evaluating this should be asking first.
AI agents are becoming operational teammates. They can ingest alerts, query logs and traces, correlate deployment events, consult runbooks and recommend or perform remediation. Their promise is not merely faster summarization: It is a shorter path from detection to safe recovery.
But an agent that can explain an incident is not automatically an agent that should change production. Restarting a stateless pod, rolling back a customer-facing payment deployment and responding to a suspected credential compromise are materially different decisions. Each requires a different amount of evidence, human accountability and execution control.
The practical answer is tiered autonomy. Tier 1 automates well-understood and reversible incidents. Tier 2 lets the agent investigate and recommend, while a human explicitly approves the action. Tier 3 keeps people in command for novel, complex or high-impact incidents while the agent accelerates evidence collection and hypothesis testing.
The three tiers of agentic incident response match an AI agent’s permissions to incident familiarity, blast radius, reversibility and diagnostic confidence. Tier 1 is autonomous remediation for proven runbooks; Tier 2 is approval-gated action for moderate-risk cases; Tier 3 is a human-led investigation supported by an AI agent.
Why Tiered Autonomy Works
The wrong framing is ‘full automation versus no automation’. Full autonomy can amplify a mistaken diagnosis across production. A read-only chatbot, meanwhile, leaves most repetitive operational work with the on-call engineer. Tiered autonomy makes automation earned, bounded, observable and reversible.
For each incident type, assess four questions before determining its tier:
Is the failure pattern well understood and represented by an approved runbook?
What is the maximum plausible blast radius if the diagnosis or action is wrong?
Can the action be reversed quickly and safely?
Is the agent’s decision supported by sufficient evidence and historical success?
Decision Factor
Tier 1: Autonomous
Tier 2: Approval-Gated
Tier 3: Human-Led
Familiarity
Frequent, repeatable pattern
Known pattern with meaningful variation
Novel, ambiguous or conflicting signals
Blast Radius
Single workload or bounded component
Single service or limited customer impact
Cross-service, security, regulatory or business-critical
Reversibility
Fast and automated rollback
Reversible but needs observation
Difficult, costly or irreversible
Confidence
High and evidence-backed
Moderate; competing explanations exist
Low or no validated precedent
Human Role
Review after the event
Approve the proposed action
Lead decisions and direct investigation
The exact thresholds will vary by organization. A useful starting point is to reserve autonomous action for runbooks with a strong historical success record and deterministic verification, require approval for anything that changes a customer-facing service and make security, data and multi-service failures human-led by default.
Tier 1: Autonomous Response
Tier 1 covers known-knowns: Common failures with an explicit, tested and reversible remediation path. The agent can execute because it is operating inside a narrow contract, not because the model has broad authority.
What Qualifies for Tier 1?
The alert signature and diagnostic evidence match a known runbook.
The affected resources are explicitly allowlisted.
The action is reversible, idempotent and limited in scope.
Success can be verified through objective telemetry.
A failed verification automatically stops further action and escalates the incident.
Sample use Case: Bad Container Image Rollback
An orders API deployment introduces an invalid image tag. Kubernetes reports ImagePullBackOff; the new ReplicaSet cannot become ready and the prior revision was healthy. This is a good Tier 1 candidate only if the service is stateless, the previous revision is known-good and rollback is pre-approved.
The agent receives the deployment-readiness alert and gathers Pod events, the current image reference, rollout history and recent change metadata.
It confirms the ImagePullBackOff condition, verifies that the prior revision was healthy and validates that the service is on the Tier 1 allowlist.
It executes a bounded rollback to the previous revision.
It verifies that desired replicas become ‘ready’ and that error rate and latency return to normal within a defined window.
It posts a concise incident record with evidence, action, result and rollback status.
In a manual workflow, this can take 30–60 minutes when an engineer is paged, collects context, confirms the change and executes the rollback. With a tested autonomous workflow, detection, rollback and verification can complete in a few minutes. Microsoft describes customer-controlled autonomy options for Azure SRE Agent and has published examples of alert-to-verified recovery workflows for AKS.
Sample use Case: Bounded Scale-Out
A checkout service experiences a predictable campaign-driven increase in queue depth and CPU utilization. The agent is allowed to scale replicas from three to a maximum of eight, but cannot change resource requests, cluster capacity or autoscaler configuration.
Trigger: CPU remains above 80% and queue depth rises for five consecutive minutes.
Evidence: Request rate, queue depth, pod readiness, node capacity and error rate support the scale-out diagnosis.
Action: Raise replicas within the approved minimum and maximum range.
Verification: Queue depth declines, CPU stabilizes, error rate remains within SLO and new replicas are ‘ready’.
This saves minutes rather than hours, but it also prevents the familiar 3 a.m. delay between a clear alert and a low-risk operational change. The value of Tier 1 is consistent execution of boring, repeatable work — not heroic automation.
Tier 1 Guardrails
Least Privilege: Use service accounts scoped to named namespaces, resource kinds and verbs.
Blast-Radius Caps: Limit concurrent actions, replica ranges, clusters and services.
Cooldowns: Prevent repeated restarts or scaling oscillation for the same workload.
Circuit Breakers: Disable the runbook after repeated verification failures or unusual error-budget burn.
Immutable Audit Logs: Preserve the incident evidence, proposed plan, executed command, result and agent identity.
Tier 2: Collaborative Diagnostics
Tier 2 covers known-unknowns. The agent has useful evidence and a plausible remediation, but uncertainty, customer impact or a non-trivial rollback requires explicit human approval. Tier 2 is frequently the fastest path to value because it removes investigation toil without giving away operational accountability.
What Qualifies for Tier 2?
The agent can form a credible, evidence-based hypothesis, but alternatives remain.
The action is reversible but may interrupt users, workloads or in-flight transactions.
The service is customer-facing or important enough to require a named approver.
The runbook is approved, but context determines whether it is appropriate to execute.
The agent can show the evidence, expected outcome, risks and rollback plan in an approval request.
Sample use Case: Database Connection-Pool Exhaustion
An orders service starts returning 503s. Connection-pool utilization is 100%, database wait time has increased sharply and a small number of long-running queries are visible. However, the root cause could be a slow query, a connection leak or a sudden traffic increase. The agent should not terminate database sessions on its own.
A high-quality Tier 2 approval message should be structured, not conversational.
Incident: Orders-api elevated 503 errors.
Evidence: Connection pool is saturated, pool wait time is 10x baseline and three active queries have exceeded five minutes.
Hypothesis: Long-running queries are blocking capacity.
Proposed Action: Terminate the named queries after confirming they are not protected jobs.
Risk: Active transactions may be interrupted.
Expected Result: Connection pool utilization should fall below 70% within two minutes.
Rollback: Not applicable; escalate if error rate does not recover.
Approval Required: Database on-call.
The engineer has the context needed to decide in seconds rather than spending 20 minutes gathering it. After approval, the agent executes only the approved action and verifies recovery. Agentic investigation systems are increasingly designed around this sequence of evidence gathering, recommendation, approval gates and monitored execution. [web:47][web:66]
Sample use Case: Payment-Service Rollback
A release of payment-service is followed by an error-rate increase from 0.1% to 4%. The agent correlates the increase with the deployment, checks dependent-service health, reviews logs and proposes a rollback. Although rollback is technically reversible, payment flows are business-critical; a human should approve the decision.
The agent should provide the relevant rollout revision, error-rate timeline, failed request sample, dependency health, expected rollback duration and post-rollback checks. If approved, it performs the rollback, watches readiness and transaction errors, then produces a draft timeline for the post-incident review.
A representative target is to reduce the time from alert to safe rollback from 45 to 90 minutes to roughly 8–15 minutes. The improvement comes from faster context assembly and faster approval — not from removing the person responsible for the customer-impacting decision.
Tier 2 Guardrails
Explicit Approval: An affirmative action by an authorized human is required; silence is not approval.
Bound Approval: Approval is valid only for the named command, target and parameters.
Evidence-First Requests: Include source links, observed metrics, confidence, risks and verification criteria.
Expiry: Expire approval tokens quickly and re-request approval if incident context changes.
Outcome Feedback: Capture whether the recommendation was useful and whether execution resolved the incident.
Tier 3: Human-Led Investigation
Tier 3 applies when the incident is novel, ambiguous, high-impact or potentially irreversible. The agent remains valuable, but it is an investigator and analyst — not an incident commander. People prioritize business trade-offs, choose hypotheses, approve actions and communicate externally.
What Qualifies for Tier 3?
Cascading failures across services or regions.
Conflicting telemetry with multiple plausible root causes.
Security events, suspected data exposure or compliance-sensitive situations.
Database schema changes, credential revocation, customer-data operations or financial actions.
Low-confidence diagnosis or a failure mode absent from historical runbooks.
Sample use Case: Cascading Microservice Failure
Checkout begins returning 500 errors. Within minutes, payment, inventory and notification services also degrade. Some workloads show high CPU, others are normal and database latency is elevated but not catastrophic. There are no recent deployments. This is not a Tier 1 or Tier 2 event; it is a Tier 3 investigation.
The agent creates a shared timeline from alerts, deployments, traces and dependency health checks.
It identifies propagation order and highlights candidate bottlenecks, without claiming certainty.
The incident commander asks it to investigate a specific branch, such as database contention or external dependencies.
The agent runs approved read-only diagnostics and reports evidence, including trace exemplars and slow-query findings.
When it identifies a likely long-running transaction, it proposes a precise action and waits for human approval before terminating it.
After recovery, it drafts the event timeline, unresolved questions and follow-up actions for the postmortem.
The agent may cut time-to-diagnosis dramatically by searching and correlating thousands of telemetry records, but the incident commander retains control of scope, risk, communication and remediation. Research and vendor guidance on AI incident management emphasize these approval and governance patterns for production workflows. [web:47][web:75][web:79]
Sample Use Case: Suspected Credential Compromise
An unfamiliar application identity is running bulk queries against user-data tables outside its normal schedule. The agent can collect identity history, audit-log context, network-egress signals and recent configuration changes. It should not independently decide whether an event is a breach, notify customers or revoke credentials without authorization.
The right Tier 3 behavior is to preserve evidence, alert the security response team, produce a clear risk summary and prepare proposed containment actions. A human security lead then directs and approves steps such as credential revocation, access-policy changes and external notifications.
Tier 3 Guardrails
Human Incident Command: Name an incident commander; the agent does not own decisions.
Read-Only by Default: Allow investigation tools, not state-changing tools, until an authorized approval is received.
Forensic Integrity: Preserve raw evidence and full agent traces; prohibit deletion or mutation of evidence.
Sensitive-Data Controls: Redact secrets and PII, enforce purpose-bound access and log every privileged query.
Escalation Policy: Automatically involve security, privacy, legal or senior engineering for defined conditions.
Expected MTTR Impact
MTTR improvements are workload-specific, so teams should treat broad industry figures as directional rather than guarantees. The main benefit differs by tier: Tier 1 removes response delay for repetitive work; Tier 2 compresses diagnosis and approval; Tier 3 reduces time-to-understanding in complex events.
Tier
Primary Value
Illustrative Before
Illustrative After
Typical Improvement
Tier 1
Automated detection, remediation, verification
30–60 minutes
2–5 minutes
80–95%
Tier 2
Fast evidence and approval-gated execution
30–90 minutes
8–15 minutes
70–85%
Tier 3
Faster correlation and guided investigation
90–180 minutes
20–60 minutes
40–75%
For example, Microsoft’s published AKS incident-response material compares an approximately eight-minute MTTR baseline with approximately four minutes in an autonomous recovery workflow. That result is specific to its documented scenario, but it illustrates why the fastest gains often come from a tightly bounded remediation path with clear verification
A Sample Tiering Policy
Use a policy engine outside the LLM to make the final autonomy decision. The model can recommend a tier; a deterministic policy must enforce it.
Example Policy Logic
If the target service is not allowlisted, the operation is Tier 3. If the action is destructive, touches production data, changes identity or security policy or spans multiple services, it is Tier 3. If the runbook is tested, the action is reversible, the scope is within limits and verification is deterministic, it may be Tier 1. Otherwise, it is Tier 2 and requires an explicit approval token.
Implementation Roadmap
Start With Incident History
Export 6–12 months of incidents from your alerting and ticketing systems. Classify incidents by frequency, root cause, remediation, blast radius, reversibility and time-to-recovery. Your first Tier 1 candidates should be frequent, safe and tedious — not merely, technically easy.
Turn Runbooks Into Contracts
An agent-ready runbook must specify triggers, allowed tools, required evidence, action parameters, scope limits, stop conditions, verification checks, rollback behavior and escalation paths. A vague instruction such as ‘restart the service if it looks unhealthy’ is not a safe contract.
Pilot in Shadow Mode
Let the agent investigate real incidents without execution rights. Compare its diagnosis and proposed action with the human resolution. Measure precision, false positives, evidence completeness and the percentage of proposals humans approve. Promote only runbooks that demonstrate consistent performance.
Expand Trust Deliberately
Start with a small number of Tier 1 workflows in non-critical namespaces or services. Add Tier 2 approval workflows next. Treat Tier 3 as an immediate value stream, because investigation assistance can help during severe incidents even before you trust autonomous remediation.
Measure the Right Outcomes
Mean time to detect, acknowledge, diagnose, approve, remediate and verify
Tier 1 auto-resolution rate and rollback rate
Tier 2 approval latency, approval rate and recommendation quality
Tier 3 time-to-first-useful-hypothesis and evidence completeness
What are the three tiers of agentic incident response?
Tier 1 is autonomous remediation for known, low-risk, reversible incidents. Tier 2 provides AI-led diagnosis and a human-approved action. Tier 3 keeps humans in charge of complex or high-risk investigations while the agent gathers and correlates evidence.
Can Tier 1 include production changes?
Yes, but only bounded and pre-approved production changes with strict access control, deterministic verification, a low blast radius and an automated stop or rollback path. Production access should never mean unrestricted production authority.
What should never be autonomous?
By default, do not autonomously perform destructive data operations, credential changes, security-policy changes, irreversible database migrations, external customer communications or high-impact multi-service changes.
How do you move an incident type from Tier 2 to Tier 1?
Collect enough evidence that the runbook has repeatable diagnostics, high approval and success rates, reliable verification, controlled blast radius and a proven rollback plan. Make the promotion a formal reliability and security review, not an informal model-confidence change.
Key Takeaways
The goal of agentic incident response is not to hand production to a model. It is to use AI where it reduces toil and time-to-recovery while preserving safety and accountability. Put repetitive, reversible work in Tier 1; use Tier 2 to turn diagnosis into a fast, informed approval; and let Tier 3 make human-led investigations dramatically more evidence-driven.
An AI agent that can call tools is not automatically an unsafe system. The dangerous move is smaller: Letting a workflow turn a recommendation into an external action without a durable decision record.
That distinction matters in DevOps. An agent can sensibly summarize a failed deployment, draft a rollback plan or classify a dependency alert. The moment it opens a change request, modifies a feature flag, creates an incident, messages a customer or publishes a configuration, the system needs more than a high-confidence score.
It needs a change-control gate.
The gate below is a practical pattern for a tool-using agent. It verifies whether the policy is still current, pauses for the required human decision, makes one idempotent outbound request, then confirms the receipt. It is deliberately boring. That is the point.
Figure 1: Illustration of a Workflow Moving Through Policy, Human Approval and Idempotency Gates While a Risky Duplicate Path is Stopped
Why a Confidence Threshold Isn’t Enough
Confidence says something about a model’s answer. It does not say whether a particular action is reversible, who owns its consequences, whether the policy changed while the agent was working or whether the same action has already happened.
For a production workflow, treat those as separate decisions.
Question
What the Gate Should Decide
Is this action permitted now?
Revalidate the current policy and declarations.
Does this action need a person?
Route it to an explicit approver with the exact action payload.
Has this action already been sent?
Use an idempotency key stored before or with the transmission.
Did the destination accept it?
Verify a receipt, job ID or visible confirmation without resending.
This maps cleanly to the NIST AI RMF’s idea that risk management should cover governance, measurement and management throughout the system life cycle — not merely model evaluation. It also fits a practical fact of durable agent runtimes: A paused workflow can restart a node when it resumes, so outbound side effects must be idempotent. NIST AI RMF and LangGraph’s interrupt guidance both make the broader control problem explicit.
The Smallest Useful State Machine
Do not begin with a large autonomous platform. Begin with explicit states that an operator can inspect.
The useful property is not the spelling of the states; it is that ‘approval_required’ and ‘transmitting’ are distinct. A system should be able to show an approver exactly what will happen before it happens, then preserve a record of the result.
Revalidate Policy Immediately Before the Action
The policy check belongs close to the outbound call. A week-old permissions decision is not a preflight check.
This is where an organization can apply its real rules: Production versus staging, maintenance windows, owner groups, regulated data or a mandatory incident commander for customer-impacting work. Keep the policy data outside the prompt. A prompt may explain a rule; it should not become the only enforcement point.
Ask for Approval Using the Actual Outbound Payload
An approval that says, “approve the agent’s plan?” is too vague. Show the action type, destination, change summary and required declarations.
If the user rejects the request, end the workflow. Do not reinterpret a rejection as a request to regenerate a more persuasive plan.
Make the Transmission Idempotent
The awkward failure is an ambiguous one. The receiving system may complete the change while the client times out before it receives a response. If the agent retries blindly, it can create a duplicate ticket, a second deployment or a second message.
Use a stable key derived from the action’s business identity — not a fresh UUID for each retry.
The destination must honor the key, or your own durable store must do so before the outbound request. Either way, do not put an automatically retried network call before a pause node unless that side effect is safe to repeat.
Verify Instead of Resending After Ambiguity
Treat a timeout as an observation problem first. Query the destination with the key, look for the created job or ticket and write the result to the workflow state. Only retry if the system can prove that no action exists.
async function verifyReceipt(key: string) { const result = await findActionByIdempotencyKey(key); if (result) return { accepted: true, receipt: result }; return { accepted: false, issue: “No receipt found; needs operator review” };}
That final status should be ‘submission_unverified’, not ‘failed’. The name forces the right next action: Investigate before sending another request.
A Controlled Simulation: Where Duplicates Appear
To make the trade-off concrete, I ran a deterministic simulation of 10,000 outbound agent actions. Each simulated action had a 9% policy-change state, a 21% non-approval state and 1–3 resume events. This is a controlled illustration of workflow logic, not production telemetry, a reliability claim or a measured industry failure rate.
Control Design
Sends
Duplicate Sends
Policy-Bypassing Sends
Unapproved Sends
Ungated Send
12,114
2,114
1,106
2,544
Approval Only
9,570
1,673
879
0
Preflight Gate
8,691
1,514
0
0
Durable Gate
7,177
0
0
0
Figure 2: Bar Chart Comparing Outbound Sends and Duplicate, Policy-Bypassing and Unapproved Actions Across Four Simulated Control Designs
The notable row is the preflight gate. It eliminated actions that bypassed policy or approval, but it still created 1,514 duplicate sends because resumed workflow events could enter the same action more than once. The durable gate reduced that to zero in this simulation by using a stable idempotency record.
The simulation code and raw summary are included with this submission so that editors or readers can reproduce the numbers. Modify the assumptions before applying the result to your own environment.
Keep the Approval Boundary Narrow
This pattern is not an argument for asking a human to approve every tool call. That usually leads to notification fatigue and workarounds.
Instead, classify actions by consequence:
Action Class
Typical Examples
Default Control
Read-Only
Fetch a deployment record, inspect a log
Allow with audit trail
Reversible Internal
Create a draft change ticket, add a label
Allow or sample review
Material but Reversible
Change a feature flag, queue a rollback
Named approval plus idempotency
External or Hard to Reverse
Deploy to production, message a customer, delete data
Named approval, policy recheck, idempotency, receipt verification
The fastest agent systems make safe paths easy and consequential paths explicit. They do not pretend all operations have the same risk.
What to Test Before Enabling an Agent Action
Run these cases in a non-production environment before connecting a new action to an agent:
A policy changes after the agent produces its recommendation but before the approval click.
An approver rejects the action, then the workflow resumes.
The destination completes the change, but the client loses the response.
A queue redelivers the same event.
An operator tries the same action manually while the agent is waiting.
Receipt verification is temporarily unavailable.
For each test, the expected outcome should be visible in state: Blocked, rejected, submitted, verified or unverified. “The agent probably handled it” is not an operational status.
The Operational Rule
AI agents can move quickly without bypassing change control. The reliable pattern is straightforward: Validate the rules immediately before the action, show the real payload to the right approver, record one idempotent transmission and verify the result before retrying.
That sequence gives teams something better than a promise of autonomy. It gives them a system they can inspect when the answer is ambiguous and the consequences are real.
Raw Results: `research/contribution-gate-simulation-2026-08-21/summary.json`
The simulation uses a fixed seed and synthetic policy, approval and resume-event rates. It does not measure any customer system.
The article’s workflow pattern was implemented and tested in TypeScript as part of an internal contribution-control graph. The sample code is simplified for teaching.
Enterprise AI agents need more than stronger models. They need durable execution environments that can coordinate multi-step workflows, survive failures, pause for human review and resume reliably after disconnects or delays.
AI Agents Have Moved Beyond Chat Demos
AI agents work beautifully in demos. A user asks a question, a large language model generates a response and everyone sees possibility. Production systems are different.
Consider what these systems are now asked to do. An agent assessing a change request may pull deployment history, evaluate blast radius, check freeze-window policy, wait for a release manager’s sign-off and then schedule the rollout. An agent adjudicating an insurance claim may extract fields from submitted documents, cross-check them against prior claims, apply underwriting rules and route anything unusual to a human adjuster. An agent triaging a security alert may enrich indicators, correlate against past incidents, assess asset criticality and hold containment until an analyst approves it.
Those three workflows have almost nothing in common at the domain level. They share a shape: Multiple steps, several systems, independent failure modes and at least one point where a person decides. They take minutes or hours, not milliseconds.
The challenge is no longer only intelligence; it is execution. Many enterprise AI conversations focus on model selection, prompt engineering, retrieval-augmented generation and tool calling. Those are important, but they do not answer what happens after the agent begins executing long-running work across multiple systems.
The Problem: Most Agents Are Still Designed Like Request-Response Applications
Traditional AI applications assume a simple request-response model: User input goes in; a model response comes out. That model works well for Q&A, summarization, content generation and search-like experiences.
Enterprise workflows are different. A procurement review agent might parse a contract, compare its terms against a standard template, check vendor risk ratings, invoke a sanctions screening service and produce a recommendation. These steps may execute independently, fail independently and complete at different times.
Once an agent crosses the boundary from answering a question to executing a process, it starts to look less like a chatbot and more like a distributed system. It needs state, retries, coordination, observability and recovery.
Why Stateless APIs Break Down
Teams often start by implementing an agent as a synchronous API. That approach works until the first real workflow appears. What happens if the HTTP request times out? What if the user closes the browser? What if an external system is unavailable? What if a human approval arrives six hours later?
A stateless API can initiate work, but it is a poor place to manage long-running state. Developers quickly end up building custom queues, status tables, retry logic, compensation logic and ad hoc workflow tracking. The hidden cost is not the first prototype; it is operating the system after it begins handling real workloads.
The missing layer is a durable runtime: A workflow engine that can preserve progress, coordinate parallel work, wait for external events and resume execution reliably.
Figure 1: The Same Multi-Step Workflow Under Two Runtimes
A stateless service holds progress in process memory, so a host failure discards completed work and the retry begins again from the first step. A durable runtime checkpoints each completed activity, so a replacement worker replays the history and continues from where execution stopped.
The Key Design Shift: the Workflow is the Application
The most important design shift is this: The model is not the application. The workflow is the application. The model is one activity inside a larger execution graph.
In production-grade agentic systems, the orchestrator coordinates work while specialized agents perform specific tasks. The specialization is domain-specific, but the division of labor recurs: One agent gathers and enriches raw signal, another retrieves reference material, another looks for precedent among prior cases and another evaluates policy or risk conditions.
This design makes the system easier to reason about. Each agent has a focused responsibility, and the orchestration layer owns execution flow, state, retries, progress and human interaction.
Using Durable Orchestration as the Agent Runtime
A practical architecture places a durable orchestrator between the calling application and the AI execution layer. The caller starts the workflow and immediately receives an instance identifier. The orchestrator then coordinates specialized agents and records progress as the workflow advances.
Azure Durable Functions is a strong fit for this pattern because it supports stateful workflows, activity functions, external events, checkpointing and long-running orchestration. Azure AI Foundry can provide the model and agent execution layer, while Durable Functions handles the operational execution semantics around the agent.
The result is a cleaner separation: AI services reason; activity functions perform work; the durable orchestrator governs the process.
Figure 2: The Orchestrator Between the Calling Application and the Reasoning Layer
It owns sequencing, retries, timers and external events. Specialized agents run on the model layer with narrowly scoped access and every completed activity is checkpointed so the workflow can be rebuilt after a failure or a process restart.
Fan-Out/Fan-In Maps Naturally to Multi-Agent Systems
These investigations are rarely one sequential task. Many subtasks can run independently. Enrichment, reference retrieval, precedent search and policy evaluation usually have no dependency on one another, so they can execute in parallel. This is where fan-out/fan-in becomes a natural orchestration pattern.
The orchestrator fans out work to specialized agents, waits for them to complete, and then fans in the results to generate a synthesized recommendation. This pattern improves latency while keeping the workflow easier to understand than a large monolithic agent prompt.
The fan-in step is also where engineering judgment matters. The system should handle partial results, conflicting findings and low-confidence recommendations rather than assuming every agent will succeed perfectly every time.
Example Orchestration Sketch: The sketch below triages a security alert; the domain is incidental. Rename the activities and the same orchestration serves claims adjudication or change-risk review.
Three details in that sketch are worth calling out. The external event is raced against a durable timer, so an approval that never arrives escalates instead of leaving the instance parked indefinitely. The timer is then cancelled on the success path, because a durable timer that is neither cancelled nor allowed to expire keeps the instance in the Running state long after the orchestrator function has returned. Since Task.WhenAll surfaces the first exception it encounters, genuine partial-success handling means having each activity return a typed failure result rather than throwing it once its retries are exhausted.
Human-in-the-Loop is Not an Edge Case
In regulated and high-impact workflows, human review is part of the process by design. A payment exception above a threshold, a production change during a freeze window, a claim falling outside underwriting rules: None of these should be finalized automatically when confidence is low or the consequences of being wrong are large. The important thing is to make human review part of the workflow rather than a side channel.
A durable orchestration can pause while waiting for a review event, then resume when the approver submits a decision. The system does not need to keep an HTTP request open or hold compute resources while waiting. The workflow state remains available, and the final recommendation can include the reviewer’s context.
This capability is especially important because the slowest step in a production workflow is often not the model call. It is the human decision, the external dependency or the operational handoff.
Figure 3: One Instance Over Time
Parallel agents make wall-clock cost the slowest agent rather than the sum of all of them; a failed agent degrades the result instead of failing the run, and the review window consumes no compute because the orchestration is parked rather than blocked.
Operational Considerations Matter as Much as Prompts
A durable runtime does not remove the need for engineering discipline. It makes that discipline easier to apply. Production-grade agents still need observability, correlation identifiers, retry policies, cost controls, security boundaries and careful versioning.
Workflow telemetry should answer questions such as: Which stage is running? Which activity failed? How many retries occurred? How long did human review take? What evidence supported the final recommendation? These are operational questions, not prompt engineering questions.
Retries should be designed around external dependencies such as AI model calls, search systems, databases and APIs. At the same time, not every failure should fail the entire workflow. Multi-agent systems should be designed for partial success where appropriate. If the precedent agent fails but enrichment and retrieval succeed, the system may still produce a useful recommendation with clear caveats.
Three constraints tend to surface only once a workflow reaches production. Orchestrator code has to stay deterministic, because recovery works by replaying it: Wall-clock reads, random values, fresh identifiers and direct I/O belong in activities, not in the orchestrator. Every wait needs a deadline, else an approval that never arrives becomes an instance nobody ever looks at again. Versioning deserves a decision before the first production deploy because long-running instances guarantee that new orchestrator code will ship while old instances are still in flight.
Security and Governance Cannot Be Bolted on Later
AI agents often sit at the crossroads of sensitive enterprise data, operational tooling and user-facing experiences. That makes security and governance foundational design concerns.
Each specialized agent should receive only the access necessary for its responsibility. A retrieval agent may need the document corpus and nothing else. An enrichment agent may need read access to telemetry. The agent that composes the final decision may need only summarized evidence, never the raw sources behind it. Avoid creating one over-permissioned super-agent that can reach everything.
Prompts and outputs should also be auditable. Store workflow version, prompt version, model deployment, agent version, evidence references and correlation identifiers. As agents become part of operational decision-making, teams need to explain not only what the system recommended but why it recommended it.
Figure 4: Scoping Access per Agent Contains the Blast Radius
A single agent holding every credential turns one poisoned input into estate-wide exposure, while narrowly scoped agents limit any single compromise to one agent’s data, with the synthesis step working from summarized evidence.
What This Means for DevOps and Platform Engineering Teams
The future of enterprise AI is not just better prompts. It is reliable execution. As agents become responsible for operational workflows, DevOps and platform engineering teams will need to provide runtime capabilities similar to those used in distributed systems: Orchestration, observability, resiliency, governance and deployment discipline.
This resembles the evolution of microservices. Early conversations focused on APIs. Later, the industry learned that production systems also require service discovery, telemetry, deployment strategies, circuit breakers and operational practices. AI agents are entering a similar phase.
Organizations that treat agents as production workflows rather than chat interfaces will be better positioned to build systems that users trust.
Conclusion
Most enterprises already have access to powerful foundation models. The harder challenge is building systems that can execute reliably when work spans minutes, hours, tools, services and human decisions.
Long-running agents of any kind need a durable execution layer. They need to coordinate multiple specialized agents, survive transient failures, pause for human review, provide progress visibility and generate auditable outcomes.
Azure Durable Functions and Azure AI Foundry offer one practical way to approach this architecture: Durable Functions provides orchestration and stateful execution, while Azure AI Foundry provides the intelligence layer. The broader lesson applies beyond any specific platform: Production AI agents need durable runtimes. Intelligence is only half of the system. Execution is the other half.
Anyone who’s ever been on an on-call rotation knows the feeling. A dashboard lights up green to red across a dozen services, an incident channel starts filling with theories and somewhere in that noise is one root cause hiding behind six symptoms that all look equally suspicious. Fixing the problem is rarely the hard part. Figuring out what the problem actually is- that’s where the time is spent.
So, when yet another vendor pitch promises that AI has solved this (point a model at your telemetry and it tells you what broke), part of me wants to believe it. Honestly, some of that promise is real. However, the more time you spend around incident response, the easier it gets to spot claims that skip past the hardest part of the job. Finding symptoms is easy; understanding causes is not. This is just my opinion on where that gap actually sits, and what it would really take to close it.
The Gap Between Correlation and Diagnosis
Look closely at what most ‘AI-driven root cause analysis’ tools actually do, and a pattern starts to show up. They’re very good at telling you that 47 alerts are all part of the same problem. They’re much less reliable at telling you what that problem actually is. Alert correlation, topology mapping, and noise reduction are genuinely useful capabilities that meaningfully reduce the time an engineer spends on triaging. However, grouping related symptoms isn’t the same thing as identifying a cause.
That distinction isn’t just semantics. It’s the difference between an engineer opening an incident channel to “here are the 12 things that fired around the same time” versus “here’s why they fired, in that order, and here’s what to fix.” The first still needs a human to do the actual diagnostic reasoning. The second means the system has built something closer to a real causal model, an understanding of how a change three services upstream produced a symptom two hops downstream, three minutes later.
Most tools on the market today are much closer to the first category than they’d like you to believe.
Sketching What Real Diagnosis Looks Like
If correlation is “these things happened together,” diagnosis is “this happened because of that.” Getting from one to the other isn’t just a matter of bolting on more dashboards. It’s a genuinely different process, and I think it’s worth actually sketching out instead of leaving it vague.
At a high level, a system capable of real causal diagnosis needs to move through like this:
The step that quietly gets skipped is testing causal direction. Does perturbing the upstream service actually explain the downstream symptom, or are the two just moving together? Most tools stop at correlation dressed up as causation, because that step is genuinely hard to build. Matching against incident history is where organizational discipline comes into play, since that knowledge base doesn’t build itself. The confidence check at the end, the part where the system is willing to say, “I’m not sure, escalate this,” is the one I’d trust least to actually exist in most tools being sold today. Uncertainty doesn’t make for a great product demo.
Where This Gets Harder: Non-Deterministic Systems
All of this is already hard for traditional infrastructure, where failure modes are at least somewhat bounded and repeatable. It gets a lot harder once AI and LLM-based components are part of the system you’re trying to diagnose.
The traditional signals SRE teams have leaned on for a decade (latency, traffic, errors, saturation), all assume a system that behaves the same way twice given the same inputs. A RAG pipeline or an agentic workflow doesn’t offer that guarantee. The same request can fail differently on different days for reasons that have nothing to do with infrastructure health: A shift in retrieved context, a subtle change in model behavior and a guardrail stepping in somewhere unexpected. A diagnostic system trained to reason about deterministic failure patterns will confidently give you the wrong answer here, and it’ll say it with the same tone of authority it uses when it’s right.
That’s the part that worries me most, honestly, more as a leader than as an engineer. An automated system that’s occasionally, confidently wrong isn’t neutral. It actively erodes an on-call engineer’s willingness to trust it, often for good, after just one bad call. Trust, once a team loses it in a tool, is brutally hard to earn back. It’s not uncommon to see decent tooling get quietly abandoned after exactly this kind of incident, and it rarely comes back into rotation once that happens.
The Human-in-the-Loop Argument, Restated
None of this is an argument against automating incident diagnosis. The toil is real, the pages at inconvenient hours are real and the case for AI assistance in incident response is a strong one. It’s an argument for being precise about what’s actually being automated, and for treating the postmortem, not the dashboard, as the real training ground for these systems.
A good postmortem is a structured record of a causal chain that a human worked out under pressure. That’s exactly the kind of data the ‘match incident history’ step in the flow above needs to work well. This is where leadership matters just as much as architecture. A team that treats postmortems like a checkbox exercise, written thin and fast just to close out a ticket, is quietly starving its own diagnostic tooling of the one input that would actually make it smarter. A team that puts real-time into writing specific, causally clear postmortems, even when it’s tempting to just write “flaky network” and move on, is building the training data for tomorrow’s automation. Whether or not anyone thinks of it that way in the moment.
This is one of the more underrated jobs of an engineering leader right now. It’s not about picking the right AI vendor; it’s about making sure a team’s own incident discipline is good enough to be worth automating in the first place.
A Practical Checklist
Before adopting or building automated incident diagnosis, a few questions are worth asking honestly:
Does this tool group related alerts, or does it actually explain why one caused another?
Can it show its reasoning in a way an engineer could defend in a postmortem review?
Does it work off the live dependency graph, or a stale architecture diagram from months ago?
How does it hold up on non-deterministic components, and does it know when to say “I’m not confident” instead of guessing?
Is there a feedback loop where past incidents actually improve future diagnosis, or does that knowledge just sit locked in a wiki page?
The teams that get real value out of automated diagnosis won’t be the ones with the fanciest model. They’ll be the ones who were already disciplined about turning incidents into institutional knowledge, and who are now feeding that discipline into the machine instead of hoping the machine invents it from scratch. That’s a leadership problem before it’s an engineering one, and I think it’s the one most of the current conversation keeps skipping past.
After years of exploring how AI can support agency operations and make better use of growing volumes of data, agencies are now preparing for the next phase: agentic AI.
The infrastructure needed is changing along with it. Agentic AI, unlike regular AI capabilities, can coordinate multiple specialized agents to carry out complex, multistep workflows, which means agencies are no longer planning only for the compute required to run AI models. They also have to account for the orchestration between agents, the movement of data across environments, and the points where human judgment still belongs.
That makes it important to start with the work itself—not the newest, shiniest technology. The following three strategies can help.
Start With the Workflow, Not the Hardware
Agentic AI is more sophisticated, but it also requires more orchestration and preparation. Consider a permitting process. One agent might evaluate municipal requirements while another examines state or federal statutes. A third agent—or a human—might then validate conflicting information before the process can move forward. The individual AI tasks are only part of the workload. The system must also coordinate those tasks, determine when one step depends on another, and move information between them.
That changes infrastructure requirements. AI environments have often been designed around compute-intensive model workloads, with significant attention paid to accelerators. But agentic systems can introduce substantial CPU and networking requirements as agents execute workflows and interact with one another.
Before deciding where to invest, agencies should map both the workflow and the data flow. Where will each agent perform its work? What information will it need, and where does that information reside? Which steps can occur simultaneously, which depend on one another, and where is human review required?
Those questions are especially important in hybrid environments, where data and workloads may span cloud and on-premises systems. An architecture optimized for one generation of AI can create new bottlenecks when multiple agents must coordinate across distributed environments.
Mapping the workflow can also reveal where agentic AI will and will not provide value. An existing 12-step process, for example, might contain five steps that agents can accelerate while others lack sufficiently accessible or reliable data to make automation worthwhile. The goal is not to insert an agent into every step, but to understand the process well enough to determine where autonomy can improve it and what infrastructure those agents will require.
Prioritize Resources With Observability
With more agents operating simultaneously, agencies also need a way to determine which workloads receive infrastructure resources first. Those priorities can reflect mission importance, deadlines, or operational requirements. A financial reporting workload at the end of the month, for example, might temporarily receive priority over a less time-sensitive optimization workload.
The underlying concept isn’t new. High-performance computing environments already use scheduling systems to prioritize workloads based on factors such as urgency and deadlines. As agentic AI develops, agencies must consider how similar principles might help automate resource prioritization more broadly rather than assuming there is already a mature playbook for doing so.
That depends on visibility. IT teams already collect telemetry such as performance metrics, storage information, and logs. In an agentic environment, that information may need to be readable not only by IT teams but also by the systems monitoring and coordinating autonomous workflows.
Consider what happens when an agent encounters a latency spike or another performance issue in the middle of a workflow. Instead of simply stopping, could it use performance or security telemetry to help determine what went wrong? Depending on the policies in place, the system could then recommend reprioritizing or moving the workload or escalating the issue for human review.
Design Around Data Movement, Not Rip-and-Replace
Agentic AI also puts new pressure on data architecture. Agents may depend on information residing across multiple clouds, local systems, and external data sources. Simply having access to that information does not mean an agent can retrieve it quickly enough—or in the appropriate form—to complete a workflow efficiently.
Agencies should map those dependencies to identify potential bottlenecks, from data cleansing and outdated external sources to latency when retrieving information from remote environments. Because agents often depend on one another, a delay in one step can affect the entire workflow. Understanding dependencies can also inform decisions about where data should reside and whether compute, networking, and other infrastructure resources align with agentic workloads.
But identifying a bottleneck should not automatically trigger the need for a new technology purchase. Agencies should first establish the “as-is”: What infrastructure, platforms, data sources, code, and capabilities are already available? What can be reused or consolidated? And where would a new investment fill a genuine gap?
That assessment matters because few agencies can (or should) replace their infrastructure every time the technology landscape changes. A stepwise approach allows them to target the most consequential bottlenecks, build on existing investments, and consider total cost of ownership as agentic AI evolves.
The infrastructure required for agentic AI will continue to change as the technology matures. Agencies don’t need to predict every requirement today. They do need a clear picture of their workflows, data, and existing environment so they can modernize where the mission actually demands it.
It was around 11 p.m. on a Thursday. Our AI support agent had been live for three weeks. Latency: Green. Error rate: Green. Then a customer DM landed in Slack with a screenshot — the bot had cheerfully invented a refund policy for a product we had never sold. Made up the SKU. Made up the rules. Returned a confident answer in 1.2 seconds.
Every SRE metric said the system was healthy. The system was lying to customers at scale, and we had no signal. That night I started building what I now call a production-grade eval system. This is the version I wish someone had written for me before that Thursday.
The Honest Problem
For 15 years, the SRE playbook worked because systems were deterministic — same input and output. LLMs break that contract. Your vendor can silently push a new model checkpoint on a Wednesday, and your agent develops a new personality. A re-indexed retrieval store can send ‘what’s your return policy?’ to a marketing blog post instead of the actual policy doc. None of those registers as a 4xx.
The result: Dashboards all green; product quietly degrading. Everything below exists to close that gap.
The Three Places You Must Evaluate
Most teams vibes-check their AI feature: A PM tries six prompts, says “feels good” and ships. There’s no regression suite, no quality baseline and no rubric. The right fix is to evaluate in three explicit places:
Most teams have Phase 1, sort of. Almost nobody has Phase 2. Phase 3 is where the screenshots-in-Slack live. If I could pick only one, I’d start with Phase 3 — it catches failures you didn’t predict. You need all three to call yourself production-grade.
The Four-Layer Evaluator Stack
There is no single quality metric. What works is layers — cheap checks at the bottom, expensive judges at the top — with sampling upward.
Layer 1 (deterministic code) runs on every trace — free. Layers 2–3 run on a sampled subset; LLM judges cost real money and will eat your budget if you let them run inline. Layer 4 (domain checks) runs with humans in the loop — slowest, most valuable.
The Flywheel: Where Good Evals Come From
Nobody hands you a good eval set. Vendors sell generic benchmarks that score 95% on your system because they test nothing customers care about. Real evals come from your own production failures.
Pull production traces — bias toward anomalies, low-confidence scores and customer complaints.
One person labels them — consistency beats coverage. Two labelers create noise that looks like signal.
Cluster failure modes — hallucination? tone? wrong tool call? Each mode needs its own judge.
Promote failures to regression tests — the failure can never happen silently again.
When you lack data, generate only inputs synthetically, then run your actual application on them. Never let an LLM generate both sides — you’ll get a data set that scores 99% and means nothing.
RAG: the Three Metrics That Matter
If you’re running retrieval-augmented generation — and most of you are — every interesting metric is a relationship between the question, the retrieved context and the generated answer.
Retrieval Tier: Context precision and recall. If this is broken, nothing downstream matters. Start here.
Core RAG Tier: Faithfulness (model stays grounded in context) and answer relevance (model answers the actual question).
Diagnostic Tier: Citation accuracy, noise sensitivity, per-chunk hallucination rate. Run these on investigations, not alerts.
Guardrails Vs. Evaluators
This confusion causes more bad architecture than anything else I see in production AI today.
Keep them in separate code paths. Draw them in separate boxes on your architecture diagram. A guardrail that takes three seconds is a broken product. An evaluator that takes three seconds on 5% of traffic is healthy.
The Production-Readiness Checklist
If someone asks me whether their AI product is ready for production, I walk through this list:
Golden regression data set — in the repo, version-controlled, owned by a named human.
CI eval gate — blocks merges when quality drops on any PR touching prompts, retrievers or model config.
Online evals on sampled production traces — at least Layers 1–2 on every span.
LLM judges validated against humans (Cohen’s kappa >0.7), re-validated on every model upgrade.
Weekly annotation session with a written agenda — not random sampling.
Pinned model versions for production model and judge model. Vendor upgrades are deploys.
Guardrails and evaluators in separate code paths.
Someone whose job is to turn findings into roadmap items.
The Mindset Shift
Reliability for AI is not measured in uptime, it’s measured in quality of output over time. The dashboards your SRE team already built are necessary but no longer sufficient.
The new layer is the eval system — multi-tier, fed by an error analysis loop, wired into CI and live traffic, with calibrated human-in-the-loop judges. Build it, and AI stops being the system your team is scared to put on the on-call rotation.
That Thursday night was almost a year ago. We haven’t had another one like it. The dashboards are still green — and now I know what green actually means.
The pull request was clean. Tight commit message, a one-line fix to a retry helper, green checks. I approved it in the time it takes to drink coffee. It came from an agent we’d wired into our workflow to chew through flaky-test toil, and it had done exactly that all week.
What I almost missed: The change widened the retry window and dropped the jitter on a client that fans out to a downstream service we don’t own. Under normal load, invisible. Under a partial outage, that’s a synchronized retry storm — the kind of thundering-herd regression that reads as one removed line and behaves as an incident. A change-budget gate caught it because the file lived behind a protected path, not because I did. I’d already clicked approve.
That was the moment I stopped trusting my own review as a control. Not because the agent was bad but because it was good enough that the diff looked fine, and ‘the diff looked fine’ is not a control; it’s a vibe.
Why Human Review Stopped Scaling
Code review was designed around a human bottleneck. One engineer writes a few hundred lines a day, another reads them and the slowness is load-bearing — it’s the rate limit that keeps the queue legible. Agents delete that assumption. A single agent can open a dozen PRs an hour, each individually plausible, each touching a different corner of the system.
Plausible is the problem. Agent-authored changes are optimized to pass the smell test. They have clean names, reasonable commit messages and tests that go green, because the agent can see the test suite and write to it. A reviewer scanning 20 of these a day is not really reviewing — they’re rubber-stamping with extra steps, and they’ll wave through the one that matters because it looks like the 19 that didn’t.
You cannot fix this by reviewing harder. The bottleneck you removed isn’t coming back. You fix it by moving the control out of the human’s head and into the pipeline, where it runs the same way on PR number 1 and PR number 200.
Provenance is the New Gate
Here’s the uncomfortable reframe: An AI-authored change is an artifact from an untrusted producer, and we already know how to handle those. We’ve spent years building supply-chain controls for exactly this shape of problem — code entering the pipeline from somewhere you don’t fully trust, that you need to verify before you act on it.
The supply-chain world settled on a clear idea: Don’t trust the artifact, verify its provenance. The SLSA framework formalizes this as a signed attestation that travels with an artifact and answers how it was produced. The in-toto project gives you the attestation format. Sigstore gives you the signing and verification. None of this was built for agents, and all of it applies directly.
So make every agent-authored change carry a provenance record, and make that record machine-checkable. Not a label a human reads — a signed attestation the pipeline enforces. Which model and version produced this change? What prompt or task spec drove it? Which tools was it allowed to call? Which tests and evals gated it? What they returned? If the change shows up without that record, it doesn’t get reviewed. It gets rejected at the door.
This is the inversion that matters. The default is deny. The agent earns its way into the human queue by proving where the change came from, not by looking convincing.
The Gate, in About 20 Lines
The control I trust is boring on purpose. A pipeline stage, vendor-neutral, that refuses to advance an AI-authored change unless it carries a verifiable provenance attestation and clears the eval and policy gates. Nothing here is exotic — it’s the supply chain playbook pointed at a new kind of producer.
# ci: gate for AI-authored changes. deny-by-default.
gate:
applies_when: change.author_type == "agent"
require_all:
# 1. provenance must exist and verify (SLSA-style attestation, sigstore-signed)
- attestation.present: true
- attestation.signature_valid: true
- attestation.fields_present: [model_id, task_spec_ref, tools_allowed, tests_run]
# 2. executable eval gate — the agent's own tests don't count alone
- eval_suite.passed: true # independent suite the agent cannot edit
- eval_suite.coverage_delta >= 0 # no silent removal of checks
# 3. policy-as-code — least privilege, protected paths, change budget
- policy.protected_paths_untouched: true # iac/prod/*, auth/*, billing/*
- policy.requested_scopes ⊆ task_spec.granted_scopes
- policy.lines_changed <= budget.per_pr # change-budget guardrail
on_fail: reject # never auto-merge; route to human with the failing reason
on_pass: route_to_human # human reviews a verified change, not a raw one
Three things make this hold up. The eval suite is independent of the agent and the agent can’t write to it, so green isn’t self-certified. The policy checks are mechanical facts about the change — paths, scopes, line counts — not judgments about whether the code is ‘good’ and the failure mode is rejection, not merge. A gate that auto-merges on pass and only flags on fail has the logic backwards; the whole point is that nothing reaches a human until it’s already provably in-bounds.
Staged Autonomy, and What Still Breaks
Provenance and policy tell you whether to trust a change. Staged autonomy decides how much rope the agent gets to begin with. I run agents through four levels:
Observe (read-only, it comments)
Recommend (it drafts, a human commits)
Bounded-write (it merges, but only inside an explicit allowlist of paths and scopes with a change budget)
Governed (wider authority, every action attested and reversible)
An agent earns the next level by accumulating a clean track record at the current one. It doesn’t start at bounded-write because it sounded confident in a demo.
I’ll be honest about the holes, because pretending they’re closed is how you get burned. Provenance proves origin, not correctness — a signed attestation on a wrong change is a well-documented wrong change. Your eval suite is now a security boundary, which means a gap in coverage is a gap in your defenses, and agents are very good at finding the path that your tests don’t watch. Policy as code only constrains what you thought to encode; the regression that bit me was caught by a path rule, but a subtler one could live entirely inside an allowed path. Every signing key and policy engine you add is itself attack surface — the OWASP guidance on supply chain and AI risks is worth reading precisely because these controls become the thing worth attacking.
None of that is an argument against the gates. It’s an argument for treating them as load-bearing infrastructure — versioned, tested, owned — instead of a checkbox. The eval suite and the policy bundle deserve the same on-call rigor as the service they protect.
The Takeaway
The agent proposes; the pipeline disposes. Stop asking whether the diff looks fine, because at agent volume your judgment isn’t the control and was never going to be. Make every AI-authored change prove its provenance, pass an eval gate it can’t edit and clear policy rules a machine enforces the same way every time. Build those controls outside the agent’s reasoning loop, where its confidence can’t reach them.
Anthropic is removing a step most developers were skipping anyway. Starting August 14, Claude Code will run in auto mode by default for Pro, Max, and Team plan users, cutting back the steady stream of permission prompts that ask developers to approve each action the AI agent wants to take.
The company first tested auto mode back in March, framing it as a middle ground between speed and control. Instead of stopping to ask permission for every command, auto mode routes each tool call through a classifier that only interrupts when an action looks irreversible, destructive, or aimed outside the user’s own environment. Everything else runs without a pause.
The timing tracks with a pattern Anthropic says it’s seeing across its own usage data: People don’t actually review most permission prompts. According to the company’s blog post announcing the change, users approve 97% of permission requests in Claude Code. That’s not evidence people are carefully checking each command. It’s evidence they’ve stopped reading them.
Anthropic backs this up with numbers from a controlled study of 1,053 paid testers. Partway through each coding session, researchers swapped in a genuinely dangerous command disguised as a routine permission prompt. Human reviewers caught it 13.6% of the time. Auto mode caught it 89% of the time. The gap widened as sessions ran longer — human catch rates dropped to around 5% after 50 or more prior prompts, while auto mode’s detection rate held steady no matter how long the session ran.
“A 13.6% catch rate tells you per-action approval stopped working long before anyone turned it off,” said Mitch Ashley, VP and practice lead for software lifecycle engineering and AI-native software engineering at The Futurum Group. “Teams counted clicks because clicks were easy to count. Nobody measured whether the click caught anything.”
Anthropic paired that testing with real production data. Looking at flagged sessions from May and June, the company found that sessions using manual approval contained serious unintended harm more than twice as often as auto mode sessions — 6.3% versus 2.4% at production-severity levels, like accidentally deleting rows from a live database.
The company also ran auto mode through adversarial testing with Apollo Research, an AI safety firm, injecting synthetic attacks into real coding trajectories. After a find-fix-verify cycle, auto mode’s miss rate on a held-out attack set dropped from 12% to 7%. A separate third-party evaluation from Trajectory Labs tested 72 prompt injection scenarios against Claude Code and OpenAI’s Codex. None of the 720 attack attempts succeeded against Claude Code running auto mode. Codex’s comparable auto-review mode had a 5.83% success rate on the same attacks.
None of this means auto mode approves everything. Anthropic built in specific guardrails it calls hard denies — data exfiltration, for instance, is a category the classifier is designed to never approve, full stop. The classifier also checks git status before destructive commands like git reset –hard, distinguishes between public and private repositories before allowing pushes, and screens content pulled from external sources for prompt injection attempts. If the classifier blocks something three times in a row, or twenty times across a session, Claude Code drops back into manual approval mode.
There’s a productivity angle here too. Anthropic says teams using auto mode ship about 25% more pull requests than those using manual review. Nuro, one of the companies quoted in Anthropic’s announcement, described kicking off an agent at 10 p.m. and getting three finished PRs by morning — something that wasn’t realistic under a model that stopped for permission at every step. Adobe, Gusto, and Garner Health are also running auto mode as their production default, with Garner pushing it to all 550 employees through managed settings.
That shift doesn’t remove the human from the process. It moves them earlier. “Human in the loop isn’t scalable and must become human engineering the loop, with the person defining what an agent may touch before the session starts,” Ashley said. “Teams still owe auditors a record of what ran unattended and why.”
For now, the change only applies to Pro, Max, and Team plans. Auto mode stays opt-in on Claude Enterprise, the Claude API, and the major cloud platforms — AWS, Google Cloud, and Microsoft Foundry — giving admins time to evaluate it before Anthropic plans to flip the default there too within the next month. Enterprise admins who want to move now can already set auto mode as the default through managed settings.
Anthropic is also dropping the token surcharge tied to the classifier’s overhead for Pro, Max, and Team users, effective immediately. Users who’ve already set a different permission mode manually won’t be switched automatically — they’ll get a one-time prompt asking if they want to opt in.
Claude Code Head Boris Cherny put it plainly in a post on X: He and his team have used auto mode exclusively for months and don’t want to go back to permission prompts. Anthropic’s data suggests that’s less an endorsement than a description of what happens to most users’ vigilance over time anyway — the company is just betting that a classifier trained on it does the job better than tired humans clicking “approve.”
Every team deploying AI agents in DevOps eventually faces the same design question, and it’s more consequential than it first appears: How much should the agent do on its own?
The question sounds like a settings dial — more autonomy here, less there. In practice, it is a governance question, an engineering question, and an organizational trust question bundled together.
This article gives you a framework for thinking through the autonomy decision — what factors actually determine where on the copilot-to-autopilot spectrum a specific action should sit, and how to build the guardrails that make the decision defensible.
The Spectrum Isn’t Binary
The framing of “human in the loop vs. fully autonomous” is too coarse to be useful in practice. Real DevOps agent deployments live somewhere on a more granular spectrum:
Level 0 — Observe only: The agent watches and logs. No output to humans, no actions. Used for baselining and evaluation before deployment.
Level 1 — Inform: The agent surfaces findings passively — posts a summary to a Slack channel, adds context to an existing incident thread. Humans read it if they want to.
Level 2 — Recommend with context: The agent surfaces a recommendation with explicit reasoning attached. “I recommend restarting the pods in service X because the error rate spiked 400% two minutes after the last deployment. Here’s the relevant log excerpt.” Humans decide.
Level 3 — Act with approval gate: The agent proposes a specific action and waits for explicit human approval before executing. The approval request includes the action, the reasoning, and the expected outcome.
Level 4 — Act with notification: The agent executes the action and notifies humans afterward. A human can override within a defined window.
Level 5 — Fully autonomous: The agent acts without notification. Humans see the result in logs or postmortems.
Most DevOps teams should have agents operating at Levels 1–3 for the vast majority of their use cases right now. Level 4 is appropriate for a narrow, carefully defined class of actions. Level 5 is appropriate for even fewer — and only after a documented track record at Level 4.
The Four Factors That Determine the Right Level
For any specific action your agent might take, four factors should determine where on the spectrum it sits.
Reversibility
The single most important factor. An action that can be trivially undone — adding a label, posting a message, running a read-only query — can tolerate a higher level of autonomy than an action that can’t. A pod restart is reversible but has customer impact. A database schema migration is largely irreversible. A cache flush is reversible but might trigger cascading load. A deployment rollback is reversible but takes time.
Map your agent’s action space by reversibility before you assign autonomy levels. Any irreversible or difficult-to-reverse action should require human approval by default, regardless of the agent’s confidence.
Blast Radius
How many users, services, or systems does this action affect? Restarting a single pod in a non-critical internal service has a small blast radius. Scaling down a fleet of pods serving your highest-traffic API has a large one. Modifying a shared ConfigMap that multiple services read has an unpredictable impact.
Blast radius interacts with reversibility: a large-blast-radius reversible action (restarting all pods in a deployment) is still higher risk than a small-blast-radius irreversible action (deleting a single test resource). Both factors matter.
Agent Confidence and Signal Quality
Is the agent working from clean, unambiguous signals, or is it reasoning about a noisy, ambiguous situation? An agent that’s detecting a clear threshold breach — a metric is 10x above its baseline, no deployments have happened, the same failure occurred twice before — can be more trusted than an agent that’s inferring a root cause from indirect signals.
This is hard to measure precisely, but it can be approximated. Well-defined success criteria for “high confidence” situations — specific signal patterns, specific prior incident matches, specific thresholds — let you build confidence-gated autonomy into the agent explicitly. If the confidence score is above the threshold, proceed at Level 4. If below, escalate to Level 3.
Time Sensitivity
Some failures get significantly worse if action is delayed by the time it takes for a human to respond. A memory leak that will OOM a pod in the next 90 seconds may genuinely warrant automated intervention without waiting for approval. A misconfigured alert that’s been firing for three hours can wait for a human to decide how to respond.
Time sensitivity is the factor that most justifies moving up the autonomy scale — but it’s also the factor most often used to rationalize autonomy that isn’t actually warranted. Be honest about whether the failure actually gets worse with a 5-minute human response delay, or whether it just feels urgent.
The Approval Gate: Design It to Be Used
The biggest failure in human-in-the-loop systems is approval fatigue: too many requests, too little context, and people start approving blindly.
A good approval gate should:
Be decision-ready: Include action, reason, expected outcome, and risk — so someone can decide in seconds.
Have a timeout plan: If no response, define what happens (escalate, fallback, or abandon). Never stall.
Fire at the right frequency: Too many approvals = poor design. Batch actions or automate more.
Building the Autonomy Track Record
Before increasing autonomy, prove reliability at the current level.
Track for each action:
How often do humans approve it
How often is the outcome correct
Whether humans modify it before approving
When and why it’s rejected
Use this to decide readiness:
~95% approval with no changes → ready for more autonomy
~70% approval with frequent edits → needs improvement
Measure per action type, not overall — agents can be good at some tasks and weak at others.
The Actions That Should Always Stay at Level 3
Regardless of track record, there’s a class of actions that should always require human approval. This isn’t a temporary policy while you build confidence — it’s a permanent boundary.
Any action affecting a production database (migrations, deletions, bulk updates)
Any action that could cause data loss
Any action affecting security configuration (IAM policies, network policies, secrets)
Any action that affects more than a defined percentage of production capacity simultaneously
Any action taken during a declared major incident, where the blast radius of a wrong action is already elevated
These aren’t limits imposed by lack of trust in the agent. There are limits imposed by the nature of the actions themselves. The cost of a wrong autonomous action in these categories is high enough that human judgment in the loop is worth the latency.
The Bottom Line
The copilot-to-autopilot question doesn’t have a universal answer. It has a framework: assess reversibility and blast radius for every action, build confidence levels into the agent’s decision-making, design approval gates that actually work, track the agent’s judgment empirically before expanding its autonomy, and maintain hard limits on actions where the cost of a wrong autonomous decision is simply too high.
The teams making the most progress with agentic DevOps are the ones who were most deliberate about the boundaries — and most rigorous about earning the right to expand them.
Autonomy is a consequence of demonstrated reliability, not a starting assumption.
