We are working on one of the biggest updates we have ever built: AI Agents as WordPress Users.

This idea has been around for a long time. We actually started working on it quite a while ago, but we decided to put it on hold so we could focus our resources on improving the user experience. A few days ago, we rebuilt a the pull request, redesigned several parts of the feature, and now it is finally in the testing phase.

And honestly, we believe what is coming is going to be huge.

AI Needs an Identity

Most WordPress websites are managed by a single administrator. One person writes the content, manages plugins, updates the site, and takes care of everything.

Of course, there are also large websites, such as online newspapers or enterprise platforms. where many people work together every day.

No matter the size of the website, the idea behind this feature is the same.

Today, there are many AI tools available for WordPress. They create content, edit posts, delete data, update settings, and automate tasks. But they all share the same problem: they are not traceable.

Even worse, they usually don’t have a proper permission system. If an AI agent has access to the wrong tools, a simple mistake could cause serious damage to your website.

AI Agents as WordPress Users

Our next release focuses on three key concepts:

• Traceability
• Permissions
• Identity

Instead of running as anonymous AI assistants, agents will become actual WordPress users.

You will be able to create a dedicated WordPress account for each AI agent, define its identity, configure its instructions, and decide exactly which tools and permissions it should have.

Each agent will have a clear role, just like any other member of your team.

Every Action Is Recorded

Because agents work through real WordPress users, every action becomes traceable.

You’ll know:

• When an agent edited a post.
• What content it changed.
• What it deleted or created.
• Which actions it performed during its work.

This gives you complete visibility into everything your AI agents do, making automation much safer and easier to trust.

Imagine a Different Workflow

Picture this.

You’re in your WordPress Desktop (yes, the place we all used to call wp-admin).

There is a new section called Agents.

Inside, you have several specialized agents:

• An SEO expert.
• A grammar and style reviewer.
• A translator.
• An image optimization assistant.
• Or any custom agent you create.

Now imagine you have a post ready to review.

Instead of opening prompts or copying and pasting text into different tools, you simply drag the post onto one of your agents.

The agent immediately starts working.

Or imagine an even more natural workflow: you simply right-click on a post and select “Send to Agent Spanish Translator”. The chat window will open, the agent will start to work autonomously, and it will create a Spanish version of the post, exactly with everything you have asked for defined in its behaviour.

Once it’s finished, every change is recorded. You can review exactly what it modified, what decisions it made, and when the work was completed.

Everything is transparent.

Everything is traceable.

This Is Just the Beginning

This update is about much more than letting AI edit WordPress content.

It’s about giving AI agents a real identity inside WordPress, with their own permissions, responsibilities, and complete activity history.

We believe this will unlock entirely new workflows that simply weren’t possible before.

And this is only the beginning.

The WICG HTML in Canvas proposal lets you draw real, live, styled HTML directly into a <canvas>. No screenshots, no html2canvas, no invisible DOM overlay that you have to keep in sync by hand. All of this is implemented behind a flag in Chromium and can be enabled at chrome://flags/#canvas-draw-element.

The moment I understood what that meant, I knew where I wanted to take it. I am building Desktop Mode, a WordPress plugin that turns /wp-admin into a desktop operating system with real windows, drag and drop, a dock and widgets. And a window is just a rectangle of HTML. What if that rectangle could also be a piece of cloth?

First attempt: a wall, and then a thread

A month ago I did a first exploration. I never published it, because it did not work. Desktop Mode uses Web Components, and nothing rendered.

My first reaction was the usual one: I must be doing something wrong. It took me a while to accept the other possibility, which is that the API itself was not ready. So I opened the repository, found the issue about Slots, Shadow DOM and Web Components, and I asked for help. It turned out that Google engineers were already working on it.

Yesterday I suddenly remembered the thread and went to check. The fix had landed in Chromium and had been deployed to Canary two or three days earlier.

Eight hours later, my windows were made of pixels.

What happens when a window becomes a canvas

Once drawElementImage renders a live admin window into a canvas, that window stops being a fixed box on a page and becomes material you can work with. The DOM keeps doing what it does well: layout, text, accessibility, form controls. The canvas takes that result and does whatever it wants with it.

• Windows as cloth. A window can bend, wave and fold, because it is a texture now.
• Disintegration. Closing a window can be the Thanos snap. The window breaks into thousands of particles that drift away and disappear.
• Recomposition. The particles can come back. Reopen the window and it reassembles itself.
• A different render pipeline. I swapped the whole output through a shader so the entire desktop looks like an old CRT television, with scanlines, curvature and that soft glow tube screens had.

The posts list is still the posts list. The buttons are still buttons. They just happen to be made of dust, or displayed on a cathode ray tube.

None of this is a new idea, by the way. Anyone who ran Linux around 2007 remembers Compiz on Kubuntu: the rotating desktop cube, the wobbly windows, the windows that burned away when you closed them. This post from 2007 captures the feeling perfectly, and it is honest about the point of it all, which is that desktop effects are not practical at all, they are simply fun. Nearly twenty years later I am doing the same thing, except the desktop is /wp-admin and the window manager is a browser.

Try it yourself: the experimental branch lives here: GitHub

You will need Chrome Canary with chrome://flags/#canvas-draw-element enabled. Go and break it. Fork it, make something stranger than what I made, and tell me about it.

Is this as big as CSS3?

I keep going back and forth on this one. CSS3 changed every website on the internet, and the reasonable objection is that HTML in Canvas will not. It is behind a flag, it is only in Chromium so far, and most sites will never need it.

But this technology has not even left the experimentation phase, and judging its ceiling by the first few months of demos is historically a terrible way to predict anything. There is also one difference that makes me lean the other way: CSS3 gave us more expressive power inside a model we already had. HTML in Canvas removes a wall between two models that have been separated for twenty years. It is a new primitive, and there are things you can do with it that have no CSS equivalent at all.

Eight hours

That number is the real story here.

Eight hours is not enough time to read an experimental specification, understand a shadow DOM bug at the compositor level, write a particle system, write a CRT shader, and wire all of it into a plugin with more than one hundred thousand lines of code. Not for one person, not five years ago.

What changed is that AI tools removed most of the distance between having an idea and being able to test it. They help you synthesise: to hold a scattered set of half formed intuitions, a specification you read once, an error message and a vague visual memory of how a CRT screen looked, and turn all of that into something you can run. The creativity is still yours. Nobody suggested to me that a WordPress window should disintegrate like Thanos snapped his fingers. What the tools give you is permission to follow the strange idea instead of abandoning it because it would cost you three weekends.

About Desktop Mode

Desktop Mode is a WordPress plugin with more than one hundred thousand lines of code. It uses the state of the art of what the web platform can do today, it is in continuous development, and it gets better every day thanks to the feedback of the people who use it.

Thanks to Automattic and to Matt for always pushing at the frontier of what is possible. Work like this only happens when someone keeps the door open to experiments that have no guaranteed answer.

• Development blog: openstation.blog
• GitHub repository: github.com/WordPress/desktop-mode
• WordPress plugin repository: wordpress.org/plugins/desktop-mode

Install it, open a window, and then close it. You will see what I mean.

Further reading

The Chromium fix that made it possible

WICG HTML in Canvas explainer

Exploring the HTML in Canvas Proposal, on Codrops

The issue thread that started this experiment

Hello! 👋🏼 I’ve just joined the project as a designer, and before I start diving into any kind of work, I wanted to write about my first impressions trying the plugin, since so far I’ve only seen the demo videos.

I have to say, I feel like a kiddo unboxing a new toy right now, so… expect a bit of chaos in this post. I will be sharing ideas and feelings in no particular order. 😀

To make it very real, I’m using my beloved unkai.blog: it’s my content and my ways of working, so I’m familiar with the surroundings.

Let’s dive in!

Onboarding

Unkai.blog is hosted at WordPress.com, so the only thing I had to do was search for the plugin, install it, and activate it. Super easy.

After that, you are welcomed with this splash screen:

My first reaction was: this is done with AI. Which is totally fine, the project is still young, and most of the branding and design isn’t defined yet, but I think this could be delivered with less text and more showing.

💡 Maybe we could use a slider like the one we use on the editor:

Into the dashboard

Then I went straight into the dashboard. This view made it crystal clear I could move things around, resizing, minimizing, and so on. I love the UI affordances 💖 it really looks like an OS, so I started to click literally everything…

But when I minimized a window, I expected it to fold down into the bottom dock, with an animation like the macOS Finder. Nothing really happened. Luckily I’m familiar with the wp-admin icons, so I knew where to click, but I wonder if we could give a bit more guidance through animations, as long as it helps and keeps accessibility in check.

💡 Add minimize/maximize animation. It would help with usability (affordances) and with learning where things are kept.

Managing content

When opening all my posts, I expected to see a table like the one you see in Posts. I found the pin icons a bit redundant (perhaps we could show the post cover instead?) and the draft tag a little too prominent.

And here’s an idea that got me hyped—could we drag things into things? 😀 I always struggle with sorting content into Categories/Tags, so I’d love a quick way to select a bunch of posts and quickly move them from one window to another.

I absolutely loved the whole flow: sticky note → draft, but it’s a pity that the sticky note disappeared after opening the editor. I’d like to keep both and delete the note myself — like I do in real life.

And the last one (I promise).

Is there a way to save the existing setup/view? I ended up liking my desk combination very much, but if I close and come back tomorrow, what happens? I think you can set each widget individually, but it would be cool to do a “group” save.

That’s all for now. Amazing work @prismiwi2015 @roberto @miguel @nick 💖 I’m super excited to get hands-on with the design part, but I have to say you got so much ground covered! Kudos!

We’re excited to announce Desktop Mode 0.9.6! This is another huge release, packed with new features, UX improvements, performance optimizations, and bug fixes.

This version also celebrates our amazing open source contributors. Many of the improvements in this release come directly from community contributions, and we’re proud to introduce a new Contributors section on this blog to recognize everyone who helps make Desktop Mode better.

THANK YOU!

The previous release was already one of our biggest. Somehow, this one is even larger.

We’re working hard to deliver the features people ask for while fixing as many bugs as possible. Looking at everything included in 0.9.6, we think we’re moving in the right direction.

Let’s start with the fun part.

🎮 Games

Desktop Mode now includes a game framework.

Think of it as a small version of Steam built directly into WordPress. It provides everything needed to create games inside Desktop Mode, including invitations, leaderboards, play time tracking, and even a shared dictionary that developers can use to build word games.

The first two games are available today:

• InkFall
• Alphabet Soup

We can’t wait to see what the community creates next.

🤖 AI

We’ve redesigned the WordPress Command Palette and fully integrated it with the AI Assistant.

Everything is now unified in a cleaner interface that is faster, simpler, and much easier to use.

📁 File Manager

Turn your WordPress installation into your own cloud storage.

Create folders, upload files, organize your content, and download entire folders as ZIP archives.

We’ve also improved the upload window experience, making file management much smoother.

📝 Notes

Notes have become much more powerful.

You can now pin notes to your desktop, share them with other WordPress users, and even create a new post directly from a note.

And yes… they also look beautiful.

✨ Better User Experience

Editing content is now much easier thanks to a new relationship system.

When you open a post, Desktop Mode can automatically show related information such as:

• Comments
• Categories
• Tags
• Other posts linking to the current post

Everything you need is only one click away.

⚡ General Improvements

Desktop Mode 0.9.6 also includes many improvements across the entire project:

• Better loading states and improved accessibility for the Desktop Mode Controls Library button.
• Improved window minimization, dock badges, and window states (minimized, active, unfocused, and more).
• Selecting a window from Overview Mode no longer maximizes it automatically.
• The WordPress Admin Bar now hides while using Focus Mode.
• Fixed folder renaming, which previously required refreshing the window.
• Fixed a regression in our heuristic window generation system that affected plugins such as Advanced Custom Fields (ACF).
• Improved overall plugin performance.
• Improved the authentication system.
• Many bug fixes and stability improvements across Desktop Mode.

Desktop Mode continues to evolve with one goal: making WordPress feel like a modern desktop operating system.

Thank you to everyone who reports bugs, suggests new ideas, contributes code, or simply uses the plugin every day.

See you in the next release 🚀

👀 P.S.

You may have noticed the little eye icon that now appears at the end of the last screenshot window’s title bar…

You may have noticed the little eye icon that now appears at the end of the last screenshot window’s title bar…

Well…

That’s for the next release. 🙂

Stay tuned.

Desktop Mode needed an initial proof of concept. As I mentioned before, I had never published a serious plugin in the WordPress repository. I had built a few small custom plugins for friends and family, but never anything that I would call a real plugin.

To start the project, I simply asked Claude to add a button to the WordPress admin bar. When clicked, it would collapse the WordPress sidebar into an icon-only menu, and clicking it again would restore the text.

But that first prompt also included an initial claude.md file. In that file, I described my vision of what Desktop Mode would become: a WordPress plugin that would turn wp-admin into a desktop environment for multitasking, with multiple windows and multiple users.

That was it. Thirty seconds. Boom.

It worked on the first try, what people call a “one-shot”. I loved the result. It was exciting. It became the seed of Desktop Mode, and it was only a tiny piece of code that wasn’t difficult to understand or particularly large.

It’s a shame that during those first three days of development I didn’t make a single commit or push. The original claude.md is gone, and the one I linked above is already a much more evolved version.

The next step was asking Claude Code to stop showing plugins in the WordPress sidebar and move them into a macOS-style Dock instead.

Boom. Another one-shot. I was genuinely excited.

The next thing that really validated the proof of concept was asking it to open everything inside iframes. That one wasn’t a one-shot. I actually had to debug a bit, inspect the network requests, and “understand” how WordPress moved data around.

The beginning wasn’t:

Claude, turn wp-admin into a desktop operating system with windows. Make no mistakes.

It started with a single button. And today, I’m using it even to write this post:

Ins’t that amazing?

I’m incredibly lucky to be part of a Slack conversation with Matt Mullenweg, and I’m receiving a lot of pearls of wisdom. I use the word “pearl” because it reminds me of the book Programming Pearls, but mainly because they are small principles that are simple but shiny, and I see immense value in them.

One of them proved useful just today, as I was “using the product” (as Matt recommended) and identified a bug I don’t think I would have encountered otherwise.

You could think that it is obvious, and that of course you should use your product, but if you are not intentional about it, it is easy to get lost in adding all the technical features that you think the product needs, and working the whole day improving and extending the product, but not spending that much time using it.

So now you know, use the product.

It was a morning in April, and everything looked like it was going to be a normal day. I would keep working on internal tools at Automattic, because my current role is Applied AI Engineer. We build internal tools that push our internal workflows to the max (The amazing HAL team, Lead by Sirin Odrowski). We build a framework to create workflows that is really impressive, and it lets us do amazing things inside Automattic, but it’s proprietary software, only for internal use.

But no, it was not a normal morning. Matt Mullenweg had just announced “RSM” (Radical Speed Month). (For more information, you can read this great article from The Repository: Automattic’s Radical Speed Month Wraps Up)

I panicked, and for a couple of days my head was full of ideas, but none of them felt “big” enough to fill an entire month (yes, I still have other ideas waiting, don’t worry :D). In the end I decided to go for something else: rebuilding wp-admin, after more than 10 years without a real change.

Do you know how it all started? By asking for help, almost desperately, from a coworker 😀 My vision didn’t seem to match what others expected, and my colleagues couldn’t quite see the genius of the idea: recreating an operating system while keeping WordPress’s core strength, its extensibility and its plugin ecosystem. Treating plugins as apps, not as “extensions.” A real window system. Maybe my coworkers saw it as too ambitious, and since “word of mouth” wasn’t working for me, I built the first prototype in just 3 days (and nights).

When you believe in your product, when you feel that excitement, and you know deep down that it’s something great, nothing can stop you.

I’m a WordPress developer, I know PHP, and I know many other languages after more than 20 years as an engineer and 10 years as an enthusiast (I started programming my own video games when I was only 10 years old). But I had never built a plugin or a theme before, and I started with a plugin that would eventually reach more than 100,000 lines of code 🙂

The Alcazaba Project (Desktop Mode)

What came next were HOURS and HOURS of excitement. I wouldn’t even call it “programming,” because every line of code felt like a small joy, and every proof of concept that worked gave me a feeling I can’t really describe.

And all of this… thanks to AI tools (I even spent $2,000 in just a couple of hours).

The idea-pitching period was coming to an end, and Matt suggested that projects should be built in pairs. My fear kept growing, but my idea was already quite advanced, so I published the demo that would convince Matt, deciding the fate of Desktop Mode. I worked day and night, and after many hours without rest, I recorded a video of myself explaining what I had built, trying to find a partner who could help me carry out my vision.

I published the demo, and deep inside I knew it was going to cause a stir. But I decided to clear my mind, so I walked down to the market, five minutes from my house, to buy a few things and get something to eat.

And that’s exactly what happened: the reaction was real. Matt messaged me directly to set up a call, and without thinking twice I just told him I was out shopping 😀

Ten minutes later, after a short interview, Matt gave us the green light.

By the way, that demo caught the attention of many developers, including Roberto Aranda. In the end, I chose him to join the project, mostly because we already knew each other, we had worked together before at another company.

That’s the story of how Desktop Mode started. But stay tuned, because in the next article I’ll tell you how I wrote the very first lines of code. And it started SIMPLY, with a plugin that only showed a button in wp-admin 🙂

In this new AI era, working in multiple tasks at once is a reality and Desktop Mode plugin is not an exception. But we as humans are not really designed to work in parallel, and switching contexts is always costly and inefficient, so these are some things I do to work on different tasks at the same time:

Use tmux to open different windows for every task.

Open claude in its own worktree by using claude -w.

Rename the claude session as soon as the task is taking shape, which is any task that requires multiple prompts. I sometimes open a tmux window with ctrl-a c, open Claude, ask something, and when done, I usually rename the session with /rename [A explanatory name], then I close Claude and close the window. I have learned to be ruthless about closing tmux windows (I still need to learn that for the browser 😜).

One small detail is that I configured tmux to display the current directory, and sometimes I rename the tmux window (pressing ctrl-a ,) to be more explicit. I still need to figure out a better way to display the window name for different worktrees, which currently read things like twinkly-questing-minsky.

Now the important part, manual testing: how can I test different worktrees at the same time? Do I need to move the plugin code to a WordPress installation? Do I need to symlink the plugin code to a WordPress folder? Those two approaches would work, and I have done them a lot (and I still do sometimes), but the latest approach I’m following is to use wp-env on the Desktop Mode repo directly, using different ports for every worktree.

This is the flow:

The first thing is to open the worktree directory; for that, I open a new tmux window by pressing ctrl-a c. I configured tmux to open the same folder that you are running in.

Then run

WP_ENV_PORT=8894 npm run env:start

Changing the port for every worktree. Then open your browser pointing to it http://localhost:8894/wp-admin/ and thoroughly test your changes.

Of course, this is documented in Testing several worktrees at once

And that’s it! This is how I work in parallel.

• Frozen came out… and has already had two sequels (the third one is almost there!).
• We launched a telescope into space that’s changing how we see the universe.
• We flew a helicopter on Mars.
• AI went from a curiosity to writing code, generating images, and helping you at work.
• TikTok didn’t even exist… and now it’s one of the biggest social networks in the world.
• The Nintendo Switch launched… and already has a successor.
• Tesla went from a risky bet to reshaping the entire car industry.

And through all of that, wp-admin still looks pretty much the same as it did back in 2013.

Did nobody stop to think this was overdue for a change?

That’s where Automattic‘s Radical Speed Month comes in, an idea championed by Matt Mullenweg himself. For one month, the company asked its engineers to focus entirely on innovation. It was a historic moment: the whole company kept running on a skeleton crew of brave volunteers, while everyone else, engineers, Happiness Engineers, admins, designers, HR, and more, rolled up their sleeves to try to innovate in an era where AI can write code, and it’s humans who bring the endless creativity.

This blog tells that story: the making of the biggest wp-admin redesign in WordPress history. Bookmark this site, and follow along with us (Daniel López, Roberto Aranda, Miguel Torres, and Nick Hamze) as we take you through the development of the most disruptive wp-admin plugin yet.

Let’s change the rules of the game.