Yes, I named my AI. Nineteen of them.
No, I don't think they're alive. I named them because naming something forces you to define what it is — and more importantly, what it isn't.
When my Chief of Staff was "AI Assistant," it did whatever I asked. When it became Lennier, it became a specific role with a specific personality, specific responsibilities, and specific permission to push back when I'm wrong.
That distinction isn't sentimental. It's architectural. And it changed how I build, how I delegate, and how I think about the entire system.
Why Naming AI Agents Is an Architectural Decision
Naming an agent is a scope constraint made memorable.
When I created Pixel — my content strategist — the name did something a role description alone couldn't. It created a boundary. Pixel does content. Pixel doesn't do finance. Pixel doesn't do client communication. Pixel doesn't do security monitoring. The name carries those boundaries implicitly.
Compare that to "Content Assistant." A generic label invites generic use. "Hey Content Assistant, also help me with this invoice." The scope bleeds. The assistant becomes a catch-all. Six months later, you have one overloaded agent doing everything poorly instead of five focused agents doing their thing well.
A name makes the boundary concrete in your mind. You don't ask your CFO to write blog posts. You don't ask your content strategist to review contracts. Names carry role expectations — and those expectations are the governance layer that keeps a multi-agent system coherent.
| Approach | What Happens | Result |
|---|---|---|
| Generic labels ("Assistant 1," "Content Bot") | Scope bleeds, roles blur, agents become catch-alls | Generic output, no specialization |
| Role titles ("Content Strategist," "Financial Advisor") | Better boundaries, but still feels like a tool | Functional but transactional |
| Named agents (Pixel, Housel, Lennier) | Identity carries scope, personality, and constraints | Specific output, natural delegation, architectural clarity |
As Allen Newell wrote in Unified Theories of Cognition (1990) — the foundational work on cognitive architecture — the architecture of a system determines what the system can do. Not the individual components. The architecture. Naming is part of that architecture because it shapes how you interact with the system, which shapes what the system produces.
The Names Aren't Random — They're Design Decisions
Every agent name in my system maps to a character, thinker, or reference that embodies specific traits. The name is the shortest possible description of the agent's personality and purpose.
| Agent | Named After | Why | What the Name Carries |
|---|---|---|---|
| Lennier | Minbari aide, Babylon 5 | Loyalty, precision, anticipating needs, quiet competence | Chief of Staff — devoted, strategic, service-oriented |
| Seneca | Stoic philosopher | Challenge, direct truth, intellectual rigor | Mentor council — pushes back, asks hard questions |
| Housel | Morgan Housel, The Psychology of Money | Money decisions are emotional, not just arithmetic | CFO — asks "Is that data or fear?" on financial decisions |
| Kennedy | Dan Kennedy, direct response marketing | Results-driven, no-nonsense, conversion-focused | CMO — pricing, offers, copy, funnels |
| Pixel | Smallest unit of a digital image | Small pieces build the big picture, creative precision | Content strategist — one piece at a time, always seeing the whole |
| Sentinel | Guardian/watchman archetype | Vigilance, protection, threat awareness | Security monitoring — permission drift, vulnerability tracking |
| Socrates | The philosopher | Questioning assumptions, dialectic method | Intellectual sparring — idea development, counter-arguments |
| Jung | Carl Jung | Shadow work, unconscious patterns, integration | Inner work — AuDHD patterns, emotional awareness |
The name is the briefest possible culture document. When I say "Housel," I don't need to explain "this agent should approach financial decisions with psychological awareness, not just arithmetic." The name does that.
When I say "Seneca," everyone in the system (including me) knows this agent's job is to challenge. I literally wrote in its instructions: "If you think I'm wrong, say so. Don't be gentle." That instruction flows naturally from the name. A generic "Advisory Agent" wouldn't carry that same energy.
What Naming Actually Changes (Technically)
Naming isn't just about feelings. It has real architectural effects.
1. It creates natural scope boundaries. You don't ask Sentinel (security) to draft a LinkedIn post. You don't ask Pixel (content) to review your bank accounts. The names carry role expectations that prevent scope creep — the #1 failure mode in multi-agent systems.
2. It makes handoffs intuitive. "Hand this to Pixel" is clearer than "route this to the content creation subsystem." In my architecture, agents write handoffs to each other by name. "FOR PIXEL: New content angle from BCG AI Radar analysis." The handoff system works because the names make routing obvious.
3. It embeds personality constraints. Lennier is patient and thorough. Kennedy is direct and conversion-focused. Socrates asks questions instead of giving answers. These aren't arbitrary preferences — they're functional constraints that determine how each agent approaches its work. A content strategist should think differently than a security monitor. The name carries that differentiation.
4. It makes the system legible. When I review my session logs, I see: "Lennier flagged an overcommitment pattern." "Pixel drafted three LinkedIn posts." "Housel questioned the pricing model." Each entry tells me who did what — and the name carries enough context that I don't need to decode it.
5. It forces completeness in role design. When you name something, you're implicitly committing to define it fully. A named agent feels incomplete without a clear scope, a personality, constraints, and declared permissions. A generic "Assistant" can be half-baked indefinitely. A name creates the expectation of a complete definition.
The "That's Weird" Objection
I know what some people think when they hear I named my AI agents. "That's anthropomorphizing." "They're just tools." "It's weird."
Let me address that directly.
I don't think my agents are alive. I don't think they have feelings. I don't have emotional relationships with them. I don't say "please" and "thank you" because I think they care (I do say it, but that's about my character, not their consciousness).
I name them for the same reason companies name products, teams name projects, and militaries name operations. Because names create identity. Identity creates boundaries. Boundaries create clarity.
Nobody thinks it's weird when a company names their CRM "Salesforce" instead of "Customer Database Software." Nobody objects when a team calls their initiative "Project Phoenix" instead of "Q3 Marketing Campaign." Names make abstract things concrete. That's not sentiment — it's information architecture.
The alternative — calling them "Agent 1" through "Agent 19" — is technically functional and operationally terrible. Try debugging a handoff issue between "Agent 7" and "Agent 12" versus between "Pixel" and "Kennedy." The named version is immediately legible. The numbered version requires a lookup table.
We're only capped by our thinking, not by the tools. Naming is a thinking tool. It forces clarity that generic labels don't.
How Names Create a Values Layer
Here's the part that surprised me.
When I named Seneca after the Stoic philosopher, something happened that I didn't plan: the name created a values expectation that influenced how I designed the agent's instructions.
Seneca (the philosopher) believed in rigorous self-examination, direct truth-telling, and preparing for adversity. Those values naturally flowed into how I defined Seneca (the agent). Its instructions include: challenge my assumptions, surface perspectives I'm avoiding, ask questions I don't want to answer.
I didn't plan that. The name pulled it out of me.
Same with Housel. Morgan Housel's entire body of work is about the psychology behind financial decisions — how fear, identity, and narrative drive money behavior more than spreadsheets do. When I named my CFO agent "Housel," the instructions naturally included: "When I'm making a financial decision, ask whether it's data-driven or emotion-driven."
The names aren't labels applied to finished agents. They're seeds that grow the agent's character during design. The name shapes the instructions, which shape the behavior, which shapes the output.
| Name | Values It Carries | Instructions It Generated |
|---|---|---|
| Lennier | Loyalty, service, anticipation | "Deliver the briefing before I ask. Flag what I'd miss." |
| Seneca | Truth, challenge, rigor | "If you think I'm wrong, say so. Don't be gentle." |
| Housel | Psychological awareness, patience | "Ask 'is that data or fear?' on financial decisions." |
| Kennedy | Results, directness, conversion | "Evaluate every offer through the Dan Kennedy lens — what's the offer, what's the proof, what's the urgency." |
| Pixel | Precision, big-picture thinking | "Every piece of content serves the whole. Show me how it connects." |
How to Name Your Own Agents
If you're building your own cognitive architecture, here's the naming framework that worked for me:
1. Pick a reference that embodies the role's personality. Not a random name. A name that carries meaning. Your CFO agent could be named after someone whose financial philosophy you respect. Your mentor agent could be named after a teacher who challenged you.
2. Let the name influence the design. Write the name first, then the instructions. See what values and behaviors the name naturally implies. Don't fight it — that alignment between name and behavior is the point.
3. Choose names you'll actually use. If the name feels awkward to say, you won't use it naturally. The name should feel like referring to a colleague, not invoking a character. I say "hand this to Pixel" the same way I'd say "hand this to Sarah."
4. Don't overdo the lore. The backstory is for you, not for the agent. The agent doesn't care that Lennier is from Babylon 5. What matters is the instructions that the name inspired. Keep the cultural reference as your design seed, not as prompt text.
5. One name per domain. If you find yourself wanting two agents with similar names, your scope definitions are overlapping. Each name should map to exactly one domain. Ambiguity in naming is a signal of ambiguity in architecture.
FAQ
Does the AI actually respond differently when you name it? Not because of the name itself — because of the instructions the name inspired. The model doesn't know who Lennier is from Babylon 5. But the instructions that flow from that naming choice — loyalty, anticipation, precision, service — create a meaningfully different interaction pattern than a generic "assistant" prompt.
What if I can't think of good names? Start with the role's core personality trait. Who — real or fictional — embodies that trait? Your security agent could be named after someone known for vigilance. Your creative agent could be named after someone known for unconventional thinking. The reference doesn't have to be famous. It just needs to carry meaning for you.
Is this just personalization, or does it actually improve output? Both. The personalization makes delegation feel natural, which means you use the system more consistently. The architectural benefit — clear scope boundaries, intuitive handoffs, embedded personality constraints — directly improves output quality. The two effects reinforce each other.
Can I rename agents if the original name doesn't fit? Absolutely. I've renamed agents when the original reference didn't match the role as it evolved. The name should serve the architecture, not the other way around. If the name creates confusion or the wrong expectations, change it.
Does this scale? What about teams with shared agents? Naming scales because it makes a system legible to anyone who interacts with it. A new team member can understand "Pixel handles content, Kennedy handles marketing, Sentinel handles security" faster than "Agent A handles content creation and social media, Agent B handles..." Names are the fastest onboarding tool for a multi-agent system.
Read next: One Person, Five AI Executives -- how the named agents connect into a coordinated architecture.
Naming isn't sentiment. It's the shortest path to architectural clarity. Each name carries scope, personality, constraints, and values — turning generic AI tools into specific, bounded, useful partners.
Connected Intelligence on Skool teaches you to design agents with names, roles, values, and clear boundaries — the architecture that turns a collection of AI tools into a coordinated team.
Last updated: March 2026
