Example of Agentic AI: Real-World Use Cases for DevOps Teams

Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

If you’ve spent any time on engineering Twitter or LinkedIn lately, you’ve seen the term “agentic AI” thrown around next to buzzwords like “autonomous” and “self-healing.” It’s easy to dismiss as marketing noise, but the underlying pattern is real and it’s already running in production systems. This article breaks down what agentic AI actually is, walks through a concrete example of agentic ai applied to a CI/CD pipeline, and shows several more use cases you can build or evaluate today.

Disclosure: This post contains affiliate links. If you sign up through one of the links below, we may earn a commission at no extra cost to you. We only recommend infrastructure providers we’ve actually used in production.

What Is Agentic AI, Actually?

Agentic AI refers to systems built around a large language model (LLM) that can plan a sequence of actions, execute tools (scripts, API calls, database queries), observe the results, and decide what to do next — without a human manually approving each step. This is different from a traditional chatbot, which just answers a question and stops.

Think of the difference this way: a standard AI assistant tells you how to restart a crashed container. An agentic AI system checks the container’s exit code, pulls the last 200 lines of logs, correlates them against a known error pattern, restarts the container, verifies the health check passes, and only pings you if it can’t resolve the issue on its own.

Key Characteristics of Agentic AI

Autonomy — it takes multi-step action without a human in the loop for every decision

Tool use — it calls real functions: shell commands, REST APIs, database queries, Kubernetes controllers

Memory/state — it tracks what it has already tried so it doesn’t loop forever

Goal-directed planning — it breaks a high-level objective (“keep the API under 200ms p95”) into concrete steps

Feedback loops — it observes the outcome of each action and adjusts the next step accordingly

If a system is missing most of these traits, it’s probably just an LLM wrapper, not a true agent.

Example of Agentic AI #1: Autonomous CI/CD Remediation

Here’s a concrete example of agentic ai wired into a GitHub Actions pipeline. When a deployment fails, instead of just notifying a human, the agent investigates and attempts a fix first.

# .github/workflows/deploy.yml
name: deploy-with-agent-remediation
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to production
        id: deploy
        run: ./scripts/deploy.sh
        continue-on-error: true
      - name: Trigger remediation agent
        if: steps.deploy.outcome == 'failure'
        run: python3 agents/remediation_agent.py --job-id ${{ github.run_id }}

The remediation_agent.py script is where the actual agentic loop lives. Below is a simplified version showing the plan-act-observe pattern:

import subprocess
import json

def run_tool(cmd: str) -> str:
    result = subprocess.run(cmd, shell=True, capture_output=True, text=True, timeout=30)
    return result.stdout + result.stderr

def remediation_agent(job_id: str, max_steps: int = 5):
    context = [f"Deployment {job_id} failed. Diagnose and attempt a fix."]

    for step in range(max_steps):
        # In production this call goes to an LLM API (e.g. Claude) with
        # the current context and a list of available tools.
        action = decide_next_action(context)

        if action["type"] == "done":
            print(f"Resolved in {step + 1} steps: {action['summary']}")
            return True

        output = run_tool(action["command"])
        context.append(f"Ran: {action['command']}nResult: {output[:500]}")

    print("Agent could not resolve the issue automatically. Paging on-call.")
    page_oncall(job_id, context)
    return False

In practice, decide_next_action sends the accumulated context to an LLM with tool-calling enabled, and the model returns a structured action like {"type": "tool", "command": "kubectl rollout status deploy/api -n prod"}. The loop keeps going until the model reports success or the step budget runs out, at which point a human takes over.

Why This Beats a Static Runbook

A static runbook is a fixed script: if X fails, run Y. Agentic systems instead reason about which diagnostic to run next based on what the previous command returned. That flexibility matters because production failures rarely match the exact scenario a runbook author anticipated.

Example of Agentic AI #2: Self-Healing Infrastructure Monitoring

Monitoring tools like BetterStack already do a good job of alerting you when something breaks. The agentic layer sits on top: instead of just firing a Slack alert, an agent receives the alert, pulls metrics and logs, forms a hypothesis, and takes a corrective action such as scaling a deployment or restarting a stuck worker pool.

A simple version of this pattern for a Dockerized service:

#!/bin/bash
# health_agent.sh - called by a monitoring webhook on alert

SERVICE=$1
EXIT_CODE=$(docker inspect --format='{{.State.ExitCode}}' "$SERVICE")

if [ "$EXIT_CODE" -eq 137 ]; then
  echo "OOMKilled detected for $SERVICE — raising memory limit and restarting"
  docker update --memory=1g --memory-swap=1g "$SERVICE"
  docker start "$SERVICE"
elif [ "$EXIT_CODE" -eq 1 ]; then
  echo "Generic failure — pulling logs for LLM triage"
  docker logs --tail 100 "$SERVICE" > /tmp/last_failure.log
  python3 agents/triage.py --log /tmp/last_failure.log --service "$SERVICE"
fi

We cover the broader monitoring stack this pairs with in our Docker container monitoring guide, which walks through setting up the metrics pipeline an agent like this depends on.

Cloud Cost Optimization Agents

Another increasingly common example of agentic ai lives in FinOps tooling. These agents monitor cloud spend across providers, identify idle resources (unattached volumes, oversized instances, forgotten load balancers), and either flag them or terminate them automatically based on policy rules you define. If you’re running infrastructure on DigitalOcean or Hetzner, pairing their APIs with a lightweight agent script is often cheaper than buying a full FinOps platform — you can query usage via their REST APIs, feed the results to an LLM for anomaly detection, and auto-tag or resize resources that look wasteful.

Security Triage Agents

Security operations centers use agentic AI to pre-triage alerts from tools like intrusion detection systems and cloud security posture managers. The agent correlates a new alert against historical incidents, checks whether the source IP has prior flags, and either auto-closes false positives or escalates genuine threats with a written summary — cutting analyst workload significantly. This only works safely with tight guardrails, which we discuss more in our Linux server hardening checklist.

Building Your Own Agentic AI Workflow

If you want to experiment with this pattern yourself, here’s a minimal stack that works well for infrastructure use cases:

An LLM with reliable tool/function calling — Anthropic’s Claude models or OpenAI’s GPT-4 class models both support this

A sandboxed execution environment (a container, not your host shell) so the agent can’t run destructive commands unchecked

A hard step limit and cost budget per run, so a bad loop doesn’t rack up API bills or spin forever

Structured logging of every action the agent takes, for audit and debugging

A human-approval gate for any action that’s destructive or hard to reverse (deleting resources, force-pushing, dropping databases)

That last point is the one teams skip most often, and it’s the one that causes incidents. An agent that can restart a container autonomously is low risk. An agent that can delete a database volume autonomously needs a human in the loop, full stop.

Guardrails That Actually Matter in Production

When you move an agentic workflow from a demo to production, the failure modes change. A few guardrails worth building in from day one:

Allowlist the tools the agent can call — never let it construct arbitrary shell commands from raw model output

Rate-limit destructive actions so a hallucinating agent can’t, say, restart the same service 50 times in a minute

Log every decision with the reasoning attached, not just the action, so you can audit why it did what it did

Set a maximum blast radius — scope credentials so the agent can only touch the specific resources it’s meant to manage

Teams that skip these steps tend to have a rough first incident. Teams that build them in up front get most of the benefit of autonomy with a fraction of the risk.

Wrapping Up

Agentic AI isn’t a single product you buy — it’s a design pattern: give a model tools, let it observe outcomes, and let it iterate toward a goal within defined limits. The CI/CD remediation example above is a good starting project because failures are frequent, low-stakes to experiment with, and easy to roll back. Once that’s stable, extending the same pattern to monitoring, cost optimization, or security triage is a natural next step.

If you’re setting up the underlying infrastructure these agents run on, a reliable VPS with predictable performance and an API you can script against matters more than people expect — check out DigitalOcean or Hetzner if you’re evaluating providers, and pair it with BetterStack for the observability layer your agent will read from.

Recommended: Ready to put this into practice? DigitalOcean is a tool we use for exactly this, and we have a real, disclosed affiliate relationship with them.

FAQ

Q: What’s a simple example of agentic ai that doesn’t involve infrastructure?
A: A common non-infra example is an AI travel-booking agent that searches flights, compares prices across sites, checks your calendar for conflicts, and books the ticket — taking multiple sequential actions toward one goal without you approving each search individually.

Q: How is agentic AI different from RPA (robotic process automation)?
A: RPA follows a fixed, pre-scripted sequence of steps with no reasoning involved. Agentic AI decides its next step dynamically based on the outcome of the previous one, which lets it handle situations the original script author never anticipated.

Q: Is agentic AI safe to run against production systems?
A: It can be, but only with guardrails: sandboxed execution, an allowlist of permitted tools, step/cost limits, and a human-approval gate for destructive actions. Without those, an agent can amplify a small bug into a large outage.

Q: Do I need a custom LLM to build an agentic workflow?
A: No. General-purpose models with function-calling support, like Claude or GPT-4-class models, work fine for most DevOps use cases. The engineering effort goes into the tool integrations and guardrails, not the model itself.

Q: What’s the easiest first agentic AI project for a DevOps team?
A: Automated log triage on failed CI/CD jobs. It’s low-risk, the failure modes are well understood, and it gives immediate, measurable time savings for the on-call rotation.

Q: Can agentic AI replace on-call engineers entirely?
A: Not currently, and probably not for a long while. It reduces the volume of alerts that need a human, but genuinely novel failures still require human judgment, especially for anything with real business or safety impact.