PLATE 01
An open-source agent system that drafts, illustrates and optimises posts inside the WordPress editor

PLATE 01

AgenticWP

ROLE
Sole developer
STACK
PHP · React · REST · OpenAI language and vision models
LINK
agenticwp.org
InterfaceBlock editor, ReactOrchestrationPrompt design, toolcallsQueueBackground jobs,retriesModelsLanguage and visionDistributionWordPress plugin,PHP, REST

BRIEF

A set of agents that live inside the WordPress block editor, where they draft posts, generate the images to go with them, and revise what is already published. It is for people who write on WordPress and would rather the drafting work happened in the editor than be pasted in from somewhere else. The plugin is free and every user brings their own model key.

DECISION LOG

  1. Blocks, not markup

    The generator emits real editor blocks rather than markdown or HTML converted after the fact.

    The reason is editing, not generation. Because output is blocks, an agent can modify any existing post without breaking its formatting, and any custom styling a user has already applied to their blocks is inherited by the blocks the agent creates. Converted markup would have produced content that looked right on publish and was inert the moment anyone tried to edit it — and it would have discarded the user's own styling every time an agent touched a post.

  2. One orchestrator, several specialists

    An orchestrator assigns work to a set of agents, each carrying its own tools and its own instructions.

    The alternative was a single agent holding every tool behind one long instruction set. Splitting bought two things: tasks run in parallel, and each agent carries narrower, more focused instructions than a generalist can hold without drift.

  3. The assistant must not be the bottleneck

    Generation runs as orchestrated background jobs with retry, rather than sequentially inside the request.

    Sequential execution worked and was too slow — and the slowness changed what the thing was, from an assistant you work alongside into a tool you wait on. Moving the work to background jobs let the agent keep responding and keep taking new instructions while long tasks ran. The architecture followed from how the interaction needed to feel.

  4. A key you own, not one I rent

    Users supply their own OpenAI key and pay OpenAI directly. No server of mine sits in the path.

    The alternative was proxying inference and bundling the cost into the plugin. Owning the key is the only way the plugin stays genuinely free without me funding everyone's usage. It costs real things: no rate limiting, no usage visibility, and no central place to debug a failing call. Support is harder, because failures happen between the user and OpenAI where I can't see them.

  5. Progress you can see

    Achievements, experience thresholds, publishing streaks and a progress dashboard.

    An unusual thing to build into a plugin, and it is there to solve a writing problem rather than a technical one: these mechanics keep people returning to drafts, improving what they have written, and holding a publishing schedule. The work the plugin automates is only useful if the habit around it survives.

DETAIL PLATES

Orchestration
Four specialists under one orchestrator, each holding its own task and its own state. A tool call is in flight and a queued job is retrying while the editor keeps taking input.
DETAIL A · OrchestrationFour specialists under one orchestrator, each holding its own task and its own state. A tool call is in flight and a queued job is retrying while the editor keeps taking input.
Interface
Real editor blocks rather than converted markup: the selected block carries the block toolbar and its own handles, and the styling applied elsewhere in the post repeats on it instead of being replaced.
DETAIL B · InterfaceReal editor blocks rather than converted markup: the selected block carries the block toolbar and its own handles, and the styling applied elsewhere in the post repeats on it instead of being replaced.

CONSTRAINT

The plugin had to be free, and I was not going to fund everyone's inference.

That single constraint removed the server. With no middleman in the path, cost control, privacy and failure handling all stopped being infrastructure problems and became design problems — the user holds the key, the user sets the spending limit, the content goes straight to the model and nowhere else, and every failure has to be legible in the editor because there is no log of mine to read it from.

DELIBERATE BOUNDARIES

  • Block editor only

    Classic Editor is not supported and will not be. Supporting it would mean emitting the converted markup that decision one exists to avoid.

  • You bring the key

    Real friction at install, and the price of the plugin being free. There is no trial tier, no bundled usage, and no path that avoids the OpenAI account.

In progressPLATE 02