Sub-agents - 9th Protocol

9p can spawn sub-agents through its task tool. Each gets a fresh context window, does its job, and returns only its findings — which is the point: a wide search doesn’t fill the main conversation with file dumps.

Two kinds

Type	Tools	Typical use
`explore`	read-only (`read`, `glob`, `grep`)	“find everywhere we do X”
`general`	all tools	a self-contained chunk of work

Parallelism

Multiple task calls issued in one response run concurrently. Asking a question that spans several subsystems usually produces several explorers at once, then a single synthesis.

⚙ task(explore): auth middleware
⚙ task(explore): session storage
⚙ task(explore): token refresh paths

Cost

Sub-agent usage rolls up into your session totals, and spend rows are tagged so the dashboard can separate main-loop cost from fan-out cost. Explore agents are always routed to economy models, whatever the parent is using. Three parallel explorers on a frontier model would cost more than the answer is worth.

Limits

Depth cap of 2 — a sub-agent’s sub-agent cannot spawn further.
Spawning is permission-gated, since a sub-agent runs unattended.
Sub-agents run in bypass mode internally; the gate was the spawn itself, and explore agents have no write tools regardless.

Getting good results

A sub-agent cannot see your conversation. Its prompt must be self-contained and say what to return:

Search the repo for every place we construct a JWT. For each, return
file:line, which library is used, and whether an expiry is set.

Look into the auth thing we discussed and report back.

You rarely invoke sub-agents directly — 9p decides when a task is wide enough to fan out. Asking for something explicitly broad (“check the whole codebase for…”) is what tends to trigger it.

⌘I