Your AI Agent Should Have a Job Title. Here's Why That Matters.

Most conversations we have with business owners about hiring an AI agent go the same way for the first ten minutes. They tell us they want to add AI. They tell us what tools they have already tried. They tell us what their competitors are doing. Then we ask one question that stalls almost every call: what is the job title of the agent you are hiring?

Not "what should it do." Job title. If this agent were a person you were about to interview, what would be on the offer letter.

The reason we ask is not clever. It is that the answer separates people who are ready to buy from people who are still shopping for a category. And it separates the projects that will produce results from the ones that will spend three months producing a demo.

#Why the title matters more than the tool

An AI agent is a role in your business. If the role has a name, it has a scope. It has an owner. It has success criteria that a normal human manager could evaluate on a Friday afternoon.

"AI intake agent for inbound leads" is a job title. Somebody in your business already knows what "good" looks like for that role, because you probably had a person doing it, or you always wished you did. The moment you name the role, three things fall out of it: the tasks it owns, the tasks it does not own, and the person who reviews its work.

"AI for our sales pipeline" is not a job title. It is a category. There is no clear owner, no scope, and no way to say on any given Tuesday whether it did a good job. Projects that start from a category never finish, because there is nothing to finish.

The tool question is a distraction that comes early and stays late. "Should we use OpenAI or Anthropic." "Do we need a vector database." "Is this an n8n job or a custom build." All of those are engineering decisions that can only be answered once the role is defined. Answering them first is like buying office furniture before you have decided what the company does.

#The one-page test

Here is a test we use before any engagement. Ask the person on your team who would supervise this agent to write it a one-page job description. Not us. Not the vendor. The internal owner.

Role, reporting line, three responsibilities, three things it is not responsible for, and one paragraph on how they will know at the end of the first month whether it should keep the job. That is the whole document.

If your team can produce that in a working day, the project is real. You already know what you are hiring for, and any competent build will hit it.

If your team cannot produce that in a working day, no amount of AI tooling will save the project. You are asking a machine to do a job that no human on your team has thought through. The machine will pick a job for you, and the job it picks will be whatever is easiest to demo.

#What happens when the title is fuzzy

We have watched the fuzzy-title version of this play out enough times to describe it in advance.

Month one: the demo is exciting. The agent does five things at once, badly, and everyone agrees the pieces are impressive. Nobody wants to be the person who says the pieces do not add up.

Month two: someone starts using it for one of the things it can do reasonably well. That use grows. The other four things quietly stop being demoed, because they were never quite right and nobody has time to fix them.

Month three: the "AI project" is really just the one thing that stuck. Nobody is willing to admit that, so the roadmap keeps promising the other four. The team building it is exhausted from working on features nobody uses.

Month four: the project is either killed, or renamed, or handed to a different vendor. In every case, the reset costs more than the original build.

That entire arc is preventable. The prevention is naming the role clearly on day one, and being willing to say "not that" to everything outside it.

#What good scoping looks like

The engagements we run that go well all look the same at the start. There is one job title. There is one internal owner who signs off on the definition of done. There is a list of things the agent explicitly does not do, and that list is longer than the list of things it does.

The "does not" list is the load-bearing part. It is how you keep the project from turning into an octopus. It is how you tell six months later whether the agent is under-performing or whether it is being asked to do things that were never in scope.

An intake agent that reads inbound emails, classifies them, and drafts a routing suggestion is a scoped role. An intake agent that also handles pricing questions, updates the CRM, and books meetings is four roles pretending to be one, and it will fail as one because the failure modes of any of the four will taint the others.

Hire one role at a time. Ship it. Prove it earns its title. Then hire the next one.

#Start with the org chart, not the tech stack

If you are looking at your business and thinking "we should add AI," stop for an hour and do a different exercise instead. Look at your org chart. Look at the roles that are open, the roles that are overwhelmed, and the roles that produce work you know is being done at half the quality you would want.

Those are the job titles. Some of them will be a good fit for an AI agent. Some of them are still human jobs and always will be. But you cannot tell which is which until you have named them.

The best AI hires we have seen are the ones where a founder pointed at a single line on their org chart and said "we need someone doing this, we cannot find or afford the right person, and we know exactly what good looks like." That is a hireable role, whether the hire ends up being human or synthetic.

The worst AI hires we have seen are the ones that started with a tool demo.

Want help writing that one-page job description before you start building? Get started with a Free Technical Analysis and we will walk through the org chart with you.