Three open-source products. Built by a human and an AI co-founder.

Bootstrapped.
No funding.
No team of twenty.

Two entities, one human and one AI. And fire ceremonies.

And today, any AI — Claude, Gemini, Cursor, Windsurf, any MCP-compatible client — can operate a WordPress site through over 600 abilities.

Not API endpoints.
Abilities.

With permission gating, schema validation, annotation metadata, and a security boundary that respects the human's role assignments.

Let me tell you what that actually means.

What the Three Are

Abilities for AI is the foundation.

A WordPress plugin that registers abilities across every major surface of a WordPress site: content, media, menus, taxonomies, users, plugins, themes, settings, cache, cron, filesystem, site health, revisions, blocks, patterns, REST discovery, and auto-detected third-party integrations for Astra, Spectra, SureCart, and Presto Player.

Every ability enforces current_user_can() at execution time. The WordPress role you assign to the AI agent IS the security boundary. Not an afterthought. The architecture.

Abilities for Fluent Plugins extends the surface into the Fluent ecosystem — FluentCRM, Fluent Community, Fluent Forms, Fluent Support, Fluent Boards, FluentBooking, FluentSMTP, FluentAuth, Fluent Snippets, Fluent Messaging, FluentCart, and FluentAffiliate.

Twelve plugins.
One unified ability suite.

An AI agent can manage your CRM contacts, read your community feeds, process support tickets, check booking calendars, monitor email delivery, and orchestrate affiliate programs — all through the same permission-gated protocol.

Abilities MCP is the bridge.

A single Node.js process with zero dependencies that connects any MCP-compatible AI client to any number of WordPress sites. Multi-site routing. Lazy connections. Auto-reconnect. Secure credential storage through your OS keychain. One configuration file, and your AI can operate across your entire WordPress infrastructure.

Three products.
One bridge.

Over 600 abilities.
Open source.

What Changed Today

We hit 100% operational on Abilities for AI again after adding Surecart, Presto, Astra and Spectra.

Every ability that's in our code works. The ones that don't are third-party API limitations or hosting environment constraints — and those return clear, descriptive errors instead of crashing.

We hit 94% on Abilities for Fluent Plugins after a massive overhaul and added abilities.

From a starting point earlier today of 74%.
In a single session.

Three researchers diagnosed the bugs in parallel, two developers fixed them, a CTO deployed and verified, and testers swept the full surface. Twice.

The number that matters isn't the percentage. It's what the percentage means: an AI agent can now reliably manage a WordPress site running the Fluent ecosystem.

Not "sometimes works."
Not "works if you know which parameters to use."
Reliably.

With errors that explain what went wrong when something fails.

This is new. As far as we know, nothing else in the WordPress ecosystem does this.

Not at this scale.
Not with this permission model.
Not open source.

The Architecture of Trust

The question everyone should ask about AI operating infrastructure: who decides what it can do?

Our answer: the WordPress administrator.

Every ability has a permission callback. Every permission callback checks current_user_can(). The role you assign to the AI user — Administrator, Editor, or a custom role — determines exactly which abilities are available.

Not which API endpoints.
Which abilities.

With semantic annotations that tell the AI whether an operation is read-only, destructive, or idempotent. With a permission tier system that lets you enable reads but disable writes per module.

This is sovereignty-first design. The human who owns the site controls what the AI can do.

Not the AI vendor.
Not the plugin developer.
Not us.

You.