Subagents and agent skills, two ways to run knowledge that has to last

The work under discussion is Subagents vs Agent Skills: Executing Reusable Knowledge for Long-Horizon Agentic Tasks, published on arXiv as arXiv 2609.09233. Its claim can be put in one sentence: subagent execution outlasts in-context skill execution when skill packages carry clear input output contracts plus the procedural knowledge that honors them. The original is linked under the title.

Hello, this is Patrick.

Teams run into a familiar moment when the manual sits open on the desk and the work still stalls. So what happens if we stop asking everyone to memorize the manual and instead hand part of the job to a colleague who owns it end to end. What interests me more in this paper is that it compares those two moves head on. The same reusable knowledge can behave differently depending on how it is run, and that difference grows with task length.

Would memorizing the whole cookbook make the kitchen faster

I first read this topic a little lightly, because skills sound like an obvious win. Give the agent the instructions and it should do better. Yet reusable knowledge turns out to be a loose phrase once you sit with it. Having a document and living with that document over a long job are separate things. For a short job, reading the manual once and following it is enough. For a long job, the reading list keeps growing, the intermediate results keep piling up, and judgment that started sharp slowly softens.

So what frays first. In my experience the order of reasoning goes first. The agent starts mixing up what it already checked, what it still owes, and where the current answer sits in the sequence. More knowledge does not help in that state. Extra reading makes judgment heavier instead. This paper moves the question to exactly that spot. It treats the issue as running knowledge over time rather than collecting knowledge, which reframes the whole discussion.

Anyone who operates automation will recognize the feeling. A job that starts at 9 in the morning and runs past 3 in the afternoon fills the context with logs and tool outputs and memos, and then a clear instruction arriving late gets missed. People handle this by clearing the desk or splitting the job. Should agents get a similar choice.

Why agents start to wander the longer they work

The difficulty of long jobs does not come from laziness. Reasoning quality slips as information accumulates in the context window, and this paper states that mechanism plainly. When skill instructions sit at the front while the live work happens pages later, the link between the instruction and the present state loosens. The agent still follows the skill early on, then gradually responds to the latest output more than to the original procedure.

This difference matters more than it looks. In short question answering the context stays clean, so one reading carries the whole task. In work that touches several tools, edits files, and checks intermediate results, the agent must keep comparing what it saw with what it owes now. As that comparison repeats, the procedure written in the skill fades into background, and the most recent tool output takes its place. The agent has not forgotten the knowledge. It has lost easy reach to it.

People learn in a similar way. Think of it as a cluttered desk where the checklist on the wall stops registering once working memory fills up. The checklist did not get worse. The room to look at it disappeared. Reading this, I felt that long agent runs should be judged with context clutter in mind alongside success rates. The same failure can come from very different causes.

What sits inside the box called a skill package

Agent skills in this study are not single prompt sheets. They are skill packages, bundles of several files that hold instructions with scripts and supporting resources. There is prose to read when doing the task, code or tools that can run directly, plus examples and references packed in the same box. Building a skill is therefore closer to packing a small workbench than to writing one clever sentence.

Here an odd question comes up. Is the content of the box the full story, or does the way we open it matter just as much. The same box can be opened flat on the main desk with everything spread out, or handed over whole to someone else who returns only the result. The paper compares exactly those openings. One path loads skill instructions into the main context and asks the agent to follow them there. The other path starts a subagent with a fresh context and lets that context solve the subtask.

I liked this split because skill talk usually converges on content quality. Better prose, fuller examples, kinder docs, as if documentation alone decides the outcome. This study shifts the gaze slightly and says the same content can feel different under different execution shapes. Look at the path the box takes into the working seat, in addition to the inventory inside the box.

Two ways to pull out the same knowledge

The conventional path feels natural. The skill text goes into the main agent context, and the agent reads it while working. It resembles cooking with the recipe propped up beside the stove. Ingredients in view, steps in view, comfort at the start. When the job is short with few surprises, this path is fastest. Nobody extra must be briefed, and no handoff must be phrased.

Subagent execution resembles calling one more cook into the kitchen. Instead of loading the full skill into the main context, the system opens a fresh context for the subtask and solves the skill inside it. The main agent only needs to know what it delegated and what should come back. It is close to a head chef telling the sauce cook to follow the recipe for the sauce alone and report back taste and amount. The head chef keeps a light head, and the sauce cook sees only sauce work.

So which side lasts longer. The answer here is conditional, and I trust the conditional form more than a blanket verdict. Subagent execution holds up better when skill packages expose clear input output contracts and encode the procedural knowledge that fulfills those contracts. Delegation works when the assigned slice is crisp and the steps that satisfy it sit organized inside the box. That condition deserves slow reading.

Why the convenient path of loading context breaks down

Loading everything into one context has clear appeal. No briefing means a fast start. Yet as the job lengthens, that comfort turns into debt. Skill text, chat history, tool outputs, and file fragments pile into one window, and the agent grows unsure which part should ground the next decision. The skill sits early, the live work sits late, and the distance between them widens.

Then strange failures appear. The agent skips a step the skill states plainly, rechecks a condition it already settled, or believes it verified something it only glanced at. These are failures of buried knowledge rather than missing knowledge. They resemble a desk buried under paper where the top sheet wins regardless of weight. Recency beats relevance.

From a systems perspective, the next question is obvious. Why not summarize or clear the context along the way. Summaries help, though they demand fresh judgment about what may be dropped, and a wrong cut can erase the premise the skill needs. (Knowing what to discard is itself a hard call in the middle of a long run.) So this path stays light and quick for short work while turning structurally weaker for long work. Convenience and durability point in separate directions.

What changes when you open a fresh window and hand work over

Subagent execution flips the response. Instead of scrubbing one room ever harder, it offers a new room for the messy part. Each subtask gets a fresh context, so the skill text and the live problem stay close together inside that room. The main agent keeps the overall goal with short notes on intermediate outcomes, while detailed procedure lives with the subagent.

The effect is easy to feel. A new room makes the visible job simpler. The main agent can attend to what went in and what should come out. The subagent can attend to how the contracted output gets built from the given input. Neither side carries the incidental middle of the other, so the axis of judgment stays steadier over long stretches. I think the more important result is that structure rather than any single score. Scores fade, while the reason behind them guides the next design.

Still, delegation asks for its side of the bargain. Both sides must agree on what passes between them. Vague input leaves even a clean room confused. Missing output criteria leave the main agent unable to trust what returns. Opening a new window is therefore not only a context trick. It is a work design choice about where to cut, what to pass, and what to inspect. With that agreement in place, separation gives strength. Without it, separation gives scatter.

Why delegation holds only when the contract is clear

This is where I would be careful not to over-read the experiment, because the condition carries the whole point. Subagent execution pulls ahead when a skill package shows a clear input output contract and holds procedural knowledge that carries it out. A contract is a boundary around the assigned slice. It says what enters, what must exit, and what counts as done, in terms both sides share.

Picture a late night data cleanup that runs while the team sleeps. If the input tables and date range are fixed, the output path and file shape are fixed, and empty value handling is written down, then this slice fits delegation well. The subagent can walk the steps inside the promise, and the main agent can check the promise at the door. If the request stays loose, along the lines of tidy this up sensibly, extra rooms will not save it. A vague job in a clean room leaves only clean vagueness.

The wording matters. This does not say good prose wins. It says knowledge shaped for handoff wins under separation. Procedure means the order is known, and contract means the order can be checked. So before lengthening skill docs, I would narrow the entrance and the exit. Once inputs and outputs turn crisp, the middle steps grow easier to fix, teach, and test.

Why clean separation never comes free

It would be easy to hear all this as praise for splitting work, so the other half of the finding deserves equal weight. Isolation has a price in coordination, paid in extra tokens that pass between the main agent and its subagents. Clean rooms still need hallways. Context must be handed over at the start, results must be inspected at return, and mismatches must be explained again.

That price stings most on short jobs. Splitting a small chore can make briefing longer than doing. Everyone knows tasks that finish faster alone than explained. On long and tangled jobs the same price feels lighter, because damage from a crowded main context outweighs briefing cost. It becomes a budget choice about where to spend. When clutter threatens heavy losses, paying for coordination leaves more on the table.

When our team reads a new AI architecture, we look past the headline number toward what changed and what cost shape it creates in a system. This paper reads well in that light. The durable insight is less that subagents won and more what was paid and what was bought. Extra tokens are a price tag rather than a flaw. With the tag visible, builders can decide which jobs deserve separation.

Why saying the knowledge is good is only half right

The sentence I will keep from this study is that reusable knowledge earns its keep through organization and invocation as well as content. The same skill can live longer or shorter in long work depending on how it is packed and called. If skill review used to resemble hunting for good docs, it now needs a second axis for choosing good execution.

The question itself has moved. It changed from what should a skill contain to how should contained skill run. That shift explains why content craft and execution design belong on the same team. A blurry contract scattered across subagents drifts, while procedure without reachable context sinks. When content and execution pull apart, long jobs show the strain first. So a skill review should weigh narrow inputs and outputs with checkable steps and sensible delegation units, alongside friendliness of prose.

So what transfers to daily work. I would start by rewriting the skill list around delegation units rather than topics. Ask whether each skill can be handed over whole, what narrowing of inputs and outputs that handoff needs, and which steps serve as checkpoints. Even before answers arrive, the exercise helps. The moment those questions appear, a skill stops being a document and starts becoming a unit of work.

What to ask if you want agents that last

Open questions remain, and they feel concrete rather than decorative. We still need a better sense of which skills expose contracts well, how explicit procedural knowledge must be, and where the advantage of separation flips with job length. This study sets the direction, though production work runs messier than lab tasks. Tools change, formats skew, people interrupt. Whether contracts hold through that mess is the next thing to check.

What I would watch next is the shape of failure. I want to see where subagents fail, whether from blurry contracts or missing steps or misaligned handoffs. Visible failure locations point to fixable spots. If in-context runs fail through fading, subagent runs likely fail through mismatch, where expectations on two sides quietly differ. Telling those two apart would sharpen the rule for picking execution by job length.

So what is the human role here. It looks closer to dividing skills than to writing them. Someone decides where to cut the job, which promises travel with each piece, and which checks must pass before moving on. Agents that work long hours stand on small kept promises. This paper quietly shows their worth. The next time I plan a long agent job, I will ask one thing before gathering more knowledge. Which room should hold this task so it fades least.