Bringing WordPress AI to the Market  🔗 **Source:** [Bringing WordPress AI to the Market](https://www.briancoords.com/bringing-wordpress-ai-to-the-market/) > [!note]+ Document Notes > tags: [wordpress-ai, abilities-api, mcp-adapter, go-to-market, agentic-site-management] > author: briancoords.com > source: briancoords.com > reference: https://www.briancoords.com/bringing-wordpress-ai-to-the-market/ > date created: 2026-09-29 15:56 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Bringing WordPress AI to the Market > <!-- deep-read:sections start --> ## 🧭 Table of contents - [📝 Summary](#-summary) - [📖 Main content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning styles assessment](#-learning-styles-assessment) - [📊 Accessibility assessment](#-accessibility-assessment) - [🌍 DEIB assessment](#-deib-assessment) - [✅ Logical validity](#-logical-validity) - [🛡️ DARVO analysis](#️-darvo-analysis) - [🎯 Conclusion](#-conclusion) - [🔄 Refactor appendix](#-refactor-appendix--bringing-wordpress-ai-to-the-market) ## 📝 Summary - **What happened.** briancoords.com published a personal opinion post on 2026-09-29 arguing that the WordPress project needs a go-to-market strategy for AI, built around outside-in agentic site management (¶1). The captured text has no byline, so the author is recorded as the site name. The author writes in first person and calls the piece "a go-to-market thought exercise," not a technical roadmap, and adds "I might be wrong" (¶11). - **The claim.** Five recommendations run through the post. Release a Core Abilities plugin with read-write content abilities (¶14). Treat MCP as "good enough" and make it canonical and discoverable (¶16, ¶17). Rank external agent access above dashboard AI features that need an API key (¶21, ¶22). Let hosts and plugins sell premium layers on top (¶28 to ¶30). Build an AI and MCP marketing home on WordPress.org with landing pages, copy-paste prompts, and AGENTS.md files (¶31 to ¶43). - **Why it matters.** The post names a specific gap: the building blocks exist (Abilities API since 6.9, per ¶13), but WordPress.org gives no route for someone who wants to manage a site with AI (¶32). The author's closing worry is that an agent won't recommend WordPress at all (¶48). - **Key stakeholders.** Core AI contributors (praised in ¶0 and ¶45), James LePage (named in ¶0 for the AI building blocks), hosts (WordPress.com, Pressable, Siteground, Kinsta, ¶7), plugin ecosystems (Jetpack, Elementor, AwesomeMotive, WooCommerce, ¶8), Jordy Meow (named plugin author, ¶27), and site owners who start with an agent instead of a host (¶4). - **Risks and tradeoffs.** This is opinion and advocacy from one voice. The data is four or five plugins' install and review counts (¶24 to ¶27), and the author calls the numbers unclear and the conclusion a "theory" (¶24). The post names commercial players and one product it praises (Spacefast, ¶44) without describing its own commercial interests in the captured text. A plugin-first Core Abilities release trades speed for a second delivery path to core (¶14). - **Bottom line.** The strongest, checkable part is the gap description: what WordPress.org tells a user about AI (¶32) and what core Abilities exist (¶13). The weakest part is the usage evidence, which rests on install-to-review ratios. Read it as a well-argued position paper, not as market research. ## 📖 Main content **Source type.** A personal blog post by a self-described developer advocate, marketer, and user (¶11). It is advocacy for a strategy, addressed to the WordPress AI contributors and the wider project. It contains few facts the reader can verify without leaving the page, and the link list has only six links (see References). **The framing.** The post opens by crediting the AI building blocks that James LePage set in motion a year earlier and the current Core AI contributors (¶0), then shifts to product and marketing (¶1). The author's thesis is that the WordPress brand should align with "outside-in agentic site management": an external agent (Claude, Codex) connects to a site and manages it, as opposed to AI features inside the dashboard. The author asks whether the project shows "a compelling user experience" (¶1). **Ecosystem approach.** ¶3 says the AI story should be easy to tell for an open, extensible platform, but the gap is filled by plugins and hosts, or users leave for other frameworks and static site generators. ¶4 adds that sites increasingly begin "in their AI agent," not at a host's front door, so the project needs a clear, opinionated path. ¶5 to ¶9 define three layers (core and brand, hosts, plugin ecosystems) and state the hard problem: a single entry point that still leaves room for each layer to add value and monetize. **Composable architecture.** ¶13 credits the Abilities API (in core since 6.9) as the strongest demand signal, and notes core has no content-management Abilities, comparing that to a REST API with no endpoints. ¶14 proposes a Core Abilities standalone feature plugin with read-write abilities (fetch patterns, design a page, post, update header and menu) that migrates to core later. ¶15 disagrees with folding these into the MCP adapter or the AI Experiments plugin, with a link to a GitHub issue comment, because content abilities are a primitive that shouldn't depend on either. **MCP position.** ¶17 concedes MCP may not last a decade and argues demand today justifies first-class treatment, like Laravel, Shopify, Vercel, Figma, and Spacefast. MCP should be canonical and discoverable, not in core. ¶18 welcomes moving the package out of bundles in Woo and Elementor into its own plugin and asks to drop "Adaptor" from the name. ¶19 says installing it is "a non-event" without Core Abilities and suggests an onboarding screen for Claude and Codex plus basic governance such as disabling exposed Abilities. **Priorities for core versus products.** ¶21 and ¶22 rank dashboard AI features that need an API key below external agent access, because agents can build such UI quickly and the larger gains sit in external bots with access to Google Drive, Linear, GitHub, and spreadsheets. ¶23 says the Abilities API compounds when every plugin uses it. ¶24 to ¶27 offer install and review counts: AI Experiments (50k installs, 9 reviews), Angie (100k, 18), Siteground's agent (1m, mostly negative), WPVibe MCP (40k, 77 positive), and a plugin by Jordy Meow (90k, almost 900 positive). ¶28 to ¶30 assign premium layers (governance, audit trails, analytics, multisite management, plugin and theme management, rollbacks, branded Claude and ChatGPT plugins) to hosts and plugins. **Marketing home.** ¶32 says a basic Google search shows no core guidance on using AI to manage a site, that third-party plugins hold the top results, and that what core does publish is about building AI tools for WordPress. ¶33 to ¶37 split user goals: connect an existing agent (install MCP), enable dashboard AI (install AI Experiments), build from scratch (one-line Playground CLI and Agent Skills), and route developer content to the developer site. ¶38 to ¶45 list the steps: landing pages for humans and agents at /ai, /mcp, and /try, copy-paste prompts and AGENTS.md files, dashboard promotion, unified CLI and SDKs, centralized developer resources, with Spacefast named as a good AI-first marketing example. ¶45 restates that the post doesn't criticize any project. **Closing.** ¶47 admits AI predictions age fast: block markup worried the author a few weeks earlier and worries less now. ¶48 gives the new worry, that an agent won't recommend WordPress because the tools aren't clearly accessible and WordPress.org isn't telling anyone. ¶49 asks for comments. **Uncertain or contested in this source.** - Usage claims. ¶24 says it's unclear how many installs are "active" and asks for data. The claim that outside-in approaches are winning is labeled a theory. - The Google search result claim (¶32) has no date, query, or screenshot in the captured text. - Nothing in the captured text says whether the Core AI team has already scoped a Core Abilities plugin. ¶15 refers to discussions and links a GitHub comment I didn't open. - The Abilities API "in core since 6.9" (¶13), the install and review counts (¶24 to ¶27), and the bundling of the MCP package in Woo and Elementor (¶18) have no link in the captured markup. - The name of the plugin credited to Jordy Meow is missing from the captured text (¶27 reads "Jordy Meow’s – 90k installs"), probably because the plugin name was a link or image that didn't capture. ## 🗒️ Notes #### 📄 ¶0-¶1 Credit, then a marketing question - Core AI contributors are building on the AI building blocks that James LePage set in motion a year earlier, and the author is optimistic about the ecosystem (¶0). - The author's lens is product and marketing: align the WordPress brand with outside-in agentic site management (¶1). - Open question posed: the building blocks exist, but is the user experience compelling (¶1)? #### 📄 ¶2-¶4 An ecosystem approach - AI enablement "should be an easy story to tell" for an open and extensible platform, and the project isn't telling it well (¶3). - Plugins and hosts fill the gap, often using core plumbing such as the Abilities API and the MCP adapter, or users move to other frameworks (¶3). - Sites now start "in their AI agent," so the project needs a clear, opinionated path (¶4). #### 📄 ¶5-¶9 Three layers that must cohere - Layer 1: open source core and the WordPress brand. Layer 2: hosts (WordPress.com, Pressable, Siteground, Kinsta). Layer 3: plugin ecosystems (Jetpack, Elementor, AwesomeMotive, WooCommerce) (¶5 to ¶8). - Hard part: one entry point and experience for users while each layer keeps room to add value, monetize, or build loyalty (¶9). #### 📄 ¶10-¶11 Prioritization and the author's stance - Question: which building blocks to market first, where to dive in, where to wait and see (¶10). - Stance: developer advocate, marketer, and user. A go-to-market exercise, not a technical roadmap, and "I might be wrong" (¶11). #### 📄 ¶12-¶15 Grow the composable architecture - The Abilities API has the strongest demand signal and adoption across the ecosystem. Core has no content-management Abilities, which the author compares to a REST API with no endpoints (¶13). - Proposal: a standalone Core Abilities feature plugin with read-write abilities (patterns, page design, posts, header and menu), migrating to core later (¶14). - Disagreement with placing Core Abilities in the MCP adapter or AI Experiments: AI Experiments shouldn't be a dependency for MCP users, and content abilities are a primitive under both (¶15). #### 📄 ¶16-¶19 MCP is good enough - MCP may not last a decade, but current demand justifies first-class promotion alongside Laravel, Shopify, Vercel, Figma, and Spacefast (¶17). - MCP shouldn't be in core, but it should be canonical and easier to find (¶17). - The package is bundled in Woo and Elementor and is becoming its own plugin. The author wants "Adaptor" dropped from the name (¶18). - As a plugin without Core Abilities it does nothing for core users. Add onboarding for Claude and Codex and basic governance such as disabling exposed Abilities (¶19). #### 📄 ¶20-¶23 Priorities for core versus the product ecosystem - Dashboard AI features that need an API key rank below solving external agent access without full REST or SSH access (¶21). - Excerpt, featured image, and post-writing features are useful, but external bots with Drive, Linear, GitHub, and spreadsheet access will likely have more impact, including bulk work and bespoke themes, blocks, and admin screens (¶22). - "Lets prove it first" where people use AI before adding sparkle buttons to core (¶22). - The Abilities API compounds in value when every plugin uses it, since it aggregates functionality into one layer (¶23). #### 📄 ¶24-¶27 Install and review counts - AI Experiments: 50k active installs, 9 reviews. The author doubts how "active" those installs are and asks for more data (¶24). - Elementor's Angie: 100k installs, 18 reviews. Siteground's agent: 1m installs, overwhelmingly negative reviews attributed to the rollout, 14 positive (¶25). - WPVibe MCP: 40k installs "in a fraction of the time" and 77 positive reviews (¶26). - A plugin from Jordy Meow: 90k installs, almost 900 positive reviews. Hard to compare because it includes a chatbot builder and premium offerings (¶27). #### 📄 ¶28-¶30 Room for hosts and plugins - Even with core Abilities, hosts and plugins can add value. Existing admin-experience plugins such as Jetpack and Elementor can fill the dashboard AI gap (¶28). - Premium layers: governance, audit trails, analytics, multisite management through one connection, plugin and theme management, rollbacks (¶29). - Plugins with MCPs can register branded Plugins for Claude and ChatGPT that surface all registered Abilities (¶30). #### 📄 ¶31-¶37 A marketing home on WordPress.org - WordPress.org needs an opinion on AI. A basic Google search shows no core information on using AI with WordPress, and third-party plugins hold the top URLs (¶32). - Core information that exists is about building AI tools for WordPress, not managing a site with AI (¶32). - Three user paths: connect an existing agent (MCP), enable dashboard AI (AI Experiments), build from scratch (one-line Playground CLI and Agent Skills install) (¶34 to ¶36). - The developer site should focus on building with AI blocks and contributing with AI through the Plugins MCP, Trac MCP, and Contributor Toolkit (¶37). #### 📄 ¶38-¶45 Steps to tell the story - Landing pages for humans and agents at /ai, /mcp, /try (¶39). Copy-paste prompts and AGENTS.md files (¶40). - Dashboard promotion for installing canonical abilities and MCP (¶41). CLI tooling and SDKs that don't need several tools strung together (¶42). - Centralized AI developer resources on developer.wordpress.org (¶43). Spacefast cited as doing AI-first marketing well (¶44). - Core AI contributors are doing "a phenomenal job." The post prioritizes users' needs over technical tooling (¶45). #### 📄 ¶46-¶49 Last thoughts - AI is hard to predict. Block markup worried the author weeks ago and worries less as the frontier moves (¶47). - New worry: agents won't recommend WordPress because they don't know what it can do, the tools aren't clearly accessible, and WordPress.org stays quiet (¶48). - Closes with a request for reader opinions (¶49). ## 📚 References The link list from the captured markup has six entries. I didn't open the linked pages, so descriptions come from the anchor text and the sentence around each link. - [AI building blocks](https://make.wordpress.org/ai/2025/07/17/ai-building-blocks/): the anchor text in ¶0 for the work James LePage put in motion a year earlier. The URL path suggests a make.wordpress.org/ai post dated 2025-07-17. - [disagree with this approach](https://github.com/WordPress/ai/issues/40#issuecomment-5843000679): a comment on issue 40 of the WordPress/ai repository, linked from ¶15 where the author disagrees with adding Core Abilities to the MCP adapter or AI Experiments plugin. The captured text doesn't say who wrote the comment. - [It’s cleaner.](https://www.youtube.com/watch?v=PEgk2v6KntY): a YouTube link on the sentence about dropping "Adaptor" from the plugin name (¶18). The captured text doesn't say what the video shows or why it's linked. - [a lower priority for core than solving the external agent access problem](https://x.com/briancoords/status/2102452956419489890): an X post linked from ¶21. The account name in the URL matches the site name, but the captured text doesn't state that the post belongs to the author. - [developer.wordpress.org](https://developer.wordpress.org/): the site named in ¶43 as the home for centralized AI developer resources. - [Spacefast](https://spacefast.com/): named in ¶17 (with Laravel, Shopify, Vercel, and Figma as tools with MCP support) and in ¶44 (AI-first marketing). The captured text doesn't describe what Spacefast is beyond those two uses. Claims and names with no link in the captured markup: the Abilities API "in core since 6.9" (¶13); the AI Experiments, Angie, Siteground agent, and WPVibe MCP install and review counts (¶24 to ¶26); Jordy Meow's plugin and its counts (¶27); MCP bundling in Woo and Elementor (¶18); the Google search claim (¶32); and the Plugins MCP, Trac MCP, Contributor Toolkit, Playground CLI, and Agent Skills tools (¶36, ¶37). Those are the claims to check against wordpress.org plugin pages and the make.wordpress.org/ai posts. ## 🗣️ Paraphrase The author thinks WordPress already has the right AI parts and is bad at showing them off. The Abilities API is in core, MCP is usable, and hosts and plugins are building on both. What's missing is a story that starts where more sites now start: in an AI agent, not on a host's homepage. The proposal has three parts. First, ship a Core Abilities plugin so an agent can read and write basic content, and keep it separate from the MCP adapter and AI Experiments plugin. Second, treat MCP as a first-class, discoverable connection, and rank access from an external agent above new AI buttons inside the dashboard. Let hosts and plugins sell the premium layers: governance, audit trails, analytics, multisite control, and rollbacks. Third, give WordPress.org a home for AI: landing pages for people and agents, copy-paste prompts, AGENTS.md files, a one-line site-building install, and one place for developer resources. The author backs the ranking with plugin install and review counts and says outright that the numbers are unclear and the conclusion is a theory. The post ends on a worry that an agent won't recommend WordPress because nobody told it what WordPress can do. ## 📰 Newsletter **A marketing plan for WordPress AI, from someone who wants to see it work.** A new opinion post argues that WordPress has the AI parts (the Abilities API since 6.9, MCP, a growing set of plugins) but no front door for someone who arrives through an agent. The author's fix is concrete: a standalone Core Abilities feature plugin for reading and writing content, a clearer standalone MCP plugin with onboarding for Claude and Codex, and an AI landing area on WordPress.org with prompts and AGENTS.md files. Read it as a position paper. The install and review counts behind the "outside-in is winning" theory are four or five plugins, and the author flags them as unclear. The post also doesn't say whether the Core AI team has scoped the Core Abilities plugin. Links: [the post](https://www.briancoords.com/bringing-wordpress-ai-to-the-market/), [AI building blocks](https://make.wordpress.org/ai/2025/07/17/ai-building-blocks/), and [the GitHub comment on Core Abilities placement](https://github.com/WordPress/ai/issues/40#issuecomment-5843000679). ## ✅ Action items #### DevRel - Developer advocacy: turn the ¶34 to ¶36 user paths (connect an agent, enable dashboard AI, build from scratch) into a demo script with one working example per path. - Education: run a workshop on connecting an external agent to a WordPress site through MCP, using ¶19's onboarding gap as the outline. - Developer experience: draft the copy-paste prompts and AGENTS.md file ¶40 asks for, and test them with two different agents. - Developer marketing: test the ¶32 claim. Record the queries, dates, and top results for "use AI with WordPress" style searches so the gap is measured, not remembered. - Community management: when discussing this post, label it as opinion and point to the ¶24 caveat that install counts are unclear. - Internal/external/cross-project: ask the Core AI team whether a Core Abilities plugin is scoped, and link the ¶15 GitHub comment for context. #### OSPO - Policy and governance: decide who owns the canonical Abilities and MCP naming and placement. ¶15 to ¶18 show the question is open. - License compliance: no direct action from this source. The post names no license questions. - Security management: ¶19 asks for governance such as disabling exposed Abilities. Define what a default-safe set of read-write content abilities is before one ships. - Software inventory: track which major plugins bundle the MCP package (¶18 names Woo and Elementor) so a move to a standalone plugin doesn't leave duplicates. - Developer support: no direct action. Nearest relevance: ¶42 asks for CLI tooling and SDKs that need fewer tools strung together. - Community engagement: no direct action from this source. - Strategic alignment: add a KPI for whether an agent recommends WordPress in a fixed prompt set (the ¶48 worry), measured monthly. #### Community - Maintainers: a maintainer of a plugin that registers Abilities can list them and compare against the ¶14 core content set to find overlaps. - Contributors: a first-issue candidate is testing the ¶14 workflow (fetch patterns, design a page, post, update header and menu) through Abilities and filing gaps. - Sponsors: ¶29 puts premium governance and audit trails outside core. A sponsor can track which of those get built as plugins. - Ecosystem: run a cross-project session with hosts and plugin makers on the ¶9 problem, one entry point with room for each layer to earn. #### WordPress - Core: decide whether content-management Abilities belong in core or in a feature plugin first (¶13, ¶14). The post argues for the plugin path. - Core Performance: no direct action from this source. The post gives no performance figures. - Core AI: respond to ¶14 and ¶15 on where Core Abilities ship, and ¶21 to ¶22 on ranking external agent access above dashboard AI. Publish the reasoning. - **Core Program Team:** track the Core Abilities plugin, the standalone MCP plugin, and the WordPress.org AI pages as one cross-team dependency chain, since ¶19 says the MCP plugin does little without Core Abilities. - Mobile: no direct action from this source. - Playground: ¶36 asks for a one-line Playground CLI install for building a site from scratch. Prototype it with Agent Skills preloaded. - Community: no direct action from this source. Nearest relevance: ¶49 invites feedback that a community channel could collect. - Training: add a lesson on managing a site through an external agent, covering onboarding, Abilities, and disabling risky ones (¶19). - Marketing: primary fit. Draft the /ai, /mcp, and /try landing pages (¶39) for both humans and agents, and decide who owns each. - Support: prepare answers for the question a user asks after installing the MCP plugin with no Core Abilities present (¶19). - Design: design the onboarding screen for Claude and Codex setup (¶19) and the dashboard promotion (¶41). - Documentation: document how to use AI to manage a site (¶32), separate from the existing material on building AI tools for WordPress. - Photos: no direct action from this source. - TV: no direct action from this source. - Polyglots: no direct action from this source. Nearest relevance: landing pages meant for agents and humans (¶39) need translation planning. - Accessibility: audit the proposed onboarding screen and landing pages against WCAG 2.2 AA before launch. The post doesn't mention accessibility. - Meta: WordPress.org hosts the proposed pages (¶31, ¶39). Scope the routes and the plugin directory tie-ins. - CLI: ¶42 asks for CLI tooling that doesn't need several tools strung together. Inventory the current tools and the steps to reach a working agent connection. - Hosting: ¶29 and ¶30 give hosts a premium layer (governance, audit trails, multisite through one connection, rollbacks). Decide which to offer and how to expose them through a single MCP connection. - Tide: no direct action from this source. - Openverse: no direct action from this source. - Themes: ¶22 mentions bespoke theme design through external agents. No specific theme-team action in the text. - Plugins: ¶19 and ¶28 to ¶30 put plugin makers in the value-add layer. Review how plugins register Abilities and whether directory guidance should say so. #### The WPOCC - Programs: no direct action from this source. - Projects: a documentation sprint on managing a WordPress site with AI (¶32) fits a WP Open Community Collective project. - Funding experiments: a small grant for the ¶14 Core Abilities plugin tests or the ¶36 one-line install prototype would show the strategy in working form. ### FAIR - Technical independence: no direct action from this source. Nearest relevance: ¶44 and ¶17 show tool choice shaping discovery. - Policies and covenants: no direct action from this source. - Productized governance artifacts: ¶19's governance idea (disabling exposed Abilities) could become a policy template that plugin and host operators reuse. ## 🧪 Hypotheses 1. Sites managed through an external agent over MCP grow faster than sites using dashboard AI features that need an API key (¶21, ¶22, ¶24). 2. The install-to-review ratio of AI plugins (¶24 to ¶27) doesn't predict active use. 3. A Core Abilities plugin that ships read-write content abilities (¶14) raises MCP plugin retention measurably, because installing MCP today is a "non-event" without them (¶19). 4. Landing pages at /ai, /mcp, and /try (¶39) with copy-paste prompts and AGENTS.md files (¶40) increase agent recommendations of WordPress in a fixed prompt test. 5. A basic search for using AI with WordPress returns third-party plugin pages ahead of any WordPress.org page (¶32) across queries, regions, and dates. 6. Reviews concentrate in plugins with a chatbot or premium tier (¶27), so review count tracks marketing and monetization more than MCP quality. ## 📊 Methodology - **H1.** Pair sites that adopt MCP against sites using dashboard AI, matched by host, plugin count, and age. Use opt-in telemetry from a host or plugin partner. Measure content operations per week, retained connections at 30 and 90 days, and time to first published change. - **H2.** Pull install counts, active-install buckets, review counts, and support-forum activity from the plugin directory for AI plugins on a fixed date. Sample plugins across types. Add a small survey of installers to estimate activity. Report correlation between review ratio and survey activity. - **H3.** Build the Core Abilities plugin as a prototype. Run a usability test with 15 site owners installing MCP with and without it. Measure completion of a fixed task list (¶14: fetch patterns, post, update header and menu). - **H4.** Run 50 prompts such as "which platform should I use to build a store" across three agents, before and after landing pages ship. Count how often WordPress is recommended and what tools the agent names. - **H5.** Script the search queries from ¶32 in clean browser profiles from three regions on the same day. Log result order and domains, and repeat weekly for eight weeks. - **H6.** Classify a sample of plugins by tier (free only, chatbot, premium). Compare review counts and sentiment after controlling for install count and age. - **Controls throughout.** Pre-register the outcome measures. Record the date of every data pull, since ¶26 compares plugins over different time spans. ## ❓ Questions - What is the current status of a Core Abilities plugin, and who decides whether it goes into core, the MCP plugin, or AI Experiments (¶14, ¶15)? - Which content-management Abilities should be read-only by default, and which should require explicit opt-in (¶14, ¶19)? - How should the Abilities that an external agent can see be governed and disabled per site (¶19)? - What does "active" mean in AI Experiments' 50k active installs, and where does that number come from (¶24)? - How many of the 40k WPVibe MCP installs came from a launch push, and how do review counts change over time (¶26)? - Who owns the WordPress.org routes and copy for /ai, /mcp, and /try (¶39), and how would agent-facing pages differ from human-facing ones? - If more sites start in an agent (¶4), which agent-facing files (AGENTS.md, prompts, skills) does WordPress.org need to publish and maintain? - What should the project do if MCP is replaced by another protocol (¶17)? Which parts of the Abilities layer survive? ## 🔮 Future research - **Measuring outside-in use.** Install and review counts are weak proxies. Anonymous, opt-in connection telemetry from hosts would answer whether agent-managed sites are growing (¶24). - **Agent recommendation behavior.** ¶48 fears agents won't recommend WordPress. A repeatable prompt benchmark across agents would measure it. - **Governance defaults.** ¶19 mentions disabling Abilities. There's no comparison of what other platforms expose by default to agents. - **Discovery through search.** ¶32 describes search results by anecdote. A time series of results would show whether the gap closes. - **Layered monetization.** ¶9 and ¶29 want a shared entry point and room for each layer to earn. How that works in practice for hosts and plugin makers is untested in this source. ## 💡 Implications - **Practice.** Plugin makers can register Abilities and branded Claude and ChatGPT plugins on top of a shared set (¶30). Site owners get one connection surfacing all of them. - **Policy.** The project has to decide what core owns (content Abilities, canonical MCP) and what it leaves to others (premium governance, analytics, ¶29). ¶15 shows that decision is active. - **Security.** Read-write content Abilities exposed to external agents raise the stakes of default settings and audit trails. ¶19 and ¶29 raise governance but the post gives no security analysis. - **Education.** A new user path (¶33 to ¶36) means new tutorials, prompts, and AGENTS.md files (¶40) written for agents as well as people. - **Funding.** The ¶28 to ¶30 layers assume hosts and plugins earn from premium features. Core-side work (Core Abilities, landing pages, CLI) has no funding source named in the post. - **Evidence literacy.** The post's data is thin by its own admission (¶24). Readers who repeat "outside-in is winning" should attach the caveat. ## 🧠 Learning styles assessment - **Reading level estimate.** Flesch-Kincaid Grade Level of roughly grade 9 to 10, and Flesch Reading Ease near 55 to 60, from sampling the prose paragraphs (short, conversational sentences, with terms such as Abilities API, MCP, AGENTS.md, and Playground CLI undefined). This is an estimate from sampling, not a computed score. #### 👀 Visual learners - Present: the captured text has no images or diagrams. It uses short lists for the three ecosystem layers (¶6 to ¶8), user paths (¶34 to ¶36), and steps (¶39 to ¶43). - Improve: add a diagram of core, hosts, and plugins with the external agent connecting through MCP and Abilities. The three-layer idea in ¶5 to ¶9 needs a picture. #### 🔊 Aural learners - Present: no audio version is referenced in the captured text. One link (¶18) points to a YouTube video, and its content isn't described. - Improve: a 3-minute audio summary of the five recommendations. #### 🗣️ Verbal learners - Present: analogies (a REST API with no endpoints, a CLI with no commands, ¶13) and plain, first-person argument. - Improve: define Abilities API, MCP, outside-in, and AGENTS.md on first use. ¶13 to ¶19 assume the reader knows them. #### 🧩 Kinesthetic learners - Present: ¶14 gives a concrete task list (fetch patterns, design a page, post, update header and menu). - Improve: a step-by-step walkthrough connecting Claude or Codex to a test site, using the ¶36 Playground CLI idea. #### 🧠 Logical learners - Present: numbered-style proposals with stated reasons and one data set (¶24 to ¶27). - Improve: state the evidence standard. A table of the four or five plugins with install date, install count, review count, and pricing tier would let readers test the theory. #### 🧑‍🤝‍🧑 Social learners - Present: ¶49 ends with "What do you think?" and ¶15 links a public GitHub discussion. - Improve: link a discussion venue for the go-to-market proposal so contributors can respond in one place. #### 🧘‍♀️ Solitary learners - Present: the post is short and linear with headings-style breaks, so it works for solo reading. - Improve: add a checklist of the five recommendations so a reader can mark which they agree with. #### 🌿 Naturalistic learners - Present: nothing explicit. - Improve: none needed for this topic. ## 📊 Accessibility assessment #### Screen reader semantics - Present: the captured text keeps paragraph order, and short heading-like lines ("An ecosystem approach," "Grow the composable architecture," "MCP is good enough," "Last thoughts") mark sections. The capture shows no heading levels, so real heading markup is unknown. Lists appear as short separate lines (¶6 to ¶8, ¶34 to ¶36, ¶39 to ¶43), and whether they are real list elements can't be confirmed. - Improve: verify the section lines are real headings (WCAG 1.3.1) and the lists are real lists. The link on "It’s cleaner." (¶18) has text that doesn't describe its target (2.4.4 Link Purpose in Context) and points to a video the surrounding sentence doesn't mention. The bare URL link in ¶43 is acceptable since the URL text names the site. #### Keyboard navigation - Present: not assessable from captured text. - Improve: verify all six links are keyboard reachable with visible focus (2.1.1, 2.4.7). #### Contrast and readability - Present: unknowable from text. I can't see the page styling. - Improve: check 1.4.3 for body text and link color against the background. #### Text resizing and reflow - Present: unknowable from text. The capture shows no wide tables or fixed elements. - Improve: test 200% zoom and 320 CSS pixel reflow (1.4.4, 1.4.10). #### Media and captions - No media referenced in the captured text. One link in ¶18 points to a YouTube video with no description of its content, so whether it carries captions or a transcript is unknown (1.2.2 would apply if it's embedded). #### Forms and interactions - Present: no form is visible in the captured text. ¶49 invites comments, which likely means a comment form on the page. - Improve: check comment form labels and error messages (3.3.2, 3.3.1). Not assessable from the capture. #### Standards reference - Candidate gaps against WCAG 2.2 AA, each unverified: **1.3.1** (heading and list semantics), **2.4.4** (the "It’s cleaner." link text), **1.2.2** (captions if the YouTube video is embedded), **1.4.3** and **1.4.10** (contrast and reflow, need the rendered page). ## 🌍 DEIB assessment #### Cultural breadth - Present: the post names hosts and plugin makers from a global ecosystem (¶7, ¶8), though it doesn't state locations. - Improve: the post treats the English-language web and a Google search as the discovery model (¶32). Add how non-English users and agents find WordPress, and connect it to translation work. #### Inclusive language - Present: plain, first-person language, with a stated uncertainty ("I might be wrong," ¶11) and a request for other views (¶49). - Improve: "sparkle buttons" (¶22), "dive head-first" (¶10) are informal idioms. Terms like MCP and AGENTS.md need definitions for readers new to the project. #### Neurodiversity support - Present: short paragraphs, section-like breaks, and lists for steps (¶39 to ¶43). - Improve: add a summary at the top listing the five recommendations. The post's structure moves between three layers, five topics, and three user paths, and the capture doesn't show which parts are formal headings. #### Representation - Present: two people are named, James LePage (¶0) and Jordy Meow (¶27), and Core AI contributors are credited as a group (¶0, ¶45). - Improve: the post is one voice and cites no users, site owners, or agency clients beyond the author's own perspective (¶11). The proposal is about users' needs (¶45), and no user data or quotes appear. #### Psychological safety - Present: ¶45 states the post isn't complaining about any project and praises the Core AI contributors, and ¶11 admits the author might be wrong. That lowers defensiveness for the teams named. - Improve: ¶25 describes Siteground's agent reviews as "overwhelmingly negative." A note that the counts are hard to compare (as ¶25 begins to say) would keep that from reading as criticism of a named company. ## ✅ Logical validity Source type: personal opinion and advocacy. The author argues a strategy and labels it a thought exercise (¶11). The post advocates specific products (a Core Abilities plugin, a standalone MCP plugin, WordPress.org pages) and praises one named product (Spacefast, ¶44). The captured text doesn't disclose the author's employer or commercial interests, and this analysis doesn't claim any. #### Strong reasoning - **Gap by contrast, ¶13.** Comparing a CMS Abilities API with no content Abilities to a REST API with no endpoints or a CLI with no commands states the gap in a way a reader can test by listing registered core abilities. - **Dependency reasoning, ¶15 and ¶19.** The argument that AI Experiments shouldn't be a dependency for MCP users, and that MCP does little without Core Abilities, is a clear logical chain. Each step is checkable in the plugins. - **Honest scoping of evidence, ¶24 and ¶27.** The author says it's unclear how many installs are active, calls the conclusion a theory, and notes one comparison plugin includes a chatbot builder and premium offerings. - **Layered value, ¶28 to ¶30.** Assigning premium features to hosts and plugins (governance, audit trails, multisite, rollbacks) follows from the ¶9 goal of room for each layer to earn. - **Stated humility, ¶11 and ¶47.** "I might be wrong" and the note that block markup worries have faded weeks after being raised model calibrated claims about AI. #### Fallacies - **Weak proxy, ¶24 to ¶26.** Install-to-review ratios stand in for real use. Reviews depend on prompts to review, plugin age, and audience, so a low ratio doesn't show inactive installs. Fix: pull active-use data or survey installers. - **Small, uneven sample, ¶24 to ¶27.** Four plugins with different ages ("a fraction of the time," ¶26) and tiers (¶27) can't rank approaches. The author partly concedes this. Fix: a table with install date, tier, and pricing. - **Speculation stated as a point, ¶25.** "install numbers might be even less organic" has no support in the captured text. Fix: name the mechanism (bundling, default activation) and cite it. - **Anecdotal search claim, ¶32.** "A basic Google search shows no core information" depends on the query, date, and personalization. Fix: log the queries and results. - **Bandwagon, ¶17.** Listing Laravel, Shopify, Vercel, and Figma as having MCP support argues from other companies' choices. The link to Spacefast is one of six in the post and the others aren't tied to this list. Fix: cite adoption or usage data for MCP. - **Possible false dichotomy, ¶21 and ¶22.** Dashboard AI versus external agent access is presented as a priority ranking, and the author does allow plugins to fill the dashboard gap (¶28). The tension is mild, and the post is clear that the ranking concerns core. #### Tone of voice - Collegial, candid, and advocacy-driven. First person throughout ("I disagree," "I'd consider," "I might be wrong"). Praise for the Core AI contributors frames each criticism (¶0, ¶45). The register turns urgent in ¶48, where the author says the worry has shifted. ## 🛡️ DARVO analysis Not applicable to this source. DARVO describes a response to accusation, and this post is a strategy proposal with no accuser or dispute. **Deny:** none. The author doesn't deny a criticism. **Attack:** none. ¶15 disagrees with a proposed plugin placement and ¶45 states the post isn't complaining about any project. **Reverse victim/offender:** none. The nearest pre-emptive move is ¶45, which anticipates a reading of the post as criticism and answers it with praise for the Core AI contributors. ## 🎯 Conclusion The post's most useful contribution is a clear description of a gap: core has the Abilities API but no content-management Abilities (¶13), an MCP plugin does little without them (¶19), and WordPress.org offers nothing on managing a site with AI (¶32). The recommended sequence follows from it: Core Abilities plugin, standalone and discoverable MCP, external agent access ahead of dashboard AI, a marketing home with landing pages, prompts, and AGENTS.md files. The weakest part is the market evidence. Install-to-review ratios for four or five plugins (¶24 to ¶27) carry the "outside-in is winning" theory, and the author says the numbers are unclear. The post has six links, none of which cover the install counts, the Google search claim, or the 6.9 Abilities API statement. **Next steps for readers:** check the AI Experiments, MCP, and other plugin pages for current install and review data. Read the [GitHub issue comment](https://github.com/WordPress/ai/issues/40#issuecomment-5843000679) for the Core Abilities placement discussion. If you work on WordPress.org, run the ¶32 search yourself and record the results. ## 🔄 Refactor Appendix — Bringing WordPress AI to the Market > Density: 2–5 Literature atoms (H1 pad), 0–3 Permanent candidates (H4 pad). > Emitted: 4 Literature, 2 Permanent. Resonance filter applied: the plugin-by-plugin install counts > and the branded-plugin idea were dropped as thin evidence or side detail. > > Konik claim-header rules: present tense, declarative, ≤10 words, searchable, unique. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Split Pad #### [H1] Core has no content-management Abilities > [!quote] [¶13] > Yet WordPress core as a content management system has no content management Abilities. **Context & use**: - ¶13, after the author calls the Abilities API (in core since 6.9) the strongest demand signal. - The starting fact for the Core Abilities plugin proposal in ¶14. The claim is checkable against the registered abilities in a current core install, and the post gives no link for it. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H2] WordPress.org needs an official AI position > [!quote] [¶32] > Ultimately, WordPress.org needs to have an opinion on AI. **Context & use**: - ¶32, opening the marketing-home argument that leads to landing pages at /ai, /mcp, and /try (¶39). - The supporting claim is a Google search anecdote with no date or query, so the position is stronger than its evidence. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> #### [H3] Outside-in AI is a theory, not a finding > [!quote] [¶24] > my theory is that ‘outside-in’ AI approaches are winning right now. **Context & use**: - ¶24, following the AI Experiments numbers (50k installs, 9 reviews) and the author's doubt that the installs are active. - Use as a template for stating a hypothesis with its evidence limits. The post's own data (¶24 to ¶27) can't confirm it. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> #### [H4] The worry is agents never recommending WordPress > [!quote] [¶48] > Now I’m more worried that an agent isn’t going to recommend WordPress in the first place **Context & use**: - ¶48, the closing reframe after ¶47 says block markup worries have faded. - This turns discovery by AI agents into the strategic question. A fixed prompt benchmark across agents would measure it. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> ### 🧠 Atomic Split Pad #### [P1] Abilities before adapters **Claim** (one sentence, Courtney's voice): An agent connection to a CMS does nothing useful until the CMS registers the basic abilities the agent can call. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds when the agent needs structured read-write access and no other route (REST, CLI) covers the task. Breaks when existing endpoints already give the agent enough, and the post doesn't compare Abilities with what the REST API already exposes. ¶19 states the same dependency for the MCP plugin. **Links**: - [[Abilities API]] — because extends - [[MCP adapter for WordPress]] — because evidence-for - [[Core AI roadmap]] — because applies-in <!-- atomicity: 1 idea ✓ --> #### [P2] Agents are now a discovery channel **Claim** (one sentence, Courtney's voice): A platform gets recommended by an AI agent only if the platform's own pages tell the agent what it can do. **Evidence pointer**: [[#H2]] · [[#H4]] **Scope & conditions**: Holds when agents read public pages and files such as AGENTS.md when choosing tools. Breaks when agents rely on training data that pages don't change, and the post gives no test of how agents choose. Its search evidence in ¶32 is anecdotal. **Links**: - [[Generative engine optimization]] — because extends - [[WordPress.org information architecture]] — because applies-in - [[Documentation for agents]] — because contrasts on audience, agents versus people <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Run the ¶32 search queries and log dates, queries, and top results #fleeting #inbox - [F2] Open question: is a Core Abilities plugin already scoped, and where does the ¶15 GitHub comment leave the decision? https://github.com/WordPress/ai/issues/40#issuecomment-5843000679 #fleeting #inbox - [F3] Check whether plugin pages show the install and review counts in ¶24 to ¶27 today #fleeting #inbox - [F4] Article seed: "What an agent needs to see before it recommends WordPress" using ¶39 and ¶40 as the outline #fleeting #inbox #articleseed ### → Things 3 (max 2 actions) - [ ] Run and log the ¶32 "use AI with WordPress" searches from a clean browser profile, WordPress AI positioning, 20 min #things - [ ] Read the linked WordPress/ai issue 40 comment and list what it says about Core Abilities placement, WordPress AI roadmap, 15 min #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Bringing WordPress AI to the Market.md|Bringing WordPress AI to the Market by briancoords.com]] ## Highlights - The Abilities API (in core since 6.9) has the strongest signal for demand. We’re already seeing adoption across the ecosystem and we should continue promoting it as the core plumbing for agentic workflows. Yet WordPress core as a content management system has no content management Abilities. It’d be like shipping a WP REST API with no endpoints, or WP CLI with no commands. ([View Highlight](https://read.readwise.io/read/01m3qc00n1awqbb0trad15nk0p)) - Note: [H1] Core has no content-management Abilities - Tags: atom/literature/h1 - If we survey the landscape, the AI Experiments plugin has 50k active installs but only 9 reviews, so it’s unclear how much of these installs are ‘active’ in the way we’d consider it. I’d love to see more data on this because my theory is that ‘outside-in’ AI approaches are winning right now. ([View Highlight](https://read.readwise.io/read/01m3qc05ba25ske6x0n90nw8g7)) - Note: [H3] Outside-in AI is a theory, not a finding - Tags: atom/literature/h3 - Ultimately, WordPress.org needs to have an opinion on AI. A basic Google search shows no core information about how to use AI with WordPress, and the top URLs are taken by third-party plugins that may or may not work for everyone. Much of the information that is available from Core is for building AI tools for WordPress, nothing about managing your WordPress site with AI. ([View Highlight](https://read.readwise.io/read/01m3qc02zzj7pdhhdmdxysf3jx)) - Note: [H2] WordPress.org needs an official AI position - Tags: atom/literature/h2 - Now I’m more worried that an agent isn’t going to recommend WordPress in the first place because it doesn’t know how much it can do with it, because the tools aren’t clearly accessible, and because WordPress.org isn’t telling anyone about it. ([View Highlight](https://read.readwise.io/read/01m3qc07m54zpd63pvnckbjmp6)) - Note: [H4] The worry is agents never recommending WordPress - Tags: atom/literature/h3