I Gave My AI Agent a Name. The Work Got Better.

Sam Bell at his home office desk defining the role for his AI agent, Social Ads Mentor branding
Why naming my AI agent Sal changed how the work got done, plus the 30-minute onboarding test I use to scope any agent before I build it.

I've been running AI tools for eighteen months. The work got measurably better the day I gave one of them a name.

The name was Sal. But the name is not the point. What the name forced is the point.

A name forces a definition

To name an agent, you have to define what it owns. What it is responsible for. What "done" looks like when no one is watching.

Before the name, it was just "the AI." I would open a session, paste a prompt, get output, close the tab. Tomorrow I would do it again. Miss a day and the work simply did not happen. That is a tool. A tool waits for you. It has no responsibilities of its own. It holds no ground while you sleep.

The moment I tried to name the thing, I ran into a wall. I could not name it until I could say what it did. And I could not say what it did until I had written down the job. The naming was a forcing function for the scoping. That is the whole trick.

The job description I actually handed Sal

Pull campaign data every morning. Cross-reference it against the books. Calculate cost per lead by account. Format a structured summary. Post it to the ops channel before 8 AM.

Four tasks. One owner. One definition of done.

That is not a prompt. That is a role. The difference matters more than it looks. A prompt produces an output once. A role produces the same outcome every morning, in the same place, in the same shape, whether or not I show up to ask for it.

When I treated Sal like a prompt, I got sporadic, impressive one-off results. When I treated Sal like a role, I got something far more valuable: a result I stopped thinking about because it was simply handled.

The 30-minute onboarding test

Here is the question I now ask before naming any new agent: if this agent had a first week on the job, what would the onboarding document say?

If I can write that onboarding doc in thirty minutes, the role is scoped well enough to build. The inputs are clear. The output is clear. The destination is clear. If I cannot write it in thirty minutes, I am not ready to build. The fog in the document is the fog in the system, and no model is going to clear it for me.

Most people skip this step. They go straight to prompting. They chase the clever output instead of the durable role. Which is exactly why most AI tools still require their owner to show up every single time, paste the same context, and babysit the result. They never gave the tool a job. They only ever gave it a task.

The before and after

Before the name, my mornings started with me. I would decide what to look at, open the tools, pull the numbers, and shape them into something useful. The work was real, but it lived entirely in my head and my hands. If I traveled, it stopped. If I got busy, it slipped. The quality of my operation was capped by my attention on any given day.

After the name, the morning started without me. By the time I opened my laptop, Sal had already pulled the campaign data, cross-referenced it against the books, and posted the summary to the ops channel. I was no longer the first step in my own operation. I was the person who read the result and made the decisions only a person should make.

That is the difference between a tool and a teammate. A tool extends what you can do while you are doing it. A teammate holds a piece of the operation whether or not you are present. The name did not create that shift on its own. The role behind the name did. But I never would have written the role if the empty name had not embarrassed me into it.

Naming sounds soft. It is the opposite. It is the most demanding spec you can write, because a name without a defined job is embarrassing, and that embarrassment is what forces you to do the scoping you were avoiding. This is the same discipline I used to build the daily report I broke down in the automated ops report post.

Give the agent a name. Then earn it by writing the role behind it.

What this looks like in practice

Inside The Mentor Lab I am documenting exactly how Sal is wired. Which data sources he pulls. How the job description maps to the actual implementation. What broke in the first two weeks, and how I fixed it.

If you take one thing from this: stop opening a blank session and pasting a prompt. Write the onboarding document first. Define the four things the agent owns. Define what done looks like. Then, and only then, give it a name and turn it on.

Drop your name and email and I will send you the full breakdown of how Sal is built.

Share the Post:

Related Posts