DeepSeek: Skills, Subagents, and Extensions

§1

Skills use catalog first, body on demand

The skill registry merges provider catalogs across host and per-scope layers. The model-facing consumer injects a durable catalog of names and bounded descriptions, not full bodies or paths. A permitted skill({name}) call then loads the complete definition and returns its body plus resource guidance. Source · registry Source · model presentation

Catalog replacement is itself logged model context. Body-only edits affect later tool calls without rewriting earlier results. Invocation flags distinguish model access, human command access, and trusted registry-only access.

§2

One subagent seam, several transports

Provider shape	Conversation seed	Execution boundary	Do not infer
Spawn in process	Fresh child conversation.	Ordinary child agent under a new flat scope.	No automatic copy of parent tools or authority.
Fork in process	Balanced completed-turn prefix of the parent log.	New child session and flat scope.	Conversation seeding is not service/permission inheritance.
External provider	Provider contract decides supported creation inputs.	ACP, Codex, Claude Code, or DSH SDK transport package.	Core seam does not make external products share one internal protocol.
Continuable child	Durable descriptor plus managed activation/resume.	Continuation manager owns activation and delivery.	Listed or stored does not necessarily mean currently active.

The provider field inheritsParentContext describes conversation seeding only: fork is true; spawn and ACP are false. The documentation explicitly warns that this does not imply inherited tools, services, or authority. Source · providers and context

§3

Child control is session-backed

The shared subagent service owns creation and continuable-child orchestration, while separate model-facing tools can start work, send messages, interrupt, list, or report. Durable descriptors and session lineage let cold children be discovered without loading every agent. Source · subagent family

A one-shot result and a continuable conversation are different lifecycle contracts. Parent reconciliation still matters: the child may return a summary, while artifacts and event history remain behind session references.

§4

Dynamic extensions make model-authored code a lifecycle

The dynamic extension subsystem can define versioned Cordis packages with host and browser halves. The runner mints plugin/package identities, requires approval for model-driven activation where configured, uses an exact run identity for calls, and emits activation and retraction events. Source · extension purpose Source · runner contract

The subsystem names contracts that arbitrary code evaluation would leave implicit: version, ownership, approval, host/client boundary, active run, invocation, failure reporting, and disposal. The operational surface is still large, so sandboxing and lifecycle correctness remain essential.

§5

Code Mode and workflows shift orchestration

Code Mode presents a reserved run_code transport and serialized subcalls, but both the transport and each subcall still pass through the tool pipeline. Denials remain binding and subcalls are logged rather than becoming a policy bypass. Source · Code Mode pipeline

Workflow packages take the other direction: deterministic orchestration can call probabilistic child agents at explicit steps. Use that form when the surrounding sequence, budgets, and artifact handoffs should be code, while particular judgments remain model work.

§6

Choose the least powerful seam that fits

Use a skill for reusable instructions and resources.
Use a subagent for bounded work that benefits from another context or provider.
Use a tool/provider for a stable capability contract.
Use a plugin when lifecycle-managed services or events must join composition.
Use a dynamic extension only when runtime-defined code and UI justify its approval and sandbox surface.
Use a workflow when the sequence should remain deterministic around model calls.

← State Assessment →