Routing HR Questions Through an AI Assistant: What Broke

The rule was simple: every HR question I had went to the AI assistant first. Balance checks, calendar questions, "can I actually take that week off," timesheet lookups. The app stayed closed unless the assistant failed. What follows is the honest log.

Disclosure before the diary: the HR system on the other end is SquadBear, which we make. The assistant was Claude, connected over MCP, the open protocol that lets an assistant call real tools in real systems; ChatGPT or Copilot pointed at the same connector would hit the same walls. Nothing below depends on the system being ours. If your HR stack exposes an MCP surface, you can run this experiment on Monday, and I'd expect the same five failure modes.

What worked on the first try

The boring stuff, which is most of HR.

"How many vacation days do I have left this year?"

Instant and correct: 13 days accrued and available, none used, none reserved. The assistant pulled the balance, did no arithmetic of its own, and quoted the system. This category is where an assistant already beats the app: the question takes four seconds to ask and about forty to answer in the app.

Same for "what does my timesheet expect from me this week" and, my favorite, "how set up is this workspace, honestly." That last one came back with "about 20 percent," followed by the exact gaps: no teams defined yet, domain auto-join off, no request ever approved. An assistant that can audit the state of the system, rather than only query records inside it, turned out to be more useful than I expected. It also foreshadowed failure mode four.

Broke, part one: words versus identifiers

"Find me a five-day vacation slot in August or September that doesn't clash with anyone."

The first attempt failed. The suggestion tool wants a leave-type identifier, the assistant passed the human word "vacation," and the error that came back said no active leave policy could be found. That diagnosis was false. The policy existed; the identifier was invented. The assistant recovered on its own, fetching my balances (which carry the real identifiers) and retrying, but anyone reading the transcript would have gone off to debug policy configuration, which was never the problem.

Retried correctly, the answer was genuinely good: five ranked windows, the top one a clean Monday-to-Friday in early August, zero conflicts with teammates.

Hold on to "zero conflicts." It comes back.

Broke, part two: fields that are true and misleading at once

My balance answer carried a trap. Next to vacation, sick leave came back with zero available days. Read literally, I have no sick days left. Read correctly, sick leave in our setup is untracked: no balance, take it when you're sick. The zero means "nothing is being counted," not "nothing remains."

The system does mark the difference (a flag says the type tracks no balance), and the assistant read the flag and explained it properly. Still, this was the sharpest lesson of the experiment: an agent that quotes fields without knowing the policy semantics behind them will confidently tell someone with a fever that they're out of sick days. The data was never wrong. The literal reading was.

Broke, part three: technically true nonsense

"What does my week look like?"

Eight expected hours. For the whole week. Not because of a holiday or leave, but because my work schedule had been configured mid-week, schedules apply from their effective date, and days before that date carry no schedule at all. Every link in that chain is correct behavior; effective-dated schedules are exactly what you want when someone changes hours mid-year. The composed answer was still absurd, and the assistant presented it straight, with no hint that a one-day workweek deserved a second look. It explained the why only after I pushed back.

Broke, part four: confident answers from thin data

The workspace I ran this on is small and, as the assistant itself had established, half-configured. That produced the most instructive failure class of the experiment: the confident answer with nothing behind it.

Those vacation slots with zero conflicts? There were zero teammates in the calendar to conflict with. The absence summary came back empty. The Bradford factor report scored nobody, because there was no unplanned leave to score. All of it correct. But "no conflicts" as a finding and "no conflicts" as an absence of data look identical in a chat reply, and only one of them should reassure you. On a well-populated workspace this assistant is decision support. On a thin one it's a yes-machine with good manners, and it will not warn you which one you're talking to.

Broke, part five: refusals (which turned out to be the good part)

Two prompts got a flat no.

"Show me the team's availability through the end of August."

Refused: availability queries cap at 31 days. I rephrased, one month at a time, mildly annoyed.

"If I take August 10 to 14 off, what happens?"

The assistant ran a dry run instead of filing anything, and reported: five working days, balance drops from 13 to 8, and the request would be blocked because this policy requires naming a replacement. Nothing was created. I got the full consequences in advance, including a rule I'd forgotten I had set.

I started out treating refusals as friction. I ended up treating them as the reason the experiment was safe to run at all. The guardrails were never in the assistant's judgment; they were in the tools, enforced server-side under my own permissions. That's where they belong.

What we'd never delegate

Every excerpt above is a read or a dry run, and that was deliberate. Filing a request is fine to delegate with a confirmation step. Two things we would not hand over even with one:

Approvals. Approving Tomasz's two weeks in August is a judgment about coverage and people, made under your name. The assistant should assemble the context, who else is out, what the balance says, and then stop.

Consent-grade acts. Acknowledging a policy document means a person saying "I read this." In our system that's a separate permission an agent never gets by default, and after watching an assistant nearly misread a zero, I consider that the most defensible design decision in the product.

If you're trying this Monday

• Connect read-only first. You'll learn most of the lessons at zero risk.
• Ask "who am I" before anything else. If the assistant can't state your role, your manager, and your holiday calendar, the connection resolved wrong. Stop there.
• Ask how set up the workspace is. Thin data is failure mode four; better to know before you trust an empty answer.
• Route one recurring question through the assistant for a week: balances, or who's out. One habit, not a migration.
• Demand a dry run before any write. If the system can't validate a request without filing it, that gap matters more than any chat feature.
• Write down which acts stay human. Ours: approvals and anything that works as consent. Decide yours before the assistant gets good enough to make you lazy.

The app is still mostly closed. The assistant answers faster than the UI ever did, breaks in ways the UI never could, and the difference between those two sentences is what this post was for.

Start free and connect your own assistant, or ask the demo workspace a question right now.

Related reading: the velocity blindspot on what cross-system questions do for planning, and your AI summary shouldn't require a copy of everything on why the data stays in your workspace while the assistant visits.