# Building an SRE Incident Response Agent with Claude Managed Agents: Complete Implementation Guide

> Build an SRE incident response agent with Claude Managed Agents. Triage alerts, analyze logs, and open pull requests autonomously. Get the complete implementation guide here.

- Repository: [Anthropic/claude-cookbooks](https://github.com/anthropics/claude-cookbooks)
- Tags: tutorial
- Published: 2026-04-14

---

**Claude Managed Agents provide a hosted, stateful runtime that enables you to deploy an autonomous SRE incident responder capable of triaging PagerDuty alerts, analyzing logs, and opening pull requests through sandboxed tool execution and human-in-the-loop approvals.**

Production incident response demands reliability, auditability, and safe access to production resources. The `anthropics/claude-cookbooks` repository demonstrates how to build an SRE incident response agent using Claude Managed Agents (CMA), combining persistent file storage, sandboxed execution, and custom tool integrations to automate on-call workflows from initial alert to merged fix.

## Architecture Overview

The SRE incident response agent follows a five-stage pipeline that bridges external alerting systems with autonomous remediation. According to the source code in `managed_agents/sre_incident_responder.ipynb`, each stage maps to specific CMA API endpoints and resource types.

### 1. Upload Runbook Knowledge as a Skill

Instead of bloating the system prompt with operational procedures, the agent references a dedicated **Skill**—a versioned Markdown bundle that provides progressive disclosure of runbook conventions. In the cookbook, the Skill is defined as a string constant with YAML frontmatter and uploaded via the Files API.

### 2. Create the Managed Agent with Capabilities

The agent is instantiated with three capability layers: the built-in `agent_toolset_20260401` (providing bash, read, edit, and grep tools), the runbook Skill from step one, and three custom tools (`open_pull_request`, `request_approval`, `merge_pull_request`) that interface with external services like GitHub.

### 3. Provision a Sandboxed Environment

A lightweight cloud environment with limited network access hosts the agent's execution context. The notebook uploads log files, infrastructure manifests, and runbooks via `client.beta.files.upload`, then mounts these as resources in the agent's workspace at `/workspace/`.

### 4. Execute the Agent Loop

When a PagerDuty webhook triggers `client.beta.sessions.create`, the agent enters a turn-taking loop that polls `client.beta.events.list`. The loop routes tool calls to local implementations and pauses when human approval is required, ensuring dangerous operations (like merging to main) receive explicit sign-off.

### 5. Human-in-the-Loop Approval

When the agent invokes `request_approval`, the session idles until an on-call engineer reviews the proposed fix via the Anthropic Console. Once approved, the loop resumes and executes `merge_pull_request` to finalize the remediation.

## Implementation Walkthrough

The following snippets from `managed_agents/sre_incident_responder.ipynb` illustrate the core implementation steps. The complete runnable notebook is available in the `anthropics/claude-cookbooks` repository.

### Uploading the Runbook Skill

Define operational knowledge as a versioned Skill to keep the system prompt concise while allowing detailed reference material.

```python

# Lines 20-45 in sre_incident_responder.ipynb

RUNBOOK_SKILL = """---
name: incident-runbooks
description: How to triage production incidents using the team runbooks.
---

# Incident runbooks

When an alert references a service, locate that service's recent logs...
"""

skill = client.beta.skills.create(
    display_title="incident-runbooks",
    files=[("incident-runbooks/SKILL.md", RUNBOOK_SKILL.encode(), "text/markdown")],
)
print(f"skill: {skill.id} (version {skill.latest_version})")

```

### Creating the Managed Agent

Combine built-in tools, the uploaded Skill, and custom GitHub integration tools when defining the agent.

```python

# Lines 26-63 in sre_incident_responder.ipynb

agent = client.beta.agents.create(
    name="sre-incident-responder",
    version="v1",
    system_prompt=SRE_SYSTEM_PROMPT,
    tools=[
        {"type": "builtin", "name": "agent_toolset_20260401"},
        {"type": "skill", "skill_id": skill.id},
        {"type": "custom", "name": "open_pull_request", ...},
        {"type": "custom", "name": "request_approval", ...},
        {"type": "custom", "name": "merge_pull_request", ...},
    ],
)
print(f"agent: {agent.id} v{agent.version}")

```

### Configuring the Environment and Resources

Create an isolated cloud sandbox and mount the incident-specific data as read-only resources.

```python

# Environment creation and file upload pattern (Lines 12-22)

env = client.beta.environments.create(
    name="cookbook-sre-env",
    config={"type": "cloud", "networking": {"type": "limited"}},
)

def upload(path: Path, mime: str) -> str:
    with path.open("rb") as f:
        return client.beta.files.upload(file=(path.name, f, mime)).id

log_id = upload(Path("example_data/sre/log.txt"), "text/plain")
repo_id = upload(Path("example_data/sre/infra_manifest.json"), "application/json")
runbook_id = upload(Path("example_data/sre/runbooks.md"), "text/markdown")

```

### Running the Incident Response Session

Initialize a session with the PagerDuty payload and implement the event polling loop to handle tool calls.

```python

# Session initiation and event loop (Lines 400-460)

session = client.beta.sessions.create(
    agent_id=agent.id,
    environment_id=env.id,
    resources=[
        {"type": "file", "id": log_id, "mount_path": "/workspace/log.txt"},
        {"type": "file", "id": repo_id, "mount_path": "/workspace/infra"},
        {"type": "skill", "id": skill.id},
    ],
    input={"role": "user", "content": pagerduty_payload},
)

# Event loop with tool call routing

while True:
    ev = client.beta.events.list(session_id=session.id).events[0]
    if ev.type == "tool_use":
        handle_tool(ev)  # Routes to mock/custom implementations

    elif ev.type == "end_turn":
        break

```

## Key Architectural Components

Understanding how the pieces fit together ensures you build reliable, auditable automation.

| Component | Implementation Details | API Endpoint |
|-----------|------------------------|--------------|
| **Skill** | Encapsulates runbook knowledge in Markdown with YAML frontmatter | `client.beta.skills.create` |
| **Built-in Toolset** | Sandboxed bash, file read/edit, and grep capabilities | `agent_toolset_20260401` |
| **Custom Tools** | JSON schemas defining GitHub PR operations and approval gates | `client.beta.agents.create` with `tools` parameter |
| **Environment** | Limited-network cloud sandbox with persistent storage | `client.beta.environments.create` |
| **Resources** | Mounted files and Skills accessible at `/workspace/` | `client.beta.files.upload` and session config |
| **Event Loop** | Polls for `tool_use` and `end_turn` events to drive execution | `client.beta.events.list` |

## Summary

Building an SRE incident response agent with Claude Managed Agents requires orchestrating several distinct components into a cohesive workflow:

- **Skills** provide modular, versioned knowledge without prompt bloat
- **Custom tools** bridge the sandbox to external services like GitHub while maintaining safety boundaries
- **Environments** offer isolated, persistent workspaces for incident-specific data
- **The event loop** handles autonomous execution while preserving human-in-the-loop control points for critical decisions

The implementation in `managed_agents/sre_incident_responder.ipynb` demonstrates production-ready patterns for handling PagerDuty webhooks, executing runbook procedures, and managing pull request lifecycles through the Anthropic Console.

## Frequently Asked Questions

### What is the difference between a Skill and the system prompt?

A **Skill** is a versioned, uploadable artifact that the agent references on-demand, whereas the system prompt is static text injected into every request. Skills support progressive disclosure—the agent loads the relevant runbook section only when needed—reducing token usage and keeping the context window focused on the immediate incident.

### How does the human-in-the-loop approval mechanism work?

When the agent calls the custom `request_approval` tool, the Managed Agent runtime sets the session status to `awaiting_user`. The event loop polls `client.beta.events.list` and detects this state, pausing execution until an on-call engineer approves the action via the Anthropic Console. Once approved, the session resumes and the agent can invoke `merge_pull_request` to complete the fix.

### Can I use persistent storage across multiple incidents?

Yes. The **Environment** created via `client.beta.environments.create` maintains persistent file storage beyond individual sessions. You can upload historical logs, previous incident analyses, or configuration files that remain available across multiple alert cycles, though the cookbook demonstrates mounting fresh resources per incident for isolation.

### What built-in tools are available in the `agent_toolset_20260401`?

The built-in toolset includes sandboxed bash execution, file read/write operations (`read`, `edit`), text search (`grep`), and directory listing. These tools execute within the limited-network cloud environment, allowing the agent to analyze logs and modify configuration files without requiring custom tool implementations for basic file system operations.