Merlino AI

Naming Every Agent a Role, Not a Tool

2026-07-144 min readagent-fleetagent-namingorchestrationfleet-doctrine

The bot problem

Most people who build with AI agents end up with a folder of scripts called things like agent1.py, seo_bot.py, and content_helper.js. That naming pattern is a tell. It means the agent is a function, not a hire. You call it, it does one thing, you forget it exists until you need it again.

I did not want a folder of scripts. I wanted a company.

Every agent gets a role, not a job description

My fleet is over 40 individually named specialists, and every one of them owns a domain the way a real employee would. Dan owns engineering. Frankie owns frontend. Merlin runs SEO and marketing strategy. Shakespeare owns content. Einstein owns semantic SEO. Tommy owns technical SEO. Ghost owns local and GMB. Linx owns link building. Raven does wide research, Sherlock goes deep on one thing at a time. Knox handles security. Picasso does design. Spielberg produces video. Vox runs telephony and voice AI. Warren watches spend and risk. Ted looks after fleet health. Ava is my executive assistant and chief of staff.

Each one of those names is a real, deployed instruction file, not a label I made up for a slide. They live in the ecosystem repo as individual agent definitions and get pushed out to every machine that runs my fleet. Open the folder and you see 44 separate files, each one a person with a job, not a tool with a function name.

Why the naming actually matters

This is not branding for its own sake. There is a rule that shows up independently across several of my agents' own consolidated memory, stated almost word for word every time it gets confirmed: plan before you act, close every loop with real validation, minimize how much correction I personally have to do, use semantic naming, and layer your tools instead of locking into one. That naming principle is not decoration in that list. It sits right next to plan-before-action and close-the-loop because it does the same job they do: it reduces how much I have to explain.

When an agent is named Shakespeare instead of content_generator, every other agent that reads a task assignment already knows what Shakespeare is for. The name carries the context. I do not have to write a paragraph explaining what content_generator does every time I hand it work, and neither does any other agent in the chain that needs to route something to it. A verbose, semantic name is implicit context, for free, every single time it gets read.

What this buys me day to day

Naming a role instead of a tool changes how the fleet operates in three concrete ways.

  • Routing gets faster. If a request is about video, it goes to Spielberg. If it is about local SEO or GMB, it goes to Ghost. Nobody has to reverse-engineer a script name to guess what it does.
  • Accountability gets real. A named agent with a fixed domain can be held to a standard the way a person can. Shakespeare owns content quality. If content is weak, I know exactly who owns the fix.
  • Growth stays organized. When I add a new capability, I do not bolt on another anonymous script. I decide whose domain it belongs in, or I name a new role for it.

The tell you're doing it wrong

If your team of agents is a pile of scripts named after what they technically do, you built a toolbox. If your team of agents has names, owns domains, and reports the way a real specialist reports, you built an org chart. I built the second one on purpose, because a toolbox needs a supervisor for every call, and an org chart runs itself. That difference is the entire reason I can run 40-plus agents without spending my day translating between them.

The Build Log

One email.The whole build.

One email when something ships: the dashboard, the agent, the GMB play, and the prompts and configs that made it go. If it fell over on the first try, I say that too.