The most useful adoption advice I give people sounds like a gimmick. Name your agents.
For months I referred to AI as “the tool”, and that language did quiet damage. Tools are things IT deploys, governs and owns. Calling AI a tool let everyone, including me, keep responsibility at arm’s length. The business requests, IT delivers, everyone consumes. Familiar and comfortable, and exactly the mindset that fails with AI.
Then we started building agents, and I noticed people struggled with the same conversation every time. They wanted “AI to help” but couldn’t describe what help meant. What inputs it would work from. What output would be good enough to use. What it must never touch.
So I started asking a different question: what’s its name?
It sounds trivial. It isn’t. The moment an agent has a name, the questions change shape, because you’re no longer consuming a feature, you’re managing a role. What is its job? What does it need access to, and what should it be denied? How will you judge its output? What does it do when it’s unsure? How do you know when its performance is slipping?
Notice something about that list. Those are the questions you’d ask about a new hire. And they’re also, almost exactly, the questions a risk or audit committee should ask about any agent operating in critical infrastructure. Access, accountability, performance, escalation. Naming doesn’t just help adoption, it drags governance out of the abstract.
The deeper shift is about ownership. While AI is “the tool”, people look to the CIO to drive adoption, and that’s wrong. The CIO can build the platform and set the guardrails. But only the person who owns the outcome can say what the agent is for, whether it’s doing a good job, and most importantly must remain accountable for the outcome. AI can never be accountable, a person must be.
If someone in your organisation wants an agent, ask them its name, its job, and how they’ll know it’s performing. If they can’t answer, they’re not ready to own one.