From prompts to systems

The People function is in a strange position with AI. The technology is cheap, the curiosity is high, the leadership pressure is real, and yet, six months in, almost nothing has changed in how the work actually gets done. Recruiters still triage manually. Onboarding still depends on a single person's calendar. Performance reviews still consume entire weeks every cycle. The dashboard says "AI initiative in progress." The grain says otherwise.

There are two traps that catch nearly every team, and they look like opposites.

The Dabbler

Someone on the team, usually one of the curious ones, opens ChatGPT, asks it to write a job description, gets back something acceptable but generic, and quietly stops using it. The next day they go back to the template they already had. They tell themselves AI is "interesting" but "not quite there yet."

What actually happened was simpler: they asked once, got a generic answer, and never built any of the context that would have made the second answer better. They treated the model like Google. Google has no memory of you. Neither did the model, because nobody gave it any.

Dabblers produce individual tricks. They do not produce team capability.

The Tool Shopper

The opposite trap, equally common at scale. A Head of People decides to "do AI properly." They book a strategy day. They evaluate vendors. They run a pilot of an AI recruiter, then a pilot of an AI coach, then a pilot of an AI policy assistant. They write an AI strategy deck. They share it in an exec meeting and nobody disagrees, because nobody understood it well enough to disagree.

Six months pass. The market has moved twice. Three new categories of tooling exist that the strategy doesn't mention. The team has been busy and produced nothing they actually use.

Tool shoppers produce decks. They do not produce capability either.

Why both fail

Both traps share the same fault: they treat AI as a thing you procure, a tool, a model, a feature, rather than as something you build with. They mistake the answer for the system that produces the answer.

A real AI capability inside a People function is not a tool. It is:

• Connected context. The model knows what your company is, who your people are, what your policies say, what last quarter looked like. Not because you pasted it in, but because the system holds it for you.
• Repeatable workflows. The work that used to consume an afternoon now happens in a chain of steps the team can re-run, refine, and trust.
• Internal builders. A small number of people inside the team who can wire two tools together, write a workflow, deploy a small agent. Not engineers. People who know the work and have learned the craft.
• Clear governance. Where the human stays in the loop. Where the model never goes alone. What is logged, what is reviewed, what is forbidden.

None of that comes from a prompt, and none of it comes from a procurement cycle.

The mechanic: workflows, automations, agents

The third path has a shape. It is not "use more AI." It is a sequence: workflows first, automations second, agents only when both are in place.

Workflows are the foundation layer. A workflow is a structured, step-by-step process: hiring manager creates requisition, recruiter posts job, candidates apply, interviews scheduled, offer extended, background check, first day. Humans make decisions at the right points. The workflow is visible, documented, and easy to teach. Most People teams are missing this layer entirely. They have habits, not workflows.

If you cannot draw the workflow on a whiteboard, you cannot improve it. And you certainly cannot automate it.

Automations are the efficiency layer. Once a workflow is stable and the rules are clear, you automate the boring parts. Time-off request triggers a balance check, manager notification, calendar update, payroll sync. No interpretation needed. The system runs. Errors drop. Hours come back.

Automations are appropriate when the rules are stable, the inputs are clean, and human judgment is not adding value. They are inappropriate when the situation needs context, when policies vary, or when the rules change every quarter.

Agents are the autonomy layer. An agent is an AI system that can take a goal, decide a next action, use tools, and move work forward. A benefits agent that fields employee questions, pulls relevant policy, interprets edge cases, and escalates when it should. Useful, powerful, and almost always built too early.

Most "agents" in production are just prompts with ambition. They hallucinate confident answers, forget what they were doing mid-task, call the wrong tool at the wrong time, and work perfectly in the demo and fall apart the second reality shows up. Agents need a stack of context: task context (what's happening now), process context (how your business works), organisational context (your policies, language, cost centres). They need state, tooling contracts, exception handling, observability, and a human escalation path. Without that you have a roulette wheel with a UI.

Build agents last. Build them on top of stable workflows and tested automations. Or do not build them.

Outcomes, not outputs

Underneath the workflow stack sits a habit shift that most teams find harder than the tooling: working from outcomes, not outputs.

A traditional task list says "schedule interviews," "send offer letters," "process onboarding paperwork." The work is broken down into outputs. AI cannot do much with outputs. It can do the same speed, slightly faster.

An outcome-shaped workflow says "shorten time-to-hire from 28 days to 14 without dropping quality." Now AI has a target. You can design a chain of steps, decide where humans add judgment, decide where automation removes friction, decide where a small agent could absorb the long tail of candidate questions, and you can measure whether the workflow moved the outcome.

The shift from tasks to outcomes is the shift from doing AI to building with AI. It is also the thing that finally makes the work measurable, which is the thing that finally makes it survive a budget conversation.

The third path

The third path is the one we keep seeing work. It looks unglamorous from the outside. There is no strategy day. There is no vendor.

A small group inside the People team takes one workflow, usually a painful, well-bounded one, and rebuilds it with AI in the loop. Inbound applications, or first-week onboarding, or the manager check-in cycle. They build it together, with one person who understands the work and one who has learned to wire things up. They run it. They watch where it breaks. They fix it. Then they take a second workflow.

After six months, the team has not "done AI." It has changed how four pieces of its work get done. The change compounds. People outside the team start asking how. The People function, quietly, has become the part of the company most fluent in building with AI.

That is what this track is about. Not which model to use. Not which vendor to back. The slow, stubborn discipline of moving from prompts to systems, and the patterns that make it stick.

In the next pieces we go deep on what that actually looks like: setting up the AI workspace that makes any of this possible, governance that protects judgment instead of strangling it, the champion model that grows builders inside the team, the readiness diagnostic that tells you what to build first, the automation patterns we keep seeing pay off, and the domain map that makes all of it legible. Underneath all of it sits the same scaffold: an AI operating system shaped to a People function.

It is not a strategy. It is a practice. And like any practice worth having, it has a grain.

What this connects to

Auto-recommended next reads in the People Ops cluster, ranked by shared concepts and headings:

• An AI enablement operating model for People leaders
• The HR Architect: a new role inside the People function
• AI governance for People teams
• An AI policy blueprint for People teams