Production agents for People Ops

A People team I worked with had a policy bot they were proud of. In the demo it was flawless: someone typed a question about parental leave, it pulled the right clause, cited the handbook, and everyone nodded. Three weeks after it went live, an employee on a fixed-term contract asked the same question mid-TUPE-transfer, and it answered with total confidence and total inaccuracy. The demo worked. The rollout didn't. Production agents for People Ops are not smarter demos. They are demos plus the infrastructure a demo skips.

That infrastructure is the whole subject here: real data the agent can reach, a context stack so it stops guessing, explicit tool contracts, exception handling, an off-switch to a human, a trace you can read afterwards, and one named owner. Get that scaffolding right and the agent behaves like a junior operator who actually works there. Skip it and you have a confident guessing machine wired into people's lives. This is the same wall pilots hit everywhere, which is why most AI pilots stall at production rather than fail outright.

What a production agent actually is

The word "agent" has been abused until it means almost anything. A vendor macro that fires canned text is sold as one. A Zapier zap that forwards an email is sold as one. Neither is. Here is a working definition worth holding to:

An AI agent is a system that takes a goal, decides its next action, calls tools, keeps state, and moves the work forward with an audit trail you can read. Everything short of that is automation wearing the word.

That is more than a chatbot and more than a workflow with an LLM step bolted in. It is closer to a junior operator with superpowers. And like a junior, it needs a clear job, access to the right systems, rules about what it must not decide, memory, a way to recover when something breaks, and a human to escalate to. Miss any of those and what you have built is a roulette wheel with a nice interface.

The distinction matters because it changes how you govern the thing. Automation you can trust on rails. An agent makes choices, so it needs the guardrails that come with choice. Before you call something an agent, run it through the test below. If it fails the first two rows, it is a workflow, and that is fine. Just do not trust it, or govern it, like something that decides for itself.

Start with the data, not the app

There is a reflex in People Ops: there is a problem, so buy a tool. The market is delighted to oblige. There is now a specialist AI product for every box on the org chart. The reflex is wrong, and it is wrong for a specific reason. Your problem is not a missing feature. It is that the data sits in silos that do not speak to each other.

The HRIS knows the employee. The ATS knows the candidate. Payroll knows the comp. Performance knows the rating. Engagement knows the sentiment. None of them know each other, so nobody in the building has one clean view of a single person.

Buying a tenth product adds a tenth silo. The value you are missing lives in the integration and orchestration layer, not in another app. This is why a workflow tool such as n8n, at roughly £20 per builder seat per month, SOC 2 and ISO 27001 compliant and self-hostable if your security team needs that, often produces more real capability than the newest specialist HR app. It connects what you already own. It lets a small AI step run inside a pipeline that touches the systems where the truth actually lives, and it stays auditable, fixable, and visible when something breaks. Build the extraction steps model-first, never with regex fallbacks that quietly rot. And a plain rule of thumb: if you cannot pull the data through an API today, do not build an agent on top of it tomorrow.

The context stack that stops an agent guessing

The single biggest reason agents fail in production is missing context. Most teams build one like this: here is a model, here are some tools, go figure it out. That fails because the agent does not know what matters, what happened five steps ago, which policy applies, or what "good" looks like in your business. So it guesses. And a guessing system in a People function is worse than no system, because people assume it is reliable until the day it isn't.

The fix is to think in a stack, not a blob. Context is not a wall of text you paste into a prompt. It is three layers, and the agent needs all three at once.

Give an agent task context alone and it behaves like a temp on their first hour. Give it the full stack and it starts behaving like someone who has worked there for a year. That is the difference between an answer you can publish and an answer you have to check.

Context also has to be the right shape. It must be structured, so the agent reads clean payloads with IDs, owners, and timestamps rather than messy email threads. It must be retrievable, so the agent can fetch what it needs instead of relying on what happened to fit in the prompt. It must be verifiable, so every claim it makes can be traced back to a source. And it must be relevant, filtered down to what this task needs rather than everything the business knows. This is why the AI workspace you set up for the team matters as much as the model: it is where that context lives so nobody has to invent it from scratch on every run.

Contracts, exceptions, and the off-switch

An agent without explicit tooling contracts is a hazard. Every tool it can call needs a written contract: what it does, what inputs it expects, what it returns, what side effects it has, and when it is allowed to be called. Without contracts, the agent invents tool calls when it hits an edge. With them, it stays inside the rails you set.

Exception handling is the next thing production demands and demos never show. What happens when the model returns nothing useful? When a tool call times out? When the policy is genuinely ambiguous? In a demo these never happen. In production they happen constantly. Agents that survive have explicit retry logic, real fallback paths, and a clear point at which they stop.

That stopping point is the escalation path, and it is not optional. Every production agent has a moment where it should hand off to a named human rather than power through. The agent that knows when to stop is worth more than the agent that answers everything, because the second one will eventually answer a TUPE-transfer parental-leave question with total confidence and be wrong. Design the off-switch before the agent ever runs live, not after it embarrasses you.

What ships versus what stalls

Two agents can chase the same use case and end up worlds apart. The one that ships and the one that dies in a demo loop are not separated by cleverness. They are separated by whether anyone did the unglamorous work. Here is the split, laid out plainly.

None of the left-hand column is exotic. It is what you would ask of a new hire: know where to find things, check before you assert, follow the process, put your hand up when you are not sure, and leave a record. We build agents like operators because operators are the standard they have to meet.

Observability: if you cannot see it, you cannot trust it

If you cannot see what the agent did, you cannot trust it. If you cannot trust it, you cannot scale it. Observability for a People Ops agent has three parts, and most teams build the wrong two.

Trace. Every action the agent took, in order, with the inputs and outputs at each step. This is the part teams skip, and it is the part that matters most the day something goes wrong, which it will. Without a trace, debugging a failure is guesswork. With one, it is a five-minute conversation.

Metrics. How often it succeeds, how often it escalates, how often it fails silently, and what it costs to run. A silent failure rate you are not watching is the one that ends the programme.

Audit. Decisions tied to identifiable inputs, retained for as long as your governance requires. In a People function this is not a nice-to-have. Agents touch pay, performance, and personal data, so the audit trail is what keeps you defensible. Wire it in from the start, because retrofitting it is far harder, and read AI governance for People teams before you point an agent at anything sensitive.

Your first production agent

Start with the least glamorous thing on the list, and do it in order. This is the sequence that works, and each stage earns the right to the next.

Each of those bounded agents has the same shape: clear scope, a real escalation path, an observable trace, honest exception handling. Each one earns the right to expand, and none of them tries to be the agent that runs the whole function. The through-line is the move from prompts to systems: a prompt is a one-off, a system is a thing the team owns and improves. If you want a structured way to pick the first workflow and get a ranked plan for it, the Grain Audit takes one process end to end and hands you a 90-day plan you keep, whether or not you carry on working with us. That belongs to the AI workspace for People Ops more broadly: the agents are the visible bit, but the workspace is what makes them survive a quarter.

Production agents are not magicians. They are operators. Build them like operators, hold them to an operator's standard, and they will work like operators. Build them like demos and they will keep working right up until the moment a real person needs them.