G&C Glover & Co. The Blog
Essay · 29 August 2026 · 5 min read

Writing a new agent spec? Review it with your HR partner.

I built a staff of AI agents and gave them personalities. The research says the personality does nothing. What actually matters is a document HR has been writing for decades.

I hired a marketing lead named Meredith. She has an MBTI type. She does not exist.

Meredith is an AI agent. So is Brad, my business development agent, and Fiona, who keeps track of my finances. I built them in my first weeks on my own, and I gave each of them a personality I thought would suit the work. I am a solopreneur, and this was my way of building a team — one that would balance me out.

Then I went looking for research on whether any of that helps, and found out the personality part does nothing.

What I found out

A Wharton study published in December 2025 tested expert personas across six frontier models on graduate-level questions. Telling a model it was an expert produced no reliable improvement in accuracy. An earlier study tested 162 different personas against more than two thousand factual questions and concluded that the effect of any given persona is, in their words, largely random. And a 2025 paper found that injecting a personality trait dramatically changed what a model said about itself, while not measurably changing what it actually did.

My first reaction was a little defensive. I still see their personalities come through in their responses, and I still like that. However, the honest read is that their personality is not what makes them work.

If not a personality, what does? Anthropic publishes guidance on this, and it says a subagent needs four things: an objective, an output format, guidance on the tools and sources to use, and clear task boundaries.

I read that list and stopped, because I have pored over hundreds of these in my career.

The four things are a job description

The objective is the job summary. The output format is the essential functions of the role. The guidance on tools and sources — what the agent is allowed to draw from to do the work — is the qualifications. The clear task boundaries are the scope of the role: what sits inside it, what does not, and where the authority ends.

That is a job description. Engineers arrived at it from first principles, apparently without noticing that human resources has had a form for it since before most of us were born.

And once you see it that way, you can see what is coming and plan for it, because we have already made every one of these mistakes on people.

Two things HR already knows

Job descriptions rot, and nobody notices until it costs something.

Recently, I was deep in a project rebuilding job descriptions. The old ones had repetitive language that was already documented in our company core competencies and did not need to stay in the description. They lacked clarity and meaningful differentiation between levels. Most of all, they were badly out of date with the work that was actually being done.

If you use AI seriously, that should sound familiar — a subagent that is not fully current with your work, still following instructions you wrote for a version of the job that has moved on. A tech leader may not think about this at all. An HR person thinks about almost nothing else, because we have watched it happen. Agents will need governance and a consistent process for keeping them current, the same way roles do. Nobody is going to want to build that. It is the part that matters.

Role ambiguity has a price, and it is usually paid by your best people.

In this same project, we had two roles doing essentially the same work. One was paid slightly higher. The original intent behind that difference had eroded over the five years since the job description was written, and by the end nobody could explain it. Employees were confused about how to reach the higher level, and why they were not paid the same for doing the same job.

It showed up in our engagement scores, in the questions about growth and career mobility. It also showed up in our internal mobility scores. Some of our strongest people at the lower level moved to other departments because they had decided they could not move up in Operations.

Nobody set out to do that. It happened because a document stopped matching reality, and getting approval to fix it took years.

Now picture the same drift across a set of agents whose responsibilities overlap, in a company where nobody’s job is to notice.

Who should be writing these

It depends on the size of the company, and the pattern is consistent.

At the smallest businesses, the owner writes the job descriptions — which is to say, the owner who is already the whole HR department. At mid-sized companies it belongs to a general HR leader. At the largest, it sits with a compensation professional or a compensation team.

The strongest discipline I ever saw around job descriptions was at my largest employer. I also found it was the slowest — governance that strict meant we could not make changes at the speed the work required. That tension is about to land on agent design, and small businesses have the best shot at both: enough structure to hold, enough room to move.

What a compensation professional brings is specific. They will catch vague criteria on sight. They have a feel for which language will be difficult to keep current, because they have maintained it for years. And they think about how roles work together — the thing not every agent builder may immediately jump to, because it only becomes obvious after you have watched two overlapping roles quietly cost you three good people.

The objection I would expect

Someone building their own agents could reasonably say I am describing a resemblance rather than a real thing — that a job description is a static document in a drawer, and an agent specification is executable code.

I would push back on the first half. HR and compensation professionals know better than to treat a job description as static. It must stay current with the work that is happening today, and it must stay current for legal compliance. These are the people who know what language ages a description and how to reframe it.

The same goes for your spec. If it is not current, it may not work the way you want it to — and it may not interact well with your other agents, especially the new ones you add later. Which is precisely what happens to a job description when the company grows around it and nobody goes back.

Monday morning

If you are using an AI agent for anything that matters, take your spec to your HR or compensation partner and ask them to read it as a job description. Is any of your language vague? What will go stale? What overlaps with something you are already running? What is missing that would make it work better?

If you do not have an HR partner, feel free to reach out! I would love to see what you have built 🤖

I am not suggesting that HR should build your agents. I am suggesting that the specification is a human resources artifact, and the people who write specifications for a living have been standing right here the whole time.
From Glover & Co.

Send me an agent spec.

The Monday assignment, but with me. Send the spec for one agent you are actually running — the whole thing, however rough — and I will read it the way I would read a job description and send back what is vague, what will go stale, and what overlaps with something else you have running. No charge and no deck.

Send me your spec See the Concierge
Erin on LinkedIn Glover & Co. on LinkedIn Reply to this essay
← All essays