Letting one agent ask another

Your agents, exposed to each other as tools. A generalist can hand a billing question to the agent that actually knows billing, instead of being given every billing tool itself.

Setting it up

Create one Agent delegation connection for the workspace. There is nothing to authenticate against — the connected system is Caterfli.

Discovery then generates one tool per deployed agent, named ask_ and the agent's name: ask_billing_agent, ask_support_agent. Each carries that agent's purpose in its description, which is how a calling model decides whether the work belongs to it. Write a real purpose on every agent — it is the only thing another agent has to go on.

Then open the agent that should be able to delegate and enable the tools for the agents it may call. That is the entire permission model: an agent can call exactly the agents whose tools you enabled on it. Nobody can call anybody by default, and delegation is one-way unless you enable it both ways.

Only deployed agents appear

A draft agent is runnable — that is how you test one — but it is not offered for delegation. Being reachable by another agent in a live run is a different thing from being testable, and not something anyone asked for by saving unfinished work. Deploy the agent, then re-run discovery on the connection.

What a delegated run actually is

A complete run. Its own execution record, its own steps, its own policy checks, its own approvals. Nothing is shortcut because the caller was an agent rather than a person.

The called agent runs with its own tools, never the caller's. It also cannot see the calling conversation — the task description is all it gets, which is why the tool asks for the task stated in full.

In the execution list a delegated run shows the run that asked for it, so you can follow a chain from the question a person asked down to the work three agents later.

What stops a loop

Two agents that can each call the other will do so until something stops them, and every hop is a full run with real model spend — a loop gets expensive long before anyone notices it.

Two guards, both read from the recorded execution chain rather than from anything the model passes in:

• •An agent already working further up the chain cannot be called again. It is told so plainly and asked to answer with what it has, because a model that only hears "failed" will look for another way round.
• •A request that has already passed through the depth limit is refused. The default is two agents. You can set it as high as five on the connection.

What it costs

Every hop is a full agent run. A three-agent chain costs considerably more than three times a single answer, because each agent re-reads its own instructions and tool catalogue before doing anything.

Delegation buys focus — smaller, better-aimed tool sets, which is what makes a model choose well — and you pay for it in tokens. The depth limit is a cost control as much as a safety one. Two is a sensible default; raise it only for a chain that genuinely needs it.

Approvals across a delegation

If the called agent hits something needing approval it pauses, and the caller is told that it paused rather than being held open while somebody clicks. The approval appears in the queue as normal, against the delegated run.

The one thing to understand about permissions

A delegation tool is classed as an action, so a person needs execute permission to trigger one at all. Someone who cannot run tools cannot get one run by asking an agent to ask another agent.

Past that gate, a delegated run carries no acting user. It is judged by the called agent's own configuration — its enabled tools, its approval settings, its policy rules — and not by the role of whoever started the chain.

So choose which agents are delegatable the way you would choose what a scheduled job may do, rather than what a particular colleague may do. If an agent should never act without a specific person behind it, do not enable its delegation tool anywhere.