Over the past couple of years I have heard the phrase “let’s start using AI” so many times that it has become background noise. And every time I want to give the same answer: that is not a plan. That is an intention. A plan does not start with a tool — it starts with a task.
The trouble is that the vast majority of HR teams enter the AI conversation from the wrong end. First a product gets chosen — because someone wrote about it, because it was demoed at a conference, because a peer from another company praised it. Then the team starts hunting for a use case to justify the purchase. And when no strong use case appears, or the result turns out to be mediocre, the conclusion is: “AI doesn’t work in HR.” In reality it was the approach that failed, not the technology.
The numbers make this brutally clear. According to recent research, 88% of HR tech leaders have not seen meaningful ROI from AI. And only 28% of organisations get what could be called a high value result from artificial intelligence. This is not about weak models. This is about tasks that were never broken down before someone tried to automate them. A tool without a task is spending without return. That is exactly why I built the AI HR Architect course: not to hand you yet another list of services, but to teach you to think like an architect — to start with the task and finish with the tool, never the other way round.
The trouble is that the vast majority of HR teams enter the AI conversation from the wrong end. First a product gets chosen — because someone wrote about it, because it was demoed at a conference, because a peer from another company praised it. Then the team starts hunting for a use case to justify the purchase. And when no strong use case appears, or the result turns out to be mediocre, the conclusion is: “AI doesn’t work in HR.” In reality it was the approach that failed, not the technology.
The numbers make this brutally clear. According to recent research, 88% of HR tech leaders have not seen meaningful ROI from AI. And only 28% of organisations get what could be called a high value result from artificial intelligence. This is not about weak models. This is about tasks that were never broken down before someone tried to automate them. A tool without a task is spending without return. That is exactly why I built the AI HR Architect course: not to hand you yet another list of services, but to teach you to think like an architect — to start with the task and finish with the tool, never the other way round.
Why “Let’s Implement AI” Is Not a Strategy
The Tool Is Chosen Last
Picture a builder who arrives at an empty plot carrying a single hammer and announces: “Let’s build.” Build what exactly? A house, a warehouse, a bridge? The hammer does not answer that question. AI works the same way. A chat, an agent, a connector — these are tools. They do not tell you what work needs doing.
The companies that started experimenting with artificial intelligence earliest were also the first to get disappointed. They bought licences, handed out access, ran training on which buttons to press — and six months later discovered that nothing in the process had changed. People were still doing the same things, only now with a chat window open in the next tab. Money spent, no return. Not because the model is weak, but because the sequence was inverted.
Market Noise Is Its Own Problem
There are currently more than 120 agentic AI tools across eleven categories, and that is only the portion someone has bothered to catalogue. Each has its own interface, its own logic, its own vocabulary. Trying to pick among them manually means drowning in noise.
The logic of “we need to learn about even more AI tools, let’s try them all” feels rational but is a losing strategy. Products change at ferocious speed. Over this short period of explosive development I personally went from ChatGPT to Claude, then added Codex on top — and that is just my own trajectory. A product exists today; tomorrow it has been acquired, renamed, shut down or reborn in a different form. Building your competence around a specific product means building on sand.
What does not change is the architect’s way of thinking. It is not tied to any product. If you can break a task apart, you can match any tool to it — whichever tool happens to be around this month.
Two Ways of Looking at the Same Task
Picture a builder who arrives at an empty plot carrying a single hammer and announces: “Let’s build.” Build what exactly? A house, a warehouse, a bridge? The hammer does not answer that question. AI works the same way. A chat, an agent, a connector — these are tools. They do not tell you what work needs doing.
The companies that started experimenting with artificial intelligence earliest were also the first to get disappointed. They bought licences, handed out access, ran training on which buttons to press — and six months later discovered that nothing in the process had changed. People were still doing the same things, only now with a chat window open in the next tab. Money spent, no return. Not because the model is weak, but because the sequence was inverted.
Market Noise Is Its Own Problem
There are currently more than 120 agentic AI tools across eleven categories, and that is only the portion someone has bothered to catalogue. Each has its own interface, its own logic, its own vocabulary. Trying to pick among them manually means drowning in noise.
The logic of “we need to learn about even more AI tools, let’s try them all” feels rational but is a losing strategy. Products change at ferocious speed. Over this short period of explosive development I personally went from ChatGPT to Claude, then added Codex on top — and that is just my own trajectory. A product exists today; tomorrow it has been acquired, renamed, shut down or reborn in a different form. Building your competence around a specific product means building on sand.
What does not change is the architect’s way of thinking. It is not tied to any product. If you can break a task apart, you can match any tool to it — whichever tool happens to be around this month.
Two Ways of Looking at the Same Task
Think about the last task where you used AI. Did you pick the tool first, or break down the task first? For most people the honest answer is the tool. When there were three tools on the market, that still sort of worked. Today it does not.
Three Types of HR Tasks: One-Off, Recurring, Process
The first thing an architect does is classify the task. Not by function — recruiting, learning, C&B — but by its nature. There are exactly three types, and the type determines everything that follows.
Type 1. The One-Off Task
One result, once, often urgently. Context is not preserved because the task will not come back in this form. Examples: a rejection letter to one specific candidate, the review of a single CV, a job ad for an urgent role you are closing this quarter and never again.
There is no system to build here. What you need is a fast, precise prompt — nothing more. Building a project for the sake of one letter is effort that will never pay for itself.
Type 2. The Recurring Task
The same work comes back regularly — on a schedule or triggered by an event. There is a stable context: templates, rules, documents, criteria. Examples: screening applications, where dozens and sometimes hundreds of CVs arrive every day; the weekly hiring funnel report; the monthly turnover summary.
The main mistake here is treating a recurring task as a one-off. New chat every time, and every time you explain to the model who you are, what your criteria are, what output format you need. You are burning time recreating a context that should have been saved once. These tasks belong in a project — with instructions, uploaded files and persistent context.
Type 3. The Process
A chain of steps and roles that runs continuously. Multiple participants, multiple systems, multiple handovers. The classic example is onboarding: HR, the recruiter, the personnel department, IT, the manager, the employee, a mentor, colleagues. Or the performance review cycle.
A process looks like this: the offer is accepted — prepare accesses and documents; day one — welcome letter, adaptation plan, introductions; week one — immersion into the team and first tasks; ninety days — the first goal and feedback. No single prompt covers that. This requires an architecture with triggers and with humans involved at key points.
Why AI Lands in Some Processes and Not Others
If you have already tried applying artificial intelligence in HR, you have probably noticed something odd: in recruiting a plain chat helps a lot, in onboarding noticeably less, and in performance review almost not at all. Many people conclude the tool is weak.
The tool is fine. The task types are different. Recruiting is full of one-off and recurring tasks — perfect ground for prompts and projects. Onboarding is dominated by recurring tasks with process elements creeping in. Performance review is almost pure process: few one-off tasks, few recurring ones, but plenty of chains, roles and handovers. That is why a conversational chat where you write prompts gives you, at best, rewritten manager feedback and a draft survey. As a system, AI absolutely applies there. As a chat, it does not.
Type 1. The One-Off Task
One result, once, often urgently. Context is not preserved because the task will not come back in this form. Examples: a rejection letter to one specific candidate, the review of a single CV, a job ad for an urgent role you are closing this quarter and never again.
There is no system to build here. What you need is a fast, precise prompt — nothing more. Building a project for the sake of one letter is effort that will never pay for itself.
Type 2. The Recurring Task
The same work comes back regularly — on a schedule or triggered by an event. There is a stable context: templates, rules, documents, criteria. Examples: screening applications, where dozens and sometimes hundreds of CVs arrive every day; the weekly hiring funnel report; the monthly turnover summary.
The main mistake here is treating a recurring task as a one-off. New chat every time, and every time you explain to the model who you are, what your criteria are, what output format you need. You are burning time recreating a context that should have been saved once. These tasks belong in a project — with instructions, uploaded files and persistent context.
Type 3. The Process
A chain of steps and roles that runs continuously. Multiple participants, multiple systems, multiple handovers. The classic example is onboarding: HR, the recruiter, the personnel department, IT, the manager, the employee, a mentor, colleagues. Or the performance review cycle.
A process looks like this: the offer is accepted — prepare accesses and documents; day one — welcome letter, adaptation plan, introductions; week one — immersion into the team and first tasks; ninety days — the first goal and feedback. No single prompt covers that. This requires an architecture with triggers and with humans involved at key points.
Why AI Lands in Some Processes and Not Others
If you have already tried applying artificial intelligence in HR, you have probably noticed something odd: in recruiting a plain chat helps a lot, in onboarding noticeably less, and in performance review almost not at all. Many people conclude the tool is weak.
The tool is fine. The task types are different. Recruiting is full of one-off and recurring tasks — perfect ground for prompts and projects. Onboarding is dominated by recurring tasks with process elements creeping in. Performance review is almost pure process: few one-off tasks, few recurring ones, but plenty of chains, roles and handovers. That is why a conversational chat where you write prompts gives you, at best, rewritten manager feedback and a draft survey. As a system, AI absolutely applies there. As a chat, it does not.
Take three tasks from this week and count honestly: how many are recurring but handled as one-offs? That is probably the single most common gap in how HR applies AI.
Decomposition with Jobs to be Done
Jobs to be Done came out of product development and business analysis — we teach it on our business analyst course. But it fits HR perfectly, because it solves our core problem: we formulate tasks far too superficially.
People Hire an Outcome, Not a Process
The central idea of the methodology: people do not “do a task” — they hire an outcome in order to make progress. So the architect’s first question is: what job does this task need to get done? What progress is required and where is the current blockage?
The distance between a weak and a strong formulation is enormous:
People Hire an Outcome, Not a Process
The central idea of the methodology: people do not “do a task” — they hire an outcome in order to make progress. So the architect’s first question is: what job does this task need to get done? What progress is required and where is the current blockage?
The distance between a weak and a strong formulation is enormous:
A weak formulation describes an artefact. A strong one describes an outcome. Only the strong one lets you verify whether AI actually delivered.
The Decomposition Algorithm
1.Formulate the job. One sentence: what outcome and what progress are needed.
2.Split it into 5–7 subtasks. Not more, not fewer — that is the working range.
3.Define an input and an output for every subtask. What goes in and what comes out.
4.Mark the type of each subtask: one-off, recurring, process.
5.Note what data is needed and where it lives. This is critical — without data the architecture stays on paper.
Working Through a Real Task
A hiring manager comes to you and says: “We need to hire a senior backend engineer, write the job ad.” It looks like one task. In reality it is a job made of several subtasks, and here is how an architect lays it out:
The Decomposition Algorithm
1.Formulate the job. One sentence: what outcome and what progress are needed.
2.Split it into 5–7 subtasks. Not more, not fewer — that is the working range.
3.Define an input and an output for every subtask. What goes in and what comes out.
4.Mark the type of each subtask: one-off, recurring, process.
5.Note what data is needed and where it lives. This is critical — without data the architecture stays on paper.
Working Through a Real Task
A hiring manager comes to you and says: “We need to hire a senior backend engineer, write the job ad.” It looks like one task. In reality it is a job made of several subtasks, and here is how an architect lays it out:
Notice that subtasks 1 and 6 involve people and approvals, while 2–5 involve text and data. Their AI potential is completely different. Until the task is broken down you cannot see that, so you try to automate the whole thing at once — and end up disappointed.
This is exactly how systems get designed in software development. A business analyst listens to a user, the user says one sentence, and behind that sentence sits an entire chain of subtasks. The HR architect does the same.
Where Decomposition Breaks
•Fragmenting into micro-steps that are meaningless on their own. If a subtask has no standalone output, it is not a subtask.
•Mixing different jobs into one task. “Hire and onboard” is two distinct jobs.
•Stopping at the artefact. “Write a job description” with no inputs and outputs is not decomposition, it is a rephrasing.
•Ignoring the type and the data of each subtask. Without those you cannot take the next step.
To support this, course participants get the Task Decomposition Worksheet — a working sheet where you record the task as a job, the 5–7 subtasks, inputs and outputs, the type of each, and the required data with a note on where it lives.
This is exactly how systems get designed in software development. A business analyst listens to a user, the user says one sentence, and behind that sentence sits an entire chain of subtasks. The HR architect does the same.
Where Decomposition Breaks
•Fragmenting into micro-steps that are meaningless on their own. If a subtask has no standalone output, it is not a subtask.
•Mixing different jobs into one task. “Hire and onboard” is two distinct jobs.
•Stopping at the artefact. “Write a job description” with no inputs and outputs is not decomposition, it is a rephrasing.
•Ignoring the type and the data of each subtask. Without those you cannot take the next step.
To support this, course participants get the Task Decomposition Worksheet — a working sheet where you record the task as a job, the 5–7 subtasks, inputs and outputs, the type of each, and the required data with a note on where it lives.
Four Criteria: AI Fit or Not
Once the task is broken down, you need to decide whether artificial intelligence belongs here at all. Four criteria answer that.
Criterion 1. Repeatability
How often does the task come back? If it is one-off, AI fit is low — sometimes doing it by hand is simply faster. If it is periodic, build a project. If it is constant, it is a direct candidate for automation. The higher the repeatability, the more strongly the task pulls towards AI.
Criterion 2. Data Volume
How much information has to be processed? A couple of lines, one document, dozens of files, hundreds of records, large exports? Data is what artificial intelligence feeds on. Where there is a lot of uniform data, AI saves the most. Where data is scarce, the benefit shrinks and sometimes disappears entirely.
Criterion 3. Input and Output Format
What are you feeding in — text, a table, a file? How clear and structured is it? What do you expect out, and in what shape? Between input and output sits the processing, which is what AI performs. The clearer the input and output, the better the task suits automation. A vague input and a vague output mean you can neither set the task properly nor check the result.
Criterion 4. Cost of Error
What happens if AI gets it wrong? If the cost is low — a draft letter, alternative phrasings, a set of ideas — you can grant more autonomy, because mistakes are easy to spot and fix. If the cost is high — decisions about people, payments, terminations — you need a human in the loop and firm constraints, or guard rails. Those things do not get automated, full stop. We cover this in depth in lesson six of the course.
Criterion 1. Repeatability
How often does the task come back? If it is one-off, AI fit is low — sometimes doing it by hand is simply faster. If it is periodic, build a project. If it is constant, it is a direct candidate for automation. The higher the repeatability, the more strongly the task pulls towards AI.
Criterion 2. Data Volume
How much information has to be processed? A couple of lines, one document, dozens of files, hundreds of records, large exports? Data is what artificial intelligence feeds on. Where there is a lot of uniform data, AI saves the most. Where data is scarce, the benefit shrinks and sometimes disappears entirely.
Criterion 3. Input and Output Format
What are you feeding in — text, a table, a file? How clear and structured is it? What do you expect out, and in what shape? Between input and output sits the processing, which is what AI performs. The clearer the input and output, the better the task suits automation. A vague input and a vague output mean you can neither set the task properly nor check the result.
Criterion 4. Cost of Error
What happens if AI gets it wrong? If the cost is low — a draft letter, alternative phrasings, a set of ideas — you can grant more autonomy, because mistakes are easy to spot and fix. If the cost is high — decisions about people, payments, terminations — you need a human in the loop and firm constraints, or guard rails. Those things do not get automated, full stop. We cover this in depth in lesson six of the course.
How It Looks in Practice
The AI Fit Checklist
Run every task through four points:
1.The task recurs regularly.
2.There is enough data and it is uniform.
3.The input and output formats are clear.
4.The cost of error is acceptable or controllable.
In practice the question is rarely a simple yes or no. Usually it is a question of prioritisation: there are many tasks and you must decide what to automate first. The four criteria give you an objective scale instead of intuition and internal politics.
Run every task through four points:
1.The task recurs regularly.
2.There is enough data and it is uniform.
3.The input and output formats are clear.
4.The cost of error is acceptable or controllable.
In practice the question is rarely a simple yes or no. Usually it is a question of prioritisation: there are many tasks and you must decide what to automate first. The four criteria give you an objective scale instead of intuition and internal politics.
The Architect’s Map: Eight Layers of Thinking
The course is built as eight layers, where each lesson is one layer and each one goes deeper. This is not a sequence of buttons — it is a sequence of decisions.
We look at these layers not through the lens of specific solutions and products but through principles. Once you own the framework, any tool becomes just a marker in the box: you know how to draw, so you pick the right colour, rather than letting the colour decide the picture.
The Palette of Six Capabilities
Everything artificial intelligence can currently do for HR reduces to six capabilities. This is the shift from 200 tools to a single language of choice.
Capabilities 1–3 are the basics — that is where most people start. Capabilities 4–6 are advanced, and they are precisely what separates an architect from a chat user.
An important point: all six capabilities are supported by practically every major engine. Prompts — ChatGPT, Gemini, Grok, Microsoft Copilot, DeepSeek, Perplexity, Llama and dozens of others. Projects exist in Claude, in ChatGPT, and Gemini has implemented them too. Connectors are available in most solutions. The same goes for computer use, scheduled actions and vibe coding.
That is why the palette outlives any product. Learning a specific product is sometimes useful — we do that on separate courses such as AI in Recruiting or ChatGPT for HR. But it is fragile knowledge: products change, close, get acquired. Owning the palette of capabilities makes you universal.
An important point: all six capabilities are supported by practically every major engine. Prompts — ChatGPT, Gemini, Grok, Microsoft Copilot, DeepSeek, Perplexity, Llama and dozens of others. Projects exist in Claude, in ChatGPT, and Gemini has implemented them too. Connectors are available in most solutions. The same goes for computer use, scheduled actions and vibe coding.
That is why the palette outlives any product. Learning a specific product is sometimes useful — we do that on separate courses such as AI in Recruiting or ChatGPT for HR. But it is fragile knowledge: products change, close, get acquired. Owning the palette of capabilities makes you universal.
What the Architect’s Work Looks Like in Practice
Put it all together on one real task:
1.Take one real task from this week — not an abstract one, but something actually on your plate.
2.Formulate it as a job in one sentence: what outcome and what progress is needed.
3.Break it into 5–7 subtasks with clear inputs and outputs for each.
4.Mark the type of each subtask: one-off, recurring, process.
5.Run each subtask through the four AI fit criteria.
6.Only then think about which of the six capabilities applies.
Notice that step six is the first moment you think about a tool. Everything before that is about the task. That is the core shift in thinking.
1.Take one real task from this week — not an abstract one, but something actually on your plate.
2.Formulate it as a job in one sentence: what outcome and what progress is needed.
3.Break it into 5–7 subtasks with clear inputs and outputs for each.
4.Mark the type of each subtask: one-off, recurring, process.
5.Run each subtask through the four AI fit criteria.
6.Only then think about which of the six capabilities applies.
Notice that step six is the first moment you think about a tool. Everything before that is about the task. That is the core shift in thinking.
Answer Three Questions for Yourself
Before moving on, answer honestly:
•How do you currently decide whether to do a task with AI or by hand? Do you have a criterion, or is it intuition?
•The last time you opened a chat — was that a one-off task or a recurring one? And if it was recurring, why did you handle it as a one-off?
•Which task do you do roughly the same way every single week? That is your first candidate for a project.
•How do you currently decide whether to do a task with AI or by hand? Do you have a criterion, or is it intuition?
•The last time you opened a chat — was that a one-off task or a recurring one? And if it was recurring, why did you handle it as a one-off?
•Which task do you do roughly the same way every single week? That is your first candidate for a project.
Your actions
1.Pick one case — a real HR task in your company that you will work through. If you do not have a large HR team, take the task you feel is missing.
2.Reformulate it as a job to be done — through outcome and progress, not through an artefact.
3.Break it into 5–7 subtasks with inputs, outputs, type and required data.
4.Run it through the four AI fit criteria and cut everything that should not be automated.
5.Find the recurring tasks you handle as one-offs and build projects for them.
6.Identify where the cost of error is high and design human involvement in from the start.
7.Do something concrete this week. Do not let this end with reading — take one subtask and drive it to a working solution.
2.Reformulate it as a job to be done — through outcome and progress, not through an artefact.
3.Break it into 5–7 subtasks with inputs, outputs, type and required data.
4.Run it through the four AI fit criteria and cut everything that should not be automated.
5.Find the recurring tasks you handle as one-offs and build projects for them.
6.Identify where the cost of error is high and design human involvement in from the start.
7.Do something concrete this week. Do not let this end with reading — take one subtask and drive it to a working solution.
The AI HR Architect course explains how to think in terms of AI tools for various HR tasks. Learn how to integrate AI systematically!
