You don’t need Temporal. You don’t need Prefect. You don’t need to migrate to a new orchestration platform to start running AI agents in your delivery pipeline — you need a YAML file and a clear mental model.
The misconception is understandable. The AI agents space is thick with vendors promising purpose-built orchestration infrastructure, and most articles about AI agents CI/CD pipeline integration are either vague trend pieces or deep dives into deploying AI products via CI/CD — which is a completely different problem. Neither helps you figure out what to actually add to your `.github/workflows` folder on Monday morning.
This guide cuts through that noise. You’ll walk away with a concrete decision tree, copy-paste workflow snippets for GitHub Actions, GitLab CI, and Jenkins, and a clear safety model for keeping agents inside appropriate guardrails — all without adopting a single new platform.
The Two Different Problems People Mean When They Say ‘AI Agents in CI/CD’
Before writing a single line of YAML, you need to separate two problems that sound identical but require completely different solutions.
Problem A: Shipping an AI agent product via CI/CD. You’ve built a chatbot, an autonomous coding assistant, or an LLM-powered API. Your pipeline tests it, packages it, and deploys it — just like any other software artifact. The “AI” part is what you’re shipping, not the pipeline doing the shipping.
Problem B: Adding AI agents into your CI/CD pipeline. The pipeline itself becomes agentic. An LLM-powered step diagnoses a build failure, reviews a pull request, or writes a deployment summary. The AI agent is part of your delivery infrastructure.
Almost every competing article conflates these two. If you’re reading this, you almost certainly want Problem B — and the good news is that every major CI platform already has the primitives you need to make it work today.
What Your Pipeline Already Has That Makes This Possible
GitHub Actions now executes over 6 million workflows every single day, up 40–55% year-over-year — and those workflows already know how to run arbitrary containers, call external APIs, handle secrets, and gate on human approvals (GitHub platform data, March 2026). The infrastructure for agentic steps isn’t something you need to build. It’s already there.
The same is true for GitLab CI and Jenkins. Every modern CI runner can:
- Execute a Python or Node.js script in an isolated container
- Read and write to a repository via a scoped token
- Trigger on any event — push, PR, schedule, manual dispatch
- Wait for a human approval before proceeding to the next stage
- Expose structured output as artifacts, annotations, or comments
That’s the full surface area you need to embed an AI agent into a pipeline. The only missing piece is calling an LLM API and wiring its output to something useful. That’s exactly what the tools below handle.
Option 1 — GitHub Agentic Workflows: Define Agent Jobs in Markdown, Run in GitHub Actions
On February 13, 2026, GitHub shipped Agentic Workflows in technical preview. The core idea is clean: you define agent behavior in a Markdown file inside a `.github/agents/` directory, and GitHub runs it as a native Actions job — no new infrastructure, no external orchestration layer.
Here’s what a minimal agent definition looks like:
“`markdown
# CI Failure Diagnosis Agent
Role
You are a CI debugging assistant. When a workflow job fails, analyze the
logs and open a GitHub Issue with a root-cause hypothesis and suggested fix.
Tools
- read_workflow_logs
- create_issue
Trigger
On: workflow_run (conclusion: failure)
Output
A GitHub Issue labeled `ci-diagnosis` with structured markdown output.
“`
The Actions workflow that wires this up is straightforward:
“`yaml
# .github/workflows/diagnose-on-failure.yml
name: AI Failure Diagnosis
on:
workflow_run:
workflows: [‘CI’]
types: [completed]
jobs:
diagnose:
if: ${{ github.event.workflow_run.conclusion == ‘failure’ }}
runs-on: ubuntu-latest
permissions:
issues: write
actions: read
uses: ./.github/agents/diagnose-failure.md
“`
Two things to notice. First, the `permissions` block is explicit and minimal — the agent can write issues and read action logs, nothing else. Second, the agent creates an issue for human review; it does not self-merge, self-deploy, or modify code without approval.
GitHub Agentic Workflows is still in technical preview as of April 2026, which means the API surface can change. For production workloads today, the Cicaddy approach below is more stable.
Option 2 — Cicaddy: A Platform-Agnostic Agent Framework for GitLab CI, Jenkins, and Beyond
If you’re on GitLab, Jenkins, or a multi-platform shop, Cicaddy is the practical answer. It’s an open-source Python framework that runs LLM-powered agentic tasks inside any existing CI pipeline job, connecting to MCP (Model Context Protocol) servers to access tools like code search, issue trackers, and external APIs.
Red Hat deployed a production Cicaddy-based system as GitLab CI pipeline templates — teams adopt it by adding a single `include` statement with no agent infrastructure to provision (Red Hat Developer, March 2026).
Here’s a Jenkins Pipeline snippet using Cicaddy to run a PR review agent:
“`groovy
// Jenkinsfile
pipeline {
agent any
stages {
stage(‘AI PR Review’) {
when { changeRequest() }
steps {
sh ”’
pip install cicaddy
cicaddy run \
–agent agents/pr-review.yaml \
–input pr_diff=$CHANGE_ID \
–output-format github-comment \
–token-budget 50000
”’
}
}
}
}
“`
The `–token-budget` flag is your cost control lever. More on that shortly.
For GitLab CI, the same agent runs via an `include`:
“`yaml
# .gitlab-ci.yml
include:
- project: ‘your-org/cicaddy-templates’
ref: main
file: ‘/agents/pr-review.yml’
pr-review:
extends: .cicaddy-agent
variables:
AGENT_FILE: agents/pr-review.yaml
TOKEN_BUDGET: ‘50000’
OUTPUT_FORMAT: merge-request-comment
rules:
- if: $CI_PIPELINE_SOURCE == “merge_request_event”
“`
Cicaddy’s MCP integration means the agent can reach out to external tools — Jira, Slack, Datadog — through a structured protocol, without you writing bespoke API integration code for each one.
Option 3 — GitLab Duo Agent Platform: Agentic Automation Built Into Your Existing .gitlab-ci.yml
If your team runs GitLab, the path of least resistance is the GitLab Duo Agent Platform, which became generally available in January 2026. It extends GitLab’s DevSecOps platform with agentic automation without any pipeline migration.
The key advantage over Cicaddy on GitLab is native integration with GitLab’s security scanning, merge request workflows, and compliance frameworks. If you’re in a regulated environment and already rely on GitLab’s audit logs and approval rules, Duo Agent Platform slots in cleanly.
A scheduled daily service-health report looks like this:
“`yaml
service-health-report:
stage: report
image: gitlab-agent-runner:latest
script:
- gitlab-duo agent run \
–agent-config agents/health-report.yaml \
–services “$MONITORED_SERVICES” \
–output merge-request-draft
rules:
- if: $CI_PIPELINE_SOURCE == “schedule”
environment:
name: monitoring
“`
The `–output merge-request-draft` flag is deliberate: the agent produces a draft MR with its findings rather than taking any direct action. A human approves and merges. This is the correct default mental model for any agentic CI output.
Three Use Cases You Can Ship This Week
Theory only gets you so far. Here are three concrete patterns, ordered from lowest to highest complexity.
1. CI failure diagnosis agent
Trigger: `workflow_run` on failure (or `after_script` in GitLab)
What it does: Reads the failed job’s logs, identifies the likely root cause, and opens a labeled issue or MR comment with a structured analysis.
Value: Cuts the average time-to-understand a flaky CI failure from 15 minutes of log spelunking to 2 minutes of reading a summary. A great first agent because its output is purely informational — zero blast radius if it’s wrong.
2. Automated PR review agent
Trigger: `pull_request` / `merge_request` event on open or update
What it does: Reviews the diff for common anti-patterns, security issues, or style violations. Posts a structured review comment. Does not approve, request changes, or block the PR — it leaves all of that to a human reviewer.
Value: Catches obvious issues before human reviewers spend time on them, focusing review energy on architectural and logical concerns.
3. Scheduled service-health report agent
Trigger: Daily schedule (e.g., `0 8 *`)
What it does: Queries service metrics, error rates, and recent deployment logs. Produces a morning briefing as a draft PR or Slack message, flagging anything that warrants human attention.
Value: Surfaces signal that gets lost between alert fatigue and manual log reviews, without paging anyone at 3 a.m.
All three share the same pattern: the agent outputs a recommendation or draft, and a human decides what to do with it.
The Safety Layer You Cannot Skip: Permissions, Sandboxing, and the Human Approval Gate
Only 11% of enterprise engineering teams have AI agents fully in production at scale; 25% are still in pilot. The gap is primarily about trust, observability, and guardrails — not capability (Opsera 2026 Benchmark Report). Getting the safety model right is what separates a proof of concept from something you’d stake production on.
Every agentic CI job needs four primitives:
1. Sandboxed execution. Run agent jobs in ephemeral containers with no persistent state. Use `runs-on: ubuntu-latest` (ephemeral) rather than self-hosted persistent runners for agent steps. The container is destroyed after each job — no leftover credentials, no cross-run contamination.
2. Read-only repository access by default. Set `permissions: contents: read` in GitHub Actions. In GitLab, use a deploy token scoped to `read_repository` only. The agent should never have write access unless the specific use case requires creating a branch or draft MR — and even then, it should never have merge permissions.
3. Structured outputs for human review. Never let an agent write a final commit, merge a PR, or trigger a deployment directly. The correct pattern: agent produces a draft, artifact, issue, or comment → human reviews → human triggers the downstream action.
4. Scoped secrets and permissions. Create a dedicated service account or bot token for agent jobs with the minimum permissions needed. Use GitHub’s `secrets` context or GitLab’s masked/protected CI variables. Rotate tokens on a schedule. Never use a personal access token with broad repository access.
Configuring the human approval gate
For any agentic step that produces output a human needs to review, use your platform’s native approval mechanism:
“`yaml
# GitHub Actions — require human approval before applying agent output
jobs:
run-agent:
runs-on: ubuntu-latest
permissions:
contents: read
issues: write
steps:
- name: Run diagnosis agent
run: cicaddy run –agent agents/diagnose.yaml
apply-recommendation:
needs: run-agent
runs-on: ubuntu-latest
environment: production # <-- requires reviewer approval in GitHub
steps:
- name: Apply recommendation
run: ./apply-recommendation.sh
“`
- GitHub Actions: `environment` protection rules with required reviewers
- GitLab CI: `when: manual` on the downstream job, or protected environments
- Jenkins: the `input` step with a configurable timeout
This pattern ensures agents remain recommendation engines, not autonomous actors in your production pipeline.
How to Choose the Right Approach for Your Stack
Here’s the decision tree:
“`
Are you on GitHub?
├── YES → Use GitHub Agentic Workflows (technical preview)
│ For production stability today: Cicaddy on GitHub Actions
└── NO
├── Are you on GitLab?
│ ├── Need deep security/compliance GitLab integration?
│ │ └── YES → GitLab Duo Agent Platform
│ └── Want platform-agnostic portability or full MCP tool access?
│ └── YES → Cicaddy
└── On Jenkins or multi-platform?
└── Cicaddy (runs inside any pipeline job)
“`
A quick summary of the tradeoffs:
| Tool | Platform | Stability | MCP Tool Access | Setup Complexity |
|—|—|—|—|—|
| GitHub Agentic Workflows | GitHub only | Technical preview | Limited | Very low |
| Cicaddy | Any CI platform | Stable (Red Hat production) | Full MCP | Low |
| GitLab Duo Agent Platform | GitLab only | GA (Jan 2026) | GitLab-native | Low |
A realistic note on cost
Token costs are real and consistently ignored in other guides. A PR review agent on a busy repository running on every push can consume 500K–2M tokens per day depending on diff size and model choice. At current frontier model rates, that’s roughly $1.50–$6.00 per day for that single agent — manageable, but worth modeling before you enable it on every branch.
Cicaddy’s `–token-budget` flag caps tokens per run. GitHub Agentic Workflows inherits GitHub Actions billing (runner minutes) plus whatever LLM API costs the agent incurs. GitLab Duo Agent Platform usage counts against your GitLab Duo seat licenses. Set budgets before you go wide, not after your first surprise invoice.
Runner costs are typically negligible for agent jobs — they’re fast LLM API calls, not long compilation steps. Token costs are where the real scaling variable lives.
Your AI Agents CI/CD Pipeline Starts Here
Adding AI agents to your AI agents CI/CD pipeline doesn’t require a new platform, a new vendor, or a migration project. It requires understanding which problem you’re actually solving, picking the tool that fits your existing platform, and applying four non-negotiable safety primitives from day one.
Start with the CI failure diagnosis agent — it’s the lowest-risk entry point, produces immediate value, and has zero blast radius if the agent output is imperfect. Get comfortable with the output quality, tune the token budget, then expand to PR review and scheduled reports. The infrastructure you already have is more capable than most vendors want you to believe.
Pick your platform from the decision tree, drop in the relevant snippet, and run it on your next failed build. That’s your week-one win.