Skip to main content
A running agent can delegate sub-tasks to your own named agents in .praisonai/agents/*.md — by name, mid-run, with no Python.
Prefer to opt agents in per run instead of editing frontmatter? Use the --subagents allow-list:
A primary agent assembles a team: it hands specific sub-tasks to specific named agents (researcher, coder, reviewer, …) that already live in .praisonai/agents/*.md. Unlike a generic spawn_subagent — which spins up an anonymous scoped worker — the delegatee here is a user-authored profile with its own model, tools, and permissions.

Quick Start

1

Mark an agent as delegatable

Add mode: subagent to any agent’s frontmatter. The agent’s author opts it in once, and every run can delegate to it.
2

Or opt agents in from the CLI

Pass --subagents to expose exact agents for a single run, no frontmatter changes required.
3

Run the primary agent

The lead agent calls spawn_subagent(agent_name="researcher"), the resolver loads researcher.md, and the researcher runs under its own model, tools, and permissions.

How It Works

The primary agent picks a teammate by name; a resolver instantiates that agent from its Markdown definition and runs the sub-task.

How delegation is chosen

Which agents become delegation targets depends on whether --subagents is set.
  • Explicit --subagents a,b,c wins — any named agent can be opted in, ignoring mode:.
  • Otherwise every agent whose frontmatter has mode: subagent is exposed.
  • If neither yields anything, no spawn_subagent tool is attached — the run behaves exactly as before (backward compatible).

Two ways to opt agents in

Choose per-agent frontmatter for stable teammates, or the CLI flag for ad-hoc runs. When --subagents is passed, those exact names are exposed regardless of mode. When it is omitted, every agent whose frontmatter has mode: subagent is exposed. If neither yields any agent, the spawn_subagent tool is not wired at all and the run is identical to before.

What the delegated agent inherits

Each named agent runs under its own model, tools, and permissions from its frontmatter. The primary agent does not override them. A named agent’s mode: subagent marker never changes its permissions — it only marks the agent as delegatable (see Delegatability vs permissions).

How the model discovers them

The tool description lists each delegatable agent so the primary model can pick one by purpose:
Each line’s text is the agent’s description, falling back to goal, then role, then an empty string when none is set. Give every delegatable agent a clear goal or description so the primary model chooses the right teammate.

Fallback behaviour

Delegation is purely additive — nothing changes when there is nothing to delegate to.
  • Unknown name: if agent_name targets a name the resolver cannot find, the resolver returns None and the existing generic-spawn path runs instead.
  • No delegatable agents: if no agent is marked mode: subagent and --subagents is omitted, the spawn_subagent tool is not wired at all — the run is byte-identical to before.

Delegatability vs permissions

mode: subagent is a delegatability marker, not a permission mode. It is ignored (case-insensitive) when computing permissions, so it is never rejected as an unknown mode. Any other mode value — read-only, plan, accept-edits — still flows through the permission engine as before. See Custom Agents & Commands for the full mode reference.
To make a delegatable agent read-only, set mode: read-only and name it in --subagents (it no longer carries the subagent marker, so the CLI allow-list is how you keep it delegatable). A delegatable agent’s permission: block is honoured — it is translated to an approval config on construction, so a scoped agent runs under its restrictions.

Configuration Options

agent_resolver and resolvable_agents are SDK parameters on create_subagent_tool. The CLI wires them for you from your .praisonai/agents/ definitions — you only need mode: subagent or --subagents.

--subagents CLI flag

Result shape

When the resolver runs a named agent, spawn_subagent returns:

Common Patterns

A lead delegates to two teammates marked mode: subagent:
The lead calls spawn_subagent(agent_name="researcher") and spawn_subagent(agent_name="reviewer"), each running under its own frontmatter.

Best Practices

Mark agents you always want available with mode: subagent and commit them to git. Reach for --subagents when you need a one-off delegation without editing files.
The primary model picks teammates by their description (falling back to goal, then role). A vague goal makes the model guess; a specific one routes the right sub-task to the right agent.
Put heavy tools on the delegated agents and keep the primary agent focused on coordination.
Each named agent runs under its own permissions. Add a permission: block (or a mode: like read-only) to a delegated agent to sandbox its side-effects independently of the primary agent.
A delegated agent chatting to finish its sub-task is fine. Nested delegation — a delegated agent delegating again — is not part of this feature; design flat teams with a single coordinating agent.

Subagent Tool

The create_subagent_tool seam and its parameters

Subagent Delegation

Programmatic spawn control and parallel fan-out

Custom Agents & Commands

Define named agents in .praisonai/agents/*.md

Agent Presets & Modes

Modes and per-agent permission scoping

Run CLI

—agent and —subagents flags

Handoffs

Agent-to-agent routing inside a conversation