When to Escalate: Skills, Single Agents, and Multi-Agent Architectures
A Claude Skill does not automatically require a multi-agent system. The decision in this chapter is when a Skill-equipped single agent is sufficient, when a structured workflow adds needed control, and when several agents earn their coordination cost. The useful comparison weighs control requirements, domain complexity, independent directions, context, observability, latency, and resources. It treats architecture as a response to an observed boundary rather than as a measure of ambition.
The starting point is deliberately simple. The agent guide recommends beginning with a single-purpose agent, measuring its behavior, and adding complexity as requirements evolve. A Skill is often the first way to add specialized knowledge and a repeatable procedure without multiplying agents. That baseline matters because every additional component creates another interface whose state, errors, and costs must be understood.
What a Skill adds to one agent
A single agent operates in a loop: it receives a task, forms a plan, calls available tools, observes the results, and adjusts its next action until it completes the work or reaches a stopping condition such as human review. A Skill adds a structured method to that loop. It can provide domain-specific knowledge, a sequence of actions, specialized tool guidance, validation criteria, and failure handling.
The gain is not that the Skill makes the agent infallible. It narrows the space of reasonable actions for a recurring use case and makes important decisions explicit. A customer-support agent equipped with a service-specific Skill may know which account information to retrieve, how to apply the support procedure, and when a case should move to a specialist. A research agent with a research-method Skill may know how to separate collection, analysis, and synthesis. The model still chooses actions dynamically, and tools still return uncertain or incomplete states.
A single agent with a Skill is a strong baseline when the work stays within one domain, follows an established workflow, or benefits from a consistent method more than from independent perspectives. It is easier to connect behavior to a metric, easier to trace a user request through one loop, and generally less expensive to run than a coordinated group. It also preserves a straightforward ownership model: one agent interprets the Skill and the user request, while external tools own their systems of record.
The baseline breaks down for identifiable reasons. The Skill may need more context than one agent can manage coherently. The task may span distinct domains whose rules must be applied by different specialists. The work may require several independent investigations at once. Or the quality of one draft may depend on a separate evaluator with criteria that the generator should not be allowed to redefine. These are reasons to examine an architecture change, not proof that a larger system will solve the problem.
Progressive disclosure and context management should be tried before adding coordination. A focused core instruction, on-demand references, bounded tool responses, pagination, filtering, and external memory can keep a single agent within a workable context. The agent guide describes context-window overflow, degraded reasoning, and coordination failure as consequences of uncontrolled context growth. Splitting an overloaded conversation across agents may help, but it can also move the same information problem into messages and shared state.
Observability belongs in the baseline as well. Agents make dynamic decisions, and a conventional stack trace may not explain why a tool was selected or why a result was rejected.