Agentic WordPress: How we built 3 plugins in 24 hours

We asked our Newsletter subscribers to tell us what plugin they wish they’d have had time to build, and then we built it for them in 24h. We were only supposed to do 1, but we got more suggestions, so we decided to build them all.

We built these plugins using our reference implementation of the framework that helps organizations move from individual AI usage to organizational AI usage.

The reference implementation can turn a one-paragraph description or a video call transcript into shippable code in ~24h. But this isn’t magic, it’s not a one shot where you sit back and just watch. You have to interact with it, give it direction when there are multiple stakeholder agents that have opposing opinions, you need to review the data flows and the proposed architectural decision records. It’ll ask you questions and it will need human judgment as input, but it takes care of everything an AI can, including drafting the requirements, the acceptance criteria, proposing an architecture, coding it to spec, running reviews, tests, and even sending a video walk-through it created to stakeholders in Slack when it’s done (we’re quite fond of that feature, check them out below).

The framework has five prerequisites: coordination, context, pipeline, harness, and compounding. All five have to be in place for this to scale to a team, but context is the one doing the most visible work here, so it’s worth spending a minute on.

One of the reasons our reference implementation is able to create high quality plugins is the amount of context it has. We’ve greatly expanded upon the core WordPress skills and we have an agent that creates context for existing community plugins. While you can often rely on LSP to guide your coding agents to get off to a good start, it doesn’t always catch everything. It also doesn’t know exactly where each hook runs, which ones are better for which outcomes, and it certainly doesn’t know about known bugs or incompatibilities with other plugins.

Some of this is discoverable, we have an agent that creates initial context for a plugin based on the code, the support pages, guides we find online, potential existing bugs from GitHub, and potential incompatibilities with other plugins flagged in the support forums. But the really useful context is the hard-won context, the kind that only comes from the system making mistakes and either having a reviewing agent fix them or having a human correct them. The feedback loops ensure that this information is part of the context for that plugin going forward.

Our reference implementation has built over 100 plugins by now, many of them automated runs whose sole purpose was to create context for community plugins or for WordPress in general. That accumulated context is why the output looks the way it does. The infrastructure (agents, review gates, orchestration) is relatively straightforward. The context is what compounds. Your implementation would build its own as you use it: knowledge of your codebase, your patterns, your stakeholders’ priorities.

We’ll probably redo this stunt in a few weeks. If you want in on the next round, sign up for email updates or follow us on LinkedIn, that’s where we’ll be capturing suggestions.If you’re curious about how we’d help your team build something like this, reach out, happy to chat. Or start with the framework if you want the longer version first.