Daily paper · Friday, September 11

A skill with a clear input and output contract runs better as a subagent than as loaded instructions

cs.AI · Piriyakulkij, Lawrence & Curth et al. · arXiv:2609.09233

The authors compare two ways to run the same skill package. Agent-skill execution loads the skill's instructions into the main agent's context. Subagent execution starts a fresh context window with those instructions and returns only the result. On a 64-task subset of SkillsBench, subagents win only when the skill states its expected input, its output, and a step-by-step procedure. With the benchmark's own human-written skills, which rarely state this, inline skills match or beat subagents. Subagents also cost more total tokens, but they keep the largest single context smaller.

Skills add to the context they are supposed to help

An agent skill is a folder. It holds a short description, an instruction file named SKILL.md, and resources such as scripts. The agent always sees every skill's description. When it invokes a skill, the harness returns the instruction file, and the agent follows it inside its normal turn loop.

The authors identify a cost in this design. Language models reason less well as their context grows. Tasks with many steps already fill the context with tool calls, tool outputs, and intermediate reasoning. Each skill invocation adds a full instruction file on top. The skill contains useful knowledge, but loading it reduces the agent's ability to use it.

Same skill package, two execution modes

Agent-skill execution. The harness appends the instruction file to the main context. The main agent performs every step in that one window.

Subagent execution. The harness starts a new agent. Its context begins with the instruction file plus a task and input that the main agent writes for it. The subagent works in its own window, calls its own tools, and returns only its final message. The main agent never reads the subagent's trace. In the authors' setup, each subagent appears to the main agent as one tool.

Two execution modes for one skill: inline execution appends the instruction file to the main context so one window grows; subagent execution starts a second window from the instruction file and returns only a final messageAgent-skill execution (inline)task, tool calls, tool outputsreasoning so farSKILL.md instruction fileappended in full on each invocationevery skill step runs heremore tool calls, more outputsone window keeps growingpeak context: highSubagent executionmain contexttask, tool calls,tool outputswrites task + inputrestates the factsreceives finalmessage onlyfresh windowSKILL.md+ task + inputown tool callstrace never sentto main agentpeak context: lower, total tokens: higher
One skill package, two ways to run it. Inline execution appends the instruction file to the main window, so that window grows. Subagent execution starts a second window from the instruction file and passes back only a final message.

The authors state that what limits a model is not the total tokens a task consumes. It is the peak length of any single window. Subagent execution splits the task across windows, so the peak drops. The cost is duplication. A subagent cannot see the main context, so the main agent must restate the facts the subagent needs. The authors note that Claude Code and Codex already offer subagents, but mainly as parallel workers without a skill attached.

The contract makes a skill safe to delegate

Subagent execution adds a delegation problem that inline skills do not have. The main agent must pick the right subagent and give it enough information to succeed. If either step fails, the subagent returns a wrong result or nothing.

The authors' answer is an input-output contract in the skill description. A contract here means a plain statement of what the skill accepts and what it returns. The description becomes three parts: a one-line purpose, an expected-input list, and an output list. The instruction file must then satisfy that contract with a procedure that transforms the stated input into the stated output. The authors compare this to the options framework in reinforcement learning, where a reusable behavior declares when it may start, what it does, and when it stops.

The input-output contract: a skill description states purpose, expected input, and output; the instruction file is the procedure that turns the stated input into the stated outputSkill description = purpose + expected input + outputwhen to call itwhat it doeswhat comes backExpected inputscanner JSON report pathfrom the scan stepseverity filter, CSV columnsfrom the audit planSKILL.md procedurepurpose: convert a scannerreport into normalizedvulnerability recordsfixed steps, input to outputOutputJSON list of recordspackage, version, CVE id,severity, score, fixed version,title, URLa main agent reads the description and knows what to pass in and what it gets back
The contract, shown with one of the authors' synthesized skills. The description states the input and the output. The instruction file is the procedure between them.

One of their synthesized skills, shown above, converts a scanner report into vulnerability records. A main agent can read its description and know what to pass in and what comes back.

Results

The benchmark is SkillsBench. It has 87 multi-step tasks, and each task ships with human-written skill packages. The harness is OpenHands. The authors first ran it with GPT-5.3 Codex three times per task and kept the successful runs. They then used GitHub Copilot CLI, driven by Claude Opus 5 with GPT-5.5 subagents, to write new skill packages from those runs. A manual check confirmed that each new package states its input and output. This worked for 64 of the 87 tasks, and every result is on that subset.

Three findings matter.

The contract decides which mode performs better. With the benchmark's own curated skills, which describe relevant knowledge but rarely state inputs or outputs, inline agent-skill execution matched or beat subagents for every model tested. With the synthesized procedural skills, subagents beat inline execution, and the gap was largest for small models. The authors also report that the synthesized skills beat the curated ones under both execution modes. They note that this second comparison is not controlled, because the two skill sets differ in content.

Which execution mode wins depends on the skill: curated skills without a stated contract favor inline execution; synthesized procedural skills with a contract favor subagents, most for small modelsInline (agent-skill)SubagentCurated skillsthe benchmark's own, human-written;rarely state inputs or outputsmatched or beatfor every model testedno gainSynthesized procedural skillswritten from successful runs;each states input and outputloseswinslargest gap for small models
Which execution mode performs better depends on the skill set. The filled cell in each row is the mode that performed better on the 64-task subset.

Subagents degrade more slowly as context fills. The authors appended descriptions of extra tools that the task did not need. As the number of these unused tools grew, inline execution lost accuracy faster than subagent execution.

Peak context falls, total tokens rise. For the stronger models, GPT-5.3 Codex and Kimi K2.6, subagents produced a lower peak context on more than 80% of tasks. For weaker models the effect was small or reversed. The authors explain this as early termination: under inline execution the weak model stops before its context grows. Total token use was substantially higher with subagents across models, and subagents made more skill calls per task.

An appendix experiment organizes the skill library as a tree or graph of routing nodes above leaf skills, so the agent sees only a few options at each level. On Qwen3.5-9B, hierarchy helped, a graph beat a tree, and a hybrid mode was best in every layout: routing nodes ran inline, leaf skills ran as subagents.

Some limits apply. The exact accuracy numbers appear only in figures, so the size of each gap is not stated in the text. The synthesized skills were written from successful runs on the same tasks they were then scored on. The 23 tasks with no synthesized skill were dropped. All runs used one harness, and the hierarchy result comes from one 9-billion-parameter model.

What you can do with it

Sort your skills into two kinds. A reference skill carries conventions or background that the agent must combine with other things it knows. Keep those inline. A procedural skill takes a defined input and produces a defined output through fixed steps. Those are candidates to run as subagents, and the benefit is larger when the main context is already large.

Rewrite the descriptions of your procedural skills with an explicit contract: purpose, expected input, output. This helps even if you never delegate, because the agent decides when to call a skill from the description alone. Then check that the instruction file turns that input into that output and ends by reporting the result, with exact file paths for anything written to disk.

If your harness lets a subagent start from a skill file, use the hybrid pattern from the appendix. Routing and selection skills stay inline. Leaf skills that do the work run in fresh windows. Expect higher total token use. If you generate skills from successful traces, add the contract check to the generator, because that property decides the result.