Alibaba SkillWeaver Commentary: Why agent tool selection should prioritize skill search, DAG, and failure recovery budget rather than long prompts

When AI agents start taking on actual tasks, the problem does not end with whether the model can speak well. The bottleneck is which of the hundreds of APIs, MCP tools, and in-house automation skills to use, and in what order. SkillWeaver, released by Alibaba researchers, attempts to solve this problem with “task decomposition, skill discovery, and DAG execution planning” rather than “putting all the tools in the prompt”.

1. One-line problem definition

Key line: The reality of agent tool selection is not a lack of tools, but too many tools to choose correctly within context and operating budget.

For beginner developers, a skill can be viewed as a “task card that can be called by AI.” For example, functions such as file downloading, CSV conversion, chart creation, Slack notifications, and Supabase queries could each be a skill. When you have 10 tools, you can get by with at least all of the prompts, but when you have more than 200, the model gets confused between tools with similar names, and the context cost quickly increases.

This article is aimed at developers and planners who want to operate in-house automation agents, MCP servers, business AI assistants, and no-code/low-code agent builders. The scope is to translate the structure of SkillWeaver papers into practical operational standards. Conversely, if you have a simple chatbot with less than 5 tools or a bot that only executes a single set of workflows, this structure may be overkill.

2. First, conclusion

Key line: The core message of SkillWeaver is not “Let’s use bigger models”, but “Let’s separate tool selection into search problems and execution planning problems”.

The paper published on arXiv on June 16, 2026 describes SkillWeaver as a three-step framework: Decompose, Retrieve, and Compose. It divides complex requests into small subtasks, searches for skills appropriate for each task, and combines them into a DAG-type execution plan, taking dependencies into account. DAG stands for Directed Acyclic Graph, and is a task map that connects “tasks that must be completed first” and “tasks that can be done in parallel” with lines.

The practical conclusion I see is clear. Teams with more than 50 agent tools need to move away from tooltips within prompts. Skill catalog, search index, re-ranking, execution plan verification, and failure recovery policies must be designed as separate layers. However, since SkillWeaver is still weak in error recovery, it is safer to start operation introduction by separating “plan creation” and “execution approval”.

3. Decomposition of core structure

Key line: Rather than asking agents to memorize a list of all tools, SkillWeaver finds and assembles appropriate skill candidates at the moment of need.

The first layer is Decompose. Break the user's large requests into atomic subtasks. The request “Download the data, convert it, and create a visualization report” is divided into data download, data conversion, chart creation, and report creation. If the quality at this stage is low, subsequent searches will also be incorrect.

The second layer is Retrieve. The paper explains that it uses a bi-encoder skill finder and FAISS indexing. Simply put, this method stores each skill description as a vector and quickly finds skill candidates whose meaning is close to the subtask. This can significantly reduce context usage compared to cramming all tooltips into the LLM prompt.

The third layer is Compose. Organize the discovered skills into DAG according to task sequence and dependencies. Data transformation must follow the download, but summary statistics calculations and chart creation can run in parallel after the same data has been prepared. This structure allows you to view long tasks as an actionable plan rather than a list of one-line tool calls.

4. Description of design intent

Key one-liner: The design intent is not to increase model intelligence, but to calibrate the model to think in the context of real-world tools.

What makes SkillWeaver interesting is that it does not view task decomposition itself as a fixed, prompted ability. The paper proposes Iterative Skill-Aware Decomposition, or SAD for short. First, LLM creates a work plan, searches for candidate skills using the plan, and then revises the work plan by referring back to the searched skill information. In other words, it is a feedback loop of “making a plan, checking the available tools, and revising the plan again”.

What this design achieves is reality consistency. Even if the model abstractly says “data cleaning”, the actual catalog may only have more specific skills like csv-normalize, dedupe-records, schema-validate. SAD narrows the model's representation to actual skill names and categories.

An alternative is to give up. It adds layers of search index, skill metadata, re-ranking, and plan validation rather than just a one-time prompt. Operational complexity increases. So this approach is better suited for teams with many tools and frequently changing work mix than for teams with few tools.

5. Evidence and Comparison

Key line: SkillWeaver's rationale lies more in the analysis that “the quality of task decomposition is a prerequisite for tool selection” than in token savings numbers.

Approach	Change target	Advantages	Limit	Recommendation status
LLM-Direct	Include all tooltips in prompt	Simple implementation	With more tools, token cost and confusion increase	Less than 10 tools, short-term experiment
ReAct type repetitive call	Alternate between reasoning and action	Familiar with search-type problems	Difficult to reliably divide complex requests into subtasks	Exploratory operations in minority tools
Static routing rule	Select tool by keyword or menu	Predictable and easy to audit	Weak to new work combinations	Organization with fixed regulatory work and approval flow
SkillWeaver-style search routing	Task decomposition, skill search, DAG combination	Suitable for large skill catalogs and reduces context costs	Skill metadata and failure recovery system required	50+ tools, MCP/in-house automation platform

The paper created CompSkillBench based on 2,209 real skills and 24 functional categories collected from the public MCP ecosystem, and evaluated 300 complex queries. Standard LLM task decomposition achieved a 34.2% step-level category recall, while SAD increased decomposition accuracy from 51.0% to 67.7%. The paper reports this improvement as +32.7% and describes it as statistically significant.

The AI ​​Times report also introduced efficiency figures. The LLM-Direct method of listing all tools used about 884,000 tokens, while SkillWeaver utilized only the information needed, averaging about 1,160 tokens. This leads to claims of reducing context tokens by 99.9%. However, the numbers are results under specific benchmark and skill catalog conditions, so they may vary depending on the actual in-house tool name and description quality.

6. Actual operation flow / step-by-step execution method

Key line: Product teams should start by creating a skill catalog and routing assessment set rather than replicating the entire SkillWeaver.

1. Standardize your skill catalog. Give each skill a name, description, input schema, output schema, permission level, failure code, and example query. It is better to separate the description into a short search description of around 140 characters and a long document description.
2. Creates 30 complex tasks into an evaluation set. Collects requests that frequently occur in actual work, such as “Creating a report by segment after organizing customer CSV.” Each request is human-marked with expected subtasks and accepted skill candidates.
3. Measuring decomposition and retrieval separately. If you only look at the final success, you won't know where the problem is. View separately the number of decomposition steps, whether the correct category is included, and whether the correct answer is included in the top five candidates.
4. Insert policy check before DAG execution. Payment, distribution, external transfer, and personal information access skills are not automatically executed but are sent to the approval stage.
5. Design failure recovery separately. The SkillWeaver paper also reported a step success rate of 86.9% and an overall chain completion rate of 76.7% in the pilot run. We must deal with the problem that failure at one step breaks the entire chain.

skill:
  id: csv-normalize-v2
  category: data_transform
  short_description: Normalize CSV headers, date formats, and numeric columns.
  input_schema:
    file_url: string
    date_format: string
  output_schema:
    normalized_file_url: string
    validation_report: object
  permission: internal_file_read_write
  retry_policy:
    max_attempts: 2
    fallback_skill: csv-normalize-basic

There is no need to attach a complicated re-ranking model from the beginning. In the first version, it is sufficient to select the top-10 candidates through embedding search and show LLM only 10 sub-tasks and candidates to select one. The important thing is to break the habit of showing all the tools and create a loop to narrow down and then verify candidates.

7. Pitfalls

Key one-liner: Tool routing failures often start with poor catalog, permissions, and recovery design, not model issues.

1. Pitfall: Skill descriptions are long and abstract, like human documentation.
   Prevention: Search descriptions must clearly specify inputs, outputs, and verbs. Insert:
   Recovery: Pull incorrectly selected skill pairs from the failure log and rewrite their descriptions by 1 sentence each.
2. Pitfall: Decomposing the task into too small pieces.
   Prevention: Easy tasks take 2~3 steps, difficult tasks take 2~3 steps. Leave the allowable range as in steps 4 and 5.
   Recovery: Create a separate bucket for queries that increase unnecessary intermediate skill calls and adjust the decomposition prompt.
3. Trip: Operate and distribute only after looking at search accuracy.
   Prevention: Candidate inclusion indicators such as CatR@k and the actual chain completion rate together. View:
   Recovery: Records the failed chain at what stage it was broken and divides it into retry, fallback, and human approval.
4. Pitfall: Tools with high privileges are routed like regular tools.
   Prevention: External transfer, payment, deletion, and distribution skills are tagged with policy tags. Prevent automatic execution.
   Recovery: Move critical skill calls to an approval queue and show a summary of changes to the user before execution.
5. Pitfall: Adding a new skill does not update the evaluation set.
   Prevention: Add skill At least 3 example queries and counterexamples in PR Requires 1.
   Recovery: Refresh CompSkillBench-style internal mini-benchmark based on routing failures in the last two weeks.

8. Strengths and Limitations

Key one-liners: SkillWeaver is great at reducing the cost and confusion of tool-heavy agents, but it doesn't automatically address execution stability.

The strengths are clear. First, reduce the context budget. Second, break down tool selection into steps that humans can appreciate. Third, the DAG structure clearly demonstrates parallel execution possibilities and dependencies. Fourth, we move away from the simple conclusion that a larger model is always better and make skill structure and search quality targets for improvement.

The limitations are also clear. The paper explains that it focuses on execution planning and tool selection, and does not yet include error recovery required for actual service operation. Even in the pilot run, the overall chain completion rate was 76.7%, compared to a step success rate of 86.9%. In a multi-step task, a single step failure can cause a compound failure that stops the entire process.

The counterexample I see is a business with strong regulations. For example, in tasks where one wrong tool choice can be costly, such as payment approvals, medical decisions, or legal document submissions, static workflows and human approvals take precedence over automated routing. SkillWeaver-style routing is useful for recommendations and draft planning, but high-risk execution should be gated separately.

9. Points to study more deeply

Key one-liners: To learn more about this topic, you should look at Search Quality, Skill Schema, and Execution Plan Verification before the agent framework name.

• Difference between bi-encoder search and cross-encoder or LLM reranking
• How to update and version control skill descriptions in vector indexes such as FAISS
• How to represent parallel execution, retry, rollback, and acknowledgment nodes in the DAG executor
• How to shorten the tooltip of an MCP server to be search-friendly
• How to change routing metrics such as CatR@1, CatR@5, ChainCat, and chain completion rate to internal product metrics

The recommended learning sequence is three steps. First, read the arXiv abstract and Figure 1 to understand the Decompose, Retrieve, and Compose flows. Next, let's quickly check out the key numbers and limitations in the AI ​​Times article. Finally, create a mini-catalog of just 20 in-house skills and label the 10 actual requests with the expected human skills. This small experiment will tell you the fastest way to adopt your product.

10. Action Checklist + Author's Perspective

Key line: The completion criterion for agent tool selection is not “adding a lot of tools” but “being able to track and recover the reason for choosing the wrong one”.

Definition of Done: The user's complex request is decomposed into subtasks, candidate skills and selection reasons for each step are logged, failure moves to either retry/fallback/approval, and the primary tool routing scheme is considered complete when the target chain completion percentage is exceeded in the internal evaluation set. View.

From the author's point of view, SkillWeaver is more a change in operation than “a new agent framework.” As agents have more tools at their disposal, prompts become part of the routing policy rather than a manual. I recommend that teams with more than 50 tools start by creating a skill catalog and routing assessment set rather than buying a huge agent platform right away. Without that foundation, it is difficult to explain the reason for failure no matter what model is attached.

11. Reference

• AI Times - Alibaba unveils agent tool selection framework ‘Skillweaver’ (Publication date: 2026-07-03, Confirmation date: 2026-07-03)
• arXiv - Compositional Skill Routing for LLM Agents: Decompose, Retrieve, and Compose (Submission date: 2026-06-16, Confirmation date: 2026-07-03)
• arXiv HTML - SkillWeaver paper body (Confirmation date: 2026-07-03)
• Model Context Protocol Official Introduction (Confirmation date: 2026-07-03)
• FAISS Documentation (Confirmation date: 2026-07-03)