Enterprises building AI agents have a simple fantasy: give the model every tool, let it figure out what to use, and move on. Alibaba’s SkillWeaver project is built to kill that fantasy fast. In their experiments, SkillWeaver slashes context window use from an estimated 884,000 tokens down to roughly 1,160 tokens per query, a 99.9% reduction, while also improving how often the system decomposes a task correctly.

Why does that matter? Because when agents are fed a full tool library, they don’t just get expensive. They lose the plot. In the “LLM-Direct” baseline, even a very large Qwen-Max model retrieved the right tool category only 21.1% of the time when flooded with options. SkillWeaver’s whole point is to avoid that blind exposure: build an execution graph, fetch only what’s relevant, and iteratively align decomposition vocabulary with the actual skills that exist.

Let’s translate the problem into something a CEO, CTO, or investor can act on. Modern LLM agent architectures rely on “skills,” meaning modular, reusable tool specifications with structured natural language documentation. The catch is scale. Some agents can have hundreds of tools and skills, and real business requests are compositional. A prompt like “Download the dataset, transform it, and create visual reports” does not map cleanly to one tool. It needs a sequence: an API client or fetch step, a transformation or parsing step, and a visualization/report step, all composed into one executable plan.

SkillWeaver tackles this as “compositional skill routing.” The system is structured in three stages: Decompose, Retrieve, and Compose. First, an LLM decomposes the user request into a sequence of sub-tasks, each intended to correspond to one skill. Then the system uses an embedding model to compare each sub-task against a skill library and retrieves a shortlist of candidate tools for each step. Finally, a planner evaluates how the retrieved candidates work together, checking inter-skill compatibility and wiring dependencies into a Directed Acyclic Graph (DAG) so independent work can potentially run in parallel.

That sounds neat until you hit the real failure mode: LLMs often produce generic step descriptions that don’t match the technical vocabulary in the skill library. If your decomposition says “get data” but your tools are documented as “http-fetch” or “csv-parser,” retrieval can drift. SkillWeaver’s answer is Skill-Aware Decomposition (SAD), a feedback loop. SAD has the LLM draft an initial plan, runs a preliminary search to find loosely matching skills, and then feeds those retrieved skills back into the LLM as hints. The LLM rewrites its decomposition so the granularity and vocabulary align with the actual tools available.

The results are basically a scoreboard for what matters in production. To evaluate SkillWeaver in enterprise-like settings, the researchers built a custom benchmark called CompSkillBench with 300 multi-step queries across different difficulty levels. They mirrored real-world environments using a library of 2,209 real-world skills sourced from the public Model Context Protocol (MCP) ecosystem, spanning 24 functional categories such as cloud infrastructure, finance, and databases. The core engine used a lightweight 7-billion parameter model, Qwen2.5-7B-Instruct, for task decomposition, plus a semantic search retriever (MiniLM with a FAISS index).

SkillWeaver was compared against three main setups: a brute-force “LLM-Direct” method that stuffs all tool names into the prompt of a large model, a vanilla LLM-based decomposition without SAD, and a ReAct-style agent loop. The experiments point to task decomposition as the main bottleneck. In the vanilla setup, the 7B model achieved decomposition accuracy, defined as predicting the correct number of steps, only 51.0% of the time. With SAD enabled, accuracy jumped to 67.7%, and with the larger Qwen-Max model accuracy reached 92%. On hard tasks requiring four to five distinct skills, SAD improved accuracy by 50%.

One particularly interesting twist for anyone tempted to “just buy a bigger model” is that larger can actually underperform when unguided. In the vanilla setup, a 14-billion parameter model saw accuracy plummet below the 7B model, because it tended to over-decompose tasks into microscopic, unnecessary steps. SAD anchored the model back to reality by anchoring decomposition to retrieved tool vocabulary. The underlying implication is clear: aligning an agent with the vocabulary of specific tools may matter more than paying for a higher parameter count.

Finally, the token story is where the business case becomes unavoidable. The LLM-Direct baseline failed to retrieve the right tool category reliably because the model was overwhelmed by the number of tools in context. SkillWeaver’s targeted retrieve-and-route approach instead slashed context window consumption from an estimated 884,000 tokens down to roughly 1,160 tokens per query, a 99.9% reduction. For practitioners, that translates into lower API costs and faster response times, because you are not spending your budget on irrelevant tool descriptions.

If you build or buy enterprise AI agents, this is a board-level lesson in systems design, not just model behavior. ReAct failed completely here, achieving 0% decomposition accuracy, because its loop naturally collapses multi-step plans into isolated actions rather than explicitly mapping multi-step execution. Put another way: the companies that win will be the ones that treat tool routing as an engineering problem with feedback loops and execution planning, not as a one-shot prompt stunt. In the near term, SkillWeaver offers a credible path to more accurate multi-tool workflows while controlling token spend, which is the constraint that turns demos into deployments.