Skills or subagents: what actually works

Skills, in most cases, and the result surprises enough people to be worth stating up front: a single agent with in-depth skills reaches the performance of multi-agent architectures across a wide range of tasks, at incomparably lower cost and maintenance complexity.

The reflex to split things up comes from a reasonable intuition, the division of labour. If a specialised human beats a generalist, a specialised agent should beat a single agent. That intuition travels badly, for a reason practice reveals quickly: human specialisation rests on years of accumulated experience, whereas a subagent’s specialisation rests on a system prompt you wrote yesterday.

What each approach actually adds

The useful distinction is not about performance but about the nature of what you are adding.

A skill adds know-how. It is a written, portable procedure the agent loads when it becomes relevant and then applies. It is reusable by any agent, it versions like code, and it occupies context only when it is needed.

A subagent adds a space. It has its own context, its own prompt and its own tool permissions. What it adds is not competence but isolation: what it reads and produces does not clutter the main conversation, and it can hold permissions the main agent does not.

Put that way, the choice becomes fairly simple. If the problem is that the agent does something badly, write a skill. If the problem is that the task produces too much material, or requires permissions you do not want granted everywhere, use a subagent.

The result that should change your practice

Here is the most important finding of recent work, and it is counter-intuitive for anybody hoping to industrialise the process.

Auto-generated skills provide no measurable benefit on average. Human-written and reviewed ones, by contrast, consistently beat the no-skill baseline. And crucially, a low-quality skill is not merely useless: it actively degrades performance, because it steers the agent towards an unsuitable procedure with the authority of an explicit instruction.

The consequence is unwelcome for everyone. Asking a model to write your agent’s skills is precisely the thing that does not work, and it is unfortunately everybody’s first idea. The work stays human, it is slow, and it consists mostly of writing down what your best practitioners do without thinking about it.

That observation goes beyond the technical. A senior business manager’s tacit knowledge, what makes them say a client will refuse this profile or that an availability is optimistic, is exactly the material of a good skill. Formalising it is an investment whose return exceeds the agent, since it becomes transmissible to humans too.

What each architecture actually consumes

A point rarely quantified in architecture discussions, though it weighs on the bill as much as on latency.

A subagent starts with an empty context that has to be filled. Handing it a task means passing it the relevant state: the original request, what has already been found, the client’s constraints. That transfer is billed in tokens on every call, and billed again when the result comes back and has to be reintegrated. Across a chain of three subagents, the same context is paid for four or five times.

A skill works the other way round. It costs nothing until it is loaded, and it brings only the procedure without dragging context along. That is why a well-equipped single-agent architecture is often cheaper to run than a split that looks elegant on a diagram.

Latency follows the same logic. Three subagents in series means three waits that add up, and the user feels all of them. Parallelism only helps when the tasks are genuinely independent, which is rarer than people assume as soon as one result depends on another.

That said, there is one case where splitting wins clearly, and it deserves acknowledgement: when a task produces a volume of intermediate material that would saturate the main context. Reading two hundred records to keep five is exactly that. The subagent reads everything, returns only the synthesis, and the main agent never sees the other hundred and ninety-five. That is a filtering use rather than a specialist one, and it is probably the sounder of the two.

How to recognise a skill that earns its place

Three criteria can be checked in half an hour and will stop you accumulating useless files.

It must be testable. You should be able to exhibit a task the agent completes with the skill and fails without it. If you cannot, the skill is probably repeating what the model already knows and spending context for nothing.

It must be specific to your house. “How to write a good email” is not a skill, it is a general capability of the model. “How we write a profile proposal for this client, with the three things they look at first” is one.

It must be revisable. A skill written once and never reviewed decays like any company procedure: the world moves and the file stays. A quarterly review is plenty, provided somebody is named as its owner.

What we took from this at Balt

We started with a multi-agent architecture, like more or less everyone in 2025, with the appealing idea of a sourcing agent, a write-up agent and a follow-up agent handing work to each other.

Two problems appeared quickly. The first was the cost of coordination: moving context between three agents consumes more than keeping it in one place, and every handover is an opportunity to lose a detail. The second was diagnosis: when the final output is poor, working out which of the three went wrong takes a disproportionate amount of investigation.

We came back to a main agent with hand-written skills, keeping subagents for two specific situations. Those where the task produces a lot of intermediate material it would be absurd to keep in the main conversation, and those where permissions differ, typically a read on a source the main agent has no business reaching. That second case is a security decision as much as a performance one, since it limits what a successful injection can do.

The general lesson seems to us to hold beyond our case. Architectural complexity is paid every day in maintenance and in difficulty of diagnosis, whereas the quality of a skill is paid once, at writing time. At equal performance the choice is not hard, and it looks a lot like the one already separating a well-made workflow from an agent: the simplest solution that meets the need is almost always the right one.