How to turn Claude people ops skills into agents

To turn a Claude skill into an agent, give it three things it doesn’t have yet: a trigger that starts it without you, access to the tools it needs to finish the job, and a defined point where it stops and asks a human. You can build that yourself with a scheduler and the Claude API, or use a people operations system that runs agents natively.

In Vol 2 of our Claude for people ops series, we built five people ops skills: new hire setup, probation tracking, leave audits, pre-payroll reports and review cycle checks. They save real time, but every one of them still waits for someone to open Claude and type the command. The probation check only runs if you remember it’s Monday. The pre-payroll report only runs if you’re not on holiday the week payroll closes.

This post covers the step from “skill I run” to “agent that runs”: what changes, three ways to build it yourself, what tends to break, and the alternative where you describe the agent in plain language and it reports back in Slack.

TL;DR

• An agent is a skill plus a trigger, tool access and an approval step. The skill’s instructions barely change
• Triggers come in three types: a schedule (every Monday), an event (a new hire is added), or a message (someone asks in Slack)
• Three do-it-yourself options, simplest first: Claude’s own scheduled tasks, an automation platform calling the Claude API, or Claude Code in headless mode on a scheduler
• The hard part of DIY isn’t the prompt. It’s authentication, permissions, approvals, logging and keeping it running
• Taito.ai agents skip the build: describe the workflow in plain language, pick the trigger, and the agent runs with the permissions of the person who owns it

What’s the difference between a Claude skill and a people ops agent?

A skill is a set of instructions you run. An agent is the same instructions, started by something other than you.

That sounds like a small change, but it adds three requirements:

• A trigger. Something has to start the agent: a time, an event, or a message.
• Unattended tool access. The agent needs to read your HR system, post to Slack or create a task without you being logged in and clicking “allow”.
• A safe stopping point. When nobody is watching, the approval step written into your skill becomes the most important line in it.

The good news: if you built your skills with clear approval points, as in Vol 2, they’re already most of the way there.

Which people ops skills should become agents first?

Not every skill should run on its own. The best candidates are tasks that are frequent, predictable, and mostly reading, checking or drafting.

A useful rule of thumb: if you’ve approved the agent’s output unchanged ten times in a row, it’s ready to run with less supervision. If you’re still editing it every time, keep it as a skill.

How do you build a people ops agent yourself?

There are three practical routes, listed here from simplest to most technical. All of them reuse the skill instructions from Vol 2 as the agent’s instructions, and all of them connect to your HR system through its MCP server (Model Context Protocol, the standard that lets AI tools read and write your other systems).

Option 1: Claude’s own scheduled tasks

The simplest route needs no code and no extra tools. Claude can run a task on a schedule in the cloud: you write the instructions once, pick how often it runs, and connect the same HR and Slack connectors you already use in Claude. Because it runs in the cloud, it keeps going when your laptop is closed.

Every Monday at 08:00, run the probation-tracker skill.
Post the summary to #people-ops in Slack. Don't message any managers directly.

Start with read-only tasks that end in a summary to you or one channel. Event triggers (“when a contract is signed”) and approval flows are limited here, so this route suits checks and reports rather than agents that act on records. Check what your Claude plan currently includes, since these features change often.

Best for: simple recurring reports and checks, with no developer and no setup beyond Claude itself.

Option 2: An automation platform calling the Claude API

Tools like n8n, Make or Zapier already handle triggers: a schedule, a form submission, a new row in a sheet, a webhook from your ATS (applicant tracking system). Add a step that calls the Claude API with your skill as the instructions and your HR system’s MCP server connected, then route the result to Slack or email.

Best for: teams who already use an automation platform and want event triggers without writing code. The trade-off is that complex, multi-step agents get hard to debug inside a visual workflow builder.

Option 3: Claude Code in headless mode, on a schedule

Claude Code can run non-interactively: you give it a prompt and a list of allowed tools, and it runs to completion without a chat window. Put that command on a scheduler (cron on a server, or a scheduled GitHub Actions workflow) and you have a scheduled agent.

# Runs every Monday at 08:00 (cron: 0 8 * * 1)
claude -p "Run the probation-tracker skill. Post the summary to #people-ops in Slack." \
  --mcp-config ./mcp.json \
  --allowedTools "mcp__taito__list_employees,mcp__taito__get_employee,mcp__slack__post_message"

mcp.json lists the MCP servers the agent can use (your HR system and Slack). --allowedTools restricts the agent to only the actions it needs. Read-only plus one Slack post is a good starting point.

Best for: scheduled agents with tightly controlled tool access, if someone on the team is comfortable with a terminal.

What usually breaks when you build people ops agents yourself?

The prompt is rarely the problem. These are:

• Whose permissions does the agent use? A scheduled job needs credentials that work while you’re asleep. The easy shortcut is an admin token, which means the agent can see every salary and health record in the company. That’s the opposite of least privilege, and in a GDPR audit it’s hard to explain.
• Where does the human approve? “Wait for my go” works in a chat. In an unattended agent, you need to build the approval yourself, typically a Slack message with buttons and something listening for the click.
• Events need webhooks. “When a contract is signed” only works if your HR or eSignature tool can notify your code, and your code is running to receive it.
• Logging and failures. When the payroll agent fails on the 25th, who finds out? You need error alerts, retries, and a log of what the agent did and why.
• Maintenance. API versions change, tokens expire, and the person who built it moves on. People ops agents are long-lived, so they need an owner.

None of this is unsolvable. But it’s the same build-versus-buy question as any other people ops tool: if your team enjoys running this kind of infrastructure, build it. If you want the agent rather than the infrastructure, there’s a shorter path.

How do you run people ops agents in Taito.ai without building anything?

In Taito.ai, you describe the agent in plain language and pick a trigger. Taito.ai plans the work, runs it, and posts results and pending decisions in Slack. For common workflows like onboarding, ready-made agents can be switched on in one click.

Here’s the probation tracker from Vol 2, written as a Taito.ai agent:

Every Monday at 8:00, find everyone whose probation ends in the next 30 days.
For each person, send their manager a Slack DM with the date and a link to our
probation review template, and create a task for the manager to complete the review
by the end date. If anyone has no manager, message me instead.
Post a weekly summary in #people-ops.

And new hire setup, as an event-triggered agent:

When a new employee is created, assign the time off and attendance policy for their
country, set up their onboarding tasks, and send their manager a Slack message with the
day-one checklist. Ask me before sending the invite to the new hire.

What you get without building it:

• Triggers: schedules, people events in Taito.ai (a new employee, a start or end date, with an offset like “seven days before”, or a submitted time off request), and signals from your ATS, such as a candidate moving stage in Ashby.
• Integrations: Slack, eSignature, your ATS and payroll, so the agent can act across your stack instead of only reading employee records.
• Permissions: an agent runs with the authority of the person who owns it, so it can’t see or do anything that person couldn’t. New agents start paused until you switch them on.
• Human in the loop: agents tell you about pending decisions and ask for more information in Slack when they need it, and you can see every run, ongoing and past.
• MCP stays open: you can still reach the same data and agents from Claude through Taito.ai’s MCP server. Your Vol 2 skills keep working alongside the agents.

One of our customers, a company of roughly 30 people, built four agents within two weeks of starting, covering onboarding tasks, record updates and recurring checks, without writing code.

Should you build people ops agents yourself or use Taito.ai?

Plenty of teams do both: Taito.ai agents for the core people ops workflows, and a custom agent built on Taito.ai’s MCP server for one unusual process that’s specific to their company.

Write the approval step first

A people ops agent is only as safe as its permissions and its stopping points. Write the approval step first, give the agent only the access it needs, and move it to “runs on its own” only after it has earned it. Whether you build on the Claude API or use Taito.ai, the skill instructions from Vol 2 carry straight over.

In Vol 4, we cover the governance side: what data AI should and shouldn’t touch, GDPR, permissions, and how to show an auditor what your agents did. If you’d like to see Taito.ai agents running on your own people ops workflows, see how it works, or we can walk you through it in 30 minutes.