Prompt : do a research/search on AI Devops and tell me everything that you find online about it
ChatGPT Answer:
I did a fairly broad search across Google/DORA, Microsoft, AWS, GitHub, GitLab, Harness, CloudBees, Datadog, PagerDuty, Dynatrace, CNCF-adjacent material, research papers, practitioner discussions, courses, podcasts, and articles published through August 2026.
The most important finding is this:
“AI DevOps” is emerging as an umbrella category, but the industry has not standardized on that exact name.
What is becoming very real is the convergence of DevOps + Platform Engineering + SRE + AI agents + AI infrastructure.
I would map the online landscape like this.
I found four distinct meanings being bundled together.
| Area | What it means | Common terminology online |
|---|---|---|
| AI-assisted DevOps | Engineers use AI to do DevOps work faster | AI for DevOps, AI-assisted DevOps |
| Agentic DevOps | Agents perform multi-step DevOps work | Agentic DevOps, DevOps agents |
| Agentic Operations / SRE | Agents investigate/remediate production | AI SRE, Agentic SRE, Autonomous Operations |
| DevOps for AI | Build/run the infrastructure and delivery system for AI | AI Platform Engineering, MLOps, LLMOps, AI Infrastructure |
So I would not equate AI DevOps with AIOps.
A better conceptual model is:
AI DEVOPS
│
┌──────────────┴──────────────┐
│ │
AI FOR DEVOPS DEVOPS FOR AI
│ │
┌─────────┴─────────┐ ┌───────────┴──────────┐
│ │ │ │
AI-Augmented Agentic AI Platform AI Workload
Engineering DevOps Engineering Operations
│ │ │ │
Terraform Agents GPUs MLOps
Kubernetes Skills Kubernetes LLMOps
CI/CD MCP KServe AgentOps
Troubleshooting Tools vLLM Observability
Security Memory Kueue AI security
FinOps Policies DRA Sandboxing
That taxonomy fits what I found online considerably better than treating everything as “AIOps.”
This surprised me somewhat because it is no longer just smaller AI vendors using the phrase.
Microsoft published an entire “Getting Started with Agentic DevOps” series in April 2026.
Their definition is effectively:
AI agents work alongside engineering teams across the entire software development lifecycle and can perform tasks end-to-end rather than simply provide suggestions.
Microsoft also tags Azure SRE Agent material with #AgenticDevOps. (YouTube)
That makes the terminology substantially more credible than it was a year ago.
One of the strongest pieces of evidence for this shift is GitHub.
GitHub Agentic Workflows went into public preview on June 11, 2026. (The GitHub Blog)
Instead of writing only deterministic GitHub Actions YAML, you can define an agentic workflow using natural-language Markdown.
For example:
Traditional:
event
↓
fixed workflow
↓
script
↓
fixed outcome
versus:
Agentic:
event
↓
goal / instructions
↓
agent reasons about context
↓
uses tools
↓
evaluates result
↓
takes appropriate action
GitHub gives examples including:
- issue triage
- pull-request review
- CI failure investigation
- documentation maintenance
- repository reporting
- test adequacy review
And importantly, GitHub makes the distinction itself:
deterministic work → normal GitHub Actions interpretive/reasoning work → agentic workflows
That distinction is extremely useful.
Another interesting development:
GitHub Agentic Workflows supports multiple engines, including:
- GitHub Copilot
- Claude Code
- OpenAI Codex
- Gemini CLI
That means the underlying pattern is becoming:
DevOps Workflow
↓
Agent Harness
↓
Model
↓
Tools / APIs
rather than:
DevOps Workflow
↓
one proprietary AI model
This is an important architectural shift.
This is probably the strongest signal I found.
AWS, Microsoft, Datadog and PagerDuty now essentially offer an AI SRE / DevOps engineer.
AWS actually calls the product:
AWS DevOps Agent
It reached GA on March 31, 2026. (Amazon Web Services, Inc.)
AWS describes it as an always-available operational teammate spanning:
- release readiness
- production operations
- incident investigation
- root-cause analysis
- mitigation planning
- incident prevention
- CI/CD
- observability
- multicloud
- on-premises environments
The architecture is particularly interesting.
It learns:
resources
↓
relationships
↓
application topology
and correlates:
metrics
logs
traces
code
deployments
pipelines
incidents
to reason about failures. (AWS Documentation)
That is significantly beyond classic AIOps correlation.
In June 2026 AWS expanded DevOps Agent with:
- custom SRE agents
- user-defined Skills
- scheduled agents
- agent memories
- bring-your-own subagents
- MCP
- A2A
This example from AWS is telling:
Build an agent that checks your database every day, identifies slow queries, evaluates configuration and produces a health report.
Or:
Review the previous 24 hours of logs and identify anomalies.
That makes these systems look less like chatbots and more like a programmable operational workforce.
Azure SRE Agent became GA in March 2026.
Microsoft describes it as:
an AI-powered reliability assistant for diagnosing and resolving production issues, reducing operational toil and lowering MTTR.
Its capabilities include:
- continuous monitoring
- incident diagnosis
- root-cause investigation
- mitigation recommendations
- runbook execution
- skills
- subagents
- persistent context
- MCP connectors
- Python tools
- governance
- tool permissions
Microsoft says internally it had deployed 1,300+ agents, mitigated 35,000+ incidents, and saved 20,000+ engineering hours by the GA launch. These are Microsoft-reported figures rather than independently validated benchmarks, but they still indicate substantial internal deployment. (TECHCOMMUNITY.MICROSOFT.COM)
Datadog's Bits Investigation agent automatically investigates production failures.
It works over:
- metrics
- logs
- traces
- infrastructure metadata
- networking
- alerts
- service topology
and produces RCA. (Datadog)
Their architecture resembles a team of investigators rather than simple LLM log summarization.
Datadog is also investing heavily in evaluation of SRE agents, because normal unit testing doesn't capture whether an agent's investigation quality has silently degraded. (Datadog)
That brings up another important field:
We now need:
Agent
↓
tasks
↓
traces
↓
evaluation
↓
regression detection
↓
governed deployment
Essentially:
CI/CD for agents requires behavioural evaluation, not just unit testing.
PagerDuty launched its SRE Agent as a virtual responder.
Its system can use:
- incidents
- runbooks
- SOPs
- logs
- past investigations
- deployment events
- knowledge bases
to build an investigation. (PagerDuty)
It also keeps memory of previous incidents.
That means something like:
Incident #127
↓
investigation
↓
resolution
↓
learning captured
↓
operational memory
↓
Incident #183
PagerDuty is also adding Skills, which can contain instructions, scripts and resources for specialized operational tasks. (PagerDuty)
That is very close to the Claude/Codex/Hermes-style skills model spreading into operational platforms.
This is another very strong trend.
I found MCP appearing in:
- AWS DevOps Agent
- PagerDuty
- CloudBees DevOps Agent Kit
- Azure SRE Agent
- developer tools
- platform tooling
CloudBees, for example, has an open-source-style DevOps Agent Kit that turns Claude Code/Cursor into a DevOps specialist by connecting CI systems through MCP. (CloudBees)
The architecture increasingly becomes:
AI Agent
┌──────────┼──────────┐
│ │ │
MCP MCP MCP
│ │ │
GitHub Kubernetes Grafana
│ │ │
CI/CD Infra Telemetry
This could become extremely important for DevOps engineers.
Another major trend is a shift from:
pipeline = predetermined steps
toward:
pipeline =
deterministic steps
+
reasoning steps
Harness provides one of the clearest implementations.
Their Autonomous Worker Agents execute as pipeline steps.
Harness describes the historical progression as:
manual work
↓
scripts
↓
pipelines
↓
agentic pipeline steps
That is an important model.
I suspect this will become one of the defining patterns of Agentic DevOps.
This is worth mentioning because it uses the exact terminology you asked about.
Harness now documents a:
Harness AI DevOps Agent
It can create/manage:
- CI/CD pipelines
- pipeline stages
- infrastructure resources
- GitOps resources
- OPA/Rego policies
- environments
- connectors
- secrets
- troubleshooting
- failure analysis
Harness increasingly calls the broader platform Harness AI, where intelligence exists across the SDLC. (Harness Developer Hub)
So the exact term AI DevOps definitely exists commercially.
GitLab isn't leaning as heavily on the phrase AI DevOps.
Its terminology is:
- Duo Agent Platform
- Agentic AI
- Agentic Software Delivery
- intelligent orchestration
GitLab's direction is essentially agents across:
plan
↓
code
↓
test
↓
secure
↓
release
↓
operate
(GitLab)
So there is a naming battle going on.
CloudBees now has a full positioning category around:
Agentic DevOps
Their argument is interesting.
AI has removed the bottleneck in code creation.
The bottleneck moves downstream:
AI coding
↓
MORE CODE
↓
testing
security
review
CI
deployment
governance
operations
They call this code abundance. (CloudBees)
Their 2026 survey claims 81% of responding technology leaders reported production failures associated with AI-generated code. Again, this is vendor-sponsored research and should be interpreted accordingly, but the structural argument is important. (CloudBees)
This theme appears across DORA, Harness, GitLab, CloudBees and other sources.
AI dramatically increases developer throughput.
But:
coding velocity ↑↑↑
testing capacity →
security capacity →
review capacity →
platform capacity →
operational capacity →
Therefore the bottleneck migrates.
Harness calls this the AI Velocity Paradox. Their 2026 study argues delivery infrastructure isn't modernizing as quickly as code-generation capability. (PR Newswire)
GitLab makes a very similar argument around compliance and security burden. (GitLab)
This could be one of the strongest arguments for why DevOps becomes more important, rather than less important, in an AI-heavy engineering organization.
Google's DORA 2025 research surveyed almost 5,000 technology professionals.
Its central conclusion was:
AI acts as an amplifier.
It amplifies well-functioning engineering systems, but also amplifies dysfunctional ones. (Google Research)
Google reported:
- ~90% AI adoption
-
80% reporting productivity improvements
- 59% reporting improved code quality
- substantial distrust of AI-generated output
Most relevant to our discussion:
Google now explicitly says:
Platform engineering is the new foundation for AI.
A good internal platform provides the guardrails and shared capabilities necessary to use AI effectively at scale. (Google Cloud)
That is a very significant statement.
The Perforce State of Platform Engineering 2026 report surveyed 820 technology professionals.
They report:
- 66% using AI in infrastructure/configuration workflows
- platform-mature organizations being significantly more likely to use autonomous AI workflows
- 73% of mature organizations considering platform maturity important to AI success
(Perforce)
Again, survey methodology matters, but this reinforces the broader trend.
The new equation increasingly looks like:
Platform Engineering
+
AI Agents
+
Governance
=
AI-native engineering platform
You can roughly divide maturity into four stages.
Human drives everything.
Engineer
↓
AI
↓
suggestion
Examples:
- generate Terraform
- explain Kubernetes errors
- generate PromQL
- explain pipeline failures
- write Helm charts
- write scripts
AI has direct tools and context.
Engineer
↓
Agent
↓
repo / kubectl / terraform / cloud / telemetry
The engineer still orchestrates.
Agent performs multi-step workflows.
Goal
↓
Plan
↓
Gather context
↓
Execute
↓
Verify
↓
Iterate
↓
Report
Human approves important actions.
observe
↓
detect
↓
reason
↓
decide
↓
remediate
↓
verify
↓
learn
Humans become policy/exception/escalation handlers.
Most production systems appear to still sit somewhere between Levels 2 and 3, although vendors are pushing strongly toward Level 4.
I would draw this distinction very clearly.
Mostly:
Telemetry
↓
ML
↓
anomaly detection
event correlation
noise reduction
prediction
Think:
- clustering alerts
- detecting anomalies
- capacity prediction
- root-cause correlation
Dynatrace Davis is a classic example of this lineage. (Dynatrace Documentation)
Telemetry
↓
Agent
↓
reasoning
↓
tool use
↓
actions
↓
verification
The difference is agency.
AIOps tells you:
“CPU saturation correlates with this deployment.”
Agentic SRE can potentially:
investigate the deployment → inspect traces → query Kubernetes → identify a memory leak → generate a rollback plan → obtain approval → execute rollback → verify SLO recovery.
That is qualitatively different.
This isn't just vendors.
A 2026 research project called SREGym provides a benchmark for SRE agents using real cloud-native failure environments.
It includes 90 realistic SRE problems involving:
- different infrastructure layers
- noisy environments
- correlated failures
- complex failure modes
and found substantial performance differences among frontier agents. (arXiv)
Another research system, STRATUS, uses multiple specialized agents for:
- detection
- diagnosis
- mitigation
with explicit safety properties around remediation. (arXiv)
This means Agentic SRE is becoming an actual research area, not merely vendor branding.
When an agent can merely suggest Terraform, hallucinations are annoying.
When an agent can:
kubectl delete
terraform apply
aws ...
gh merge
helm upgrade
hallucinations become operational risk.
Therefore AI DevOps architecture increasingly includes:
Agent
│
┌───────┴────────┐
│ │
Context Tools
│ │
└───────┬────────┘
│
GOVERNANCE
│
┌────────┼────────┐
│ │ │
policy approval sandbox
│ │ │
RBAC human isolation
│ │ │
└────────┼────────┘
│
Audit
The recurring concepts online are:
- least privilege
- read-only defaults
- approval gates
- safe outputs
- sandboxing
- deterministic policy
- audit trails
- identity
- secret management
- token/cost budgets
- tool permissions
- rollback
- observability
- evaluation
GitHub explicitly defaults its agentic workflows toward restricted permissions and safe write mechanisms. (The GitHub Blog)
Azure similarly exposes deterministic allow/ask/deny tool controls. (Azure SRE)
One thing I found particularly interesting:
Skills are no longer just a Claude Code convention.
The same architectural idea is appearing in:
- PagerDuty SRE Agent Skills
- AWS DevOps Agent Skills
- agent frameworks
- GitHub agentic workflows
- internal enterprise agents
A skill generally becomes:
SKILL
├── instructions
├── scripts
├── references
├── tools
└── policy/context
This is potentially important because operations knowledge traditionally lived in:
runbook.md
script.sh
It may increasingly become:
skill/
├── SKILL.md
├── scripts/
├── policies/
└── references/
That is essentially a machine-operable runbook.
Old:
Incident
↓
Pager
↓
Human opens runbook
↓
Human runs commands
Emerging:
Incident
↓
Agent loads Skill / runbook
↓
Agent gathers evidence
↓
Agent executes deterministic tooling
↓
Human approves risky operations
The important insight here isn't that runbooks disappear.
They become executable context for agents.
A generic model knows:
kubectl rollout undo deployment/foo
But it doesn't inherently know:
WHEN is rollback permitted?
Which service?
Which region?
Which deployment?
What customer impact?
What SLO?
What database migration happened?
What compliance rule applies?
What cost threshold exists?
What is the blast radius?
Those are operations questions.
So the emerging DevOps skill is shifting from:
remembering commands
toward:
encoding operational judgment into systems that AI can safely execute.
That is a substantial change.
This is often called:
rather than AI DevOps.
This world includes:
- GPUs
- accelerators
- CUDA
- ROCm
- NVLink
- InfiniBand
- RDMA
- GPU partitioning
- MIG
- scheduling
- GPU Operator
- device plugins
- DRA
- Kueue
- gang scheduling
- topology-aware scheduling
- vLLM
- Triton
- TensorRT-LLM
- KServe
- Ray Serve
- SGLang
- MLflow
- feature stores
- model registries
- dataset/version management
- inference gateways
- prompt/version management
- tracing
- evaluation
- token monitoring
- caching
- routing
- tracing
- memory
- agent evaluation
- tool observability
- sandboxing
- permissions
- cost governance
- model supply chain
- prompt injection
- tool poisoning
- secrets
- sandboxing
- confidential computing
- data boundaries
And this is clearly becoming part of platform engineering.
Practitioner discussions increasingly describe AI Platform Engineer roles as deeply infrastructure oriented.
Interestingly, some people interviewing for MLOps/AI platform positions report interviews dominated by:
- Kubernetes
- infrastructure
- CI/CD
- debugging
- production reliability
rather than ML algorithms. (Reddit)
That makes sense.
A production AI platform is ultimately still a distributed system.
Traditional DevOps Engineer
│
│
▼
Platform Engineer
│
┌────┴────┐
│ │
▼ ▼
Agentic AI Platform
DevOps Engineer
│ │
└────┬────┘
│
▼
Production AI Engineer
And there is increasing overlap among:
- DevOps
- Platform Engineering
- SRE
- MLOps
- LLMOps
- AI Infrastructure
- AgentOps
Agents themselves now need delivery infrastructure.
Harness recently introduced what it calls the:
Agent Development Lifecycle
The idea is to bring traditional DevOps controls to agents:
agent development
↓
evaluation
↓
security testing
↓
policy
↓
deployment
↓
runtime observability
↓
audit
This is effectively:
DevOps for AI agents.
I think this category will become increasingly important.
Traditional observability:
metrics
logs
traces
AI systems add:
prompts
responses
tokens
models
tools
agent traces
retrieval
memory
evaluation
cost
So we get something like:
Infrastructure Observability
+
Application Observability
+
Model Observability
+
Agent Observability
This is likely to become another major responsibility for production AI/platform teams.
Traditional cloud FinOps asks:
What does this VM/container/database cost?
AI introduces:
GPU cost
token cost
model cost
inference cost
training cost
agent-loop cost
tool invocation cost
vector DB cost
Especially with autonomous agents, a poorly constrained loop can consume significant model/API/cloud resources.
So budgets become agent guardrails.
Agents dramatically expand the attack surface because they connect:
LLM
↓
tools
↓
credentials
↓
infrastructure
Important concerns now include:
- prompt injection
- malicious repository instructions
- MCP tool poisoning
- credential leakage
- unsafe shell execution
- privilege escalation
- supply-chain attacks
- exfiltration
- runaway operations
- malicious retrieved context
Therefore I expect DevSecOps to evolve toward:
governing AI actors in addition to human identities and service accounts.
Previously:
Engineer
↓
CLI
↓
API
Increasingly:
Engineer
↓
Agent
↓
CLI/API/MCP
Instead of:
kubectl get pods
kubectl logs ...
kubectl describe ...
kubectl get events ...you may say:
Investigate why checkout latency increased after the latest deployment.
And the agent executes the deterministic investigative tools.
That means the CLI does not disappear.
It becomes agent tooling.
This is an extremely important point.
It would be a mistake to replace:
terraform applywith an LLM improvising cloud provisioning.
The architecture that keeps appearing is:
LLM = reasoning
Scripts / APIs / Terraform / Kubernetes = execution
Or:
Agent decides WHAT
deterministic automation decides HOW
That's much safer.
GitHub explicitly recommends keeping deterministic build/test/deployment work as ordinary Actions and reserving agents for tasks requiring interpretation. (GitHub Docs)
HUMAN
│
Intent/Policy
│
▼
AI DEVOPS AGENT
│
┌──────────────────┼──────────────────┐
│ │ │
CONTEXT MEMORY SKILLS
│ │ │
└──────────────────┼──────────────────┘
│
REASONING
│
GUARDRAILS
│
┌─────────┼─────────┐
│ │ │
RBAC Policy Approval
│ │ │
└─────────┼─────────┘
│
MCP
│
┌─────────┬────────┼─────────┬────────┐
│ │ │ │ │
Git Terraform K8s Cloud Grafana
│ │ │ │ │
└─────────┴────────┼─────────┴────────┘
│
PRODUCTION
│
OBSERVABILITY
│
▼
AGENT
That is what I'd call the Agentic DevOps control loop.
Here is how I would rate the terminology after searching.
| Term | Current status |
|---|---|
| AIOps | Mature/established |
| MLOps | Mature/established |
| LLMOps | Established and growing |
| AI Platform Engineering | Strong emerging category |
| AI Infrastructure | Very strong category |
| AI for DevOps | Common descriptive phrase |
| AI-powered DevOps | Common marketing phrase |
| AI DevOps | Emerging umbrella / commercial term |
| Agentic DevOps | Rapidly growing, surprisingly credible |
| Agentic SRE | Strong emerging technical category |
| AI SRE | Becoming product category |
| AgentOps | Emerging but ambiguous |
| Autonomous Operations | Enterprise/vendor terminology |
There is overlap, but they aren't synonymous.
Focus:
How AI changes software delivery and infrastructure operations.
AI-assisted IaC
agentic CI/CD
AI incident response
AI SRE
agent governance
Focus:
How we build, ship and operate AI applications reliably.
AI infrastructure
MLOps
LLMOps
AI platform engineering
model serving
RAG
agents
security
observability
evaluation
cost
The intersection is large:
PRODUCTION AI
┌───────────────────────┐
│ │
│ AI Platform │
│ LLMOps │
│ AgentOps │
│ AI infrastructure │
│ │
┌────┴───────────────────────┴────┐
│ AI DEVOPS │
│ │
│ Agentic CI/CD │
│ Agentic SRE │
│ AI-assisted infrastructure │
│ AI-powered operations │
└─────────────────────────────────┘
Not necessarily as a brand—more as a conceptual distinction.
Traditional:
use AI inside an existing DevOps process.
AI-native:
redesign the process assuming agents are participants.
For example:
commit → build → test → deploy
commit → AI reviews → build → test → deploy
intent
↓
agent plans changes
↓
agent modifies code
↓
agent chooses/evaluates tests
↓
policy evaluates change
↓
agent investigates failure
↓
agent proposes remediation
↓
approval
↓
deployment
↓
agent monitors outcome
That's a much deeper transformation.
The market doesn't need another generic “AI can help DevOps” explanation.
There are hundreds of shallow pages saying:
AI can generate Terraform, summarize logs and optimize CI/CD.
That's already commodity content.
The interesting frontier is much narrower and deeper:
Agents operating:
- Kubernetes
- Terraform
- cloud
- CI/CD
- RCA
- remediation
- incident memory
- preventive reliability
- GPUs
- model serving
- Kubernetes
- LLM platforms
- sandboxing
- runtime security
- evaluation
- observability
- cost
- governance
How we safely ship enormous quantities of AI-generated code.
Those are substantive technical areas.
After looking across the market, I'd define it as:
AI DevOps is the application of AI and autonomous agents to software delivery and production operations, combined with the DevOps practices required to safely build, deploy, govern and operate AI-powered systems.
Or shorter:
AI DevOps = AI for DevOps + DevOps for AI.
And then:
AI FOR DEVOPS
────────────────────
AI-assisted engineering
Agentic DevOps
Agentic SRE
Autonomous Operations
DEVOPS FOR AI
────────────────────
AI Platform Engineering
AI Infrastructure
MLOps / LLMOps
AgentOps
AI security
AI observability
That taxonomy is defensible against what major vendors and researchers are actually doing today.
Given the direction of the market, I would not position “AI DevOps” simply as:
Learn how to use ChatGPT for DevOps.
That already feels dated.
There is a much stronger 2026 narrative:
alongside:
Together those become:
And the DevOps engineer evolves from someone who primarily writes automation into someone who:
- architects agent-accessible platforms
- converts operational knowledge into Skills
- defines guardrails
- provides deterministic execution primitives
- manages agent identity/access
- builds AI infrastructure
- monitors agents
- evaluates agent behaviour
- governs cost
- keeps AI systems reliable in production
That is much more technically credible than an “AI tools for DevOps” niche.
If I had to pick only a handful of things showing that this transition is genuinely happening, rather than being marketing noise, I'd pick:
- Google DORA: AI is an amplifier; platform engineering is foundational for AI adoption. (Google Research)
- GitHub Agentic Workflows: reasoning agents are now native to GitHub Actions. (The GitHub Blog)
- Microsoft Agentic DevOps + Azure SRE Agent: major cloud vendor explicitly adopting the terminology and product model. (Microsoft for Developers)
- AWS DevOps Agent: actual commercial DevOps agent across releases and operations, now supporting Skills, MCP and A2A. (AWS Documentation)
- Datadog/PagerDuty: autonomous SRE investigation becoming a mainstream observability/incident-response feature. (Datadog)
- Academic work such as SREGym and STRATUS: Agentic SRE becoming a research discipline with benchmarks and safety problems. (arXiv)
- Harness: explicit “AI DevOps Agent” plus autonomous agents embedded directly into delivery pipelines. (Harness Developer Hub)
So yes: there is a genuine category forming here. The terminology is fragmented, but the underlying technical movement is very real.
For your own direction, I think the most useful next step would be for me to do a second, deeper research pass specifically on the “AI DevOps / Agentic DevOps ecosystem” and produce a landscape of 50–100 actual companies, open-source projects, GitHub repos, products, people, newsletters/podcasts, courses, conferences, job titles and emerging technologies, grouped into AI for DevOps vs DevOps for AI. That would tell us whether AI DevOps / Agentic DevOps / Production AI is the strongest category to build your authority around.