Three different products are sold under the words “AI for WordPress”. One writes text and pictures into the editor when you ask. One sits inside a page builder and suggests the next block. One connects to your site with its own set of tools and does the work: creates the page, changes the template, sets up the content type, fixes the broken links. Only the third is an agent, and the difference is not marketing. It changes what can go wrong and what you have to check.
Generator, assistant, agent
A generator produces content on request. Jetpack AI in the block editor, Divi AI writing a paragraph, an image model making a hero picture. It acts once, on the thing in front of you, and you place the result. It has no view of the rest of the site.
An assistant lives inside a tool and works on that tool’s objects. It can lay out a section in a builder or suggest a colour, because the builder shows it the page’s structure. It still acts one step at a time, inside one screen, and it stops when you stop.
An agent is given a goal and a set of tools, and it decides which tools to call, in what order, until the goal is met or it gets stuck. “Add a Courses content type with a level and a badge image, build its templates and put it in the menu” is a dozen operations in three admin screens. An agent does them, reads the results of each, and adjusts. That loop, with tools the agent can discover and call on its own, is what the word means.
What an agent is made of
Every WordPress agent, whichever product it is, has the same parts. Knowing them makes the products easier to compare.
- A model, in a client you already use: Claude, ChatGPT, Cursor, Claude Code, a desktop app. The model is not inside WordPress; it connects to it.
- Tools: the operations the site offers. In 2026 the common way to offer them is MCP, a protocol that lets the client discover what tools exist, what each expects, and call them. WordPress core’s Abilities API and the MCP Adapter, plugin servers, hosted relays and theme servers all do this in their own way; we compared them in WordPress MCP servers compared.
- An identity: the agent acts as a WordPress user, through an Application Password or an OAuth sign-in. Its powers are that user’s powers.
- Context: what it is told about your site before it starts. Some products give it nothing but the tool list. Delta gives it a briefing, a design system with notes, and skills and rules you can edit.
- Memory: what it keeps between sessions. Without it, every conversation starts from zero and repeats old mistakes. Delta keeps decisions and open items in a memory on the site.
- Brakes: approvals before certain actions, undo after them, snapshots to restore, a log of what was called. This is where products differ most, and it is the part to read the reviews for.
What an agent can do on a site today
Reliably: the structured, repetitive and well-specified work. Building a content type and its fields. Creating templates and the conditions that place them. Setting SEO titles and descriptions across fifty pages. Finding broken links and fixing the ones with an obvious target. Adding a form and wiring its notifications. Building pages against a design system, where the system does the taste and the agent does the assembly.
Less reliably: anything that needs judgement about your business. Copy that sounds like you. Deciding which of two layouts is right for your readers. Knowing that the “Team” page is out of date because someone left. An agent will do these if asked, and the result needs a person. We wrote about where the taste comes from in where design intent takes shape in an agentic workflow.
Not at all, by design: in a well-built product, the agent does not install software, create users or change payment settings without a person agreeing, and a delete leaves something to restore from. If a product lets it do otherwise, that is a finding, not a feature.
What it is not
An agent is not a replacement for knowing what you want. It is a very fast builder with no stake in the outcome, and it is literal: a vague brief produces a confident, vague site. The best results come from people who would have been good clients for a human builder, which means a clear brief, decisions made on time, and feedback given with the page open rather than from memory.
It is also not autonomous in the way the word suggests. It runs while you watch, stops when it finishes or gets stuck, and does nothing between sessions. Scheduled or unattended agents exist, but on a public website that is a choice to make deliberately, with the brakes above in place.
Six questions before you connect one
- What does it write? Post content, a builder’s structures, or the HTML, CSS and JavaScript the theme renders? This decides whether it can build a site or only fill one.
- Who is it, on the site? Which user, which role, and can you revoke it in one click?
- What waits for a human? Get the list of actions that need approval, and find out what a delete leaves behind: a trash entry, a snapshot, or nothing.
- How do you take a change back? Undo window, snapshot, or nothing?
- What does it know about your site before it starts, and can you edit that?
- Where does the traffic go? Direct from your client to your site, or through a third party’s servers?
Our answer
Delta is built on one view of this: the agent should work in the thing that renders the page, with a design system to keep it consistent, and with brakes it cannot talk its way past. So the MCP server is in the theme, the agent writes HTML, CSS and JavaScript against tokens, approvals gate the actions that hand out control, Delta saves a snapshot on its own before it deletes a template, a term or a menu, and a full snapshot is one prompt away. Other products make other choices, and the questions above apply to ours as much as to theirs.
