wren

Three WordPress sites sounds like a small number until you actually have to maintain all of them. Plugin updates, theme updates, checking for broken links, keeping an eye on drafts, knowing what’s published where. None of it is hard individually; it’s the accumulated cognitive overhead of keeping track of three separate environments that turns into friction over time.

Wren is the agent I’ve configured to handle that overhead. She\’s more like a very informed assistant who knows the current state of all three sites and can surface what needs attention. When I ask her what’s pending, she actually knows, because she has persistent memory with the site inventories: which plugins are installed, which version, what’s changed since we last looked.

The way she touches WordPress isn’t through a browser; it’s through WP-CLI commands run inside the Docker containers on my Unraid server. To run those commands, she delegates to Apex, the infrastructure agent, who has SSH access to the server and can exec into the right container. The chain looks like: I ask Wren, Wren asks Apex, Apex runs the command, the result comes back up the chain. It sounds like a lot of steps and in terms of configuration it was, but once it was set up it just works. The hardware running this doesn’t have to be a full tower; a capable mini PC like the Beelink SER5 Pro has enough headroom to run the agent stack and several Docker containers at the same time.

What Wren handles without much friction: checking plugin update status across all three sites, reading post lists and draft counts, pulling content for me to review, writing draft posts and saving them locally for my review. Those are all read operations or local writes. They don’t require my approval because they don’t change anything in production.

What still requires my explicit sign-off: any plugin update, any theme change, publishing a post, any database operation. The rule is simple and hard-coded into her configuration. She will not take a state-changing action on a live site without a clear go-ahead from me in that conversation. I set that rule early because the failure mode of an AI agent running an update that breaks a site is much worse than the inconvenience of typing “go ahead.”

The part that still requires me most is content direction. Wren can write a post draft if I give her a topic and the right context, but I still make every editorial decision. What angle to take, what to include, whether the draft is ready to publish. She handles the mechanical side of content management well, the filing, the tracking, the formatting, the metadata, but she’s an executor of editorial intent rather than a source of it.

The surprising benefit has been the accumulated site knowledge. Because Wren keeps memory files for each site, she knows things like which Avada theme version is running on elembemedia, what the affiliate disclosure policy is, what the most recent published post was and when. I no longer have to look any of that up. Over time, that knowledge base has become the most valuable thing about the setup, more valuable than any individual task she automates.

The honest limitation is that anything requiring visual inspection of the site still requires me to open a browser. Wren can’t see what a page looks like. She can tell me what content is in the database, but not whether it’s rendering correctly. For a visual platform like WordPress, that’s a real gap.

If you’re running WordPress yourself and want to ask about specific WP-CLI commands or how I’ve structured the agent configuration, leave a comment.

Hardware linked in this post:

• Beelink SER5 Pro Mini PC (Ryzen 5 5625U, 16GB RAM)

Affiliate disclosure: Some links in this post are Amazon affiliate links. If you buy through them, I get a small commission at no cost to you. It helps keep the lights on here.