DevOps Automation Agent

Agent Capabilities

Agent YAML

# devops-agent.yaml
name: devops-bot
description: "CI/CD monitoring, incident diagnosis, and remediation"

llm:
  model: gpt-4o
  temperature: 0.1

system_prompt: |
  You are a senior DevOps engineer. When a CI/CD pipeline fails:
  1. Fetch the full build logs
  2. Identify the root cause (dependency issue, test failure, infra problem, code bug)
  3. Classify severity: P1 (production broken) / P2 (staging) / P3 (non-critical)
  4. For P1/P2: create a Jira ticket with detailed diagnosis
  5. Send a Slack alert summarizing the issue and next steps
  6. For P1 only: check if the last successful deployment can be restored
  
  For Kubernetes operations, ALWAYS require human approval.
  Log every action taken with timestamps.

tools:
  - github_list_workflow_runs
  - github_get_run_logs
  - jira_create_issue
  - jira_update_issue
  - slack_post_message
  - http_healthcheck
  - kubectl_get_pods
  - kubectl_get_events

approval_required:
  - kubectl_rollout_undo        # Never auto-rollback without approval
  - kubectl_scale               # Never auto-scale without approval
  - github_trigger_workflow     # Don't auto-retrigger without approval

GitHub Actions Webhook Trigger

# triggers/github-actions-trigger.yaml
triggers:
  - type: webhook
    path: /webhooks/github-actions
    secret: "${GITHUB_WEBHOOK_SECRET}"
    filters:
      event: workflow_run
      action: completed
      status: failure     # Only trigger on failures
    run:
      agent: devops-bot
      input:
        repo: "{{ payload.repository.full_name }}"
        run_id: "{{ payload.workflow_run.id }}"
        workflow_name: "{{ payload.workflow_run.name }}"
        branch: "{{ payload.workflow_run.head_branch }}"

Jira Tool Configuration

# tools/jira.yaml
tools:
  jira_create_issue:
    type: rest
    url: "https://{{ JIRA_DOMAIN }}.atlassian.net/rest/api/3/issue"
    method: POST
    auth:
      type: basic
      username: "${JIRA_EMAIL}"
      password: "${JIRA_API_TOKEN}"
    body:
      fields:
        project:
          key: "{{ project_key | default('ENG') }}"
        issuetype:
          name: "Bug"
        summary: "{{ summary }}"
        description:
          type: doc
          version: 1
          content:
            - type: paragraph
              content:
                - type: text
                  text: "{{ description }}"
        priority:
          name: "{{ priority | default('Medium') }}"
        labels: ["ci-cd", "auto-detected"]

Example Slack Alert

🔴 *P1 Pipeline Failure* — `api-service / deploy-production`

*Branch:* main  |  *Commit:* a3f92c1

*Root Cause:*
The `pytest` step failed due to import error in `tests/test_payment.py`.
`ModuleNotFoundError: No module named 'stripe'`

This is a **missing dependency** — `stripe` package is not in `requirements.txt`
despite being used in 3 test files.

*Actions Taken:*
✅ Created Jira ticket: ENG-2847
✅ Notified on-call: @alice

*Suggested Fix:*
Add `stripe==7.3.0` to `requirements.txt` and re-run pipeline.

*Previous successful deploy:* 2h ago (commit b2e81f0)

What This Agent Does

This tutorial builds a DevOps automation agent that assists with deployment coordination, infrastructure health checks, incident triage, and operational reporting. The agent integrates with cloud provider CLIs, reads logs, checks service status, and can execute pre-approved runbook steps. It dramatically reduces the cognitive load of on-call work by automating the routine investigation and remediation steps that consume engineer time during incidents.

Step 1 — Agent Configuration

Create devops-agent.yaml:

agent:
  name: devops-assistant
  description: Assists with deployment and operational tasks
  system_prompt: |
    You are a senior DevOps engineer assistant. You have access to
    shell command execution and can help with operational tasks.

    SAFETY RULES (never violate these):
    - Never run commands that delete data without explicit user confirmation
    - Never modify production infrastructure without showing the exact command
      and waiting for approval
    - For any destructive operation, state the impact and ask "Confirm? (yes/no)"
    - Prefer read commands (get, describe, list, logs) over write commands
    - If a command produces an error, investigate before retrying

    You are helpful, precise, and safety-conscious. When diagnosing issues,
    work systematically: check health, check logs, check recent changes, propose fix.

llm:
  model: claude-3-5-sonnet-20241022
  temperature: 0.1
  max_tokens: 4096

tools:
  - name: shell_exec
    enabled: true
    config:
      allowed_commands:
        - kubectl
        - aws
        - docker
        - git
        - openclaw
      timeout: 60
      working_dir: /ops/scripts

Step 2 — Health Check Automation

openclaw run --config devops-agent.yaml   --task "Run a morning health check on our infrastructure:
  1. Check status of all pods in the production namespace
  2. List any pods that are not Running status
  3. For any unhealthy pods, get last 50 lines of logs
  4. Check CPU and memory usage across nodes
  5. Report any nodes above 80% utilization
  Produce a summary: GREEN if all healthy, YELLOW if warnings, RED if critical issues."

Step 3 — Deployment Assistance

openclaw run --config devops-agent.yaml   --task "Assist with deploying version 2.3.1 of the api-service:
  1. Check current version running in production
  2. Review the last 200 lines of the current pods' logs for any ongoing errors
  3. Show me the exact kubectl command to update the deployment image
  4. Wait for my confirmation before running any deployment commands
  5. After deployment: watch rollout status and report when complete"

Step 4 — Incident Triage

When an alert fires, run the agent with an incident description to get rapid initial triage:

openclaw run --config devops-agent.yaml   --task "INCIDENT: payment-service response time spiked from 200ms to 2000ms at 14:32 UTC.
  Triage this incident:
  1. Check payment-service pod health and recent restarts
  2. Get error rate from logs in the last 15 minutes
  3. Check if any deployments happened in the last hour
  4. Check database connection pool status if accessible
  5. Identify the most likely root cause and recommend next steps"

Step 5 — Runbook Automation

Convert your existing runbooks into agent task templates. Each runbook step becomes a directive in the task. The agent executes diagnostic steps automatically, pauses at steps that require human judgment or confirmation, and maintains a running log of what was checked and found. Over time, your runbooks self-document as the agent's execution logs become a record of what was actually done during each incident, not just what the runbook said to do.

Troubleshooting

If the agent attempts commands not in your allowlist, it will receive a TOOL_PERMISSION_DENIED error — review your allowed_commands list and add any needed tools explicitly. If the agent runs steps out of order, add explicit dependency statements to the task: "Do not proceed to step 3 until step 2 completes successfully." For commands that produce large output (full log dumps), add max_output_length: 5000 to shell_exec config to prevent context overflow.

Safe Production Operations

The highest risk in using an AI agent for operations is accidental execution of a destructive command. Mitigate this with multiple layers of protection. First, configure the allowed_commands list to include only commands the agent legitimately needs — if the agent never needs to kubectl delete, don't allow it. Second, require confirmation for any command containing create, delete, apply, rollout, or scale. Third, run the agent in dry-run mode for your first several uses in a new environment to see what commands it would run before it runs them. These layers together make catastrophic accidents extremely unlikely.

Maintain different agent configurations for read-only and read-write operations. Use the read-only config for all diagnostic and monitoring tasks — it has no write commands in the allowlist and can be used freely without risk. Switch to the read-write config only for tasks that require making changes, and treat each read-write session as requiring attention rather than unattended automation. This separation of concern reduces the window during which write operations can occur.

Documentation of Automated Actions

Every command the agent executes in production should be logged with timestamp, the task that triggered it, and the output. This creates an automated audit trail equivalent to a human engineer's operational log. After an incident, you can review exactly what the agent did and when, in what order, and what results each command produced. This traceability is essential both for post-incident analysis and for building confidence in the agent's behavior over time.

Graduated Automation

Start with the agent in pure advisory mode — it tells you what to do but doesn't do it. Once you trust its recommendations for a specific category of task (say, identifying the root cause of a specific class of alert), allow it to execute the read commands for that category autonomously while still requiring approval for remediation actions. Finally, for well-understood incidents with deterministic remediation steps (like restarting a crashed pod), allow full automation. This graduated approach builds trust through demonstrated accuracy before expanding autonomous action scope, which is the right way to deploy automation in production systems.

Long-Term Operations Evolution

Track which operational tasks you use the agent for most frequently and which still require full human execution. The tasks the agent handles reliably are candidates for further automation — add scheduling, automatic triggering from monitoring alerts, or integration with your incident management system. The tasks that still require human execution despite agent assistance reveal the boundaries of current capabilities — log these and review them periodically, as model improvements and new tool capabilities may enable automation that wasn't previously possible. Every six months, reassess your operations agent's capability boundaries and expand them where evidence supports doing so safely.