Use case

AI Agents for DevOps and CI

Name: Fleet
Author: Fleet

CI configuration and DevOps work has a maintenance burden that grows with the codebase: new services need pipeline configuration, dependency updates break builds, test flakiness requires investigation, and environment configuration drifts. This work is not glamorous, it is rarely prioritized, and it blocks everyone when it goes wrong.

The investigation pattern for CI failures is particularly time-consuming: a developer has to read logs, identify the failing step, reproduce locally, fix the configuration, push, and wait for CI to run again. On a complex pipeline, this loop takes longer than the fix itself.

How it works with an agent fleet

An infrastructure agent is assigned CI and DevOps tickets, reads the CI logs via the gh CLI, and either fixes common failures or publishes a structured diagnosis to fabric.

agents:
  - name: devops
    role: infrastructure
    model: claude-sonnet-4-6
    subscribes_to: ticket_ready

The agent's prompt lives at .fleet/prompts/devops.md — Fleet resolves it by convention from the agent name, so there is no prompt: field in config. Note that Fleet does not publish CI status as a triggering event. CI status is read by the release gate (fleet release check) and by agents via the gh CLI; it does not by itself start an agent. Dispatch a DevOps agent by filing a ticket (or fleet task assign) so it can read the failure logs, classify the failure (flaky test, dependency conflict, environment issue), and fix it or escalate.

The fleet pattern

DevOps work is filed as tickets. When a ticket is ready, the watcher dispatches the infrastructure agent. For known failure patterns documented in the agent prompt, it attempts a fix and opens a PR. For novel failures, it publishes a diagnosis event that surfaces in fleet log for a human engineer to review. This keeps simple CI fixes moving while preserving human judgment for infrastructure decisions.

Guardrails that matter here

DevOps agent changes go through PR review — no direct pushes to CI configuration files
Agent prompt explicitly lists which categories of fix the agent is authorized to attempt
Novel failure categories that the agent cannot classify always escalate to a human via fabric event

Who this is for

Engineering teams where CI maintenance and DevOps work is handled reactively, consuming developer time when something breaks. Also useful for teams wanting to keep dependencies current without a weekly manual update cycle.

Frequently asked questions

Can the agent modify infrastructure as code (Terraform, Pulumi)?

Yes, if your IaC tools are installed in the environment and you authorize the agent to modify those files in the prompt. Infrastructure changes warrant careful human review, so the default should be PR-only with required human approval.

How does the agent get access to CI logs?

The agent uses the `gh` CLI to read GitHub Actions logs. It shells out to your CI provider's CLI for other systems. You configure the access credentials in the agent's tmux session environment.

Related use cases

AI Agents for Release Management →AI Agents for Dependency Upgrades →AI Agents for On-Call and Incidents →

Run your first agent fleet

One binary. Five minutes. See every agent, coordinate every handoff, and keep a full audit trail of what your fleet did.

See how it works Install Fleet