I want to talk about the part of DesignSetGo Apps that I think is the most underrated, because it took me a while to fully see it myself.
WordPress 7.0 (May 2026) brought three pieces together: the Connectors API (one place to configure your AI provider), the WP AI Client (a provider-agnostic PHP API for calling the model), and the client-side half of the Abilities API, a way to register functions the site’s AI agent can invoke. The server-side Abilities API actually landed earlier in WP 6.9 (Nov 2025), and Yoast SEO Premium 27.5 was already shipping abilities like analyze_page_seo and suggest_internal_links by April 2026. Plugins are becoming things you talk to, not just things you click around in.
DSGo Apps plugs into all three of those. Apps you build can prompt the model via dsgo.ai.prompt(). No API keys to manage; the site’s configured Connector handles it. That part’s table stakes for any plugin in the WP 7.0 era.
The interesting part is the other direction.
Apps that publish abilities
A DSGo App can declare in its manifest that it publishes one or more abilities:
{
"id": "recipe-converter",
"isolation": "iframe",
"abilities": {
"publishes": [
{
"name": "recipe-converter/convert-units",
"label": "Convert recipe units",
"description": "Convert recipe measurements between metric and imperial.",
"category": "content",
"input_schema": { "type": "object", "properties": { "recipe": { "type": "string" } }, "required": ["recipe"] },
"output_schema": { "type": "object" },
"annotations": { "readonly": true, "destructive": false, "idempotent": true }
}
]
}
}
A few rules worth knowing: ability names are namespaced under your app’s id (recipe-converter/*, never another app’s), and publishing is iframe-mode only in v1, because inline-mode apps run too entangled with the page to host an isolated handler. Max eight publishes per app.
When the app installs, the plugin registers each ability with WordPress’s Abilities API. From that point on, the site’s AI agent (running in wp-admin via @wordpress/abilities) can discover recipe-converter/convert-units and invoke it without knowing or caring that it’s implemented by a sandboxed iframe. The publisher mounts a hidden iframe of your app on demand, dispatches the call across the bridge, and returns the result.
The user asks the site’s agent: “Convert this recipe to metric.” The agent finds recipe-converter/convert-units, calls it, your handler runs in its sandbox, returns structured data, the agent uses the data to answer.
You wrote a few hundred lines of HTML and JS. You got back a function the site’s AI agent can call.
(One honest caveat for v1: the live handler runs in a browser context, because that’s where executeAbility is async and can wait for the iframe roundtrip. Server-side callers like WP-CLI, cron, or PHP-context AI Client invocations get a structured client_only_ability error pointing them at the browser-side surface. The launch demo is the in-admin AI agent, which is browser-context.)
Why this is structural, not a feature
A static iframe app is useful but limited. It’s something a person navigates to. It has a URL. Maybe it’s embedded in a post. It’s a destination.
An app that publishes abilities is something an agent can use. It’s not a destination; it’s a verb. It has a function signature. It composes with other abilities. The site’s AI doesn’t need to know the app exists; it just needs to know recipe-converter/convert-units is a thing it can do, and the rest gets handled.
That’s the inversion. Apps stop being things users find and start being things agents reach for.
A few concrete shapes this enables:
- Vertical packs. A real-estate-themed bundle ships ten apps, each publishing 2-3 abilities (listings search, mortgage math, local market data). Drop the bundle in. Suddenly the site’s agent knows everything about the niche.
- Customer-specific tools. A freelancer builds an agency client a tool that knows their internal product taxonomy, their pricing logic, their bespoke quirks. The client’s site agent calls it the same way it calls SEO abilities, with no special integration.
- Agent compositions. Two apps publishing complementary abilities can be chained by the agent without the apps knowing about each other. You don’t build the integration; the agent does.
The same plugin that installs a calculator can install an ability. The runtime is identical. The trust model (manifest-declared, user-approved at install) is identical. The deploy command is identical.
What this means for DSGo’s strategy
WordPress is going to host a lot of agentic workflows over the next few years. The plugins that win are the ones that make it easy to publish into that surface, not just consume from it. DSGo Apps is built for that. Every app you ship is a potential ability. Every developer comfortable in Claude Code is a potential ability author. Every WP site running the plugin is a potential agent surface.
I didn’t fully appreciate this when I started. The original brief was “let people host vibe-coded apps inside WordPress.” The Abilities side was almost a check-the-box addition during the WP 7.0 spec work. But once it shipped, the implications kept widening. An app isn’t a thing you put on your site anymore. It’s a thing your site can do.
That’s the moat I’m betting on.
Justin
For the manifest fields and validation rules around abilities.publishes, see the manifest reference. For the consume side (dsgo.abilities.list/invoke and dsgo.ai.prompt), see the bridge API reference.
Leave a Reply