How to Build a WordPress Site With AI in 2026

There is a real difference between the AI features WordPress had eighteen months ago and what shipped this summer, and it is worth naming precisely.

The old model was generation: you typed a prompt into a box inside the builder, and it handed back a chunk of markup with inline styles that fought your stylesheet. Useful for a hero section. Useless for a site.

The new model is connection. Since July 2026, three major page builders expose themselves over the Model Context Protocol — the same standard your coding agent already speaks. You point Claude Code, Codex, or Cursor at a WordPress install, describe what you want, and the agent builds it as real, editable builder elements that reuse the selectors and variables you already defined.

That is a different capability, and it changes the shape of a build. This guide covers how to actually set it up, what each builder can do, and the parts of the story that the launch coverage skipped.

TL;DR

• Three builders support agent-driven building as of August 2, 2026: Breakdance 3.0 (public beta), Oxygen 6.2, and Bricks 2.4 (experimental).
• Breakdance and Oxygen use Soflyy's own Agent Connector plugin at Settings → Agents & MCP. Bricks uses WordPress core's Abilities API plus the official MCP Adapter plugin.
• Any MCP client works — Claude Code and Desktop, Codex CLI and Desktop, Cursor, OpenCode, Windsurf, Cline, Gemini CLI.
• Setup takes about twenty minutes. The build workflow takes longer to get right than the connection does.
• The credential is the catch. Every integration authenticates with a WordPress application password, which carries full administrator access and cannot be scoped down.
• Design system first, pages second. This is the single biggest determinant of whether agent output is usable or garbage.
• Staging only. Breakdance 3.0 is still in beta and Bricks calls its implementation experimental. Neither belongs on a live client site yet.

The three layers you are actually assembling

It helps to see this as a stack rather than a feature, because when something breaks you need to know which layer to look at.

WordPress 7.0, released May 20, 2026, is what made the bottom layer possible. It shipped the Abilities API, a standard way for plugins and themes to register callable actions with proper capability checks, alongside the AI Client and the Connectors Hub. WordPress 7.1, due August 19, 2026, adds streaming responses and embeddings-based semantic search on top.

The WordPress MCP Adapter is the official package that converts registered abilities into MCP tools. If a plugin registers an ability, the adapter makes it callable by any connected agent. That is the route Bricks took.

Breakdance and Oxygen took the other route — a first-party connector plugin that exposes builder-specific tools directly. It is less standards-pure and considerably more capable, because the builder knows things about its own data model that a generic ability registration would not express.

What each builder can actually do

Breakdance 3.0

Breakdance announced 3.0 on July 20, 2026, with Beta 2 following on July 25. As of August 2 it is still in public beta — the stable line remains 2.8.1 from July 15. Treat every version number here as something to re-check before you quote it to a client.

Setup lives at Breakdance → Settings → Agents & MCP, with a one-click install for Agent Connector.

The architectural decision that makes Breakdance's implementation interesting: the agent writes HTML and CSS, and Breakdance converts that output into native elements and selectors. It does not manipulate internal data structures directly, and it does not drop static markup into a page.

That conversion step is the whole point. Agent-built pages open in the visual builder as ordinary editable elements, a junior team member can adjust one without knowing it was agent-built, and the agent reuses your existing selectors rather than inventing a parallel set of one-off styles.

An agent can build pages, templates, headers, footers, selectors, CSS variables, responsive styles across Breakdance breakpoints, dynamic data through ACF and Meta Box, Posts Loops with conditional display, and multi-field forms with actions and redirects.

3.0 also ships non-AI changes worth knowing about before you update: a redesigned Selectors system that drops the automatic .breakdance wrapper class, native CSS variables, and a new Interactions system. That wrapper removal is a genuine CSS specificity change — custom overrides calibrated against the old specificity can start winning or losing where they previously did the opposite. Sites with large hand-written stylesheets are the exposed ones.

Oxygen 6.2

Oxygen 6.2 landed on the same July 20 date, with its own Beta 2 on July 25–26. Setup is identical in shape: Oxygen → Settings → Agents & MCP, one-click Agent Connector install — the same companion plugin, which tells you how Soflyy is building this across the product line.

Oxygen's agent scope is the broadest of the three:

That last row deserves a pause. An agent that can rewrite global site settings is an agent that can break every page at once. Oxygen's Beta 2 specifically fixed a set-global-settings tool bug that could break settings saves — exactly the class of bug you want found in beta rather than on a client site.

Bricks 2.4

Bricks took the standards route. Bricks 2.4 registers abilities through WordPress core's Abilities API and exposes them via the official MCP Adapter plugin. Requirements are the Abilities API (present in current core), the WordPress MCP Adapter plugin installed and activated, and an application password.

Enable it at Bricks → AI → Configuration by toggling the Abilities API on, then create credentials and connect your client. A connected agent can read and update the design system, templates, elements, dynamic data, media, WooCommerce templates, and revisions. Permission checks run against the WordPress user's capabilities and their Bricks builder access level — a slightly better security posture than the connector approach, though the application password is still the weak link.

Bricks is unambiguous about status: the feature is experimental, and their own documentation says to test on local or staging and keep it off production sites while it remains experimental. Take them at their word.

What about Elementor and Divi?

Neither has a first-party MCP integration as of August 2026. Elementor's AI remains generation-oriented — you prompt for a section, you do not connect an agent to the site. Third-party MCP servers exist for both builders and some are decent, but they are reverse-engineering a data model rather than being handed one, and they carry no vendor support commitment. If agent-driven building is your priority, that priority points at Breakdance, Oxygen, or Bricks.

The setup, step by step

1. Build on staging, never production

This is not boilerplate caution. Breakdance 3.0 is in beta, Bricks calls its implementation experimental, and an agent session can touch forty things across templates and global settings before you notice one went wrong.

Clone a site or start a fresh install. Take a database snapshot before you begin — on managed hosting that is an on-demand backup, on a VPS wp db export takes seconds. This single habit is the highest-value thing in this entire guide.

2. Install the builder and connector

Install Breakdance 3.0, Oxygen 6.2, or Bricks 2.4. Then:

• Breakdance/Oxygen: Settings → Agents & MCP → one-click install Agent Connector → refresh to confirm.
• Bricks: install and activate the WordPress MCP Adapter plugin, then Bricks → AI → Configuration → enable the Abilities API toggle.

3. Create a dedicated agent user

Do not issue the application password from your own account. Create a separate WordPress administrator used only for agent access.

It still needs the administrator role to function — there is no way around that — but it isolates the audit trail, you can delete it the moment a build finishes, and revoking it does not log you out of your own sessions.

4. Generate the application password

From the connect screen, pick your agent and generate an application password when prompted.

Read this part carefully, because it is the most consequential sentence in the whole setup: that password grants administrator-level access. Not builder-scoped. Not read-only. Administrator.

Application passwords inherit the full capabilities of the issuing user, and WordPress has no mechanism for scoping one down to "builder layouts only." An MCP client holding that credential can install plugins, read user data, and change settings through the REST API. That is a WordPress limitation rather than a builder bug, but the exposure lands on you regardless.

5. Connect your client

Copy the terminal command shown on screen and run it in your MCP client. The exact syntax varies by agent and is generated for you during setup, so use the displayed command rather than one you found in a blog post.

Then verify: ask the agent to confirm it is connected to WordPress and report site information back. If it can read your site title and plugin list, you are connected.

6. Lock it down before you build

Agent Connector gives you three controls. Use all three from the start, not after something goes wrong:

• Domain lock — ties the credential to a specific domain so a leaked one is less portable.
• Event logging — gives you an audit trail of what the agent actually did, which is the only way to reconstruct a bad session.
• Disable when idle — there is no reason to leave the connector open between build sessions.

The workflow that actually produces usable sites

Connection is the easy part. Getting good output is a discipline, and it comes down to four things.

Give it a design system before you ask for pages

This is the difference between agent output you keep and agent output you rebuild.

Before you prompt for a single page, define your colours, typography scale, and spacing as CSS variables, and create the core selectors your site will use — buttons, section wrappers, headings, cards. All three builders support this natively, and all three integrations are explicitly built to reuse existing selectors and variables rather than generate new ones.

An agent handed a design system produces pages that look like your site. An agent handed a blank install produces pages that look like every other AI-generated site, with a parallel set of one-off styles you will spend longer untangling than building from scratch.

Prompt page by page, not site by site

Oxygen's marketing says an agent can build the structure of an entire site in one go. It can. You should not let it, at least not until you have watched several builds and trust the output.

One page or template per prompt gives you a reviewable unit of work. Forty changes across templates, Components, and global settings in a single session gives you an archaeology project when one of them is wrong.

Verify in the builder, not just the browser

A page that renders correctly in the browser has passed the easy test. Open it in the visual builder and confirm the structure is native editable elements using your selectors — not a deeply nested pile of divs with hardcoded hex values that happens to look right.

Editable, on-system output is the entire promise of these integrations. Check that it holds on every build until you have reason to stop checking.

Give it a reference it can be judged against

The most useful first task is rebuilding a page you already know well. You have a known-good reference, so you can judge output quality precisely instead of vaguely. "Does this look fine?" is not a test. "Is this the same as the page I built by hand, and where does it differ?" is.

What AI still gets wrong

Being specific about limits is more useful than either hype or dismissal.

Design judgement. An agent produces competent, conventional layouts. It does not produce a distinctive one, and it will not tell you the brief is wrong. Art direction remains yours.

Content strategy. It will happily fill a page with plausible copy that says nothing. Structure, message, and proof points are still human work — and generated copy is exactly the kind of thin content the June 2026 spam update was aimed at.

Knowing when to stop. Ask for a landing page and you may get six sections when three would convert better. Agents optimise for completing the request, not for restraint.

Performance discipline. Agent-built pages are structurally clean but nobody is watching Core Web Vitals during generation. Every one of these releases improved builder performance — editor responsiveness — not front-end speed. Audit the output the same way you would audit a human build.

Accessibility. Semantic structure is usually reasonable. Focus states, keyboard navigation, and colour contrast are inconsistent. Check them.

Cross-page consistency. Build eight pages in eight sessions and small divergences accumulate — a spacing value here, a slightly different heading treatment there. This is precisely why the design system has to come first.

Fitting this into agency work

The honest positioning for the next few months: use it on internal projects, prototypes, and staging rebuilds, not on live client sites. Two of the three implementations carry a beta or experimental label from their own vendors, and the credential model is not where it needs to be.

Where it already pays off:

• Pitch prototypes. Building three real homepage directions instead of one flat mockup changes how a pitch goes.
• Repetitive structural work. Posts Loops, multi-field forms with actions and redirects, template variants — the parts of a build that are pure clicking.
• Rebuilds with an existing reference. Migrating a design you already have is the strongest current use case, because the target is unambiguous.
• Learning a builder. Watching an agent construct something in Oxygen teaches the builder's model faster than the documentation does.

Where it does not yet belong:

• Anything holding customer PII or payment data.
• Sites where you cannot cheaply revert.
• Client work you cannot budget review time for — the review is not optional, and it is not free.

Which builder should you actually pick?

If you are choosing a builder because of agent support, the decision comes down to licensing and risk tolerance.

Oxygen 6.2 has the broadest agent scope and the best economics — one-time lifetime licences from $129 (WooCommerce $149, Ultimate $179, Lifetime Bundle $199.50), with existing lifetime holders getting Oxygen 6 free. The catch is unrelated to AI: Oxygen 6 is a ground-up rebuild that deliberately broke compatibility with Oxygen Classic, with no official migration path. New builds only.

Breakdance 3.0 has the cleanest architectural approach — the HTML-to-native-elements conversion is the right design — and the most complete WooCommerce template builder in this category. It is $199.99/year for unlimited sites. Over five years that is roughly $1,000 against Oxygen's $199.50, which is a real argument. It is also still in beta.

Bricks 2.4 is the standards-aligned choice, building on core's Abilities API rather than a proprietary connector, with permission checks that respect Bricks access levels. It is also the most explicitly experimental of the three and the least broad in scope right now.

For most agencies the practical answer is: pilot on whichever builder you already run, on staging, this month. The integrations are close enough in capability that switching builders for MCP support alone is not yet justified — but forming a real opinion about agent-driven building is, because the gap between "read about it" and "know what it is actually good at" is wide and closing fast.

The short version

Building WordPress with AI stopped being a novelty in July 2026. An agent connected over MCP produces real, editable, on-design-system output, and it does the repetitive structural work faster than you do.

Three things determine whether it works for you. Give the agent a design system before you give it a brief. Take a database snapshot before every session. And treat the application password as what it is — a full administrator credential sitting in a config file on your laptop, which should be deleted the moment the build ends.

Do those three, keep it on staging until the beta labels come off, and this is genuinely useful today.

Related reading

• Breakdance 3.0: MCP-Ready AI Agents Inside Your Page Builder
• Oxygen 6.2 Review: MCP Agents, and What Classic Users Need to Know
• WordPress 7.0's AI Features, Explained for Agencies
• WordPress 7.1's AI Client Gets Streaming and Semantic Search
• Best WordPress Page Builders 2026
• Breakdance vs Bricks Builder 2026
• WordPress Staging Site Guide
• WordPress Security Hardening Checklist