Salesforce has launched seven agents, each with a first name — Casey, Paige, Carter, Hunter, Marshall, Piper and Fin — each assigned to a function: sales, customer service, commerce, IT and human resources, supply chain, customer experience. The choice to name rather than number them is a design decision, and it has measurable effects.
We have covered anthropomorphism as an involuntary reflex. Here is its deliberate version, built into an enterprise product.
Why naming works
The reason is well known and long documented in human-machine interface design: a named object is easier to summon mentally than a described one.
Saying "ask Casey" is shorter, more natural and more memorable than "use the agentic sales qualification module". In an organisation where dozens of tools coexist, that cognitive saving is not trivial.
There is also an adoption benefit. A team that hesitates before an abstract system hesitates less before something you talk to. This is exactly what we noted about the real obstacle to deployment: the technology exists, what blocks it is human.
What it produces that nobody asked for
Three effects, and they are not all desirable.
Miscalibrated trust. We have developed this point: language is the most powerful signal of interiority we know of, and a first name amplifies it. Someone who receives an answer from "Marshall" has a harder time treating it as a probabilistic output than if it came from a numbered module. Yet the central flaw of these systems — the same confidence whether they are right or wrong — demands precisely the vigilance that a first name relaxes.
The dilution of responsibility. This is the most serious point in an enterprise setting. "Casey approved the file" is a sentence that designates a non-existent person in charge. We wrote this about a system recommending a dismissal: the risk is not that the machine decides, it is that it serves to obscure who decided. A first name makes that confusion easier.
The inhibition of criticism. Challenging a module is natural. Challenging someone takes social effort, even when that someone does not exist. In a team, that can be enough for no one to question a dubious output.
There is a useful precedent. Consumer voice assistants have all had first names for fifteen years, and this has been widely studied. The finding is consistent: users attribute intentions to them, apologise to them, and overestimate their understanding. What was acceptable for setting a timer is less so for a system that processes customer files, commits sums of money or prepares decisions. The same design choice does not carry the same cost depending on the stakes.
What should be put in place alongside it
Naming is not condemnable in itself, and banning it would be absurd. Three counterweights make this choice tenable.
An explicit signature. Every output should clearly state that it is produced by a system, not merely carry a first name. This is precisely what the European transparency framework requires, which we recalled is aimed at what leads people to believe there is a human presence.
A named person in charge, too. Each agent should have an identified human owner, whose name appears next to the agent's first name. This is what prevents "Casey approved it" from becoming an acceptable sentence.
Traceability of actions. We wrote this about agents that pay: what matters is being able to establish who authorised what, within which limits.
What to take away
This design choice is revealing of a phase. What is being sold is no longer a technical capability, it is a team experience: seven virtual colleagues that you integrate into a mental org chart.
It is commercially effective, and it shifts responsibility onto the user. A system presented as a tool invites natural vigilance. A system presented as a colleague invites the trust you grant a colleague — a trust that rests, in a human, on the fact that they can be held accountable for what they say.
That is exactly what is missing here, and no first name replaces it.