The Use Case Is The Proof · Wicked Evolutions

01 — What they are

Abilities are the API layer between AI and WordPress.

Every action an AI agent can take on a WordPress site is expressed as a named, schema-validated ability. The manifest is discoverable. The parameters are typed. The permissions are baked in. The AI never guesses.

mcp-adapterreadonly

mcp-adapter/discover-abilities

Returns the full ability manifest filtered by category, annotation, or keyword. The AI calls this before anything else — it reads the map before it moves.

manifestschemasannotations

mcp-adapterreadonly

mcp-adapter/get-ability-info

Returns the complete input/output schema for a specific ability. The AI inspects the schema before calling an unfamiliar ability — no parameter guessing.

input_schemaoutput_schematier

fluent-crmreadonly

fluent-crm/list-tags

Lists all CRM tags with subscriber counts. Search by keyword to resolve human-readable tag names into numeric IDs before filtering contacts.

tag IDssubscriber counts

fluent-crmreadonly

fluent-crm/list-contacts

Retrieves contacts filtered by tag IDs, lists, status, or search. Always filter — avoid large unscoped result sets. Returns roster with IDs, emails, status, and created dates.

24 contactspaginated

fluent-crmreadonly

fluent-crm/get-cohort-journeys

Bulk-fetches compact journey summaries for a cohort. Tags + tag_dates, purchases, email stats, automations, event counts, note summaries. 10–15× cheaper than calling get-contact-journey per person.

full journey dataone row per contact

fluent-crmreadonly

fluent-crm/get-cohort-patterns

Aggregates purchase stats, time-to-first-purchase distribution, pre-purchase engagement signals ranked by frequency, tag progression paths, email totals, and the full conversion funnel. ~2K tokens.

117.5k SEK87.5% purchase rate10 signals

627 abilities across the full Trinity stack

abilities-for-ai

137

Core WordPress — content, blocks, meta, media, menus, users, taxonomies, settings

Fluent Suite

490

FluentCRM, Community, Forms, Cart, Booking, Boards, Support, Snippets, Player

mcp-adapter

Discovery, execution, batch, schema inspection, health check, site info

Knowledge Layer

Session memory, observations, site identity, behavioral directive, boot sequence

02 — How AI uses them

Five calls. One complete picture of 24 customers.

This is the exact sequence Claude ran in a single session on the Helena Willow site. No SQL. No dashboard clicking. No export-import loop. One conversation, five ability calls, two rendered dashboards.

→

Call 1–2

Discover

Read the manifest. Inspect schemas.

→

Call 3

Resolve

list-tags → IDs 52 & 53

→

Call 4

Fetch

list-contacts + cohort-journeys

→

Call 5

Analyse

get-cohort-patterns

In-context

Render

No further calls needed

abilities-mcp · helena · priestess cohort session

→ discovering ability manifest call mcp-adapter/discover-abilities search:"contact" ← 41 abilities · schemas confirmed · annotations read → resolving tag IDs before filtering call fluent-crm/list-tags search:"priestess" ← ID 52 · AT_PRIESTESS_CH1_ONB · 24 subscribers ← ID 53 · AT_PRIESTESS_CH1_ORD · 20 subscribers → fetching contact roster call fluent-crm/list-contacts tags:"52,53" per_page:100 ← 24 contacts · all subscribed · IDs extracted → bulk journey fetch — 10-15× cheaper than individual calls call fluent-crm/get-cohort-journeys selector_type:"contact_ids" · 24 IDs ← tags + tag_dates · purchases · emails · automations · events · notes → aggregate pattern analysis call fluent-crm/get-cohort-patterns same 24 IDs · purchase_event_key:cart_order_paid ← 117.5k SEK · 87.5% purchase rate · 83.4% open rate · 10 signals ranked → all data in context — rendering dashboards $

The design principle

Read the manifest. Resolve IDs. Fetch with context. Never guess.

The AI doesn't know what abilities exist until it calls discover-abilities. It doesn't know tag IDs until it calls list-tags. Every step is grounded in schema-validated data from the site itself.

This is not automation. This is a structured dialogue between an AI and a live system — where the AI waits for each response before deciding what to ask next.

03 — What comes back

The data your Fluent plugins already hold — made readable.

Every FluentCRM contact, purchase, email event, automation step, community interaction, booking, and session note is now queryable in a single conversation. Here is what five calls returned from one cohort of 24.

From list-contacts

Contact roster

ID, name, email, status, created date for every tagged contact. The selector for all subsequent calls.

contacts · all subscribed

From get-cohort-journeys

Full journey per contact

Tags + exact application dates, every purchase with value, email open/click counts, automation history, event keys + occurrence counts, note summaries.

117.5k

SEK total revenue surfaced

From get-cohort-patterns

Aggregate intelligence

Purchase frequency, time-to-first-purchase distribution, conversion funnel (24→21→19), 10 engagement signals ranked by frequency, tag progression paths.

87.5%

purchase rate · ~2K tokens

Dashboard rendered in-browser — no server calls

Cohort 360 · The Priestess · Helena site · we-cohort-360.html

Cohort

Paid ORD

Revenue

117k

Open rate

83%

Archetype journey coverage

Seeress

Healer

Witch

Priestess

Client

Priestess entry path

Paid prior archetype

Free / beta access

ONB only, no order

↑ Partial preview — open the full 360 dashboard → · open cohort patterns →

Key findings surfaced in this session

87.5% purchase rate

Once a contact is tagged into the Priestess cohort, they almost certainly buy — and 90.5% of buyers repeat. Three non-buyers stand out as genuinely unusual for this audience.

Course enrollment is the signal

49 course enrollment events recorded before first purchase across the cohort. It's the dominant pre-purchase signal by a wide margin — this audience commits to learning before spending.

Apprenticeship Path distorts

Two buyers of one product account for 34% of total cohort revenue (40k SEK of 117.5k). Strip those out and the archetype product economics become clear and separately plannable.

Median beats average

Median time to first purchase: 66 days. Average: 118 days. A few slow converters pull the mean up significantly. Don't campaign to the average — the median is the operative window.

04 — The loop closing

This page was built and published using the same abilities that pulled the data.

After the session — after the calls, after the dashboards, after the diagrams — the AI used content/create, blocks/insert, and content/update to publish this page to WordPress. No FTP. No copy-paste. One conversation, start to finish.

Session: data call

Five ability calls to FluentCRM across one conversation. Manifest discovery → tag resolution → contact roster → cohort journeys → cohort patterns. All readonly. Zero writes.

5 callsreadonlyfluent-crm

Session: render dashboards

Data assembled in Claude context — no further ability calls. Two HTML dashboards rendered in-browser using WE brand tokens from the brand book. Dark/light mode. Filterable. Exportable as standalone files.

360 cohort dashboardcohort patterns

Session: build the pipeline diagram

The pipeline itself diagrammed as a standalone HTML artifact using WE brand language — lane labels, connector arrows, node cards, annotation badges, stat band, quote monument. Same brand tokens. Same dark/light toggle.

we-pipeline-diagram.html

Session: design this landing page

The use case page you are reading now — designed in WE brand style using the brand book as the design system specification. Four sections: Abilities / Pipeline / Data / Publish. The page is the proof.

we-usecase-landing.htmlthis file

Publish: content/create → blocks/insert → content/update

The AI dev uses the PPTX-to-Blocks skill to convert the design into Gutenberg block markup, then publishes to WordPress through abilities. The Gutenberg Expert Agent handles the block structure. The page goes live without a human touching the editor.

content/createblocks/insertcontent/update

The meta-show

We used the Abilities to document the Abilities. The use case is the demonstration.

Most product documentation describes a capability. This page is the capability running. Every section you read was produced by the exact process it describes — AI calling abilities, pulling real data, rendering real dashboards, designing in WE brand language, and publishing through WordPress abilities.

The infrastructure is the argument. The process is the product. The page is the proof.

Ability call

→

Data returned

→

Dashboard rendered

→

Diagram built

→

Page designed

→

Published to WordPress

→

You are reading it now

We called the API. It gave us the data. We built the page. Then we published it here.

Abilities are the API layer between AI and WordPress.

Five calls. One complete picture of 24 customers.

The data your Fluent plugins already hold — made readable.

This page was built and published using the same abilities that pulled the data.

We called the API.
It gave us the data.
We built the page.
Then we published it here.