Can't we just build an HR assistant with Claude or Copilot?

Short answer: yes, you can

An engineer with Claude, an MCP connector and a free afternoon can put a bot in Slack that answers policy questions from your handbook. It will work, and it will be pretty good. If you're paying a vendor purely to answer questions from documents you already own, stop.

Two more things worth flagging before the argument's worth having:

Connecting systems is getting cheaper. MCP (Model Context Protocol) is doing for system integration what standardized APIs did for everything before it. Most of your stack is slowly moving that way, and we build on MCP along with APIs ourselves. Anyone telling you that making the first connection is a moat in 2026 is describing 2022. What hasn't gotten cheaper is everything after the first connection — keeping it permissioned, audited, mapping to the right fields, writing back to systems with the right approvals, and working through the vendor's next release.

A rough version is often enough at first. Teams that build usually ship something worse than what they'd have bought and are fine with it, because it takes pain away in week one.

So the question isn't whether you can build. It's what you'll be holding together in twelve to eighteen months.

Where builds stall

Not on the AI. The AI part is the easy part now.

They stall on the unglamorous middle: where to store rotating API tokens securely. Where to host the small apps that do the work. How to attribute a change to a person rather than a bot. What happens to a request the assistant can't handle. Whether Security will sign off on a service account that reads employee records.

None of that is hard in the sense of being intellectually difficult. It's hard in the sense of being months of somebody's time, and none of it is the part that made the project exciting.

The pattern is consistent: builds are strong at the front — the conversation, the answers, the knowledge — and thin underneath. Engineering attention goes where the interesting problems are, and the interesting problems are all at the front.

The cost: one more limb on the Frankenstein’s monster

Here's how a People Technology lead described their stack to us. They're good at their jobs, they've automated more than most teams, and every piece of it works:

"We're doing the best we can with what we've got. But it is, for sure, kind of a Frankenstein's monster."

Something starts in the HRIS. A report fires off to IT. Their system picks it up. A field written back into the HRIS feeds a second system, which triggers something else. To start an offboarding early, someone types a fake date into an unused field so the automations fire in time.

Nobody designed that. It accrued. Every piece was the sensible next step, and each one was cheaper to build than to buy.

Building your own assistant doesn't replace Frankenstein's monster. It adds a limb — one that now sits in front of employees, holds the credentials, and needs somebody to own it.

When we asked that same team what they'd most want from a tool, the answer had nothing to do with smarter AI:

"What system takes the largest amount of things off of other systems, or unifies it to make a process more streamlined?"

That's the buy argument, in a buyer's words. Not better. Fewer.

If you own HR or IT service, read this part

The build takes quarters. Your team works through all of them.

Whatever it costs in engineering time, that isn't your number. Your number is that your team runs unchanged while it's built. Same queue, same Monday, same manual letters, for two to four quarters. If it slips — and builds slip — that's next year too.

Ask what your team is doing differently in month three. If the answer is "nothing yet," that's the price.

You'll be a stakeholder, not a customer

Nobody puts this in the business case, and it decides how the whole thing goes.

When you buy, you have a contract, a named owner and an escalation path. When you build, you have a colleague with their own roadmap. Your request for a new workflow sits behind revenue work. The engineer who cared about this moves teams in April. There's no SLA on a favour, and no version of this where you win the prioritisation argument against the thing that makes money.

Ask directly, and get it in writing: who owns this in twelve months, what's the response time when it breaks, and what happens to my requests when engineering's priorities change?

A good CTO will answer honestly. That answer is usually the most useful thing in the whole evaluation.

What happens to the requests it can't handle

A bot resolving 60% doesn't remove 60% of the work. It removes the easy 60%, leaves the hard remainder, and adds a new problem: the failures become invisible. When you start working on the harder requests, that’s when you can get to 95% deflection rate like Sondermind did.

One team we spoke to had rolled out a Slack bot that replied to every message telling people to raise a ticket. Nobody raised tickets. They just kept going directly to HR.

The requests didn't stop, they just stopped being counted. And when an employee has already asked once, sending them somewhere else to ask again is the moment you lose them. As another HR Lead put it, having to say, “I know you already reached out, but try this other channel” is the thing nobody wants to do, so they quietly answer it themselves. Which is where you were before you built anything.

"Good enough" doesn't hold still

The failure comes later. Your HRIS ships a change. You acquire a team on a different payroll system. Edge cases pile up exactly where rules engines have always fallen over: the ones where the answer depends on the person, the country, the manager and the exception.

By month nine it's more complex and your team depends on it. That's the expensive combination, and it's why a market of employee service platforms exists at all.

Already building? This part's for you

Most people reading this have started. Nothing here says stop.

The useful question is which layer is worth your team's time. If your engineers have built a front door that people like, that's good work and it shouldn't be thrown away. What sits underneath it — the queue, the case record, the governed write path into your HRIS, the audit trail — is the same for every company of your size, and none of it will ever be your competitive advantage.

Fair warning on that shape, though. If your assistant owns the conversation and the thing underneath is just storage, you'll end up comparing service desks on price, and the cheapest one wins. That's a legitimate outcome. Choose it deliberately.

Questions to ask before you commit engineers

Put these to whoever's proposing the build. Our answers sit next to each, so you can hold us to the same bar.

1. Who owns it in twelve months, and what's the response time when it breaks?

Name the person, not the team. Ask what happens when they change roles.

Kinfolk: A named Customer Success Manager from implementation through rollout and beyond, plus a shared Slack channel with our engineers, and support response commitments.

2. What identity does it act as, and has Security signed off on a model deciding what that account can see and do?

This is the question that stops builds, usually late. A service account with broad HRIS or identity-provider access, with a model deciding what to do with it, is what security teams have been rejecting for two years. Ask them before you build, not after.

Kinfolk: the model never holds the keys. It has no HRIS credential and no path to the HRIS at all. It selects from a fixed set of pre-defined tools and expresses intent; it doesn't construct the request. Deterministic middleware owns each tool's schema, builds the call, holds the credential, and constrains the response before anything returns to the model.

Underneath that:

• Reads run on a service user whose scope you set in your own HRIS tenant. You can start read-only and widen it when you're ready. Kin can never reach past what you've granted.
• Writes can run on the employee's own OAuth token. The HRIS can enforce their permissions and record the individual as the actor in its business-process audit, not "Kinfolk." Same for a manager changing a report's record.
• A code-enforced field allowlist sits between the HRIS and the model. Compensation, personal identifiers and confidential custom fields never reach the model, so it can't surface them — regardless of who's asking, including about themselves.
• Tools are off by default, individually permissioned, and can require approval that surfaces in Slack.
• The tool surface is static. The model can't extend or discover tools at runtime. Changing the set is a deliberate configuration step by people you authorize, or an engineering change on our side that goes through code review.

We have this written up in full for security reviewers, including a walkthrough of the request-construction boundary in our codebase. Ask and we'll send it.

3. Where does the audit trail live, and can Legal pull it?

If the honest answer is a spreadsheet — and it often is, because someone in Legal asked for a timestamped log late in the build — decide now whether that survives a dispute, an access review or a regulator.

Kinfolk: Every interaction logged and audit-ready, on every plan. Writes are additionally recorded in your HRIS's own audit against the person who made them. SOC 2 Type II, ISO 27001, GDPR. EU-based infrastructure. Your PII isn't shared with third-party LLM providers and none of your data trains their models.

4. What happens to requests it can't resolve?

Kinfolk: They're queued, categorized, routed and tracked to SLA, with sensitive requests kept private, and failed requests surfaced back to your team as a signal about what to fix. You can hold them in Kinfolk or push them to your existing help desk.

5. Does it cross HR and IT, or only one of them?

Builds get scoped to whoever funded them. But a joiner needs both: HR creates the record, IT provisions identity, access and hardware, someone chases the manager for the missing approval, and it all has to land before Monday. The handoff is where employee service breaks, and it's the part nobody builds.

Kinfolk: One system across both HR and IT, sharing the joiner-mover-leaver process, so an employee asks in one place regardless of which team owns the answer.

6. Who's on call when connected systems ship a breaking change?

Kinfolk: We are. Kin Integrations are ours to maintain, and you'll hear from your named contact before you hear from an employee.

7. What's the exit, in both directions?

Ours is a contract term, and your data is yours to take. Yours is unpicking something that’s been built with sunk costs — worth knowing while it's still optional.

And the question you should ask us

"You're a small company. What happens if you're not around?"

Fair, and we'd rather answer it than leave it sitting there. Kinfolk has raised $8.5M to date, including a $7M seed round led by AlbionVC in early 2026 with PROfounders Capital, Ascension and Emerge, and angels including the founder of Oyster HR. Companies between 500 and 5,000 employees run their HR service on us today. Your data is exportable, and your knowledge and case history are yours.

Worth noting the symmetry, though. An internal build carries continuity risk too; it just doesn't have a name on it. It's whichever engineer or team member holds the context, and their next role.

How the options compare

When you should build

There are cases where we'd tell you to, when you fit all these criteria:

• Under a couple of hundred people, all in the same office, with one HR system
• No regulated audit requirement on employee data
• No need to go beyond surfacing knowledge or simple workflows
• Multi-turn, conversational experiences in Slack and Teams are not important
• No need for analytics to understand where to improve processes, policies, and the AI
• An engineer or team member who wants to own it, with protected time to do so

And when you shouldn't buy Kinfolk: if you need deep ITIL process, CMDB and change management, buy an ITSM platform. If you only need IT support and will never extend into HR, there are good IT-only tools — look at those instead.

Where foundational models and enterprise search platforms fit

Keep them. Employees should be using foundational models like Claude, ChatGPT or Copilot for their own work, and a search platform indexing your content with cross-department workflows. These are systems of answers and content generation.

Kinfolk is the system of action specifically for employee service — holding the record for the request, the work done by the agent, the approvals, the action taken in your HRIS, who owned it, how long it took, and what your team should fix so it doesn't come back.

One People leader we spoke to thinks HR and IT end up as one function. Whether or not that's right, employees already behave as though it's true — they ask wherever they happen to be standing. The layer that catches them shouldn't depend on which team owns the answer. See how teams are solving for this already. Book a demo.