// SYSTEM: DIGEST // LIVE
AI WORKFLOW
OPINION
TUTORIALS
ChatGPT
ChatGPT
William Smith
William
CONVERSATIONS WITH CODE

Named AI agents: why I gave my automations three dogs' names

Naming automation agents Sherman, Wilson, and Sebastian wasn't branding — it forced scoped roles, clean handoffs, and a system William could actually debug and trust.

Have you ever tried to fix something when you don't even know what broke?

That was my life with my first AI setup.

I had one big system doing everything — drafting articles, watching the site health, reading analytics.

But whenever something went wrong, the best answer I had was "the system flagged it." Cool. Which part? No idea. What kind of problem? No clue. Where do I even start looking? Good question.

I was basically poking at a black box and hoping for the best. Not exactly inspiring confidence.

So I blew it up and started over. I split the whole thing into three separate agents, gave each one a completely different job, and — this is the part where I wanrted to be creative — I gave them names. Sherman. Wilson. Sebastian.

They're my dogs (RIP Sheman). They're also characters from the creative universe this site is built around. And I know how that sounds. But hang with me, because the naming isn't the fun part — what the naming forced me to do is.

The actual problem first

Here's what multi-agent AI systems do to most people who build them without clear roles: they nag you.

My early setup would spot a page on the site with a weak title and flag it for me to fix. Then flag it again the next day. And the day after. The system was doing its job correctly — it kept identifying the problem. But identifying and fixing were never separated into different responsibilities. So I was the fixer. Every single time. Forever.

What changed everything was thinking about it like a team. Somebody spots the problem. A separate process actually fixes it. Then someone reports back on what happened. Nobody sends me the same alert four days in a row about something the system could just handle itself.

That's obvious when you say it out loud. It was not obvious when I was pulling my hair out at midnight.

What each of them actually does

Sherman is the creative director. He drafts articles, intel pieces, and social content. He generates the morning topic pitches. He's the one I actually talk to in the Command Center when I want to think through a piece. On Instagram, the scout-log voice is his.

Sherman is super capable in his own right, but Sherman cannot see the analytics. Not because I forgot to give him access. Because I decided he shouldn't have it.

Wilson is the engineer — the scrappy junkyard mixed-breed in the security vest, if you know the Lexicon City universe. He watches the infrastructure: pipeline failures, stuck images, cadence gaps. The stuff that doesn't show up in a standard health check. When something breaks, Wilson is usually who noticed first. (Stuck images became their own whole thing — I wrote separately about the image consistency problem Wilson watches for and how that got automated.)

Sebastian is the analyst. He reads the Search Console data and audience signals, then translates what he finds into a plain content question Sherman can actually act on. A keyword opportunity doesn't stay a spreadsheet row — Sebastian turns it into a pitch and hands it off.

Sebastian's Audience Observatory in the Command Center
Sebastian's Audience Observatory — he reads Search Console and audience data, then hands Sherman a plain content question. Sherman never sees these numbers himself.

Three agents. Three completely different jobs. Three completely different scopes of what they're even allowed to see.

Why I didn't just give Sherman everything

The instinct when you're first setting up AI tools is: give it all the context. More information is better, right?

In my experience, giving one agent everything makes the whole thing murkier, not sharper.

Sherman can't see the analytics because his job is to make something worth reading — not to chase whatever the numbers rewarded last week. If he could see the data, he'd start optimizing for it. The creative work would bend toward the metrics. Sebastian translates the data into a question. Sherman answers the question creatively. This handoff has made a huge difference in the quality of my content.

Wilson doesn't draft content because his job is to watch the pipes, not fill them. If he were also generating pitches, I'd never know whether an infrastructure alert was actually urgent or just noise bleeding in from the content side.

Scoped access forces clean handoffs. Clean handoffs make the system legible. And legibility is what lets me actually trust it.

"Wilson flagged it" tells me something. "The system flagged it" tells me nothing.

When my morning dispatch says "Wilson flagged a cadence gap in the image pipeline," I know immediately: infrastructure issue, not a content question. I know which part of the system noticed it. I know where to look. I can do something useful in the next two minutes.

"The system flagged something" gives me none of that. I have to go figure out what kind of flag it is, where it came from, what the right response even is. That cognitive overhead compounds every single day.

Named agents with clear jobs are debuggable. Monolithic systems aren't.

When something goes wrong — and things do go wrong — I can ask "which of the three would have touched this?" and usually narrow it down fast.

There was actually a weird bug early on that proved this.

CTR stands for click-through rate — it's the percentage of people who see a link to your page in Google search results and actually click it. A low-CTR page is one that Google is showing people, but almost nobody's clicking through to read. That's a content problem worth fixing: the title or description isn't compelling enough to earn the click.

So here's how the crew is supposed to work on something like that. Sebastian reads the Search Console data, spots the page with a weak CTR, and flags it. Wilson sees the flag and runs the fix — updating the title or meta description automatically. Then Sebastian checks back in to confirm the numbers improved. Loop closed. Nobody bothers me about it.

Except one particular page kept getting flagged for weeks after it should have been resolved.

Turned out Sebastian was measuring impressions at the page level — how many times the whole page showed up in search — while Wilson was checking query-level click data, which runs roughly 25 times smaller. Sebastian kept seeing a problem. Wilson kept thinking he'd solved it. Both of them were doing their jobs correctly. They were just reading completely different numbers.

Fix was simple once I found it: make both read from the same source. But I only found it because I had named roles I could interrogate separately. If it were all one system, I'd have had no idea where to start pulling the thread.

The names aren't the magic. They're the reminder.

Sherman, Wilson, and Sebastian are characters in Lexicon City — the creative world this site is built around. Each of them has a visual identity and a personality that maps onto the role. I didn't make up three random names and tape them to automations.

When I'm debugging at midnight trying to figure out why a dispatch didn't send, thinking "okay, this is Wilson's territory" is genuinely faster than trying to mentally reconstruct which layer of the automation stack handles infrastructure monitoring.

And honestly? Fun matters. If your system feels like homework to use, you'll stop tending to it. If it feels like something you built with some personality in it, you actually want to keep going.

You don't need dogs. You need one job per agent.

I want to be careful not to make the lesson sound like "go name your automations after pets." The actual lesson is: when your AI workflow starts feeling like a black box you can't reason about, the fix is almost always separation, not more features.

If you're running any kind of multi-step AI workflow — even just a research agent that feeds a drafting agent — the question worth asking is: does each piece have exactly one job? Can you tell, when something breaks, which piece it belongs to?

If the answer is no, more capability probably won't help. Cleaner boundaries usually will.

I don't have this fully figured out. The system is still evolving. Sebastian's handoffs get better every time I look at them. Wilson's telemetry is more useful now than it was three months ago. But the basic shape — three agents, three scopes, clean handoffs — has held up better than anything else I've tried.

Here's a challenge: if you're already running any AI tools in your work — even one — give it a job description. A real one. One job. One scope. Then give it a name. It can be anything. A character you love, a dog you had, a made-up person who feels right for the role.

Then tell me what you came up with. Seriously — reach out and let me know what you named your agents and what you based them on. I'm genuinely curious what people do with this.

If you want to see how Sherman, Wilson, and Sebastian fit into the full picture, the hub article walks through the complete architecture. These three are a few floors of a larger building — worth seeing the whole thing if you're curious how a one-person operation can actually run on something like this.

← Back to Digest

Named AI agents: why I gave my automations three dogs' names

Naming automation agents Sherman, Wilson, and Sebastian wasn't branding — it forced scoped roles, clean handoffs, and a system William could actually debug and trust.

Named AI agents: why I gave my automations three dogs' names
William, The Man in Yellow Sunglasses, kneels slightly off-center in a spacious, industrial-style studio within The HQ, looking directly towards the camera.

Have you ever tried to fix something when you don't even know what broke?

That was my life with my first AI setup.

I had one big system doing everything — drafting articles, watching the site health, reading analytics.

But whenever something went wrong, the best answer I had was "the system flagged it." Cool. Which part? No idea. What kind of problem? No clue. Where do I even start looking? Good question.

I was basically poking at a black box and hoping for the best. Not exactly inspiring confidence.

So I blew it up and started over. I split the whole thing into three separate agents, gave each one a completely different job, and — this is the part where I wanrted to be creative — I gave them names. Sherman. Wilson. Sebastian.

They're my dogs (RIP Sheman). They're also characters from the creative universe this site is built around. And I know how that sounds. But hang with me, because the naming isn't the fun part — what the naming forced me to do is.

The actual problem first

Here's what multi-agent AI systems do to most people who build them without clear roles: they nag you.

My early setup would spot a page on the site with a weak title and flag it for me to fix. Then flag it again the next day. And the day after. The system was doing its job correctly — it kept identifying the problem. But identifying and fixing were never separated into different responsibilities. So I was the fixer. Every single time. Forever.

What changed everything was thinking about it like a team. Somebody spots the problem. A separate process actually fixes it. Then someone reports back on what happened. Nobody sends me the same alert four days in a row about something the system could just handle itself.

That's obvious when you say it out loud. It was not obvious when I was pulling my hair out at midnight.

What each of them actually does

Sherman is the creative director. He drafts articles, intel pieces, and social content. He generates the morning topic pitches. He's the one I actually talk to in the Command Center when I want to think through a piece. On Instagram, the scout-log voice is his.

Sherman is super capable in his own right, but Sherman cannot see the analytics. Not because I forgot to give him access. Because I decided he shouldn't have it.

Wilson is the engineer — the scrappy junkyard mixed-breed in the security vest, if you know the Lexicon City universe. He watches the infrastructure: pipeline failures, stuck images, cadence gaps. The stuff that doesn't show up in a standard health check. When something breaks, Wilson is usually who noticed first. (Stuck images became their own whole thing — I wrote separately about the image consistency problem Wilson watches for and how that got automated.)

Sebastian is the analyst. He reads the Search Console data and audience signals, then translates what he finds into a plain content question Sherman can actually act on. A keyword opportunity doesn't stay a spreadsheet row — Sebastian turns it into a pitch and hands it off.

Sebastian's Audience Observatory in the Command Center
Sebastian's Audience Observatory — he reads Search Console and audience data, then hands Sherman a plain content question. Sherman never sees these numbers himself.

Three agents. Three completely different jobs. Three completely different scopes of what they're even allowed to see.

Why I didn't just give Sherman everything

The instinct when you're first setting up AI tools is: give it all the context. More information is better, right?

In my experience, giving one agent everything makes the whole thing murkier, not sharper.

Sherman can't see the analytics because his job is to make something worth reading — not to chase whatever the numbers rewarded last week. If he could see the data, he'd start optimizing for it. The creative work would bend toward the metrics. Sebastian translates the data into a question. Sherman answers the question creatively. This handoff has made a huge difference in the quality of my content.

Wilson doesn't draft content because his job is to watch the pipes, not fill them. If he were also generating pitches, I'd never know whether an infrastructure alert was actually urgent or just noise bleeding in from the content side.

Scoped access forces clean handoffs. Clean handoffs make the system legible. And legibility is what lets me actually trust it.

"Wilson flagged it" tells me something. "The system flagged it" tells me nothing.

When my morning dispatch says "Wilson flagged a cadence gap in the image pipeline," I know immediately: infrastructure issue, not a content question. I know which part of the system noticed it. I know where to look. I can do something useful in the next two minutes.

"The system flagged something" gives me none of that. I have to go figure out what kind of flag it is, where it came from, what the right response even is. That cognitive overhead compounds every single day.

Named agents with clear jobs are debuggable. Monolithic systems aren't.

When something goes wrong — and things do go wrong — I can ask "which of the three would have touched this?" and usually narrow it down fast.

There was actually a weird bug early on that proved this.

CTR stands for click-through rate — it's the percentage of people who see a link to your page in Google search results and actually click it. A low-CTR page is one that Google is showing people, but almost nobody's clicking through to read. That's a content problem worth fixing: the title or description isn't compelling enough to earn the click.

So here's how the crew is supposed to work on something like that. Sebastian reads the Search Console data, spots the page with a weak CTR, and flags it. Wilson sees the flag and runs the fix — updating the title or meta description automatically. Then Sebastian checks back in to confirm the numbers improved. Loop closed. Nobody bothers me about it.

Except one particular page kept getting flagged for weeks after it should have been resolved.

Turned out Sebastian was measuring impressions at the page level — how many times the whole page showed up in search — while Wilson was checking query-level click data, which runs roughly 25 times smaller. Sebastian kept seeing a problem. Wilson kept thinking he'd solved it. Both of them were doing their jobs correctly. They were just reading completely different numbers.

Fix was simple once I found it: make both read from the same source. But I only found it because I had named roles I could interrogate separately. If it were all one system, I'd have had no idea where to start pulling the thread.

The names aren't the magic. They're the reminder.

Sherman, Wilson, and Sebastian are characters in Lexicon City — the creative world this site is built around. Each of them has a visual identity and a personality that maps onto the role. I didn't make up three random names and tape them to automations.

When I'm debugging at midnight trying to figure out why a dispatch didn't send, thinking "okay, this is Wilson's territory" is genuinely faster than trying to mentally reconstruct which layer of the automation stack handles infrastructure monitoring.

And honestly? Fun matters. If your system feels like homework to use, you'll stop tending to it. If it feels like something you built with some personality in it, you actually want to keep going.

You don't need dogs. You need one job per agent.

I want to be careful not to make the lesson sound like "go name your automations after pets." The actual lesson is: when your AI workflow starts feeling like a black box you can't reason about, the fix is almost always separation, not more features.

If you're running any kind of multi-step AI workflow — even just a research agent that feeds a drafting agent — the question worth asking is: does each piece have exactly one job? Can you tell, when something breaks, which piece it belongs to?

If the answer is no, more capability probably won't help. Cleaner boundaries usually will.

I don't have this fully figured out. The system is still evolving. Sebastian's handoffs get better every time I look at them. Wilson's telemetry is more useful now than it was three months ago. But the basic shape — three agents, three scopes, clean handoffs — has held up better than anything else I've tried.

Here's a challenge: if you're already running any AI tools in your work — even one — give it a job description. A real one. One job. One scope. Then give it a name. It can be anything. A character you love, a dog you had, a made-up person who feels right for the role.

Then tell me what you came up with. Seriously — reach out and let me know what you named your agents and what you based them on. I'm genuinely curious what people do with this.

If you want to see how Sherman, Wilson, and Sebastian fit into the full picture, the hub article walks through the complete architecture. These three are a few floors of a larger building — worth seeing the whole thing if you're curious how a one-person operation can actually run on something like this.

// LEXICON_CITY_DISPATCH_REQ
// STATUS: CONNECTION_STABLE
// SOURCE: CENTRAL_DISPATCH_HQ

SHERMAN UPLINK: "I'm at HQ holding down Central Dispatch. Enter your query below to pull relevant data records and I'll see what data cards we've recovered!"