What changes when my skill dispatches sub-agents?

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.

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.

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.

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.

Concurrency and per-session limits are enforced, and the numbers have changed between releases. A dispatch can also be refused outright before it starts, by a classifier rather than a limit — observed refusing one dispatch and accepting an equivalent one the same day, so a refusal is possible and not reliably reproducible. A skill that dispatches a fixed wide fan-out and assumes every one starts will behave differently across versions and across runs. Treat parallelism as an optimisation, not a requirement, and handle a dispatch that never starts.

A sub-agent inherits the main thread's working directory rather than getting a private one, so the same path rules apply and absolute session paths handed to file tools are rejected there for the same reason. From Desktop 2.7032.0 the sub-agent's instructions say to pass absolute paths to the file tools, where earlier releases told it relative paths started at the outputs location; an absolute outputs path is correct on both. Two limits do not carry over from the main thread, though. Shell commands do not share the file tools' location, so the path form that is right for a file tool is wrong for the shell, which needs the absolute session path. And a sub-agent is not told how the folders the user connected are named inside the shell environment — the main thread receives that mapping, a sub-agent does not, and the tool description points it at a section of its instructions that it does not have. So if a sub-agent must work inside a folder the user connected, put the resolved path in its prompt. Left to guess, it will address the folder by name; before Desktop 2.7032.0 that silently created a same-named directory in the outputs location, and from 2.7032.0 the relative path is refused instead.

In the remote sandbox the nesting depth is pinned to one level by the session's environment — observed in two independent cloud sessions three weeks apart — so a sub-agent's attempt to dispatch another is refused with an instruction to do the work itself. The local sandbox's default is higher and is served, so it can move. A skill whose sub-agents fan out a second level works in one sandbox and silently flattens in the other.