You Can Build the HR Agent. The Hard Part Is Knowing When It’s Wrong
A third of enterprises skipped at least one software purchase to build with coding agents instead. HR is the worst place to test that logic, because nothing in the system tells you when it is wrong.
Contents
Building your own HR agent used to mean a team and a multi-year roadmap. Coding agents changed that math, and enterprises have noticed.
McKinsey published The state of AI in 2026: On the road to ROI on 25 August, drawn from 1,719 respondents across 97 countries. 32% of organizations decided against buying at least one software product or feature because they could build it internally with agentic coding tools. Among the 6% McKinsey classes as high performers, the ones crediting AI with at least 5% of company EBIT and calling its impact significant, nearly half had made that call, against 31% of everyone else.
On that reading, building is what the companies getting returns do.
The number measures one thing: someone priced a build against a purchase and chose the build. That is a judgment about the cost of construction, and construction is the cost coding agents have collapsed. They left a second cost untouched, and in HR that is the one that decides the outcome.
The cost that did not fall
Most enterprise software tells you when it is wrong. The invoice reconciles or it doesn’t. The integration returns the record or it errors. You see it without going looking.
Ask an HR agent which three people are ready for the regional director opening and you get a judgment. Nothing in the system disagrees with it. No test fails. The list looks identical whether the model of your workforce underneath it is sound or three years out of date, and the only people positioned to notice are the ones who already know those candidates by name. A built HR agent will not break. It will go on answering, and the answers will go on looking reasonable.
That asymmetry is the real variable in build vs buy AI agents for HR, and it is the one thing a coding agent cannot help you with. It will write the retrieval layer and the interface. It has no opinion on whether the answer was correct, because correctness here is not a property of the code.
Why the demo works
Pilots start with policy questions over a document corpus. How much parental leave do I get, what is the travel policy in Spain, where do I file an expense. One well-bounded source, answers you can check by opening the PDF.
That case is easy now, and buyers write the build estimate while looking at it.
The second question is different. Who on my team is at risk of leaving, and what should I do about it. Answering that means reconciling the HCM, the ATS, the learning system and the org chart, then reasoning over the result. The first question needs retrieval. The second needs a model of your workforce, and building that model is the actual project.
What the build estimate leaves out
Reconciliation, and then decay
Your systems do not agree on who people are or what they can do. The same person is a worker in one system and a resource in another. “Project management” in the learning catalogue and “project management” in the job architecture are not the same skill, and neither matches what the hiring manager wrote in the req.
Generic embeddings will tell you those strings are similar. That is not the same as knowing they describe the same capability in your organization, which is why off-the-shelf embeddings fail on workforce decisions. Somebody has to decide, and keep deciding.
Then the harder half. Workforce data is not a snapshot you load once. People move, teams reorganize, someone rewrites a job family, and employees pick up skills no one writes down. A map of your organization starts going stale the day you build it, and it goes stale without telling you. No error log fires for a reporting line that changed in March.
Permission
HR data access is relational and jurisdictional. A manager sees their own reports’ compensation and not their peer’s. A works council agreement constrains what can be processed at all.
Row-level security solves this for a person opening a screen. An agent acting for that person, across four systems, needs those same rules available to it before it acts, not checked afterwards. That requirement does not go away because your own team wrote the agent. Our governance engine makes them queryable at reasoning time. Someone also has to be able to reconstruct afterwards what the agent did and why, which is a second thing to build.
Evaluation
To improve a system you need to know when it was wrong. For an internal-mobility recommendation, that means an evaluation set: cases where someone has established the right answer, so a change can be tested rather than eyeballed.
Check whether you have one. Building it means going back through years of promotions and exits and labelling which were good decisions, which is slow and contested work. Skip it and every model change becomes a matter of opinion.
The labelled history is yours either way. A vendor amortizes the method around it: the rubric for what counts as a good move, and the tooling to label against it. You would build that from nothing, for one organization, and that has nothing to do with engineering capacity.
When building is the right answer
Build when the scope is bounded and the answer is checkable. A policy assistant over documents you own, a status lookup against one system of record. One source, and a small blast radius when it is wrong. The same goes for a process that is your own advantage and that no vendor models, as long as you accept that you will be checking the answers by hand.
Build when you have the team, and count year three as well as year one. Not the people who ship version one. The people who own the ontology and the evaluation set after the engineer who designed it has moved on. For the architecture side of that, the Academy’s build-vs-buy piece prices it out in more detail than a blog post can.
There is an answer to rule out before any of them. Before pricing a build, find out which AI features you have already paid for in the systems you own.
The question underneath the decision
Enterprise buying had been moving the other way. Menlo Ventures’ 2025: The State of Generative AI in the Enterprise, published in December 2025, found 76% of AI use cases purchased rather than built, up from 53% in 2024. McKinsey’s 32% counts declined purchases rather than delivered use cases, so neither number tells you where the share of shipped HR AI lands.
The tooling does not change which parts of your workforce model you end up owning and defending: the vocabulary that decides two skills are the same, and the evidence that says a recommendation was any good. Those are the assets. The agent is the surface. Our own answer is that the model is the product, which is what we built Loomra around. If you would rather own that layer yourself, that is the whole reason to build, and worth saying so out loud.
Either way the decision turns on the same thing, and it is not cost. Nothing in your stack will tell you the answers drifted. Someone has to be able to notice, and that capacity gets built or bought alongside the agent, or not at all. The Academy’s six dimensions for evaluating HR agent architecture is written for comparing vendors, and the same six questions work on a build plan.
If nobody can say who checks the answers, you have not priced the build.
