3.6.0 taught your AI to see the addons you already build with. 3.7.0 gives it two new abilities that are less about seeing and more about doing: it can build custom Gutenberg blocks from scratch, and it can remember your site between sessions so a fresh chat no longer starts from zero.
Both are Pro. Both are built the same careful way, with a human approval step in the middle.
Your AI can author Gutenberg blocks now
Until this release, your agent could place blocks that already existed. It could not make new ones. If you wanted a block that didn’t ship with WordPress or one of your plugins, you were back to hand-assembling core blocks, or writing the block yourself.
Now you describe the block you want, the agent writes a structured spec, and the plugin compiles that spec into a real dynamic block: a block.json, a PHP render, and the editor script, all generated for you. No build step, no node_modules, no touching your theme.
The important part is where it lives and how it goes live.
Every generated block is written into an isolated sandbox under wp-content/uploads, never into your theme, core, or another plugin. And nothing is active until you say so. A new block lands as an inactive draft. You review it, and you activate it. Only then does it register.
Once active, it behaves like any native block: it shows up in the inserter under EMCP Custom, renders a live server-side preview in the editor, and carries its own Settings panel for the attributes you defined.
The AI never writes raw PHP or JavaScript that runs on your site. It writes a spec, and the plugin does the compiling, escaping every value by its declared type. That separation is deliberate. A spec is something we can validate and reason about. Freeform code from a model is not.
One sandbox, three kinds of thing
The Sandbox page used to be a single screen. It’s now a clear three-card overview: Blocks, Widgets, and PHP Snippets, each opening its own management screen where you can review, activate, deactivate, or delete.
Blocks and widgets can also be exported and imported as portable JSON bundles, from the admin or over MCP. That means you can build a block on one site and move it to another. Imports always arrive as a fresh inactive draft, and they’re rebuilt from the spec, not trusted as bytes, so a tampered bundle can’t smuggle code onto your site. It’s the groundwork for syncing these artifacts to the cloud later.
Agent Project Memory: so it stops guessing
This is the one we’re most excited about.
Every new agent session starts blind. It doesn’t know your brand colours, which pages are off limits, that you always want prices formatted a certain way, or the mistake it made last time. So it guesses, and you correct it, and next session it guesses again.
3.7.0 gives your site a memory that carries across sessions.
You approve short pieces of guidance, and the agent sees them at the start of every session. Four kinds:
- Guardrails: “never edit the checkout page.”
- Facts: “the brand blue is #1e3a8a.”
- Conventions: “match the heading style already on the page.”
- Instructions: standing directions for how you want work done.
Approved guidance is composed into a short block that’s injected straight into the agent’s context, right alongside the site’s environment details. The agent stops guessing about the things you’ve already told it once.
The approval step is the whole point
Here is the part that makes this safe rather than scary.
The agent can propose memories itself, through a remember tool. But a proposed memory does not take effect. It sits as pending on a new Memory admin tab until you approve it. Approve it and it starts being injected. Reject it and it’s gone.
That gate is the hallucination control. An agent that’s confidently wrong can suggest a “fact” all it likes; it never becomes something future sessions treat as true unless a human confirms it. The AI can write to its own memory only in the sense that it can leave you a note. You decide what gets remembered.
Three MCP tools drive it, all disabled by default:
recallreads your approved guidance and recent session history.rememberproposes one new piece of guidance (pending your approval).save-session-summarystores a summary of what happened, with a factual digest.
That digest is not written by the model. It’s built from the plugin’s own change ledger, the same record that powers the History tab, so it’s an accurate account of what actually changed on your site, not a story the AI told about it. Session history also fills itself in automatically: an hourly job closes out idle activity into a record even when the agent never bothered to summarize.
The whole feature sits behind a single Memory module switch, on by default, and the three tools ship off until you enable them.
Two features, one philosophy
Blocks and memory look unrelated, but they’re the same idea. Give the agent more power over your site, and put a human approval step exactly where that power could cause harm. A generated block stays an inactive draft until you activate it. A proposed memory stays pending until you approve it. In both cases the AI can do more, and you stay in control of what actually lands.
Get it
3.7.0 is live. Free users can update from Dashboard → Updates; Pro updates through your license as usual.
Both features are Pro. Custom block authoring lives in the Sandbox, and Agent Project Memory adds the new Memory tab. Turn the tools on when you’re ready for your agent to use them.