# Agents inside your WordPress site > We build WordPress agents that ship as a plugin, run inside your own capability model, and leave every post at draft or pending until an editor publishes it. Canonical page: https://aispeedforce.com/platforms/wordpress/ Last updated: 2026-08-23 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. ## Three jobs we build most often 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. ### Content operations Drafts posts from your briefs, adds internal links, assigns categories and tags, and refreshes posts that have gone stale. - **Touches**: /wp/v2/posts, /wp/v2/terms, /wp/v2/media - **Human gate**: Publishing. Posts stay at draft or pending until a person moves them. ### WooCommerce order work Adds order notes, moves status where the rules are clear, and prepares refunds for someone to review rather than issuing them. - **Touches**: /wc/v3/orders, /wc/v3/products, /wc/v3/customers - **Human gate**: Refunds, and any status change past processing. ### Comment and form triage Classifies incoming comments and form submissions, routes the real ones to the right person, and holds the rest. - **Touches**: /wp/v2/comments, form plugin tables - **Human gate**: Deletion. The agent holds, it never removes. ## What it connects to 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. - **WP REST API**: The read and write surface, called through tools scoped one per operation rather than one key that can do everything. - **Custom plugin**: Where the agent lives, using `add_action` and `add_filter` hooks instead of patching core or a theme, so an update does not undo it. - **WP-Cron**: Schedules background runs. WP-Cron only fires on traffic, so we say plainly when a job needs a real system cron instead. - **Capabilities**: Every write runs as a user and is checked with `current_user_can`, so the agent inherits a permission model you already trust. - **WooCommerce REST API**: Added only on stores, and only for the order, product and customer routes the task actually needs. ## The approval queue is the admin you already use Pending posts, held comments, and a run log screen the plugin adds. There is nothing new to learn, and nothing publishes itself. **Draft and pending**: 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. **Held comments**: Comments and form submissions the agent is not sure about go to hold, where a moderator sees them. Deletion is never an agent action. **Capability checks**: 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. **Run log**: 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. ### Where to go next How we build the agent itself, the platform we most often pair with WordPress, and the supporting work around it. - [Agent engineering](https://aispeedforce.com/services/agent-engineering/) - [All platforms](https://aispeedforce.com/platforms/) - [Wix agents](https://aispeedforce.com/platforms/wix/) - [SEO](https://aispeedforce.com/services/seo/) - [Contact](https://aispeedforce.com/contact/) ## Questions WordPress teams ask first ### Does this slow the site down? 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. ### Does it work with our page builder and existing plugins? 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. ### What happens on a multisite install? 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. ## Tell us the WordPress job you would hand over 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.