# What changes when my skill dispatches sub-agents?

Sub-agents run under the same containment as the main thread — they are not a way to escape a path restriction or a permission prompt. A finished sub-agent cannot be resumed in Cowork, so recovery means dispatching a fresh one with the context restated. If you dispatch without naming an agent type you get a general-purpose agent holding the full tool surface, which is rarely what a skill intends.

### Always name the agent type when dispatching a sub-agent.

*Measured*

Omitting the type yields a general-purpose agent holding the full tool surface, including the shell. If your intent was a constrained helper — a reader, a summariser — you have instead created something with more capability than the task needs, and the dispatch will look correct in every log.

> Caveat: Observed in a large sample of real dispatches, where the type-less form was a substantial fraction of the total.

### Do not plan to resume a finished sub-agent. Dispatch a fresh one with the context restated.

*From binary*

In Cowork a completed or stopped sub-agent cannot be continued — the mechanism that does this elsewhere is not available. Recovery and follow-up work therefore mean a new dispatch carrying whatever context it needs, so design sub-agent prompts to be self-contained.

### Do not use a sub-agent to get around a path restriction or a permission prompt.

*Measured*

Sub-agents run under the same containment as the main thread. The path rules apply identically inside them, and the permission machinery fires there too. Dispatching a sub-agent changes what work happens in parallel; it does not change what is allowed.

### Put everything a sub-agent needs in its prompt. It cannot ask you for more.

*Inference*

Because a finished sub-agent cannot be resumed, a dispatch that omits context cannot be topped up — it can only be redone. Restating context is cheaper than a failed dispatch, and it is the only recovery mechanism available.

> Caveat: Follows from the no-resume behaviour rather than being separately measured.

### Write sub-agent fan-out so that a dispatch being queued or refused is handled, not fatal.

*From binary*

Concurrency and per-session limits are enforced, and the numbers have changed between releases. A skill that dispatches a fixed wide fan-out and assumes every one starts immediately will behave differently across versions. Treat parallelism as an optimisation, not a requirement.

### Write sub-agent prompts with relative paths, exactly as you would the main thread.

*Measured*

A sub-agent starts in the session's own working area, not in a private one. The same path rules apply, and absolute session paths handed to file tools are rejected there for the same reason.

## What is not established

- Fan-out limits are enforced and have changed between releases. Write skills that tolerate a dispatch being queued or refused rather than assuming unlimited parallelism.

---

Consistent with the capture of 2026-08-05. Exact artifact versions and capture identity are on the current-state page. This documentation does not detect product changes.