chesterdocs

#Let an agent call its own tasks

An agent can call any of its own tasks as a tool; the task runs as its own instance under a narrow contract and the agent waits for the result.

Every task on the agent's Tasks tab is offered to the agent as a tool, next to its adapter actions, MCP tools, BPMN tools and knowledge vaults. When the agent calls one, it pauses, a second instance of the same agent runs that task, and the agent continues with what the task returned. This lets an agent hand off work that should run under a narrow, named contract — a task's own instruction and tool set — instead of doing everything inline with its full tool set.

sequenceDiagram
    participant U as User or process
    participant A as Agent (task "Check order")
    participant T as Agent (task "Find customer")
    U->>A: Request
    A->>T: Call task with its input fields
    Note over A: Paused, waiting for the task
    Note over T: Own instance, own instruction and tools
    T-->>A: Response fields (or text)
    A-->>U: Answer

#Choose which tasks a task may call

Expand a task on the Tasks tab and open its Tools. Next to the boxes for BPMN tools, actions and MCP tools sits a fourth box, Tasks. It behaves like the others:

  • Left open, the task may call every task of the agent, including itself.
  • Switch Restrict on to pick the tasks it may call. A restricted box with no entries means the task calls no task at all.
  • A picked task that is later deleted disappears from the list on the next save; a task never gains a call it was not given.

In chat, the agent is not running one particular task, so every task is available to it there, whatever the boxes say.

#Describe a task for the agent that calls it

Under a task's instruction sits a second text field, Tool description. This is what a calling agent reads to decide whether the task fits. Write it for the caller ("Finds the customer for an order number"), not for the task itself — the instruction above it is the text the task's own run receives. When the field is empty, the agent sees the task's name only.

#What the task receives and returns

  • The task receives only the fields of its input contract, filled by the calling agent. It does not see the caller's conversation.
  • The task runs with its own instruction, tool set and knowledge vaults — the caller's scope never widens them.
  • The caller receives the task's response fields. A task without response fields returns its text; a task that returns nothing returns an acknowledgement.
  • A task that fails returns its error to the calling agent, which can react to it; the caller's own run does not fail.

Both runs use the same deployment of the agent, so a caller never mixes versions with the task it calls.

#Limits

  • Tasks call tasks, so an agent can nest itself. The nesting stops at three levels: a task call at that depth is not started, and the agent receives an error saying so.
  • Calls run one at a time. When the agent asks for two tasks in one step, the first runs and the second is reported back as not executed, so the agent can call it afterwards.
  • A task run started this way counts as an execution of the agent, exactly like any other run — including the execution limit of a development deployment.

#See the task run in monitoring

The calling agent's thought loop shows the call as a task card with the task's name, its status and what it returned, and Show in flow opens the task's instance below the agent. In chat, the task's instance appears as a workflow card in the conversation.