Subagents vs agent skills: when a reusable package should run in its own context
Should a skill run inside your context, or in a child’s?
Opening
Teams that solve long-horizon tasks build libraries of reusable knowledge: skill packages with instructions, scripts, and other resources. The usual execution path is to load the skill instructions into the agent’s context and rely on the agent to follow them. As task horizons grow, that approach becomes increasingly brittle, because reasoning quality degrades as more information accumulates in the context window. The question is whether the same knowledge does better when it runs somewhere else entirely, in a fresh context dedicated to one subtask.
What the paper does
The authors investigate an alternative in which skill packages are invoked as subagents instead of being read into the main context. This route spawns a fresh context window for each subtask, so the package’s instructions and scripts never crowd the main agent’s reasoning. They compare the two execution modes on long-horizon agentic tasks and identify the condition under which each wins: the subagent route pulls ahead when a package exposes a clear input-output contract and its instructions carry the procedural knowledge needed to fulfill that contract. They also name the price of the winning route, coordination in extra tokens between the main agent and its subagents.
Findings
The condition for winning — The subagent route is not better by default. It beats loading the skill only when the package states what goes in and what comes back, and the instructions carry the procedure that delivers it.
subagent execution outperforms agent-skill execution when skill packages expose clear input-output contracts
A fresh window per subtask — The mechanism is context hygiene: each subtask gets its own window, so the package never shares space with the reasoning the main agent still has to do.
Rather than loading skill instructions into the main context, subagent execution spawns fresh context windows dedicated to solving individual subtasks
The bill for coordination — Every handoff costs tokens, because the main agent and its subagents have to coordinate. That overhead is the price paid for keeping the main context clean.
The tradeoff is additional communication overhead, as extra tokens are required to coordinate between the main agent and its subagents.
Caveat
The authors state the cost side as their limitation: coordination between the main agent and its subagents costs extra tokens. The subagent route therefore wins only when the value of a cleaner main context exceeds what that coordination costs, and their own conclusion is that the benefit depends on how the knowledge is organized and invoked.
What this means for 5ac
This is the design question sitting inside Hermes: skills load into context, delegate_task spawns a child with its own window. The paper gives the rule for choosing. A lookup skill that a card needs for two lines of guidance stays in context, where the token cost is small. A long procedure that would crowd the card’s reasoning becomes a subagent, provided the handoff states a clear input and output, what goes in and what comes back. The change to make: write that contract into the card body before spawning, and count coordination tokens in cost per task, because the paper’s tradeoff is exactly the overhead 5ac pays on every delegation.
Source
- Subagents vs Agent Skills: Executing Reusable Knowledge for Long-Horizon Agentic Tasks — https://arxiv.org/abs/2609.09233