How to know what agent to build.
A framework for finding the right use case.
Welcome to FullStack HR, and an extra welcome to the 84 people who have signed up since last week.
If you haven’t yet subscribed, join the 11500+ smart, curious HR folks by subscribing here:
Happy Sunday!
It’s now possible to publish articles in different languages here on Substack (yey!)
Also possible for you to translate any article into your preferred language!
I will try to write articles in both English and Swedish, but if time is short, English will be the main language.
During the last six months, one of the things I’ve been doing is building agents within organizations. And while it’s somewhat easy to build them, the most overlooked question is still: What should we build in the first place?
That question is the most important one to ask before starting to build any agent. So this week, let’s talk about that and try to figure out what to build.
Also, if this resonates, I’ve made a skill out of it that you can upload to Claude/ChatGPT. It’s in the end.
Most organizations I meet these days have done one or more of these three things. But it’s usually the case that they’ve bought licenses, written a policy, and, at best, run a training or two.
And then placed the entire responsibility on the individual.
Get good at prompting. Use the tool every day.
Nothing wrong with that. It’s where you start. But individual value doesn’t scale into organizational value on its own. That’s why so many companies talk about AI while so few can point at measurable impact. Someone gets faster at writing emails, and the org chart shrugs.
But that’s also the whole allure around agents: they become a bridge. A well-chosen agent takes something one person figured out for themselves and makes it available to a team, or a whole organization. Someone builds a collective agreement coach for their own use. Shared with the entire management layer, it becomes something else entirely.
But only if it was the right thing to build.
Building these days is quite easy (at least if you have access to Codex/Claude Code), but even if you use Microsoft, it’s somewhat easy. I was part of an event where an organization built 2000 agents in a single push. Workshops, energy, everyone building.
It was truly great!
But. A few months later, we looked at usage. Three of them were alive.
Not because the technology was bad. Because nobody had asked why each agent existed, who it was for, or who would own it in six months. The building was easy, and that was the problem. When building is easy, the thinking becomes the bottleneck. And most organizations haven’t noticed that the bottleneck moved; we still perceive it to be in the “building phase”.
Hunt for friction
So how do you find the right thing to build? You map.
When we learn AI tools as individuals, the question is “what hurts for me?”. When we think about agents, the question moves up a level. What hurts for my team? What do the people around me do over and over that is repetitive, time-consuming, or plain frustrating?
List three to five of those. Not solutions, not agent ideas but friction.
If you get completely stuck at team level, fine, start with yourself. But aim upward. The value lives in the shared friction, not the personal one.
Describe the friction, not the problem
When doing this, people write down problems. “We have high employee turnover.” True, painful, and useless as a starting point.
That’s a problem. It’s not friction.
The friction is that you spend hours every month onboarding people who quit after three months, hours you don’t have, while your own work piles up. Now we’re somewhere. Now you can see when the frustration arises, who it hits, and what the real cost is.
So for every item on your list, push one level deeper. When does it hurt? Who does it hurt most? What does it feel like on the receiving end? Where can I get data to better understand and support my friction?
The models are good enough these days to build the right thing if you describe the friction honestly. What they can’t do is rescue you from a fuzzy problem statement. The most common mistake I see when organizations are doing this is not technical. It’s starting with the attitude of “let’s see what it comes up with”.
That makes the whole thing impossible to evaluate. Is it doing well? Is it failing? Nobody knows, because nobody defined what good means.
Flip it. Before anything gets built, you should be able to state the end goal in one sentence. Give clear answers about what applies in our collective agreement. Turn incoming meeting notes into a first draft of a follow-up email. One narrow, concrete goal.
If you can’t say it in one sentence, the problem is too broad. Narrow it until you can. A narrow goal is easy to test and easy to judge. A vague one just produces a demo that impresses everyone once and helps no one twice.
Maybe it shouldn’t be an agent at all
One question from the session deserves its own heading. Someone asked when to use classic automation, when to use RPA, and when to use an agent.
The rule of thumb is simple. If the flow is static and rule-based, if A then B then C every single time, classic automation is fantastic. The chain never breaks. An agent earns its place only when there’s a step in the middle that requires judgment, where information has to be weighed and a path chosen.
If nothing needs judging, you don’t need an agent. A fair share of today’s “agent initiatives” are automation projects wearing a trendier name. That’s not a technicality. It’s part of deciding what to build.
Last one, and it’s short. Before anything gets built, name an owner. A person, not a team, not “we’ll figure it out”.
An agent without an owner is an agent that’s dead in three months. I’ve watched it happen enough times that I now treat it as a law of nature.
The skill that separates organizations getting value from agents isn’t technical. It’s diagnostic. The people who get good at this aren’t the ones who know the most platforms. They’re the ones who can look at their team’s week and say “there, that’s the friction, and this is exactly what solving it looks like”.
That skill is trainable. It costs nothing. And you can start this week, without opening a single tool.
What’s the friction? Who does it hurt? What does solved look like, in one sentence? Should it even be an agent? Who owns it?
Answer those five, and you’ve done the hardest part.
The rest, honestly, is just buttons.
Need it as a skill? Download it here.