Agentic Runbook Integration Patterns: Webhooks, MCP, and Agent-to-Agent

Pattern 1: Webhook-triggered agent

The simplest and most widely supported pattern. An incident management tool fires a webhook when an alert is created or escalated. The agent receives the webhook payload, processes it, and executes the runbook.

# Python FastAPI webhook handler
# Receives PagerDuty webhook, routes to agentic runbook

from fastapi import FastAPI, Request
from langgraph_runbook_agent import handle_alert

app = FastAPI()

@app.post("/webhook/pagerduty")
async def pagerduty_webhook(request: Request):
    payload = await request.json()

    # PagerDuty sends messages list
    for message in payload.get("messages", []):
        if message["event"] == "incident.trigger":
            incident = message["incident"]

            # Route to matching runbook
            alert_data = {
                "title": incident["title"],
                "body": incident.get("body", {}).get("details", ""),
                "service": incident["service"]["summary"],
                "severity": incident["urgency"],
            }

            # Fire and forget (run agent in background task)
            import asyncio
            asyncio.create_task(
                asyncio.to_thread(handle_alert, alert_data)
            )

    return {"status": "accepted"}

Pattern 2: MCP-powered agent

The Model Context Protocol (Anthropic, released late 2024) is the emerging standard for agent-to-tool communication. Instead of custom tool wrappers, tools are exposed as MCP servers. The agent discovers and invokes them via a standard protocol.

AWS Bedrock AgentCore wraps Kubernetes, CloudWatch, CloudTrail, and EC2 APIs as MCP tools. A LangGraph or AutoGen agent consuming these MCP tools can investigate and remediate across AWS services without custom integration code.

# MCP-powered agent (AWS Bedrock AgentCore pattern)
# Tools are MCP servers; agent discovers them automatically

from bedrock_agent_core import AgentCore, MCPGateway

# Bedrock AgentCore wraps these services as MCP tool servers
gateway = MCPGateway(
    tools=[
        "aws-cloudwatch",     # Metrics and logs
        "aws-eks-kubectl",    # Kubernetes API (EKS)
        "aws-cloudtrail",     # Audit trail (read)
        "aws-codedeploy",     # Deployments
        "pagerduty-mcp",      # Incident management
    ],
    iam_role="arn:aws:iam::ACCOUNT:role/SREAgentRole",
    allowed_actions=[
        "cloudwatch:GetMetricData",
        "eks:DescribePodStatus",
        "codedeploy:GetDeployment",
        "codedeploy:CreateDeployment",  # Write: in require_human list
    ]
)

agent = AgentCore(
    model="anthropic.claude-sonnet-4-5-v2",
    gateway=gateway,
    runbook="runbooks/aws-ec2-remediation-v1.yaml"
)

# Agent discovers available MCP tools automatically on startup
# and matches signal_spec.trigger to route incoming alerts

Pattern 3: Agent-to-agent (A2A)

A top-level SRE agent orchestrates specialised sub-agents. The meta-agent handles incident classification and routing; sub-agents handle specific domains. Kubiya popularised this pattern in the SRE space.

# Agent-to-agent pattern (Kubiya-inspired)
# Meta-agent routes to specialised sub-agents

meta_agent:
  role: "incident-classifier"
  receives: pagerduty_alerts
  routes_to:
    - condition: "alert.service == 'kubernetes'"
      agent: k8s-specialist-agent
    - condition: "alert.type == 'deployment'"
      agent: deploy-specialist-agent
    - condition: "alert.type == 'cert-expiry'"
      agent: cert-rotation-agent
    - default:
      agent: general-sre-agent

k8s-specialist-agent:
  tool_scope:
    - kubectl_*          # All kubectl operations
    - helm_*             # Helm operations
  model: claude-sonnet-4-5
  max_iterations: 10

deploy-specialist-agent:
  tool_scope:
    - git_*              # Git operations (read)
    - ci_cd_*            # CI/CD pipeline operations
    - kubectl_rollout_*  # Rollout operations
  model: claude-sonnet-4-5
  max_iterations: 6

Pattern 4: Event-stream processing

For high-volume, low-latency use cases. The agent subscribes to a Kafka, NATS, or Redis stream and processes events reactively. Suitable for noise suppression and alert correlation at scale.

# Kafka consumer for high-volume alert processing
from kafka import KafkaConsumer
from alert_correlator import AgentCorrelator
import json

consumer = KafkaConsumer(
    "platform.alerts",
    bootstrap_servers=["kafka:9092"],
    value_deserializer=lambda m: json.loads(m.decode("utf-8"))
)

correlator = AgentCorrelator(
    window_seconds=300,        # 5-minute correlation window
    max_alerts_per_incident=500,
    model="claude-haiku-3-5",  # Faster model for high-volume correlation
)

for message in consumer:
    alert = message.value

    # Correlate into incident groups
    incident = correlator.process(alert)

    if incident.is_new:
        # Only page on-call for novel incident clusters
        pagerduty.create_incident(incident)
    else:
        # Suppress: add to existing incident
        pagerduty.add_alert_to_incident(incident, alert)

Pattern 5: Scheduled / proactive

The agent runs on a schedule rather than reacting to an alert. Used for toil elimination: cert expiry checking, cost anomaly scanning, config drift detection, runbook freshness auditing.

# Scheduled proactive agent (cron-triggered)
# Runs nightly to check for cert expiry

import schedule, time
from cert_checker_agent import CertCheckerAgent

agent = CertCheckerAgent(
    runbook="runbooks/cert-expiry-rotation-v1.yaml",
    namespaces=["production", "staging"],
    warn_days=14,       # Alert if expiry < 14 days
    auto_renew_days=7,  # Auto-renew if < 7 days
)

schedule.every().day.at("09:00").do(agent.run)

while True:
    schedule.run_pending()
    time.sleep(60)

Pattern selection guide

Integration gotchas