WordPress didn’t add an AI feature. It added AI infrastructure.
On May 20, 2026, WordPress 7.0 “Armstrong” shipped with something the platform has never had before: AI built into core. Not a plugin. Not a bolt-on. A standardized layer that every theme, plugin, and external agent can build against.
For most of the web, that’s a headline. For agencies, it’s an architecture decision, and the agencies that treat it as one will pull ahead of the ones that treat it as a checkbox.
Taoti has already adjusted. Here’s how we’re approaching 7.0 for our clients.
What Actually Changed
For years, AI on WordPress meant chaos. Every AI-powered plugin managed its own provider connection, its own API keys, its own governance model. Run a content assistant, an SEO tool, and a chatbot on the same site and you had three foundations doing the same job three different ways. Across a client portfolio, that’s not a feature set. It’s technical debt.
WordPress 7.0 collapses that into shared infrastructure:
- The Connectors API gives every site a single Settings panel to connect an AI provider (OpenAI, Google, or Anthropic) once, for the whole site.
- The WP AI Client SDK lets developers talk to any of those AI providers through one consistent, WordPress-native interface, instead of writing against each vendor’s API.
- The Abilities API defines safe, structured admin operations that AI can actually perform. These are the guardrails that make automation trustworthy.
- The MCP Adapter turns those abilities into tools that external AI agents can discover and call. Any ability you register becomes operable by a compatible client.
One provider connection. One governance model. One place to control what AI is allowed to touch. That’s the real story.
Why This Matters More for Agencies Than Anyone Else
A single site owner gains convenience. An agency gains leverage, and inherits risk.
The same launch that shipped this infrastructure also surfaced the obvious concern: a centralized AI key surface is a centralized target. Convenience and exposure arrive in the same release. When you manage twenty, fifty, a hundred client sites, “connect a provider in one click” is only an advantage if you’ve already decided who connects to what, which content AI can read, what data is opted out of training, and how every AI-triggered action gets logged.
That’s not a reason to wait. It’s a reason to have a position before you upgrade.
We don’t bolt AI onto sites. We architect where it’s allowed to operate.
How We’re Approaching 7.0
Our approach to Armstrong is phased and deliberate. It’s the same discipline we bring to every platform shift.
We test before we touch production. Every active client site gets validated in a staging environment before any upgrade reaches a live audience. New defaults, new admin interfaces like DataViews, and changed block behavior all get pressure-tested first.
We audit plugin compatibility. A major core release means some plugins lag behind it. We document what breaks, what needs replacing, and the remediation path, before a client ever sees a warning in their dashboard.
We define AI governance before we activate a single connector. This is the part most teams will skip, and the part that matters most. Which provider connects to which content. What gets logged. What never leaves the client’s environment. We settle those questions first, because turning AI on without answering them isn’t innovation. It’s exposure.
We treat new agentic capability as a service, not a novelty. The MCP Adapter opens a genuinely new category: external agents that can draft, review, and schedule content directly inside a governed WordPress environment. That’s powerful, and it’s exactly the kind of capability that needs human-in-the-loop design, permission boundaries, and audit trails from day one.
This Fits How We Already Work
None of this is a pivot for us. We’ve already embedded AI across development, design, QA, and content, all of it governed, reviewed, and measured against real performance, not hype. WordPress finally standardizing AI at the core layer doesn’t change our philosophy. It validates it.
The platform is now built around the same principles we’ve been operating on: provider flexibility, centralized governance, human oversight, and automation that accelerates work without bypassing approvals. Armstrong gives those principles a native home in WordPress. We were ready for it before it shipped.
What This Means for Your Site
If your site runs on WordPress, 7.0 is coming whether you plan for it or not. The question is whether the migration is scoped, or whether you find out what changed after something breaks.
Done right, Armstrong is a real upgrade: leaner block development, a faster admin experience, and AI capability you actually control instead of duct-tape across half a dozen plugins. Done carelessly, it’s an open key surface, a compatibility surprise, and an AI governance gap nobody decided to own.
We don’t separate capability from control. We design for both.
The agencies that win the next phase of WordPress won’t be the ones that adopted AI fastest. They’ll be the ones that adopted it deliberately. That’s the work we do.
If you’re wondering what WordPress 7.0 means for your site, or your portfolio, we should talk.
