Subagents: Scoped Execution and Least Privilege
What a Subagent Is
A subagent is an agent operating under the direction of an orchestrator, with a scoped goal and delegated (not inherited) privileges. The key security principle: privilege delegation, not inheritance. An orchestrator with broad access should not automatically confer that access to every subagent it spawns. Each subagent should have the minimum privileges required for its specific task. In practice, this means the IOC enrichment subagent gets read access to the TI database — not write access, not access to identity management. This is least privilege applied to autonomous systems.
The Four-Layer Architecture
Put together: hooks are the enforcement layer, skills are the capability layer, subagents are the execution layer, and plugins/MCP are the integration layer. An SE who can draw this clearly — with hooks sitting across all layers as the cross-cutting control mechanism — has a complete mental model that positions Google ADK and Agent Gateway as the architecture, not just products. Discovery question: "Do you have hooks on your agent pipelines today, or are agents currently running without pre/post execution controls?"
When to Use a Subagent
Spawn a subagent when a task needs different data access than the orchestrator has, a different model (e.g. a smaller, faster model for a narrow classification task), or an isolated blast radius — a subagent failure should not take down the orchestrator. If the task can be done with the same access and same model, it does not need its own subagent; it needs a skill call.
Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.