AI workforce management now means two things
Most articles on AI workforce management are about one thing: software that uses forecasting and optimisation to plan people. It predicts demand, drafts the schedule, flags overtime before payroll does, and leaves a manager to approve the result. That's useful, and it's what the phrase meant until recently.
The phrase now has a second meaning. If some of your work is done by AI agents (writing first drafts, triaging tickets, checking documents, researching leads), then those agents are part of the workforce. Somebody decides what they work on, how much they take on, who covers when they fail and what they leave behind. That's workforce management too, even though none of the agents has a shift.
Contact-centre vendors have started using "agentic workforce management" for a third, narrower idea: agents doing the planner's own routine work, such as adherence checks and reporting (Assembled's overview is a good example). That's worth knowing about, but it's still about planning people. This post is about the agents that take a share of the work itself.
Most teams will need both at once. Below is a one-page register and a weekly review for a team that mixes people and agents.
Meaning one: AI that plans your people
This is the established category: forecast the work, turn it into shifts, draft a roster within contracts and rest rules, and find cover when someone calls in sick. The manager still approves. A good tool shows why it put someone on a shift and which rule stopped it from using someone else. Without that, managers stop trusting the roster and go back to the spreadsheet.
Your people are still governed by working-time law. In the EU that means minimum daily and weekly rest, a cap on average weekly hours and paid leave, plus whatever your contracts and collective agreements add. Any AI that plans people has to treat those as hard limits, not preferences.
Meaning two: managing a workforce that includes AI agents
An agent doesn't need rest, but managing one raises questions that sound a lot like managing a person:
| Question | For a person | For an AI agent |
|---|---|---|
| What work may it take? | Skills, qualifications, certificates with expiry dates | Declared skills and levels, kept consistent with the tools it actually has |
| How much at once? | Contracted hours, a fair share of the queue | A backlog limit set by rate limits, cost and machine capacity |
| When is it available? | The roster, time off, on-shift status | Whether its host is online, and whether it's paused |
| Who covers when it can't? | A backup on the cover list | The next eligible worker in the queue, often a person |
| What does it keep? | Personal notes, governed by HR policy | Its results, which may contain customer data, and for how long |
| How do you review its work? | One-to-ones, quality checks | The record of what it was given, why, and what it reported |
A job sits with an agent for two days, and nobody can say whether the agent was paused or nobody qualified was free. That's what happens when agents get a separate inbox, a separate tool and a separate person who "looks after the bots". The left column has decades of practice behind it. The right column is usually improvised.
Where the two meanings meet: one queue
The cleanest setup keeps one queue of work with one set of rules about who may take what. A job that needs a skill only people have goes to a person. A job an agent is rated for may go to the agent, or to a person if the agent is busy, paused or offline. When an agent hands a job back, the next eligible worker picks it up. That might be a person who is on shift right now.
That's why the two meanings belong together. The roster plans who should be on shift, and the queue offers each job to whoever is on shift and qualified. Keep both where the person planning cover can see the queue. Otherwise nobody notices that the only person who could take over from the agent is off all week.
The register: one row per worker
Keep one register for the whole team, people and agents in the same table. Here's the shape, with two filled example rows. Both are illustrative, not customer data.
| Field | Person example: support lead | Agent example: research agent |
|---|---|---|
| Name and kind | Support lead, person | Research agent, AI agent |
| Skills and levels | Refunds 5, Billing disputes 4 | Keyword research 4, Competitor analysis 3 |
| Hard limits | Working-time rules, contract hours | Read and edit in one project folder, two web tools, no secrets passed in |
| Capacity | Rostered shifts | One task at a time |
| Availability source | On-shift status, planned by the roster | Its host online, and not paused |
| Who can give it work | The queue, the team lead | The queue, the marketing lead |
| Backup when it can't finish | Second-line lead on the cover list | Next eligible worker; a marketer reviews before anything is published |
| What it keeps | Notes under HR policy | Only the outcome, unless the owner chooses more |
| Owner | Operations manager | Marketing lead |
| Last reviewed | Date | Date |
Two fields do most of the work: hard limits and backup. If an agent's hard limits aren't written down, nobody can check them. If the backup is "someone will notice", the backup is nobody.
A weekly review that covers both
Thirty minutes, once a week, with whoever owns the queue.
- Coverage. Which shifts next week have a gap, and does any gap leave an agent with no qualified person behind it?
- Handbacks. Which jobs did agents reject or report they couldn't finish? Did each one reach a person, and how long did it wait?
- Mismatches. Did any agent get work its tools couldn't do? Fix the skills or the tools, not the individual task.
- Load. Was any agent or person consistently at their limit? For people that's a fairness and burnout question. For agents it's a cost and capacity one.
- Retention. Did any agent keep more than the outcome? Was there a reason?
- One record. Pick one finished job at random and read its record from start to finish. Could you explain to a customer who did it and why?
If question 6 takes more than five minutes to answer, fix that before you add another agent.
How Fivexer handles both halves
Fivexer has the queue and the roster in one workspace.
- People. The roster engine builds schedules under EU working-time rules, then lets a manager review and publish them. When someone calls in sick, the cover flow ranks the people who could step in and shows anyone ruled out next to the rule that ruled them out. See workforce scheduling.
- Agents. An agent is a worker in the same pool as people, with rated skills, a backlog limit, a pause and a setting for what it keeps. See the agent docs.
- One record. Each routing decision can carry a trace of who was considered and why one was chosen.
There are limits to state plainly. Fivexer doesn't build agents or host their models. An agent that finishes a task and reports it couldn't do it records the reason but isn't handed to a person automatically, so keep handbacks on your weekly review. A rejected task, though, does go back to the queue for the next eligible worker.
Start with the register
Fill in the register for your three busiest workers, including at least one agent if you run any. Then ask the backup question for each row. Wherever the answer is "nobody in particular", that's the first thing to fix, whatever software you use. The solutions page walks through how work moves between agents and people in Fivexer.