What is agentic DevOps? A short, unhyped definition

"Agentic DevOps" is doing a lot of work in a lot of marketing copy right now. Underneath it there is a real and fairly narrow idea, and it's worth separating from the two things it gets confused with.

The three tiers

Tier 1 — Suggestion. You ask a model for a Dockerfile or a GitHub Actions workflow, it writes one, you paste it in. The model produces text. You do every action. This is most people's daily AI use, and it is genuinely useful.

Tier 2 — Assisted execution. The model can run commands, but only ones you name. You say "run the build," it runs the build. It's a shell with better autocomplete. The loop is still driven by you.

Tier 3 — Agentic. The model is given a goal ("deploy this repo"), and it decides the intermediate steps itself: inspect the repo, identify the services, pick targets, sequence the work, run it, read the failures, adjust. You approve, you don't dictate.

Agentic DevOps is tier 3, and the meaningful difference is not autonomy for its own sake — it's that the model owns the plan, not just the typing.

Why the plan is the hard part

Deploying a single Next.js app is not hard. vercel deploy and you're done. Nobody needs an agent for that.

The work that actually eats an afternoon is the shape of a real repo: a web app, an API, a worker, a Postgres instance, and a cron job. Each one wants a different target. The API needs the database URL before it can start. The web app needs the API's URL. The worker needs the same queue credentials as the API but shouldn't be publicly routable. Order matters, and getting it wrong means a half-deployed system and a confusing error.

That dependency graph is exactly the kind of thing a model is good at — it's reading, inference, and sequencing over a codebase. It's also the part that's tedious enough that people put deploys off for weeks.

What "agentic" must not mean

The failure mode is obvious: an agent that can do anything is an agent that can delete anything. Autonomy without constraint is not a feature, it's an incident waiting for a trigger.

A serious agentic system draws three lines:

• Reads are free, writes are gated. Scanning your repo, listing your projects, reading logs — no approval needed, and the agent needs all of it to plan well. Deploying, provisioning, deleting, changing DNS — each one shown in full and held until you approve.
• The agent proposes; you dispose. The unit of approval is the concrete command, not a vague intention. "Deploy the API" is not reviewable. vercel deploy --prod --scope acme is.
• Credentials are out of scope for the model. The agent should know a token is needed, not what it is. Secrets live in the OS keychain and get substituted into the child process at execution time — the plan carries a reference, never a value.

Take any of those three away and you have a tier-3 system with tier-0 safety.

Local vs. hosted

The other axis is where the agent runs. A hosted agentic platform needs your credentials on its servers, which means you're trusting a vendor with the keys to your infrastructure and betting on their breach record.

A local harness runs on your machine and against your own accounts. The model provider gets prompts; your infrastructure credentials never leave your laptop. It's slower to set up than a SaaS dashboard and considerably harder to have a bad week over.

Neither is wrong for every team. But "agentic" and "hosted" get bundled together in most products, and they're independent choices.

Is it worth it?

Honest answer: it depends on how often your deploys are novel.

If you deploy the same three services through the same pipeline every day, a CI config beats an agent — determinism wins on repetition, and you already paid the setup cost.

Agentic DevOps earns its keep on the first deploy, on side projects, on prototypes, on the repo you cloned an hour ago, and on the multi-service setup you'd otherwise spend a Saturday wiring together. That's the gap: not replacing your pipeline, but getting something to production before a pipeline exists.

VibeOps is one take on it — a local harness, gates on every write, and secrets the model never sees.