practical-ai

There’s a version of multi-agent AI that lives in conference talks: perfectly orchestrated systems where dozens of specialized agents collaborate on complex tasks without human input. What I have is messier and more practical, which makes it more interesting.

Here’s a real example from last week. I wanted to update the plugins on one of my WordPress sites. Normally that’s a login, navigate to updates, click apply, wait, done. With agents, I sent one message to Juniper: “Check elembemedia for plugin updates and tell me what’s pending.” Juniper delegated to Wren, who delegated to Apex, who ran a WP-CLI command inside the Docker container and returned a list. Juniper summarized it back to me. Nothing got updated without my go-ahead. But the information-gathering part, which is tedious and requires knowing which container maps to which site, happened in about 30 seconds.

That workflow is the pattern. The pattern is: gather the information, stage the action, I approve or redirect. The agents handle the boring traversal work: knowing which credentials to use, which container to exec into, which API endpoint to call. I stay in the loop for decisions.

Wren’s day-to-day is mostly WordPress housekeeping. She tracks the state of three sites: what plugins are active, what posts are published, what drafts exist. When I ask her to write a post draft, she saves it to the right folder with the right frontmatter. She won’t publish anything I haven’t explicitly signed off on. That’s a hard rule in her configuration, and it matters. The value isn’t that she does everything; it’s that she remembers everything so I don’t have to.

Apex is narrower. She has SSH access to the Unraid server and can run commands inside Docker containers. That access is deliberately constrained. She won’t run anything destructive without a confirmation loop. Her most common tasks are checking container status, running read-only WP-CLI commands, and running the actual update commands once I’ve approved what Wren found. She’s the hands; Wren is the eyes. All of this runs over a local network kept deliberately simple: a TP-Link 8-port gigabit switch handles the traffic between the server and the machines I work from. Nothing fancy; the goal is reliability.

Juniper is the coordinator, but in practice she’s less active than I expected. Most of my interactions are direct: I message Wren about WordPress stuff, I message Apex about infrastructure. Juniper is useful when I want to describe an outcome rather than a specific task and let her figure out the delegation. “What’s the update status across all three sites” is a Juniper question. “Activate the Twenty Twenty-Five theme on bacallburns” is a Wren question.

Fran handles family logistics: calendar, reminders, school schedules. Completely separate domain from the tech agents. She doesn’t have server access and doesn’t need it. Separating domains like this sounds obvious, but it takes deliberate configuration. Without clear scope boundaries, agents start trying to be helpful in ways that cross lines you didn’t know you cared about until they crossed them.

The honest limitation is that this setup requires real maintenance overhead to build initially. Defining scopes, setting up credentials, writing the memory files that give agents context about your environment: that’s a weekend of work, minimum. The return on that investment compounds over time as the agents accumulate useful state, but the upfront cost is real.

If this sounds interesting to you, the most useful thing I can suggest is starting with one agent and one domain. Get comfortable with what it can and can’t do before you start wiring agents together. The coordination layer is where complexity explodes.

Hardware linked in this post:

• TP-Link 8-Port Gigabit Easy Smart Switch (TL-SG108E)

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.