Docs / AMS / Build / Teams of agents
View as MarkdownTeams of agents
Let one agent hand tasks to others, see what bounds a chain of hand-offs, and call agents from outside with call_agent.
After this page you can give an agent helpers it hands tasks to, know what stops a chain of hand-offs from looping or running away, and call an agent from another AI client.
What this is
An agent can hand a task to another agent in your org and use the answer. The agent that hands off is the lead agent. The agents it can hand tasks to are its helpers. Mindset calls this agent-to-agent, or A2A.
For the invoice exceptions agent, the Assess phase asks one question: does the supplier contract allow this difference, and which clause says so? A separate supplier contracts agent, with the contracts knowledge base and its own policy rules, can answer that for the invoice agent and for the procurement team's agents too. The invoice agent is the lead and the supplier contracts agent is its helper.
Where the team is set
There's no separate team tab. A lead agent's helpers are the Agents (A2A) card on its Resources tab.
- Open the invoice exceptions agent and go to Resources.
- In the Agents (A2A) card, press Add and choose the supplier contracts agent.
- Press Save as version, then activate the version on Versions & Availability. The team is part of the version, so a helper added and not yet activated isn't offered.
- Open the supplier contracts agent. On its Versions & Availability tab, make it available and tick Other agents ("Another agent can hand this one a task."). Without it, every hand-off to it is refused.
You can also ask the Agent Builder: "Add the supplier contracts agent as a helper." It adds it to the card. Whoever adds the helper, check its Other agents box yourself.
Only org admins see the Agents (A2A) card.
How a hand-off works
Each helper becomes a tool the lead's model can call, named delegate_to__ followed by the helper's handle, for example delegate_to__supplier-contracts. The tool takes one argument, task: the task or question for the helper.
When the lead calls it:
- The helper runs as itself. It uses its own resources, its own script and its own permissions, never the lead's. The supplier contracts agent can read the contracts knowledge base even though the invoice agent can't, and it can't call
register_supplier_queryeven though the invoice agent can. - The lead gets the helper's answer as the tool's result, and carries on.
- Helpers can have helpers. A helper's own
delegate_to__tools work the same way, so a chain can be several agents deep. - It stays in your org. A lead can only reach agents in the same org.
If the invoice agent runs a script, list the supplier contracts agent in the Assess phase's resources, so the invoice agent can only hand off to it in Assess. See Write a script.
What bounds a chain
A chain of hand-offs has no fixed depth limit. Two guards bound it instead:
| Guard | What it does | What the lead sees |
|---|---|---|
| Cycle guard | Refuses a hand-off to an agent already on the current chain. If the supplier contracts agent tried to hand back to the invoice agent, it would be refused | "agent 'invoice-exceptions' is already on the active delegation chain" |
| Budget | One budget of hand-offs per run, shared by the whole chain at every depth. The default is 8 | "the per-run delegation budget (8 invocations) is spent" |
A refusal comes back to the calling agent as its tool result, so it can read why and carry on without that hand-off. The budget is set for the whole deployment, not per agent. On a self-hosted instance the operator sets it with A2A_MAX_INVOCATIONS.
Every hand-off, whether it went ahead or was refused, is written to the audit log with which agent called which, how deep in the chain, and why a refusal refused.
Helpers don't draw charts, tables or other displays. Those tools are offered only on a turn a person is watching and driving, and a helper's turn is driven by the lead, not a person. Have helpers answer in words, and let the lead present the result.
Call an agent from outside
AI clients connected to Mindset over MCP, such as Claude, hand an agent a task with call_agent, and find the agents they can reach with list_callable_agents. The same rules apply as for a lead agent:
- The agent runs under its own permissions, never the caller's, inside your org only.
- The cycle guard and the budget apply.
- The caller reaches only the agents its own permissions allow. An org admin on the admin MCP can also call agents that aren't available yet, to try one before it goes live.
A call usually returns the agent's finished answer. A long task can return the state working with no text yet: the agent keeps running and its reply is recorded. Don't send the same task again, because that starts a second run. To hold a conversation, pass back the returned contextId and the earlier turns in history.
See Use your agents from Claude and other AI clients to connect a client, and Build and govern Mindset from Claude for the admin MCP.
What can go wrong
- Every hand-off to a helper is refused. The helper isn't available, or its Other agents box isn't ticked.
- The lead doesn't seem to know its helper. The version with the helper on its Agents (A2A) card isn't active yet, or the current script phase doesn't list the helper.
- A chain stops partway. It spent its budget, or an agent tried to hand back to one already on the chain. The lead's tool result says which.
- A helper did something the lead isn't allowed to. It runs with its own resources. Give each helper only what its job needs.
You're done when
- The lead lists its helpers on its Agents (A2A) card, in an active version.
- Each helper is available with Other agents ticked.
- Each helper holds only the resources its own job needs.
- You watched a hand-off on the lead's Chat tab and saw the helper's answer come back.