Illustrative AI-assisted incident response. The tools and vendors shown are examples, not verified native integrations.
Claude Managed Agents can investigate incidents, follow runbooks and interact with operational tools. For DevOps teams, the opportunity is to automate more of the response process. The challenge is deciding what an agent should be allowed to execute.
An application starts returning errors in production. Monitoring detects an unusual increase in failures and sends an alert to the on-call engineer.
The engineer begins a familiar investigation. They examine logs, check recent deployments, identify the affected service and consult the runbook. If the problem requires an infrastructure change, they prepare the fix and follow the organization’s approval process.
AI assistants can already help engineers understand logs and suggest troubleshooting steps. But what if an AI agent could begin investigating as soon as the alert arrives, without waiting for someone to describe the problem? This is one of the possibilities opened by Claude Managed Agents, which Anthropic launched in public beta on April 8, 2026.
The service provides infrastructure for running AI agents that can execute multi-step tasks, use tools and maintain their working state. Subsequent updates have added capabilities for coordinating work and exporting operational traces. For DevOps and site reliability engineering (SRE) teams, the interesting development is the possibility of connecting an AI agent to existing incident-response workflows.
How a managed agent differs from a chatbot
A chatbot typically responds to a request. An engineer shares an error message, asks what might be wrong and receives an explanation or suggested commands. A managed agent can take a more active role.
An application can create a session when an event occurs. The agent receives the incident context, calls available tools, examines their results and decides what to investigate next.
Claude Managed Agents supplies the execution environment, session management and built-in tools for tasks such as reading files and running commands. It also supports connections to external systems through tools and Model Context Protocol (MCP).
This does not mean Anthropic provides a complete incident-management product. Monitoring integrations, operational permissions and remediation procedures remain the organization’s responsibility. The difference is that developers can build an agent workflow without building every part of the underlying agent runtime themselves.
Following an incident from alert to investigation
Anthropic provides a concrete example in its April 10 tutorial, Build an SRE Incident Response Agent with Claude Managed Agents. The demonstration begins with a simulated PagerDuty alert. A webhook passes the incident details to an application, which starts an agent session.
The agent then examines logs and infrastructure files using tools available inside its sandbox. It also consults a runbook supplied through a Skill, a reusable package of instructions and supporting files. The Skill tells the agent how the team expects an incident to be investigated, including checking the runbook before modifying infrastructure.
Once the agent identifies a potential configuration problem, it prepares a patch. Custom tools allow the workflow to open a pull request and request human approval before merging. The sequence illustrates how an agent can move through several steps without an engineer manually prompting each one.
There is an important limitation. PagerDuty, GitHub and Datadog are simulated in the tutorial. The example demonstrates how to build the integration, not how reliably it performs during real production incidents.
When investigation becomes operational action
Reading logs and identifying a possible cause are different from changing production infrastructure. An agent could be connected to tools for creating incident tickets, opening pull requests or invoking approved scripts. With additional development, it could also help correlate related alerts or identify repeated notifications.
These are possible customer-built workflows. They are not evidence that Claude Managed Agents includes a ready-made alert-deduplication or autonomous remediation service.
Consider the configuration problem in our incident example. Preparing a patch gives an engineer something concrete to inspect. Applying that patch changes the operational state of the system. Even when the proposed fix looks correct, it could affect other services or interact with a deployment already underway.
The ability to execute a command therefore does not establish that executing it is safe. This is where the distinction between agent capability and operational authority becomes important.
How runbooks need to support agent execution
Traditional runbooks often assume an experienced engineer will interpret the instructions. A procedure might say, “Restart the service if it remains unhealthy.”
Before doing so, an engineer may check recent deployments, dependent services and previous recovery attempts. Those checks might not be written explicitly because the team considers them standard practice. An agent cannot safely rely on undocumented assumptions.
For automated execution, the procedure needs clearer conditions.
- What evidence confirms the problem?
- Which diagnostic checks are required?
- Is the action permitted in this environment?
- When must execution stop?
- How should recovery be verified?
This is not an entirely new discipline. Conventional automation also requires reliable preconditions, predictable actions and failure handling. Managed agents introduce another consideration because the agent can choose which available tools to use and in what sequence. A runbook can guide that decision-making, but instructions alone should not determine production permissions.
Where the decision to act is made
Claude Managed Agents provides configurable permission policies for built-in and MCP tools. A tool can execute automatically, require approval or be evaluated before execution. However, these policies do not govern custom tools. When an agent requests a custom tool, the customer’s application receives that request and is responsible for deciding whether to execute it.
That distinction is particularly important for incident response. An organization could allow an agent to examine logs, read configuration files and prepare a pull request, while requiring explicit approval for actions that restart services or modify production infrastructure. The application should enforce those boundaries independently of the agent’s instructions.
It must also consider what happens when an action fails, is requested twice or completes only partially. Stopping an agent does not necessarily undo a change already made through an external system.
Anthropic provides sandbox, network, credential and session-monitoring controls. Those controls are useful, but they do not replace secure integration design or the operational checks needed to confirm successful recovery.
Data handling requires attention too. Managed Agents is currently not eligible for Anthropic’s Zero Data Retention arrangement or HIPAA Business Associate Agreement coverage. Teams handling sensitive operational information need to review those restrictions before connecting production data.
How far DevOps teams should go today
Managed Agents creates a practical opportunity to experiment with incident investigation that starts automatically and progresses through several operational steps. The official SRE demonstration shows how that workflow can be assembled. It does not prove that autonomous remediation consistently improves recovery time or performs reliably across unfamiliar incidents.
For a team evaluating the platform, a controlled experiment is a more useful starting point than broad production access. A test alert could initiate an agent session with access to prepared logs, a runbook and a limited set of read-only diagnostic tools. Engineers could evaluate whether the agent identifies the relevant evidence, follows the procedure and explains its proposed action correctly.
The next experiment could allow the agent to prepare a change for review, without permission to apply it. These trials would help establish whether the agent adds useful operational capability and where its decisions remain unreliable.
Claude Managed Agents changes what developers can build around existing IT operations systems. It does not remove the need for monitoring, reliable automation, human judgment or established incident-management practices.
For DevOps and SRE teams, the important decision is not simply whether an AI agent can respond to an incident. It is which parts of that response can be delegated safely, and how the team will know when the agent has reached its limits.
Go deeper
- Claude Platform Release Notes, Anthropic. April 8, 2026 beta and later releases.
- Claude Managed Agents Overview, Anthropic. Managed agent infrastructure and sessions.
- Build an SRE Incident Response Agent, Gagan Bhat, Anthropic, April 10, 2026. Mocked incident response tutorial.
- Permission Policies, Anthropic. Built-in, MCP and custom tool boundaries.
- Secure Your Managed Agents Deployment, Anthropic. Execution security considerations.
- Session Operations, Anthropic. Session lifecycle behavior.
Related reading on TechiesJournal
- When AI Joins the On-Call Team: Who Controls Production Decisions? for the question of who owns a production decision once an agent proposes it.
- The MCP Credential Boundary: Why an MCP Server Should Not Decide Where Your OAuth Credentials Go for the tool and credential side of agent permissions.
- After You Close the Laptop: What Infrastructure AI Agents Actually Need for the runtime and infrastructure an agent needs to keep working.