WordPress 7.0 and AI: a forced move? How the work of web agencies changes

Anyone expecting an automatic copywriter in the dashboard was disappointed, and that is a good thing. Core did not impose any AI vendor: it laid three bricks under the floor, and they are bricks for engineers, not for marketing.

WP AI Client: a single channel to the models

It is a provider-agnostic PHP interface: plugins talk to generative models without rewriting the integration every time, and Core handles request routing. Developers can express a model preference with using_model_preference() and build prompts with WP_AI_Client_Prompt_Builder. Translated: the model becomes a configuration detail, not a choice carved into your theme code.

Abilities: the site becomes invocable

Abilities, introduced in WordPress 6.9 and available client-side too in 7.0, are registered actions with input and output schemas, permissions and annotations: read-only, idempotent, destructive. That is how an assistant — or an internal workflow — discovers what the site can do and runs it, without a hand-rolled REST endpoint for every plugin. On top sits the MCP adapter: tools such as Claude, ChatGPT or Gemini can see those actions and call them. It is not magic, it is a contract.

Connectors: where API keys end up

Under Settings → Connectors you manage provider connections: Anthropic, Google and OpenAI by default, plus your own connectors. Watch one detail that matters in production: keys entered from that screen are visually masked but not encrypted in the database. On a production site they should come from environment variables or PHP constants.

The cycle after a major release always says more than the major itself. Here it said two things: core stabilised quickly, and security did not wait for your release plans.

9 July 2026 — 7.0.1, maintenance

A minor release with 31 bug fixes across core, the block editor and media. Nothing to tell the client, everything to schedule.

17 July 2026 — 7.0.2, the release that installed itself

A security release with one critical and one high severity vulnerability (CVE-2026-60137 and CVE-2026-63030). WordPress.org forced automatic updates on affected versions, with backports to 6.9.5 and 6.8.6. If you manage fifty or two hundred sites, this is the part that hurts: a core update can start overnight on a catalogue nobody tested in staging. If you still run installs below 6.8, that backport does not cover you.

19 August 2026 — 7.1 “Mary Lou”

Less manifesto AI, more daily work: a consistent admin bar across the dashboard, responsive block visibility without custom CSS, a new media editor with freeform crop, flip and rotation, Notes with rich text and @mentions anywhere in the content, Playlist and Tabs blocks, an API to register SVG icon sets. 7.1 does not contradict 7.0: it makes it usable by a team.

It depends what you mean by forced. The two sides are worth separating, because the answer is not the same.

What is not mandatory

• No bundled provider. Core ships no AI vendor: with no connectors configured, nothing runs.
• Opt-in features. Generated summaries, excerpts and alt text mostly live among the AI experiments, enabled by hand.
• No hidden cost. Tokens are paid by whoever connects their key. A 7.x site can stay silent towards models and work exactly as before.

What you do have to live with

• The platform is agent-ready. Serious plugins will register abilities: the site becomes commandable from outside, like it or not.
• The market moves before you do. Clients will ask “does it do AI too?” and competitors will sell automated content packages.
• Forced updates. 7.0.2 went into production without asking any agency for permission.

So no, AI is not imposed. But the responsibility model changed anyway: the surface you have to govern got wider, and the security auto-update reminded everyone that on WordPress time belongs to whoever has staging, backups and a verification window. Everyone else finds out from the client ticket.

In build: from the site to the system

Value moves from the single page to the setup: theme.json, curated patterns, blocks registered in PHP, documented abilities. That is how you deliver ten coherent sites without cloning the page builder by hand. AI does not replace the design system: it consumes it. Weak patterns produce weak generated output; wide ability permissions turn that output into damage.

In maintenance: you need an inventory of abilities

A maintenance retainer no longer covers versions and backups alone. It now needs answers to new questions: which plugins expose abilities, which ones are destructive, where the API keys live, who may enable a provider. And it needs a written update protocol, because 7.0.1 and 7.0.2 showed that “we update when there is time” is not a strategy.

In sales: you sell governance, not layout

Generating a page draft or an alt text costs almost nothing, and the client will find that out. What they cannot do alone is hold together brand voice, quality, accessibility, SEO and accountability. An agency selling layout hours competes with a language model. One selling reviewed content, approval workflows, monitoring and isolated hosting raises the retainer instead of cutting the quote.

• AI and permission setup — connector configuration, keys out of the database, enabled roles, a list of active abilities with their annotations. One-off, per project.
• Editorial QA of AI output — human review of generated content: tone, sources, accessibility, SEO. By volume or on retainer.
• Core updates with staging — verification window, rollback, report to the client. This is the service 7.0.2 made sellable without having to explain why it is needed.

Three line items the client understands, and they defend your margin: none of the three can be replicated by a prompt.

• Move the fleet to 7.1 (or at least 7.0.2 / 6.9.5 / 6.8.6 depending on the branch) after a staging pass.
• Build the list of plugins and themes that register abilities, flagging the destructive ones.
• Decide whether AI is on, for which roles and on which environments. Put it in writing.
• Move API keys out of the database, into environment variables or PHP constants.
• Check that backups and staging can survive a forced update over the weekend.
• Tell the client who pays for tokens, who sees the data sent to the model and who answers if nonsense ends up online.

WordPress is not forcing you to let a model write your sites. It is forcing you to treat the site as a platform with invocable actions. It is the same curve as Gutenberg, block themes and WooCommerce: those who adapt sell better services, those who wait for the trend to pass end up fixing sites their clients already started handing to AI on their own.

On Host.it, WordPress sites run on Italian infrastructure, with backups, SSL and Application Manager to publish and update without drama. If you manage many clients, what makes the difference stays mundane and decisive: staging, observability and someone to call when a security update lands on a Saturday night. AI in core does not remove that need: it makes it more urgent.