How I Run an AI Consulting Practice with AI Agents

Before I go to bed, I press one button labeled Supervise on my Streamdeck. It starts a watchdog over my agent fleet. Then I sleep, while agents assigned to my consulting clients keep working: drafting follow-ups, reconciling data, prepping tomorrow’s briefs. If one of them gets stuck in the middle of the night, I get a message on my phone with buttons to unstick it. Sometimes I answer from bed in 10 seconds. Sometimes I see it in the morning.

People ask me how I handle the client load I do. This is how. Every client gets their own AI agent.

The account manager who never sleeps

Think about how an agency scales. You hire account managers. Each one owns a handful of clients: knows their context, watches their queue, runs their cadences, escalates when something needs the boss. The model works because context stays with the person who owns the relationship.

I run the same org chart, except the account managers are AI agents. Each client of mine has a dedicated agent route: its own workspace, its own queue of work, its own accumulated context about that client’s business, its own cadence of recurring plays (weekly reports, inbox triage, data reconciliation, whatever that client’s engagement needs). When work comes in for a client, it goes to that client’s agent, not to a generic AI with amnesia.

Why per-client instead of one big agent? The same reason you don’t have one account manager serve 30 clients from a single inbox. Context bleed. An agent that just spent an hour in a payments company’s CRM should not be the same context that drafts an email for a school network. Separate agents mean separate memories, separate permissions, separate blast radius when something goes wrong.

I have over 40 agents running across my life and clients now. The interesting part is not any single agent. It’s what holds them together.

The glue: herdr

Here’s the tool I cannot rave about enough: herdr. If I could only keep one piece of my stack besides the models themselves, this is it.

The simplest way I can describe it: tmux for AI agents. It’s a persistent server that hosts all my agent sessions in workspaces and panes. Claude Code sessions, Codex sessions, my Pi agents, my Hermes agents… they all live inside it. Nothing dies when I detach. I can attach from my desk, from my laptop, from another machine over my private network. Everything is exactly where I left it.

That alone would be useful. What makes it a game changer is state monitoring. herdr natively tracks what every agent is doing: working, idle, blocked, done. Which means my sessions stopped being isolated windows I have to babysit and became a fleet I can supervise.

Do you feel the difference? Without this, you have Claude in one terminal, Codex in another, a background agent somewhere else, and none of them know about each other. You’re missing out on a lot of firepower, because the sessions can’t be coordinated.

With herdr, I can be deep in a Claude session, get up to make dinner, and tell my Hermes agent: monitor that session, update me when it’s done, ping me if it gets stuck. Then I get an iMessage an hour later that it finished. It really feels like your agents are working for you.

This is the part that unlocks everything. Claude Code, Codex, Pi: they all sit on the same fabric, so they can hand work to each other instead of living in sealed-off windows. And my Hermes agents sit on that same fabric, which means one of them can reach across and coordinate all of them. That’s how a session becomes a fleet.

The orchestrator, the observer, and the supervisor

Once agents can see each other’s state, you can build management on top. My fleet has three roles. None of them do the actual client work. They exist to keep the agents that do the work honest.

The orchestrator. Every client has its own orchestrator. It’s the agent that spins up the other agents and oversees them: subagents for the grunt work, Codex for heavy coding, sometimes Grok for an extra review pass. Its whole job is to make sure that client’s work gets done and gets done correctly. Think of it as the account manager who owns the relationship and runs the room.

The observer. Here’s the part I didn’t expect to need. Inside each client space, I run a second agent whose only job is to watch the orchestrator. Why? Because AI agents can’t really evaluate themselves. An orchestrator managing three or four agents will still, every so often, get stuck or quietly go sideways, and have no idea it happened. The observer keeps it in check.

Let me give you a real example. I run long tasks. The orchestrator kicks off a Codex subagent to grind on something, then does what orchestrators do: it waits for the subagent to come back. Except sometimes the Codex agent hangs. 45 minutes later it’s still showing “working.” It’s actually just dead.

The orchestrator will happily wait forever, because waiting is the correct behavior right up until it isn’t. The observer is the one that notices. It looks at the orchestrator and says: your Codex agent has been unresponsive for 45 minutes, you should kill it and retry. The orchestrator would never catch that on its own.

The reason the observer works comes down to one thing. It holds the vision, while the orchestrator holds the task. The orchestrator has its head down trying to finish something. The observer knows where the whole project is supposed to go, because I feed it exactly that. For my own work it’s the CLAUDE.md files. For a client it’s the agreement and the SOW. Every time I start an observer, I give it two things up front: the vision and its role. The vision is where the project is going. The role is to watch the orchestrator and keep it moving forward. That single piece of context is what lets it call out a stuck orchestrator.

The supervisor. The orchestrator and the observer both live inside one client. But I have a lot of clients. So above all of them sits the supervisor. Here’s the key thing about it: I never actually talk to the supervisor. It’s not something I open up and hand work to. It runs in the background across every client at once, watching every orchestrator and every observer, making sure the whole thing stays alive. Its only job is to catch trouble: an orchestrator that died, an observer that crashed, a client session that hung. When it finds one, it tries to revive it. It’s the layer that keeps the fleet from quietly falling over while I’m asleep. I mostly forget it’s even there, which is exactly how it should be.

Put it together and you get the shape of the whole operation. Here’s the part that surprises people: I never talk to the supervisor. The agent I actually work with is the orchestrator. When it’s time to work on a client, I go into that client’s space and trigger the orchestrator. The observer spins up alongside it to keep watch. I tell the orchestrator what needs to happen. It drives the agents that do the work. The observer watches the orchestrator. The supervisor watches everything, quietly, from the background. It’s the same lesson every operations leader already knows: you don’t scale by working harder, you scale by adding layers of management that watch each other.

And when something is genuinely stuck on a call only I can make, it comes to me. A message shows up on my phone with buttons. I tap one. The agent unblocks and keeps going. No terminal, no laptop, no context-switch back into the work.

What my job actually is now

A framework I keep coming back to is 10-80-10. The first 10% is me: writing the spec, giving context, deciding what matters. The middle 80% is the agents doing the work. The last 10% is me again: reviewing, taste-checking, approving. My job used to be the 80. Now my job is the bookends. The bottleneck has moved from execution to orchestration.

In practice, my day is a loop through that first 10%. I go into one client’s space and think about what actually needs to happen: what are the tasks, what’s the priority. I trigger the orchestrator and fire it off. Then I move to the next client and do the same thing. Client by client, I’m setting direction and letting each fleet run. The first 10% of any task is me telling the orchestrator what to do and in what order. It does the rest.

Here’s what’s changed. It’s the most interesting problem I’m working on right now. As the models and the harnesses got better, tasks started finishing faster. A year ago a task took an afternoon of babysitting. Now the same task is done before I’ve refilled my coffee. That sounds great until you realize it flips the constraint.

My job is no longer to get one thing done. It’s to figure out how to give these agents better direction and bigger tasks. Why hand off something that takes 10 minutes when I could hand off something that takes a full day and walk away? That’s the balance I’m trying to find right now. What’s the sweet spot? Some tasks I fire off to run overnight and feel good about in the morning. Some are worth running for hours while I spend the tail end deep in the iteration. I’m still learning where each one lands.

The size of that first 10% is not the same for every client either. With a brand-new client, I spend a lot of time there: planning, building prototypes, going back to them for feedback before we commit to building anything real. That front-loading matters. Skipping it is how projects go sideways.

But once a client has been with me a while and there’s a clear roadmap of what we’re building, this setup with the orchestrator, the observer, and the supervisor humming in the background is genuinely amazing. The first 10% collapses to almost nothing. I tell the orchestrator what to build and in what priority. It handles the rest.

That’s why the fleet architecture matters more than any individual agent’s cleverness. A brilliant agent with no queue, no state monitoring, and no escalation path is a very smart intern locked in a room. A decent agent inside a fleet with supervision compounds every single day.

And to be clear about the guardrails, because people always ask: nothing in my fleet sends anything outward on its own. Client-facing output terminates as a draft in an approval queue that I clear myself. The agents do the 80. I still own the last 10. I think that stays true for a long time.

Where to start

You don’t need 40 agents or any of my plumbing to get the core benefit. Pick your one most process-heavy client or project. Give it a dedicated agent: its own folder of context, its own running list of work, its own recurring checklist. Don’t share that context with anything else. Run it for 2 weeks and watch what happens when an AI actually remembers a client between sessions. One client, one agent. The fleet comes later.