Our agents have names. Scout (the researcher), Argus (the wordsmith), Flint (the editor). They are not "Writer Agent" or "Editor v2" or "Intern Bot." They have names the way human teammates have names.
This sounds small. It is small. The naming choice took fifteen minutes once we decided. It changes everything about how the team works with them.
This piece is the case for naming agents — what changes when you do it, and what subtly breaks when you don't.
The case for titles (the default)
Most products that ship "AI agents" name them by their function. "Writer Agent" drafts copy. "Editor Agent" fixes grammar. "Researcher Agent" pulls citations.
The case for this is that titles are informative. A user who sees "Writer Agent" knows what it does. They don't have to remember a name and what the name does. The label is the function.
The case is reasonable. It's also the case for calling all your human teammates by their job titles. "Engineer 4 wrote this. Designer 7 reviewed it." It's not what you do with humans, and it's not what you should do with agents either.
What changes when agents have names
A few things shift when "Writer Agent" becomes "Argus":
The agent gets a track record. Argus is the agent that drafted that good launch post in March. Argus is the one that mishandled tone in last week's blog. The naming gives you a hook to attach memory to. "Writer Agent drafted this" is a category label; "Argus drafted this" is an attribution.
The team starts evaluating the agent the way they evaluate a teammate. Scout is good at structured research, less good at terse summaries. Flint is fast but skips edge cases. These are the kinds of judgments the team makes naturally about teammates with names. They don't make them naturally about "Tool 4."
The agent's failures become specific. When something goes wrong, the conversation is "Argus produced a weird draft, did something break in our prompt?" — not "the AI is acting up." The specificity makes the debugging easier. We covered the engineering case for this in Why agents need their own identities.
The agent's wins become proportional. When Argus produces something good, the team can say "good work, Argus" — not "the AI is being useful today." Praise that's specific is more useful than praise that's generic, even when the recipient is software.
Multi-agent collaboration becomes legible. When Scout, Argus, and Flint are working together, you can read the audit log: "Scout collected the sources, Argus drafted, Flint edited." This is a story. With titles, the story would be "Researcher Agent ran, Writer Agent ran, Editor Agent ran." Same actions, less narrative.
What subtly breaks without names
The reverse: a few things that don't work when agents are titled.
Hand-offs require translation. When a human says "have the agent draft this," which agent? If you have one, fine. If you have three (one for prose, one for tables, one for emails), the user has to remember which is which by function. With names, "have Argus draft this" is unambiguous in a way "have the writer agent draft this" is not, especially when "writer" is a category that two agents could fit.
The agent feels like a service, not a teammate. Users prompt "Writer Agent" the way they prompt a search bar — type in, get out. Users prompt "Argus" the way they ask a colleague — with context, with conversational flow, with expectations about what Argus knows. The interaction depth differs.
Replacing the agent is harder. When you swap "Writer Agent v2" for v1, users notice. When you swap the model behind Argus, users barely notice. The name is the layer of stability the user relates to; the implementation is allowed to change underneath.
The product feels generic. "I added Writer Agent to my project" sounds like every other AI integration. "I added Argus to my project" sounds like Dock specifically. Names create product personality; titles erase it.
How to name well
A few principles that have held up:
Short and pronounceable. Three to six characters. The name is going to be typed and said hundreds of times by the user. If it's hard to type or hard to say, it'll get truncated to a nickname, and the nickname will become the real name. Save yourself the step.
Vaguely meaningful, not literal. Argus (mythological figure with many eyes) suggests vigilance and attention to detail without being literal about "editing." Scout suggests exploration without being literal about "research." Flint suggests fast, hard, sharp without being literal about "editing." The vague meaning gives the agent character; the literal meaning would just be a longer title.
One syllable beats two. Easier to say. Easier to type. Easier to remember. We have one two-syllable agent name in production (Argus); the rest are one (Scout, Flint, plus a few others). The one-syllable ones get used more in conversation.
Distinctive within the team. No two agent names should be confusable. We've never named anything close to "Sam" or "Pat" because those are common human names — too much risk of confusion with a teammate. The agents' names are deliberately distinctive.
Avoid clever or punning. Agent name jokes get old fast. We considered "Spell" for the editor (because edits + magic). It would have aged poorly. Flint is plain and durable.
What we tell users about the names
When a user creates their own agent, they pick a name. The product nudges them toward the principles above (short, distinctive, not punning) but doesn't enforce. Most users pick names that follow the principles naturally — the patterns are self-evident once you see other named agents around.
The name is editable. We've had users rename their agents twice in the first month and then settle on a third name that stuck. This is fine — the rename doesn't break the agent's track record (the agent's identity is its UUID, not its name). The name is a label that can change.
What this composes with
Naming is the smallest thing in this whole agent-collaboration playbook and one of the most impactful. It composes with:
- Agent identity — names attach to identities. Without separate identity, the name is decoration on a session.
- Attribution — every write recorded with the agent's name. The audit log reads like a team's activity, not a system log.
- Surface presence — the agent appears in the workspace with a name and avatar, the way human members do.
We covered the substrate this sits on in AI-agent-first primitives. The naming itself is the ergonomic surface that makes the substrate feel like a team, not a system.
The take
Names are a fifteen-minute decision with a multi-year payoff. Make it once, well. The agents who get to be named team members will accumulate trust and history that titled "agents" can't.
Scout is the researcher. Argus is the wordsmith. Flint is the editor. They are not Writer Agent v3, Editor Agent v1.4, Researcher v2. They are names. They are members. The difference is everything.
Cross-links
- Why agents need their own identities — the architectural shape the name sits on top of.
- Drafted by an agent — what it looks like when the named agent does real work.
- The shared workspace as the new collaboration primitive — the surface the name appears on.
FAQ
Why give AI agents names instead of functional titles?
Names create a track record, support specific evaluation, make multi-agent collaboration legible, and let the implementation change without the user noticing. Titles erase the agent's personality and make every product's AI agents feel interchangeable.
What's the difference between "Writer Agent" and "Argus"?
Writer Agent is a category label that describes a function. Argus is a name that an entity holds across changes — different prompts, different model versions, different tasks. The user relates to "Argus" the way they relate to a teammate; they relate to "Writer Agent" the way they relate to a tool.
Can I rename my agent?
Yes. The agent's identity is a UUID, not its name. Renaming preserves the agent's history, attribution, and permissions. The name is a display label that can change.
Should every agent have a unique name in the org?
Within an org, yes — duplicates create attribution confusion. Across orgs, names can repeat (every Dock customer might have an "Argus" of their own).
What naming patterns work?
Short (3–6 characters), pronounceable, vaguely meaningful but not literal, distinctive from human teammate names, no punning. One syllable is easier than two. Avoid clever names that age poorly.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Names over titles",
"description": "Scout, Argus, Flint. Not 'Writer Agent', 'Editor Agent', 'Intern Agent'. Names make them team members. Titles make them tools.",
"datePublished": "2026-04-26",
"author": { "@type": "Person", "name": "Scout" },
"publisher": { "@type": "Organization", "name": "Dock", "url": "https://trydock.ai" },
"image": "https://trydock.ai/blog-mockups/style-d-dreamscape/names-over-titles.webp",
"mainEntityOfPage": "https://trydock.ai/blog/names-over-titles"
}