The agent ships as a plugin, so it runs inside WordPress's own permission model rather than beside it. Every write is made as a user with capabilities and checked with current_user_can, which means the agent cannot do anything an editor could not do.
01Use
Each one names the REST routes it touches and the decision that waits for a person. WordPress makes that second part easy: draft and pending are a review queue you already run.
Drafts posts from your briefs, adds internal links, assigns categories and tags, and refreshes posts that have gone stale.
Adds order notes, moves status where the rules are clear, and prepares refunds for someone to review rather than issuing them.
Classifies incoming comments and form submissions, routes the real ones to the right person, and holds the rest.
02Wire
The agent lives in a plugin of its own and hooks WordPress the way any plugin does. Nothing in core and nothing in your theme gets patched.
add_action and add_filter hooks instead of patching core or a theme, so an update does not undo it.current_user_can, so the agent inherits a permission model you already trust.03Gate
Pending posts, held comments, and a run log screen the plugin adds. There is nothing new to learn, and nothing publishes itself.
Posts the agent writes land at draft or pending. Your editors approve them in the post list, the same screen and the same click as today. If nobody looks, nothing goes live.
Comments and form submissions the agent is not sure about go to hold, where a moderator sees them. Deletion is never an agent action.
Every write is made as a user and checked with current_user_can before it runs. Take a capability off the agent's role and the write stops, without a code change.
The plugin adds a run log screen to the admin. Each run records what it read, what it wrote and which gate it stopped at, so a question about the agent's behavior has an answer on the site itself.
How we build the agent itself, the platform we most often pair with WordPress, and the supporting work around it.
04Asked
No, because the agent does not run inside your visitors' page loads. It works in background runs against the WP REST API, and the plugin adds no scripts or styles to the front end. Scheduling is the one thing to watch: WP-Cron only fires when someone visits the site, so for anything that has to run on time we say plainly that you need a real system cron and we set the plugin up to use it.
Usually, yes. The agent writes through the WP REST API and hooks in with add_action and add_filter, so anything stored as a post, a term, a taxonomy or post meta is reachable. Builders that keep layout in their own tables need a mapping first, and we check that before we scope the work. We do not patch core, your theme or your builder.
The plugin is activated per site and the agent runs as a user of that site, so its capabilities stop at that site's boundary. A run that has to cross sites is a separate job we scope on its own, because an agent holding network level privileges is exactly what the capability model exists to prevent.
Name one task in your admin that eats a person's week. We will tell you which REST routes it touches, which capability it needs, and where the approval has to sit.