Why the future of DevOps isn’t just about what AI can do, but what it’s authorized to do.
Agentic DevOps is not about teaching agents to act faster. It is about teaching them when not to act.
Like most engineers, I’ve had moments where I trusted automation a little more than I should have.
One of those moments came when I set up an auto-fix bot for a CI pipeline.
It found a race condition and “fixed” it by removing the lock. The deadlock that followed made its way into production and surfaced at 2am on a Friday.
The AI wasn’t really the problem. It did exactly what I asked it to do.
The problem was that I never defined what a safe fix looked like.
And the agent had no way to challenge that assumption.
AI-assisted DevOps is not Agentic DevOps
People use “AI-assisted DevOps” and “Agentic DevOps” interchangeably.
They are not the same thing.
AI-assisted DevOps is a text generator with a human execution layer.
- Copilot suggests. You run.
- Claude Code proposes. You accept.
- The agent generates. The human ships.
Agentic DevOps is an execution model.
- Agent scaffolds infrastructure.
- Provisions identities.
- Scans code, opens issues, proposes fixes.
- Cleans up when the work is complete.
You state the outcome. The agent executes the workflow.
That is the pattern I have been exploring withSnowflake CoCo.
CoCo gives me an AI-native execution layer. The CI/CD workflow described here is an implementation pattern:
- Use intent to define the desired outcome
- Use policy to define the agent’s authority
- Use human review when the agent is not confident enough to act.
The important part is not the repository.
The important part is the operating model.
What changed when I applied IDD to CI/CD
I have written before about Intent-Driven Development. The idea is simple: structure prompts around outcomes instead of procedural steps.
The four blocks are:
- Goal
- Requirements
- Constraints
- Output
The agent figures out how.
You define the what and the why.
When I started building this CI scaffold, the scan prompt initially said something like:
Find bugs and open issues
Simple. Direct. Not enough.
The agent found bugs.
It opened issues.
It also tried to auto-fix a 400-line authentication module with high confidence and wrong assumptions.
The problem was the missing constraint.
“Fix my bugs” carries an implicit constraint : “Do it safely.”
IDD forces that constraint into the prompt and the workflow.
Not as a comment.
Not as a README note.
As a policy that the agent reads before acting.
The Decision Tree
The constraint became a scoring system.
Before opening any issue or proposing a fix, the scan agent evaluates three dimensions.
- SEVERITY : how dangerous the issue is if left unfixed.
- COMPLEXITY : how much the fix touches.
- CONFIDENCE : how certain the agent is that its fix is correct.
Then it routes the issue.
The governance loop: Mapping an agent’s confidence against its authorized ceiling of action to determine when a human must step in.
conservative (default)
auto-fix only if severity=low AND complexity=low AND confidence=high everything else -> needs-review
aggressive
auto-fix if confidence >= medium
off
never auto-fix, always needs-review
This is not a magic rules engine.
It is a simple judgment model with explicit inputs.
The race-condition fix from my Friday story would have scored:
severity: high
complexity: high
confidence: medium
route: needs-review
A human would have seen the issue, read the context, and decided whether to run the fix.
That is the difference I care about.
An agent that always acts is dangerous.
An agent that never acts is just autocomplete with a workflow file.
The useful middle is an agent that can decide when not to act.
Intent defines the goal. Policy defines the boundary.
Infrastructure-as-Intent does not mean the agent gets unlimited freedom.
It means the desired outcome is expressed clearly enough for the system to act.
But action still needs a boundary.
For this workflow, that boundary lives in configuration.
For example a policy document could be:
fix_mode:
max_auto: conservative
The intent says what the agent should achieve.
The policy says how far the agent is allowed to go without human review.
Change it through a PR.
The commit history becomes the governance record.
When your security team asks who allowed the agent to auto-fix beyond low-risk changes, you do not need to reconstruct a Slack thread.
You show the PR that changed conservative to aggressive , the reviewer, and the merge date.
That is the record I want Agentic DevOps systems to preserve.
Not just what the agent did.
Who allowed it to act at that level.
For runtime experiments, there can still be a variable override.
Runtime overrides are necessary, but they introduce drift. Every temporary experiment requires a sunset tag and a hard expiration date. If the override outlives its sprint, the agent must revert to the version-controlled default and trigger a CI alert. This is how we ensure ‘temporary’ hacks don’t calcify into unreviewed permanent policy.
Maybe the team wants to try aggressive mode for a sprint. Set the variable. When the experiment ends, delete it. The policy falls back to the reviewed default.
Every scan run should log the active ceiling and its source.
Fix ceiling: conservative
Source: repository configuration
The point is not to slow the agent down.
To make authority visible, embed the active ceiling status directly into your PR templates. Don’t just show the outcome of the agent’s work; show the governance state that authorized it. A persistent ‘Governance Status’ block is the audit evidence your security team actually wants.
This is the engine of CoCo Automations. As agents move from reactive tasks to proactive operations — like daily drift detection — the ‘conservative’ vs. ‘aggressive’ dial becomes our primary safety check. Setting these modes at the repository level ensures that even when the agent operates autonomously, it is tethered to a pre-approved ceiling of authority.
Visibility alone, however, is not a substitute for intervention.
Human override should always exist
The needs-review route is not a dead end.
It is the place where human judgment enters the workflow.
A developer can review the issue, inspect the context, and decide whether the agent should proceed with the fix.
Even for a complex issue.
Even for a low-confidence issue.
The override exists by design.
Agent judgment is the default.
Human judgment is the final decision.
agent proposes -> human decides -> agent executes
A system where the agent can never be overridden is broken.
A system where the agent always acts is also broken.
The override is the acknowledgement that developers know their codebases better than any model.
They should always have the last word.
This is where Agentic DevOps becomes useful.
The agent is not replacing the engineer. It is doing the execution work after the engineer has set the boundary.
ICR did not drop. It got smarter.
The Intent Compression Ratio of this scaffold workflow is 48.
One conversation instruction.
48 distinct state-changing operations.
That number did not change when I added the decision tree.
What changed is that each operation now carries a risk assessment.
The agent that runs 48 operations conservatively is more useful than the agent that runs 48 operations blindly.
The metric I track is not only ICR.
I also track the agent-raised PR merge rate:
The percentage of agent-created PRs that engineers merge without modification.
That number measures trust.
A team at 60%+ merge rate has accepted the agent as part of the workflow.
A team at 10% has a noisy bot.
Same ICR. Different values.
Trust takes time.
The conservative ceiling builds it.
What I mean by Agentic DevOps with CoCo
Not : replace engineers with AI.
Yes : give engineers a CI pipeline that knows its limits.
The value is not faster code generation by itself.
Faster generation without better control creates faster review queues and faster mistakes.
The value is compressing the loop.
Where intent meets infrastructure: Integrating autonomous agents into traditional CI/CD loops.
That compression matters because the agent is calibrated.
It does not open a PR for every needs-review issue.
It does not silently change complex code because the prompt sounded confident.
It does not confuse autonomy with permission.
Agentic DevOps means the agent can say:
I am not sure enough to act on this one.
That is not a limitation.
That is the design.
Why this matters
Most AI engineering conversations still treat autonomy as the finish line.
Can the agent write the code?
Can it open the PR?
Can it deploy the change?
Those are useful questions, but they are not the first questions.
The first question should be:
What has to be true before the agent is allowed to act?
That is where intent becomes operational.
That is where policy becomes part of the development loop.
That is where CoCo, CI, and IDD start to become more useful than a smarter autocomplete.
Agentic DevOps is not about giving agents unlimited power.
It is about giving them:
- explicit intent
- bounded authority
- visible decisions
- human override
That is the CI agent I want.
One that knows how to act.
And one that knows when not to.
By making agentic authority visible and configurable, we are not just automating tasks; we are codifying intent. This is the final piece of theIntent-Driven Development puzzle: ensuring that the ‘evidence’ generated by our agents maps directly back to human-authorized intent.
Implementation References
The article describes the Agentic DevOps pattern rather than depending on a single repository. The following public references provide implementation context for the GitHub, GitLab, and Snowflake CoCo workflows discussed in this post.
CoCo skill
Snowflake-Labs/devops-snowflake-coco-agents
CoCo skill implementation for the DevOps agent workflow. This provides the core skill context behind scaffold, scan, issue routing, fix behavior, and the human-review loop.
GitHub template
Snowflake-Labs/github-coco-agent
Template for exploring CoCo-driven Agentic DevOps workflows with GitHub Actions. It shows how the pattern maps to GitHub-native CI/CD, repository configuration, issue routing, and PR-based governance.
GitLab template
snowflake-dev/gitlab-coco-agent
Template for exploring the same Agentic DevOps workflow in GitLab CI. It shows that the pattern is not tied only to GitHub Actions and can be adapted across CI/CD systems.
Further Reading
This post continues my Intent-Driven Development series:
- Infrastructure-as-Intent: The Field Velocity Blueprint
- The Ghost in the Machine: Why AI Needs the Spirit of UML
- Intent-Driven Development: The Shift Developers Can’t Ignore
- Intent Compression Ratio: Measuring the Power of Intent
- ICR and Token Economics
- From Intent to Evidence: Why AI Skills Need Tests
For related thinking, Andrew Ng’s recent writing on Three Key Loops for Building Great Software and his Agentic AI course reinforce the same direction: reliable AI systems are built around iterative loops, not one-shot prompts.
That is the bridge this article explores.
Intent gives the loop purpose.
Evidence gives the loop trust.
Policy gives the loop boundaries.
Human review gives the loop judgment.
Disclosure: Feature image generated with AI and reviewed by the author.
About the Author
Kamesh Sampath is a Lead Developer Advocate at Snowflake, author, and long-time open-source contributor with 25+ years in enterprise software. He works across data engineering and AI with developer communities, helping practitioners turn modern data platforms into systems that hold up in production.
Through talks, writing, and hands-on demos, Kamesh makes cloud, data, and AI topics easier to understand and apply — grounded in real-world constraints. His sessions mix deep technical detail with practical patterns that developers and data teams can apply right away.
Lately, he’s been speaking about Apache NiFi (Snowflake Openflow), AI (Snowflake Cortex), and PostgreSQL.
He believes technology becomes powerful when it is shared, taught, and built together.
Top comments (0)