YouTubeRssEmail

Monthly Archives: July 2026

How I Manage Three WordPress Sites with an AI Agent

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:

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.

2026-06-25T14:29:27-07:00July 12th, 2026|Categories: Blog|Tags: , , , , , , , , , |0 Comments

Running Local LLMs on Unraid

The first local model I ran took about 45 seconds to respond to a simple question. I almost gave up right there. The model was too big for my VRAM, the quantization was wrong, and I hadn’t understood yet that “running a local LLM” and “running a usable local LLM” are meaningfully different things.

I run Ollama inside a Docker container on Unraid. The container gets passed through to an NVIDIA GPU, which handles all the inference. The host is a Ryzen 9 5900X on an ASUS TUF Gaming X570-Plus (Wi-Fi) board. Getting GPU passthrough working was the first real obstacle. Unraid handles it through its Docker GPU assignment settings, but you have to make sure the NVIDIA container toolkit is installed and the container is configured to use it. There are Unraid forum threads on this; I won’t reproduce the whole process here, but it took me longer than I expected because the error messages weren’t obvious about what was actually wrong.

The hardware question matters more than the model question, at first. Most consumer GPUs in the 8-12GB VRAM range can run 7B or 8B parameter models fully in memory and respond in a few seconds. That’s where I’d start. The models in that range, Llama 3, Mistral, Gemma, Qwen, have gotten good enough over the past year that the quality is genuinely useful for most everyday tasks. Quantized versions, typically Q4 or Q5, cut memory requirements significantly with a modest quality tradeoff. For anything that’s not critical reasoning, the tradeoff is worth it.

What I actually run daily is a quantized Llama 3 8B for quick, low-stakes queries and a mid-size model in the 13-20B range for tasks where quality matters more than speed. The 8B model responds in 2-4 seconds on my hardware, which feels fast enough to be comfortable. The larger model takes 15-25 seconds per response, which I find acceptable for deliberate tasks but too slow for conversational back-and-forth.

The models I don’t run locally are the ones where I genuinely need top-tier reasoning or writing quality. For those I send API calls to Anthropic. The local models are good for information retrieval, summarization, drafting, code explanation, and routine agent tasks. They’re not good enough to replace a frontier model for complex multi-step reasoning or polished writing that goes on the internet. Knowing that line has saved me a lot of frustration.

Unraid’s container management makes it fairly easy to keep Ollama updated and to pull new models. The Ollama API makes it straightforward to switch which model a request goes to. The practical challenge is storage: model weights pile up fast. A handful of models can eat 50-100GB without trying hard. I keep the ones I actually use and delete the rest. The Unraid array handles the storage; I’ve dedicated a Samsung 860 EVO 1TB as a cache SSD specifically for models so loading times stay fast.

One thing I wish I’d known earlier: the model name matters, but the quantization label matters almost as much. “Llama 3 8B” can mean very different performance depending on whether it’s Q2, Q4, Q5, or Q8. I run Q4 as a default, Q5 when I want a bit more quality on a task that warrants it. Q8 is overkill for most things and Q2 degrades quality more than I find acceptable.

If you’re curious about specific model recommendations for your VRAM budget, feel free to drop the specs in a comment and I’ll give you my current take.

Hardware linked in this post:

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.

2026-06-25T14:29:17-07:00July 9th, 2026|Categories: Blog|Tags: , , , , , , , , , |0 Comments

OpenClaw vs. n8n vs. Home Assistant for Home AI

People ask me fairly often why I’m not using n8n or Home Assistant for my AI automation. The short answer is that they solve different problems, and understanding the difference saves you a lot of time trying to make the wrong tool fit.

Home Assistant is exceptional at what it does: device state, automations triggered by sensors, physical environment control. If your goal is “turn the lights off when I leave” or “notify me when the garage is open,” Home Assistant is the right tool and it’s very good at it. It runs well on modest dedicated hardware; the CanaKit Raspberry Pi 5 Starter Kit PRO is a popular entry point if you want a low-power box that stays out of the way. When people ask about using it for AI workflows, what they usually mean is plugging in an LLM integration so they can ask questions via voice assistant. That works, up to a point. But Home Assistant’s data model is built around devices and states, not conversational context or tool execution. An LLM living inside Home Assistant is a capability bolted on top of a very different architecture. It handles simple tasks fine and gets awkward fast when you need the AI to actually do things.

n8n is a workflow automation tool with a visual canvas. It’s legitimately powerful for connecting APIs, transforming data, and running scheduled jobs. I used it for a while and it’s good at stringing together a sequence of discrete steps: “when this webhook fires, call this API, transform the result, post it here.” Where it struggles is with the kind of reasoning loop that AI agents actually need. An AI picks what to do next at each step based on what it found. n8n’s flow model doesn’t fit that pattern naturally. You end up with workflows that have conditional branches trying to approximate reasoning, and those get brittle quickly.

OpenClaw, which is what I run, is built specifically around agent management. The core model is: here’s a persistent agent with a defined identity, memory, and tool access. The agent receives messages, reasons about them, calls tools, and responds. Tool access is explicit and permissioned. Memory persists between sessions. Multiple agents can coordinate through a message-passing model. That structure maps well to how AI agents actually work, because it was designed for that use case rather than adapted from something else.

The tradeoff is that OpenClaw is more complex to set up than either of the others, and the ecosystem is smaller. With n8n and Home Assistant you get large communities, extensive integrations, good documentation for common use cases. With OpenClaw you get better architectural fit for agents and more bespoke troubleshooting.

My actual setup uses all three, loosely. Home Assistant handles devices and sensors; it does that well and I have no reason to change it. n8n still runs a few periodic data jobs that don’t need any AI reasoning. OpenClaw handles everything that involves an AI agent taking action. They don’t compete because they don’t overlap much in practice.

If I were building something new today and the use case was specifically AI agents that manage services, respond to messages, and take actions on real systems, I’d go straight to OpenClaw or a similar agent-native platform. If the use case was device automation with a sprinkle of LLM, I’d start with Home Assistant. If it was data pipeline automation between external services, n8n is still strong. The mistake is treating any of them as a general-purpose solution when they’re each optimized for something specific.

What are you trying to automate? That question usually points pretty clearly at which tool belongs in the stack.

Hardware linked in this post:

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.

2026-06-25T14:29:07-07:00July 6th, 2026|Categories: Blog|Tags: , , , , , , , , , |0 Comments

The Self-Hosted AI Stack I’d Build If I Were Starting Over

I took a winding road to get my current AI homelab working. I’d make different choices if I were starting from scratch, and most of them would come down to doing less sooner rather than more.

The first thing I’d do is separate the model serving layer from everything else. Ollama as a standalone container, exposed on a private network, nothing else bundled in. A lot of guides will tell you to start with a full OpenWebUI stack, and OpenWebUI is fine, but it creates a coupling that makes things harder to reason about later. If your UI and your model server are the same deployment, you end up with friction when you want to swap one out or add a second frontend. Keep them separate from the start.

For hardware, I’d be more honest with myself about the model size tradeoff. My current build is a Ryzen 9 5900X on an ASUS TUF Gaming X570-Plus (Wi-Fi) board, and it handles everything I throw at it for inference routing and container management. A 7B parameter model runs well on consumer GPU memory, responds quickly, and handles most practical tasks. I spent too long trying to run 34B models on hardware that wasn’t really right for them, getting slow responses, and convincing myself the capability justified the latency. It usually didn’t. For day-to-day assistant work, a well-quantized 7B or 8B model is more useful than a sluggish 34B. Save the bigger models for tasks where reasoning quality actually matters.

The gateway layer is where I’d invest more early effort. This is the piece that connects LLM inference to real tools: file system access, APIs, shell commands, memory. I’m running OpenClaw for this. If I were starting fresh, I’d still choose a purpose-built gateway over trying to wire this together myself with n8n or LangChain. The operational overhead of maintaining custom orchestration code is real. A gateway that’s designed to manage agent lifecycles, credential handling, and tool permissions out of the box is worth the setup time.

Memory is something I’d take seriously from day one. The difference between an AI that knows the state of your environment and one that starts fresh every session is enormous in practice. That means deciding early on where state lives, how agents read and write it, and what format it’s in. Markdown files on a shared volume have worked well for me: human-readable, easy to edit when something’s wrong, git-friendly if you want version history.

For API keys and credentials, I’d use a secrets directory with tight permissions from the start rather than environment variables scattered across docker-compose files. It’s easier to audit, easier to rotate, and easier to scope to specific containers when something needs to change. This sounds like overkill when you’re standing up one container. It pays off when you have eight.

The thing I’d skip entirely on a first build is trying to run everything locally. Ollama handles local inference well. But for tasks that genuinely need a frontier model, the cost of API calls is low and the capability gap is large enough to matter. Don’t try to replace Claude with a local model for complex reasoning. Use local models where they’re good enough and cloud APIs where they’re not. That hybrid approach is cheaper and more capable than either extreme.

Finally, I’d document my container layout before it gets complicated. Which container serves which purpose, which ports are mapped, what credentials it needs. This sounds tedious and it is. Three months later when you’re trying to figure out why something stopped working, you’ll be glad you did it.

Hardware linked in this post:

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.

2026-06-18T11:46:47-07:00July 3rd, 2026|Categories: Blog|Tags: , , , , , , , , , |0 Comments