01A term newer than its parts
Agentic deployment is a fresh label on an old idea with one seat swapped. Deployment pipelines have existed for years; the change is who drives them. Instead of a person merging and clicking deploy, a coding agent finishes its work, commits, and pushes, and the push is the deployment. The pillar page shows the mechanics; this page is about what the swap means, because the term is doing heavy lifting in vendor slides right now and deserves a plain definition.
02Four claims, checked
Claim: it removes the human
False, and no host should want it true. Someone reviews the work, owns the account and answers for the site. The agent removes the typing, not the judgement.
Claim: it needs special infrastructure
Mostly false. The agent needs a repository it can push to and a host that deploys on push. If a pipeline demands an agent-specific SDK, ask who benefits from the lock-in.
Claim: it is riskier than human deploys
Neither safer nor riskier by nature. Agents and people both ship mistakes. Versioned releases with one-click rollback are what make either acceptable.
Claim: it ties you to one AI provider
False by construction. Any agent that writes files and drives git can operate the same pipeline. We build for all of them and depend on none.
03What actually changed
Three things, none of them magical. Speed: the gap between finished work and live work shrank from an evening of ceremony to the length of a push. Frequency: deploys stop being events and become punctuation, which quietly improves sites because small changes ship instead of queuing up. Accountability: every deploy maps to a commit, so who changed what has a mechanical answer.
The flip side is review discipline. An agent that pushes twelve times a day will eventually push something you would not have approved, and the defence is structural rather than hopeful: branch workflows, diffs you actually read, and rollback that works when you need it.
04The part we will not claim
It would be easy to say agentic deployment means the site runs itself. It does not. The agent cannot read the hosting portal, cannot decide your pricing page is out of date, and cannot care whether the contact form still works. Deployment was the automatable part; intent, taste and accountability were never deployable. Any vendor claiming otherwise is selling a demo. Keep a human who can answer for the site, and let the software do the parts software is good at. For how this sits in the wider practice, AI agent web publishing is the companion read.
05Agentic deployment questions
Is this the same as CI/CD?
It shares the shape: push, build, release. What changed is that the trigger is usually an agent finishing a task, and there is no pipeline file for you to maintain.
Can I require approval before every deploy?
Yes, structurally: the agent works on a branch, and what gets merged is what you have reviewed. Deploys follow the tracked branch, so the merge is the approval.
Which agents can do this?
Any that can write files and push: Codex, Claude Code, Copilot, Cursor, and chat sessions where you paste the commands yourself.
Does the host know an agent made the change?
The commit history says so, if your agent signs its work. The deploy pipeline treats every push identically either way.
Build it with your AI. Host it here.
Deploys on every push, from Australia, with nothing to maintain.