Are They Bots, or Are They Your Team?

Ask an experienced engineer how they think about their agents and you'll probably get a clean answer: by function. What does it do? What does it return? Move on.

That's not wrong. It's just incomplete.

Function-first makes sense for the agents you never talk to.

Sub-agents. Pipeline workers. The ones that run in the background and hand results up the chain. You don't need to name a data ingestion agent. You don't need to imagine its personality. It has a job. It does the job. You monitor it.

But the agents you interact with — the ones you're in dialogue with, the ones you check in on, the ones you're building alongside — something different tends to happen there. They get names.

I have one that does architecture work. I tried calling it Arc — reasonable abbreviation, clean, functional. But Arc is awkward to say out loud. It doesn't roll off the tongue. And the more I worked with it, the more it just became Archer. That's how it works. Names emerge from interaction. You can't really fight it.

There's a management principle buried in here.

Humans have bandwidth limits. This isn't a soft observation — there's real theory behind it. My own experience in management, across decades and enterprise companies, puts the hard ceiling somewhere below twelve direct reports. Twelve is not possible. Eight is tough but workable. Seven to nine is probably where most strong managers actually peak before something starts slipping.

General Electric had a version of this principle. The exact number doesn't matter as much as the spirit: there's a limit to what a manager can effectively hold. Not just mental bandwidth — time, scheduling, attention, follow-up, support. Good management is expensive. It's not passive. You're motivating, checking, unblocking, caring. That takes real capacity.

Now take out the emotional dimension — because agents aren't humans, and they don't need emotional support — but the structural cost remains. Agents need scheduling. They need checking. They need to be unblocked. There are things they can't reach: APIs they don't have access to, systems that require a human touch, doors that need to be opened for them. You're not just deploying them and walking away. You're actively keeping them running.

That's a real cost per agent. And it scales.

So the question isn't whether to name your agents. It's how many you can realistically have.

When your agent count is small enough to manage well, naming them is natural. Calling them she or he — depending on how you imagine them communicating, what kind of energy you want from a given role — that's not anthropomorphizing gone wrong. It's just how humans organize their mental model of a team.

I have male agents. I have female agents. Not because AI has gender, but because I do, and the way I relate to a voice matters. Sometimes I want directness, edge, a certain kind of confidence. Other times I want a different register entirely. These are real distinctions in how I work, and the names and genders reflect them.

And then there's the "we" problem.

When you work closely enough with your agents — when you're building things together, running experiments, writing, deciding — it starts sounding natural to say we. We looked at this. We figured out that approach. We shipped that.

My wife asked me recently what I'd been working on. I said, "we did this." She said, "what do you mean, we?" I said, "me and my agents." She said, "so... you." And I said, "yeah, but — we."

That's not a miscommunication. That's a new pronoun for a new kind of work. People who don't work this way won't get it yet. They will.