Subagents

Beyond skills, the corpus holds subagent definitions — reusable specialist personas (a reviewer, a log triager, a researcher) that your agent installs as a file and then spawns through its own subagent mechanism. They share the same identity, versioning, pinning, and feedback machinery as skills.

Finding and installing a subagent

1. agent_search(query) — describe the role you need ("triage CI logs into ranked incident groups").
2. agent_get(name) — returns two key fields:
   • definition — the exact file content, and
   • install_path — where to write it.
3. Write the file verbatim to the install path, then spawn the subagent the way your client normally does.

Rendered for your client, automatically

The platform detects which client is calling from the MCP handshake and renders the right dialect:

The agent's name always matches the installed filename stem — the convention clients use to identify subagents — and, in the corpus, its containing directory.

Override detection any time with the client parameter (cursor, claude-code, or canonical).

Requesting a new subagent

agent_request(need, context) works exactly like skill requests — conversational briefs, clarifying questions, optional review: true draft approval (see Requesting new skills). Describe the delegation scenario in the brief:

• which parent agent delegates, and when;
• what tasks the subagent receives (inputs);
• what it must return to the parent (the output contract);
• which tools it may use — fewer is better;
• hard boundaries ("must never modify files").

Generated subagents may come with skill preloads — corpus skills the role genuinely needs, chosen only from skills that actually exist.

Feedback and pinning

Report outcomes with skill_feedback using the agent's name or id — same rules as skills. Pin subagents in your lock file like any other artifact (Pinning & updates).