Hire The Role, Not The Tool

Hire the Role, Not the Tool

It’s time to stop asking which AI tool you should use. Instead, you should be asking what role(s) you need to fill. That simple reframing explains why most people's use of AI plateaus quickly at “really helpful sometimes,” but doesn’t go any further.

A generic chat-based assistant like Claude, Gemini or ChatGPT can answer anything badly. It has no default scope, so it has no standard to fail against, which means it never really fails - but underperforms quietly each time in a way that's easy to blow off. A role is much different. A role - copyeditor, researcher, first-pass designer - answers one thing extremely well, because it's scoped like a real job, not a search bar you type a question into. That's the real design thinking move buried in all of this: you're not shopping for a tool. You're writing a job posting for your own workflow, and the quality of what you get back is entirely determined by how well you wrote it.

Writing a role definition isn't that complicated, but it does take a bit more than a basic sentence. You need to clearly define the scope: what this role owns and what it's explicitly not responsible for. You need to specify the inputs: what it needs from you to perform the job, and what happens when it doesn't get them. You need to give the role a definition of failure: what "wrong" looks like for this specific role, not failure in general. And you need an escalation path: the point at which it should stop what it’s doing and ask for a decision from you instead of guessing around it. Leave any one of those points out and you're back to a generic AI assistant cosplaying as an agent.

Here's what that looked like in practice for me. I didn't hire a "writing assistant." I hired a copyeditor with a narrow brief: tighten my client-facing drafts, look for issues in my tone and delivery and flag anything that reads as inauthentic or overpromising, and most importantly - never add content I didn't write myself.

Every one of those clauses came out of a real mistake I'd made letting a generic assistant "help" with the same task, so the role definition is really just a list of all the things that went wrong, rewritten into boundary lines. That's how a good role gets written- not by imagining every possible failure mode in advance, but by getting narrower and narrower after each run that breaks.

This breaks down in one specific area, and it's worth mentioning directly: when starting the process, you shouldn’t delegate any roles that require a human judgment call just yet. Anything with real stakes attached, any decision that would embarrass you if it went sideways in public with a client, a call that depends on context the role wasn't given, a genuinely novel situation the job description never anticipated. The instinct to hire a role for everything is right. The instinct to hire it for everything immediately is not. Start with the narrow, low-stakes, well-bounded roles, the ones where a wrong answer is annoying instead of costly, and expand the hiring list as the boundaries prove themselves. Test these early role definitions out with low-stakes data and projects first to find their boundaries, and build trust in your own system. Then when it’s ready - consider giving your new “agent-in-training” it’s first real task, with real data.

What’s one role in your creative process you'd hire for first? Not a task, but a role, with a scope, an input, and a line where it should stop and ask for your guidance. Drop it in the #creativeai channel in my Discord. I'm genuinely curious where you’re actually starting with all this.

And be sure to drop your email at the Creative AI page for a ping when the book that talks about all this goes live. My co-author Tom and I would love to hear your thoughts on what we’ve written into it, and see how you can take those ideas even further.