When Content Needs a Human, and When It Doesn't
How the platform decides which objects an agent can publish unassisted and which ones require a human decision first.
3 min read By Platform Documentation Guide #Publishing
Two agents, two very different outcomes
An agent can create a page, adjust a navigation menu, or publish an article without asking anyone first. Try the same thing on a handful of other object types, and the system will refuse — not because something broke, but because that type is built to wait for a person. Knowing which is which, and why, saves a lot of confused troubleshooting.
Most types are autonomous; a few aren't
Every object type carries a publish policy, set per site and read from the live policy rather than guessed at run time. Most types are autonomous: an agent or editor with the right role can publish a valid, checked object directly. A smaller set of higher-stakes types needs a human's explicit approval before anything ships, whoever wrote the content. On this site those are the editorial voice and products.
An approval is pinned to one exact action
An approval is not a blanket yes that covers whatever comes next. It is tied to the specific object, the exact content revision that was reviewed, and the specific action being approved, which today is publishing now. It can also pin the images and the release behaviour that action uses. If the content changes after approval, or a different action is attempted, the approval no longer applies and has to be given again.
What an agent can and can't do alone
Practically, this means an agent working on an approval-gated object can still do almost everything up to the final step: draft it, validate it, check it against the site's own rules, get it into a reviewable state. What it can't do is make that last move alone. And even when a human executes that final publish, the platform still checks they're carrying the right role for it — authorship and authorization are checked separately.
Agent workflows carry their own switch
Workflows in CMS-Agent add a second layer. When a run starts, it records whether the site lets it publish on its own or needs an operator's go-ahead. A run that needs a go-ahead stops before publishing until an operator approves it, and a withheld decision always blocks. A flag passed in by whoever started the run cannot override that record.
Why the friction is there on purpose
The point isn't to slow an agent down for its own sake. It's to make sure the handful of changes that matter most — the ones a reader or a business decision actually depends on — always have a person's deliberate decision behind them, while everything else keeps moving at agent speed.