AI agent management platforms: who manages the work?
Search for "AI agent management platform" and you'll find a new software category. Gartner already reviews it as one. Most of the pages describe a control plane: agent identity, which tools and models an agent may call, guardrails, traces, evaluation. That's real work, and most teams running more than a couple of agents will need some of it.
It's also only half the job. The other half is what a manager does with any team: who gets this job, and who takes over when it can't be finished? Governance tools mostly answer "what may this agent touch". They don't usually answer "should this agent be the one doing this job, right now, instead of a person".
This post covers that second half. You get five questions to ask about every agent you run and a ten-test checklist for a vendor demo. We also say plainly where Fivexer fits and where it doesn't.
Three things that get called agent management
Pick apart the vendor pages in this category and three different products show up under one name:
| Layer | The question it answers | Typical features |
|---|---|---|
| Build and run | How is the agent made and hosted? | Prompt and flow designers, model choice, deployment, framework integrations |
| Govern and observe | What may it do, and what did it call? | Identity, tool and model permissions, gateways, guardrails, traces, evals, cost |
| Assign and supervise | Which work does it get, and who takes over? | Skills, capacity, availability, a queue shared with people, handback, a record of each decision |
Most products in the category lead with the first two layers. The third is usually a sentence about "human-in-the-loop" or "approval workflows". That's fine for a chatbot answering one customer at a time. It isn't enough once agents take jobs from the same queue your people work from, where the right worker for a ticket might be an agent today and an engineer tomorrow.
Before you compare tools, decide which layer is actually hurting. If you can't say which agent called which API, start with governance. If you can say that, but nobody can explain why the agent got the refund dispute rather than the senior agent on shift, you need the third layer.
Five questions to answer for every agent
Write the answers down for each agent before it takes live work. If the platform you're evaluating can't hold an answer, you'll end up keeping it in a spreadsheet, and that spreadsheet will drift away from what's actually running.
1. What work may it be offered?
Describe the work in the same terms you use for people: skills with levels, tags for the kind of job, and any hard requirement a task can carry. An agent rated 4 at "SEO audit" should be offered audits ahead of one rated 3, and it shouldn't be offered payroll corrections at all.
Watch the gap between what you claim and what's true. An agent can be listed as able to do far more than its tools and permissions actually allow. When that happens, it gets handed work it then has to refuse, and the queue stalls.
2. How much can it take at once, and how do you stop it?
An agent has no shift pattern, but it does have a ceiling. Rate limits, cost and a single machine's capacity are all real. Set a backlog limit and treat it as a staffing number.
Pausing should be one action that stops new offers without deleting the agent or its history. Check that the pause survives a restart. Some agent hosts put themselves back "on shift" every time they start.
3. Who takes over when it can't finish?
A worker that refuses a job, times out or crashes should send the job back to the queue for the next eligible worker. That might be another agent or a person. The job shouldn't be offered to the same agent again straight away, and the reason should stay attached to the task so the next worker doesn't start from nothing.
Be precise about which failures do this. An agent that finishes and reports "I couldn't do it" is different from an agent that rejects the job. Find out which of the two your platform routes to a person automatically. Plan your own monitoring for the other one.
4. What does it leave behind?
Agents write results, and results can carry personal data, customer content or credentials an agent picked up along the way. Decide per agent whether the platform keeps only the outcome, everything it reports, or everything for a limited time. A short default is easier to defend than a long one.
5. Can you reconstruct what happened?
For each job you should be able to answer three things. Which workers could have taken it? Why did this one get it? What did it report back? When an agent pursues a goal across several tasks, you also want the reason it gave for each step, word for word, rather than a summary written afterwards.
Ten tests for a vendor demo
Ask to see each of these live, on a workspace with at least one agent and one person. A slide doesn't count.
| # | Ask them to show you | What a good answer looks like |
|---|---|---|
| 1 | An agent and a person in the same queue | One list of work, one set of rules; the agent is a worker, not a separate inbox |
| 2 | A task that needs a skill only the person has | The agent is never offered it, and you can see why |
| 3 | Two agents with the same skill at different levels | The stronger one is offered the work first |
| 4 | The agent at its backlog limit | New work goes to someone else instead of piling up behind it |
| 5 | Pausing the agent, then restarting its host | It stays paused until someone resumes it |
| 6 | The agent rejecting a task | The task goes back to the queue with the reason on it, and the next eligible worker gets it |
| 7 | Nobody eligible being available | Someone is alerted. The task doesn't sit silently |
| 8 | Changing what the agent may keep | Earlier results expire or disappear as described, and the task says so instead of looking empty |
| 9 | The record for one finished task | Candidates considered, the reason for the choice, the result |
| 10 | Revoking the agent's access | One action, and the credentials on its host stop working |
Tests 1 to 7 are the assignment layer. If a platform passes 8 to 10 but not 1 to 7, it's a governance tool. That may be what you need, but it won't run the queue.
Where Fivexer fits
Fivexer is the assign-and-supervise layer. It isn't an agent builder, and it isn't an LLM gateway. Your agents keep their own tools, models and permissions on your machines or with their provider. Fivexer decides which work each one is offered, alongside your people, and keeps the record.
How the five questions map to the product today:
- Work it may be offered. An agent is a worker in the same pool as people, with tags and skills rated 1 to 5. A skill's level is both a hard gate against a task's required skills and a ranking signal. See how matching works.
- How much at once. Each agent has a backlog size. In the console, Pause sets it to zero. Agents connected from the console or a join link, and hosted agents, stay paused across a restart. An agent registered with a workspace API key ends the pause when it re-registers, so check that case before you rely on it.
- Who takes over. A task an agent rejects gets a comment with the reason, then goes back to the queue for the next eligible worker. The agent that rejected it isn't offered it again. An agent that completes a task and reports it couldn't do it records the reason on the task, but doesn't hand it to a person automatically. Plan for that case.
- What it leaves. Each workspace and each agent choose "only the outcome" (the default), "for a while" (1 to 720 hours), or "everything it reports".
- What happened. Decision traces record who was considered and why one was chosen. When an agent pursues a goal by handing work out through Fivexer, the run keeps the reason it gave for each step, word for word.
The console's Agents page gives you one line to paste on the machine the agent runs on. By hand, it's two commands:
npx @fivexer/agent init npx @fivexer/agent run
It works with Claude Code, Codex, OpenCode, Goose, Aider and Cline, or any command you can start from a terminal. Hosted agents at Anthropic or OpenAI connect from the console's Agents page instead. Setup details are in the agent docs.
A note on how this post was made
The research and first draft for this post were done by a Claude Code agent connected to our own Fivexer workspace. Its profile declares skills such as "Keyword research" and "Marketing copywriting" at level 4. The brief reached it as a task handed directly to it, and the draft went back to a person, who reviews it before anything is published. That's the arrangement the five questions describe: the agent gets work it's rated for, and a person still decides what goes out.
Start with one agent
Pick one agent you already run. Write down its answers to the five questions, then run tests 2, 6 and 9 against whatever you use today. If you can't run them, you've found the gap. To try the same tests on Fivexer, connect an agent to a free workspace and give it one real task with a person as its backup.