AI content operations: what to automate and what a human must still click
AI content operations for client sites: what an agent should draft, tag and tidy, and the publish, delete and launch clicks a human must still make.
Once an agency has connected an agent to a client site and seen it draft a page in a minute, the next question comes quickly: what else can it do? The honest answer is a great deal. The more useful question is what it shouldn't do, and how to make sure it can't.
This post is about AI content operations on client sites, the ongoing work rather than the build. It splits that work into the jobs an agent does well, the clicks that stay human, and how to hold the line between them without relying on a well-worded prompt.
The jobs an agent does well
Most content work on a client site is repetitive, bounded and easy to check. That's exactly what agents are good at.
Drafting from source material. Turning a brochure, a set of interview notes or an old page into a structured draft. The source exists, so the agent is reorganising rather than inventing.
Bulk tagging and categorising. Applying categories to two hundred old posts, consistently, using rules you wrote down.
Alt text. Drafting descriptions for images that never had them. A person still checks them, but checking is faster than writing.
Finding stale content. Listing pages that mention last year's prices, an old address or a team member who left. The agent searches and reports, and someone decides.
Translation drafts. A first pass into another language, for a translator to review rather than write from scratch.
Imports. Running a content migration into staging, then reporting what landed and what didn't.
All of these produce something a person can review before it matters. That's the common thread.
The clicks that stay human
Some actions should always be a person's decision, whatever the agent is capable of.
Publishing to live. The moment content reaches the public site.
Deleting. Pages, documents, media, anything that's hard to undo or that other pages depend on.
Schema changes. Adding, removing or retyping fields on a live site changes what every editor sees and can break existing content.
Anything legal or about pricing. Terms, privacy policies, prices, guarantees, medical or financial claims. An agent can draft, but a person who's accountable signs it off.
These aren't things agents always get wrong. They're things where a mistake is expensive, public or someone's legal responsibility.
Enforce it structurally, not by prompt
The tempting approach is to write "never publish without asking" into the agent's instructions. That works until it doesn't. Instructions get lost in long sessions, misread or overridden by something in the content the agent is reading. A rule that only exists in a prompt isn't a rule.
The reliable approach is to make the dangerous action unavailable. On Contentive, that comes in four layers.
Content-only connections. A connection scoped to content has no publish, deploy, schema or settings tools at all. The agent can draft and edit. It can't ship, because the tool doesn't exist in its list.
Read-only connections. For audits, reports and stale-content sweeps, connect read-only. The connection can be narrowed further to one category of tools, and those filters only ever remove tools, never add them.
Staging by default. When a site has deployments and no environment is set, an agent's content writes go to staging. Production is reached only by a deliberate promote step. Staging vs production explains the model.
Drafts only in the Studio. The Content Assistant inside the Studio, the one the client uses, can read, search and draft. It obeys the signed-in person's own permissions and can't publish at all. It drafts, and a human clicks Publish.
Roles matter here too. An agent should get the narrowest role that does the job, like any new member of the team. CMS user roles and permissions has a mapping that works for people and agents alike.
Idempotency and review queues
Agents retry. A network blip, a timeout or a lost thread in a long session, and the agent sends the same create again. Without protection, the client gets two About pages and nobody notices until a customer does.
The fix is idempotency: every create carries a key, and a retry with the same key returns the original result instead of making a second one. If your tooling supports it, use it. If it doesn't, have the agent check for an existing item before creating one, and accept that it's a weaker guarantee. We wrote about why this matters in building a CMS an AI agent can actually drive.
The second habit is a review queue. Everything the agent drafts should land somewhere a person can see it as a list: drafts awaiting review, changes in staging awaiting promotion. A person works down the list and ships what's right. Nothing the agent made should reach the public without passing through it.
What it costs
Review becomes the bottleneck. An agent can draft fifty pages before lunch, and someone still has to read them. If you don't plan for that, either the review gets skipped or the drafts pile up.
Treat review as real work. Put it in the schedule, give it an owner and estimate it like any other task. A rough rule is that review takes longer than people expect, and longer still the first few times, while you learn what the agent tends to get wrong. That's the trade for the speed: you swap writing time for reading time, and reading time still has to be paid for.
Sort last month's tasks
List every content task on one client site from last month. Mark each one "agent", "agent drafts, human ships" or "human". The middle column is likely to be the biggest. Start there, with a content-only connection, and a review slot booked in the diary.