AI Agents for DevOps Automation: Beyond Simple Scripts
Mentiko Team
DevOps automation has been around for decades. Bash scripts, Ansible playbooks, Terraform configs, CI/CD pipelines -- these are mature tools that solve well-defined problems. So why would you add AI agents to the mix?
Because the hard part of DevOps isn't executing known procedures. It's the judgment calls between the procedures. Deciding whether a metric spike is a real incident or noise. Figuring out which runbook applies to this specific combination of symptoms. Writing the post-incident report that actually captures what happened. These are the gaps where agents fit -- not replacing your existing automation, but connecting the pieces that currently require a human in the loop.
Where scripts end and agents begin
A bash script restarts a service. An Ansible playbook provisions infrastructure. A CI/CD pipeline deploys code. These are deterministic: given the same input, they produce the same output every time. That's their strength and their limitation.
Agents handle the non-deterministic parts. The triage step before the runbook. The analysis step after the alert. The synthesis step that turns raw logs into a coherent incident report. When the action depends on interpreting unstructured data -- log messages, error traces, metric patterns, Slack threads -- that's where agents earn their place.
The best DevOps agent implementations don't replace scripts. They orchestrate them. The agent decides which script to run. The script does the actual work. The agent interprets the result and decides what comes next.
Pattern 1: Incident response chain
The classic DevOps agent chain. Four agents handle the lifecycle of a production alert.
{
"name": "incident-response",
"agents": [
{
"name": "triage",
"prompt": "Classify this alert. Determine severity (P0-P4), affected service, and category (infra/app/network/db). Check if this pattern matches any known incidents from the last 30 days.",
"triggers": ["chain:start"],
"emits": ["incident:classified"],
"workspace": "docker"
},
{
"name": "diagnostics",
"prompt": "Pull logs from the affected service for the last 30 minutes. Correlate with recent deploys, config changes, and upstream service status. Identify probable root cause.",
"triggers": ["incident:classified"],
"emits": ["diagnosis:complete"],
"workspace": "ssh:monitoring-host"
},
{
"name": "remediation",
"prompt": "Based on the diagnosis, execute the appropriate runbook. If the root cause matches a known pattern, run the automated fix. If novel, escalate to on-call with the diagnosis attached.",
"triggers": ["diagnosis:complete"],
"emits": ["remediation:complete", "incident:escalated"],
"workspace": "ssh:ops-bastion"
},
{
"name": "reporter",
"prompt": "Generate an incident report: timeline, root cause, actions taken, resolution status. Post to Slack and create a Jira ticket if severity is P0 or P1.",
"triggers": ["remediation:complete", "incident:escalated"],
"emits": ["chain:complete"],
"workspace": "docker"
}
]
}
The triage agent classifies the alert contextually -- a CPU spike on a batch server at 2 AM during a scheduled job is different from the same spike on a web server during peak traffic. The diagnostics agent has SSH access to your monitoring infrastructure and runs the same commands your on-call engineer would. The remediation agent touches production through restricted SSH -- only approved runbook commands. It can restart a service or roll back a deploy, but it cannot drop a database or modify IAM policies. You define the boundary. The reporter synthesizes everything into a timeline and posts it.
Pattern 2: Infrastructure audit chain
Compliance and security audits are painful because they're comprehensive and repetitive. An agent chain turns a quarterly audit into a scheduled daily check.
{
"name": "infra-audit",
"agents": [
{
"name": "scanner",
"prompt": "Scan all active AWS resources. Check: unencrypted volumes, public S3 buckets, overly permissive security groups, unused elastic IPs, instances without tags.",
"triggers": ["chain:start"],
"emits": ["scan:complete"],
"workspace": "docker:aws-cli"
},
{
"name": "comparator",
"prompt": "Compare current scan results against the last scan and against the compliance baseline. Flag new violations, resolved violations, and persistent violations.",
"triggers": ["scan:complete"],
"emits": ["comparison:complete"]
},
{
"name": "alerter",
"prompt": "For new critical violations, create Jira tickets and post to Slack. For persistent violations older than 7 days, escalate. For resolved violations, close existing tickets.",
"triggers": ["comparison:complete"],
"emits": ["chain:complete"],
"workspace": "docker"
}
],
"schedule": "0 6 * * *"
}
The scanner runs AWS CLI commands with read-only IAM credentials. The comparator diffs against the previous run -- interpreting what changed and whether it matters is the judgment part that's hard to script. The alerter creates tickets based on severity and age. Run it daily at 6 AM. By the time your team starts their day, they have a prioritized list. No quarterly fire drill.
Pattern 3: Deployment verification
Your CI/CD pipeline deploys the code. But who verifies the deployment actually works? Most teams rely on basic health checks and hope for the best. An agent chain can run a comprehensive post-deployment verification.
{
"name": "deploy-verification",
"agents": [
{
"name": "smoke-tester",
"prompt": "Run smoke tests against the deployed service. Hit critical endpoints, verify response codes and payload structure. Report any failures.",
"triggers": ["chain:start"],
"emits": ["smoke:passed", "smoke:failed"],
"workspace": "docker:test-runner"
},
{
"name": "load-tester",
"prompt": "Run a 5-minute load test at 2x normal traffic. Monitor response times, error rates, and resource utilization. Compare against pre-deploy baseline.",
"triggers": ["smoke:passed"],
"emits": ["load:complete"],
"workspace": "docker:k6"
},
{
"name": "regression-checker",
"prompt": "Compare current metrics against the pre-deploy baseline. Flag any degradation in p95 latency, error rate, or memory usage that exceeds 10%.",
"triggers": ["load:complete"],
"emits": ["verification:passed", "verification:degraded"]
},
{
"name": "rollback-decider",
"prompt": "The deployment shows performance degradation. Analyze the severity. If p95 latency increased >25% or error rate >1%, trigger automatic rollback. Otherwise, alert the team.",
"triggers": ["verification:degraded"],
"emits": ["rollback:triggered", "alert:degradation"]
}
]
}
If smoke tests fail, the chain stops -- no point load testing a broken deployment. If they pass, k6 hammers the service with realistic traffic. The regression checker compares post-deploy metrics against baseline. The rollback decider makes the judgment call: a 5% latency increase after a feature deploy might be acceptable, but the same increase after a "refactoring" deploy is suspicious. The agent reads commit messages, metric deltas, and severity to make a contextual decision.
Pattern 4: Runbook automation
Every DevOps team has runbooks. Most are Google Docs or Confluence pages that describe manual procedures. They go stale. People skip steps. New hires don't know they exist.
An agent chain turns a runbook into executable automation:
{
"name": "database-failover-runbook",
"agents": [
{
"name": "pre-check",
"prompt": "Verify failover prerequisites: replica lag <5s, replica healthy, no active migrations, maintenance window confirmed.",
"triggers": ["chain:start"],
"emits": ["precheck:passed", "precheck:blocked"],
"workspace": "ssh:db-bastion"
},
{
"name": "failover-executor",
"prompt": "Execute database failover: promote replica, update DNS, verify write capability on new primary. Pause if any step fails.",
"triggers": ["precheck:passed"],
"emits": ["failover:complete", "failover:failed"],
"workspace": "ssh:db-bastion"
},
{
"name": "post-check",
"prompt": "Verify failover success: application connectivity, replication from new primary to new replica, no stale connections.",
"triggers": ["failover:complete"],
"emits": ["chain:complete"],
"workspace": "ssh:db-bastion"
}
]
}
The runbook steps become agents. The prerequisites become pre-check logic. "If this step fails, call the DBA" becomes an error event that routes to an escalation chain. The runbook is now testable, versionable, and executable.
Integration and scheduling patterns
DevOps chains connect to your existing tools through webhooks and workspace commands. PagerDuty, OpsGenie, and Datadog send webhook payloads that trigger chains. Agents post to Slack via curl, create Jira tickets via API, and check GitHub for recent merges with gh api. No SDKs needed -- the workspace has the CLI tools.
Different chain types need different schedules. Infrastructure audits run daily at 6 AM ("schedule": "0 6 * * *"). Deployment verification is event-triggered from your CI/CD pipeline's webhook. Cost optimization runs weekly on Monday mornings. Incident response is always on -- triggered by your monitoring stack, not a clock.
Start with one chain
Don't try to automate all of DevOps at once. Pick the runbook your team runs most often -- the one everyone's tired of doing manually. Turn it into a chain. Run it alongside the manual process for a week. When you trust it, let it run. Move to the next one.
The goal isn't to eliminate your DevOps team. It's to eliminate the repetitive parts of their work so they can focus on the problems that actually need human judgment. The agent handles the 3 AM page for a known issue. Your engineer handles the novel outage that's never happened before.
Explore our getting started guide to build your first DevOps chain, or see how other teams use Mentiko in our use cases.
Get new posts in your inbox
No spam. Unsubscribe anytime.