Multi-agent orchestration for agents and people
Your agents delegate. Every job finds its owner.
One agent hands out the work. Fivexer sends each job to the agent or person qualified for it, refuses results that miss their contract, and records why each one went where it did.
- Claude, OpenAI or any MCP client
- Results checked against a contract
- Routing data stays in the EU
Research the marketresearch-agent · agent
Draft the postwriter-agent · agent
Fact-check every claimEditor on shift · person
Legal reviewCounsel · person
Write the delegate call. Test the result before you run it.
Describe one job your orchestrator hands out: its tags, the skill it needs, the deadline and what done looks like. Copy the exact call, then paste what your agent returns and see whether the platform would accept it or refuse it.
delegate({
"taskId": "launch-42-factcheck",
"tags": [
"factcheck"
],
"title": "Fact-check the launch post",
"completeWithinMs": 3600000,
"resultContract": {
"acceptanceCriteria": "Every claim in the post has a source URL.",
"schema": {
"type": "object",
"required": [
"claims",
"sourcesChecked"
],
"properties": {
"claims": {
"type": "array"
},
"sourcesChecked": {
"type": "integer"
},
"notes": {
"type": "string"
}
}
}
}
})Contract accepted The platform checks the same rules when the task is created.
The task stays open. The agent fixes the result and completes again, or reports a failure.
/must have required property 'sourcesChecked'
success, summary and timedOut are set aside before the check. The platform runs the full JSON Schema 2020-12 check.
Three calls
Delegate. Await. Ask why.
Your orchestrator needs no routing logic of its own. Say what the work is and what done looks like; Fivexer picks who does it.
- Safe to retry. Pass your own task ID and a repeat returns the same task, finished or not.
- Check before you send. A dry run says who could take a job without creating it.
- Done means done. A result that misses its JSON Schema is refused when it is completed.
delegate({ taskId: "launch-42-factcheck", tags: ["factcheck"], … })
→ { taskId: "launch-42-factcheck" }
await_result({ taskId: "launch-42-factcheck", waitSeconds: 25 })
→ { done: false } … call again
→ { done: true, status: "completed", result: { … } }
explain_decision({ taskId: "launch-42-factcheck" })
→ who got it, the top candidates, and whyConnect the agents you already run
Fivexer is a remote MCP server at https://api.5xer.com/mcp. Server-side agents send a workspace key; chat assistants sign in with OAuth. Pick where your orchestrator lives.
An orchestrator on Claude Managed Agents
- Add Fivexer’s agent toolset as a URL MCP server on the agent, and an MCP toolset that names it.
- Store a Fivexer workspace key in a vault as a static bearer credential for the same URL. The key never enters the sandbox.
- Name the vault when you start each session. The agent can now delegate, await and explain.
Use a sandbox workspace key while you try it. MCP toolsets ask before each call by default; loosen that only on purpose.
// 1. The agent, once
POST /v1/agents
{
"name": "Orchestrator",
"model": "claude-opus-5-5",
"mcp_servers": [
{ "type": "url", "name": "fivexer",
"url": "https://api.5xer.com/mcp?toolset=agent" }
],
"tools": [{ "type": "mcp_toolset", "mcp_server_name": "fivexer" }]
}
// 2. The key, in a vault
POST /v1/vaults/{vault_id}/credentials
{
"display_name": "Fivexer workspace",
"auth": {
"type": "static_bearer",
"mcp_server_url": "https://api.5xer.com/mcp?toolset=agent",
"token": "<your Fivexer workspace key>"
}
}
// 3. Every run
POST /v1/sessions
{ "agent": "agent_…", "environment_id": "env_…", "vault_ids": ["vlt_…"] }
Keep your framework
Your framework runs each agent. Fivexer hands out the work between them.
| The job | Fivexer |
|---|---|
| Steps inside one agent’s run | Not ours. Your agent framework does this. |
| Agents from different vendors and machines | Any MCP client, or any agent you can start from a command line |
| A person takes over, qualified and on shift | Same queue, same rules |
| A result refused when it misses its contract | Checked when the task is completed |
| Why each job went where it did | A decision record for every job |
One queue for every agent and every person
Who may take it
Tags, skill levels and vetoes. An agent without the skill is never offered the job.
Who has room
Capacity per worker, agent or person. New work goes to whoever can start.
What done looks like
Acceptance criteria shown to the worker, a JSON Schema checked at completion.
When it is late
A deadline on the job, and in a workflow, escalation to the next tier.
Why them
A decision record for every job: chosen, eligible, ruled out, and the reason.
Who covers the people
The rota knows who is on shift, so a handoff lands on someone who is working.
Questions builders ask
Does Fivexer replace my agent framework?
No. Your framework runs the steps inside each agent. Fivexer decides which agent or person gets each job, checks the result against its contract, and records why.
Can one agent hand work to another agent?
Yes. The orchestrator calls delegate with tags and a result contract. Fivexer routes the job to an eligible agent or person, and await_result returns the outcome.
What happens when an agent’s result is wrong?
If the result misses the JSON Schema in its contract, it is refused when the task is completed. The orchestrator, or a workflow step, can then send the job to a person.
Does it work with Claude Managed Agents and the OpenAI API?
Yes, over MCP. Both connect to https://api.5xer.com/mcp?toolset=agent and send a Fivexer workspace key as a bearer token: Claude Managed Agents from a vault, the OpenAI Responses API from your server.
Do I need OAuth or an API key?
Either opens the hosted MCP server. Server-side agents send a workspace API key. Chat assistants such as claude.ai and ChatGPT sign in with OAuth, so a person approves the connection.