Every run answers three questions
What did it do, why did it do that, and what stopped it. A run that cannot answer all three is not something you can hand to a team.
Home / AI content operations
AI content operations, defined
Not "a button that writes a post". A repeatable loop — plan, produce, maintain, measure — that runs inside WordPress, records what it did, and stops for a person at the points that matter.
The four parts
Plan. A topic queue with priorities, languages and structures, plus a planner that looks for searches you already place for and do not win, and proposes what to write next.
Produce. Generation from your own prompt templates, through your own provider account, with research, SEO metadata, schema, FAQ and a featured image as part of the same pass. Output is a draft.
Maintain. A scan of what you have published, ranked by where an update would matter, proposed for approval, and undoable afterwards. This is the part that compounds.
Measure. Every AI call logged with tokens and estimated cost, attributed to the article that caused it. Search and analytics data imported alongside, so the cost of a page and its performance sit in one place.
What makes it operations rather than automation
Ceilings are frozen at the start
Steps, spend, tokens and a deadline are recorded onto the run when it begins, so changing a setting mid-flight cannot change what was authorised.
Approval is a person, always
Agents propose and stop. Nothing in the plugin can approve a plan, and handing that to another agent would remove the human while appearing to keep them.
There is a way back
The prior state of every post an agent touches is saved before the change, and restoring is itself reversible.
What the numbers include
Cost is read from the usage log rather than estimated from the text, so a run’s spend reflects what the provider actually billed for it. That figure covers every provider the run called, including one that accepted a request, consumed tokens and then failed.
This is the less flattering number and it is the correct one. A failover chain that tried two providers before succeeding spent money at both, and an operations report that quietly dropped the first attempt would understate the cost of exactly the conditions you most want to know about. It is also why the number of fallback attempts is capped rather than open ended. Details are in configuring AI providers.
What it deliberately does not do
A claim about what software will not do is worth more than another claim about what it will, so these are the boundaries rather than the features.
It does not publish behind your back. Generation leaves a draft. Publishing on a schedule is a setting you turn on, not a default you have to find and turn off.
It does not let an agent approve its own plan. Nothing in the plugin can sign off a proposal, and routing approval to a second agent would remove the person while appearing to keep them. Approvals and undo covers where the human sits.
It does not decide when to stop on its own judgement. A run ends at the first ceiling it reaches, tested before each step rather than noticed afterwards, and the reason is recorded on the run. See cost and run ceilings.
It does not back up your site. The state saved before a change covers what an agent can write to, which is the title, the content, the excerpt and the plugin’s own data. Restoring returns those. It is an undo, and calling it anything larger would be a promise it cannot keep.
Where to go next
If you are here to write: AI content writer for WordPress.
If you are here to fix what is already published: content refresh and the SEO audit.
If you want to know what the plugin will and will not do on its own: trust, safety and human control.
See how the workflow works
Every plan, every run and every change is recorded, with a way back from each.