1 Introduction↩︎

Large Language Model (LLM) agents are evolving from single-prompt interactions, limited tool calls, and short-horizon exchanges into complex intelligent systems capable of task decomposition, tool invocation, model orchestration, and interaction with external APIs [1], [2]. In this emerging paradigm, agent skills serve as a critical intermediate layer between user tasks and executable capabilities. A skill typically contains not only natural-language instructions, but also task workflows, tool-use specifications, code templates, input-output assumptions, execution constraints, examples, and risk warnings. As such skills are continuously accumulated, reused, and shared, large-scale agent skill libraries are giving rise to a new service-oriented ecosystem. Within this ecosystem, reusable skills function analogously to service units: they must be identified, modeled, discovered, selected, and composed to support complex task execution by small LLM agents operating under constrained environments.

However, as a skill library scales to tens of thousands of entries, the core challenge of agent skill selection fundamentally changes. The problem is no longer a simple retrieval task of determining whether a relevant skill exists. Instead, the system must discover, select, and organize a set of Skill Services that can jointly support task execution from a large candidate space. This issue is particularly pronounced for small LLM agents, for which skill selection is essentially a budgeted decision problem: an agent can load only a small number of service-oriented capability units under limited context budgets, available tool sets, and risk constraints. Recommending more skills does not necessarily lead to better execution performance. Redundant or incompatible skills may consume scarce context, introduce irrelevant steps, or even cause negative transfer. Therefore, an effective skill selection system must not only identify semantically relevant skills, but also assess their marginal usefulness, complementarity, cost, risk, and compatibility with the current agent profile.

Existing methods for LLM tool use and retrieval-augmented agents commonly formulate the integration of external capabilities as tool retrieval, API selection, routing, or reranking problems [3]–[5]. Given a task request, the system computes a relevance score for each candidate tool or skill and returns a fixed number of top-\(k\) items. Although this paradigm is simple and effective, it suffers from three structural limitations. First, it typically treats a skill as a retrievable document or tool description, while neglecting the service attributes implicitly associated with the skill, such as input-output types, tool dependencies, context cost, risk level, and applicability conditions. Second, it uses an individual skill as the basic decision unit, making it difficult to characterize complementarity, substitutability, conflicts, and redundancy among multiple skills. Two skills that appear relevant in isolation may be highly repetitive when combined, whereas a skill with a relatively low individual ranking may provide a critical capability required by the task. Third, fixed top-\(k\) selection assumes that all tasks require the same number of skills. This assumption cannot accommodate the budget constraints of small LLM agents, nor can it support fine-grained trade-offs among coverage, cost, risk, and execution suitability.

The central argument of this paper is that agent skills should be treated as composable services rather than retrievable documents. We model each agent skill as a Skill Service, namely a service-oriented capability unit characterized by a functional description, input-output assumptions, tool dependencies, execution constraints, token cost, risk attributes, and QoS-related attributes. This perspective is closely aligned with the long-standing research in service-oriented computing on service discovery, service selection, service composition, and QoS-aware decision-making [6]–[8]. Under this formulation, agent skill selection is no longer merely the retrieval of relevant documents from a text repository. Instead, it becomes a service computing problem situated within a skill service ecosystem: the system must discover candidate services from a large-scale Skill Service Registry, estimate the marginal suitability of each candidate service for the current task, and output a budget-controllable skill service bundle under a given service budget, context budget, and set of risk constraints.

Building on this reformulation, this paper proposes SkillSelect-Serve, a budget-controllable and QoS-aware framework for Skill Service Recommendation and Composition tailored to small LLM agents. Unlike fixed top-\(k\) retrieval, SkillSelect-Serve adopts a requirement-conditioned and dual-granularity paradigm for service utility modeling. First, the system transforms raw skill documents into structured Skill Service Profiles, which explicitly represent service attributes such as functionality, tools, input-output specifications, cost, and risk. Second, we introduce a lightweight local Micro-Agent Requirement Planner that parses a natural-language task into structured service requirements, including required capabilities, required tools, input-output requirements, hard constraints, and risk notes. It is important to note that this micro-agent does not directly select skill IDs or perform the final recommendation. Instead, it serves only as a requirement interface, enabling subsequent models to estimate the suitability of candidate services at the level of service requirements.

Given the structured requirements, SkillSelect-Serve first employs a discovery backbone to retrieve candidate skill services from a large-scale Skill Service Registry. It then performs dual-granularity service utility modeling. At the skill level, the model estimates the marginal service suitability of each candidate service for the current task, thereby identifying the most valuable services under a given budget. At the bundle level, the model further calibrates the utility, hit likelihood, redundancy, cost, and risk of candidate service bundles. Finally, SkillSelect-Serve applies Budgeted QoS-aware Service Projection to produce recommendation results under different service budgets, such as compact mode, high-recall mode, and aggressive mode. Unlike methods that directly incorporate oracle utility, SkillSelect-Serve uses only label-free service features available at deployment time during inference, thereby preserving a clean and deployable setting.

The key advantage of this design is that SkillSelect-Serve does not attempt to load more skills into the agent in an unconstrained manner. Instead, it selects more useful Skill Services under a specified service budget. Under a strict context budget, the system can operate in compact mode, prioritizing a small number of services with the highest marginal value. When higher recall is required, it can adopt a larger service budget to improve task coverage. In other words, SkillSelect-Serve elevates skill selection from fixed top-\(k\) relevance ranking to budget-controllable service recommendation and composition. The objective is not merely to maximize hit rate in a retrieval list, but to establish a controllable trade-off among task coverage, service suitability, context cost, risk, and small-agent constraints.

We evaluate SkillSelect-Serve on a large-scale skill service registry. The registry contains 35,353 deduplicated skill items, together with 586 task requests, 577 evaluable queries, 717 curated positive interactions, and 52,647 query-skill training pairs. Experimental results show that SkillSelect-Serve substantially outperforms fixed top-\(k\) baselines under the same service budget. Specifically, in the compact setting with \(k=3\), SkillSelect-Serve Compact@3 improves bundle recall from 0.8163 achieved by the Top-3 baseline to 0.8700, and increases mean utility from 0.6333 to 0.6901. In the high-recall setting with \(k=5\), SkillSelect-Serve Final@5 improves recall from 0.8492 achieved by the Top-5 baseline to 0.8873, and increases mean utility from 0.6672 to 0.7078. Further upper-bound analysis shows that Final@5 already approaches the Top-20 candidate-space upper bound of 0.8873. These results demonstrate that the gains of SkillSelect-Serve do not arise from simply enlarging the candidate pool or relying on oracle utility. Rather, they stem from clean and deployable marginal service suitability estimation and budgeted service selection.

The main contributions of this paper are summarized as follows.

• We propose a Skill-as-a-Service formulation, which redefines agent skill selection from conventional top-\(k\) retrieval into a service computing problem. We model each skill as a Skill Service characterized by functionality, input-output specifications, tool dependencies, cost, risk, and QoS attributes. This formulation transforms the task into a joint problem of Skill Service Discovery, Skill Service Composition, and QoS-aware Skill Service Recommendation.

• We introduce an agent-conditioned service requirement representation. Specifically, we design a lightweight local Micro-Agent Requirement Planner that parses a natural-language task into structured service requirements. Unlike methods that directly ask an LLM to select skill IDs, this planner does not perform the final selection. Instead, it provides capability, tool, input-output, constraint, and risk signals for subsequent service utility modeling, thereby improving the interpretability and stability of task requirement modeling.

• We propose dual-granularity service utility modeling. This mechanism jointly estimates skill-level marginal service suitability and bundle-level utility and hit calibration. The former identifies candidate services with the highest marginal value under a given service budget, whereas the latter evaluates the coverage, redundancy, cost, and risk trade-offs of service combinations. Unlike methods that rely solely on raw retrieval ranks or a single bundle scorer, SkillSelect-Serve explicitly integrates service discovery signals with service composition quality.

• We propose Budgeted QoS-aware Service Projection, which supports different service budget regimes, including compact, high-recall, and aggressive modes. During inference, this projection uses only label-free deployable features and produces the final skill service bundle according to the service budget, context cost, risk, and redundancy constraints. Experimental results show that SkillSelect-Serve significantly outperforms fixed top-\(k\) baselines under the same budget, and that Final@5 approaches the Top-20 candidate-space upper bound.

• We conduct a systematic evaluation of SkillSelect-Serve on a large-scale skill registry, covering same-budget recommendation quality, upper-bound analysis, ablation studies, efficiency–scalability trade-offs, and diagnostic execution studies. The results demonstrate that SkillSelect-Serve improves budgeted skill-service recommendation quality in a clean and deployable setting. Moreover, the execution diagnostics reveal a gap between offline service recommendation utility and downstream small-agent execution utility, providing insights for future research on execution-aware Skill Service Composition.

In summary, this paper shows that, as LLM agents enter the stage of reusable skill ecosystems, the key challenge of skill selection is no longer to retrieve more relevant texts. Rather, it is to select more useful and deployable Skill Services under a given service budget and QoS constraints. SkillSelect-Serve systematically formulates this problem as requirement-conditioned, budget-controllable, and QoS-aware skill service recommendation and composition. Through dual-granularity service utility modeling, it connects service discovery, service composition, and service recommendation within a unified framework. This framework provides a foundation for future research on service-oriented capability management, execution feedback, and execution-aware service utility learning for small LLM agents.

2 Problem Formulation↩︎

As LLM agents evolve from one-shot prompting and limited tool invocation into complex systems that rely on reusable capability libraries, the problem of agent skill selection undergoes a fundamental shift. Existing methods typically treat a skill as a retrievable text segment and return a fixed number of top-\(k\) skills according to a task request. However, this view overlooks the service attributes of agent skills. A skill often contains not only a functional description, but also implicit input-output assumptions, tool dependencies, execution steps, context costs, risk warnings, and applicability conditions.

For resource-constrained small-model agents, recommending more semantically relevant skills does not necessarily lead to better execution performance. Redundancy, unavailable tools, context overflow, and risk mismatch may all result in negative transfer. Therefore, this paper reformulates agent skill selection as a budget-controllable and QoS-aware Skill Service Recommendation and Composition problem. The system must discover candidate services from a large-scale skill service registry and select a set of more useful and deployable skill services under a given service budget, context budget, and risk constraints. Unlike fixed top-\(k\) retrieval, the focus of this work is not to load more skills indiscriminately, but to improve the overall task suitability of the skill service bundle under the operational constraints of small LLM agents.

2.1 Skill Service Model↩︎

Let a large-scale skill service registry be denoted as \[\mathcal{S} = \{s_1, s_2, \ldots, s_N\},\] where each skill \(s_i\) is modeled as a Skill Service rather than a plain document. We represent each skill service as \[s_i = \langle id_i, f_i, d_i, I_i, O_i, T_i, c_i, r_i, q_i \rangle .\] Here, \(id_i\) denotes the service identifier; \(f_i\) denotes the functional description; \(d_i\) denotes the domain or task type; \(I_i\) and \(O_i\) denote the input and output types, respectively; \(T_i\) denotes the set of tools required by the skill service; \(c_i\) denotes the context or token cost; \(r_i\) denotes the risk level; and \(q_i\) denotes other QoS-related attributes, such as reliability, latency, historical success rate, or compatibility with a specific agent.

This model transforms a skill from a retrievable text segment into a discoverable, composable, and constraint-aware service unit. Accordingly, this paper does not focus solely on the textual relevance between an individual skill and a task. Instead, it investigates whether multiple skill services can form an effective composition under a given task and a set of agent constraints.

2.2 Task Requirement and Agent Constraints↩︎

Given a natural-language task request \(x\), the system aims to recommend an appropriate skill service bundle for a small LLM agent. The operating environment of the small-model agent is represented as \[A = \langle M, C_A, K_A, T_A, R_A, P_A \rangle .\] Here, \(M\) denotes the underlying small model; \(C_A\) denotes the available context budget; \(K_A\) denotes the maximum skill service budget allowed in the current scenario; \(T_A\) denotes the set of tools currently accessible to the agent; \(R_A\) denotes the acceptable risk threshold; and \(P_A\) denotes an optional agent profile or preference, such as low-cost preference, low-risk preference, high-recall preference, or domain-specific preference.

Skill selection for small LLM agents is typically not an unconstrained optimization problem. Rather, it is a budgeted decision problem. In different deployment scenarios, an agent may be allowed to load only a small number of skill services, or it may be permitted to use a larger skill budget in exchange for higher recall. Therefore, this paper formulates skill service recommendation as budget-controllable service selection. The system should produce a corresponding skill service bundle under different service budgets and explicitly expose the trade-off among task coverage, context cost, risk exposure, and redundancy.

To avoid the instability caused by directly asking an LLM to select skills, we first represent the task as structured service requirements: \[g(x) = \rho_x = \langle Cap_x, I_x, O_x, T_x, H_x \rangle .\] Here, \(Cap_x\) denotes the set of capabilities required by the task; \(I_x\) and \(O_x\) denote the task input and expected output, respectively; \(T_x\) denotes the tools that may be required by the task; and \(H_x\) denotes hard constraints, such as mandatory output formats, prohibited tools, risk restrictions, or execution conditions. This structured requirement does not directly specify skill IDs. Instead, it serves as the task condition for subsequent service discovery and service composition, enabling the system to move beyond semantic matching toward requirement satisfaction.

2.3 Candidate Skill Service Discovery↩︎

Since the scale of \(\mathcal{S}\) is typically large, directly enumerating all possible service compositions is infeasible. Therefore, the system first performs Skill Service Discovery to retrieve a smaller candidate set from the full registry: \[\mathcal{C}_x = D(x, \rho_x, \mathcal{S}), \quad \mathcal{C}_x \subseteq \mathcal{S}, \quad |\mathcal{C}_x| \ll |\mathcal{S}|.\] The objective of the discovery stage is to provide a high-recall set of candidate skill services, rather than to generate the final recommendation directly. Unlike conventional top-\(k\) retrieval, this paper treats discovery as a candidate generation step before service composition. The final output is not a fixed-length ranked list. Instead, it is a service composition further selected from the candidate set \(\mathcal{C}_x\) to satisfy task requirements and QoS constraints.

2.4 Budget-controllable Skill Service Composition↩︎

Given the candidate set \(\mathcal{C}_x\), the system aims to output a skill service bundle: \[B_k = \{s_{i_1}, s_{i_2}, \ldots, s_{i_m}\}, \quad B_k \subseteq \mathcal{C}_x, \quad |B_k| \leq k.\] Here, \(k\) denotes the service budget allowed in the current deployment scenario, and \(m = |B_k|\) denotes the actual number of selected skill services. Unlike fixed top-\(k\) retrieval, budget-controllable composition is not equivalent to simply selecting the first \(k\) skill services from a retrieval ranking. Under the same budget, the system must determine which services provide the highest marginal value for the task and which services should be excluded from the final bundle despite being semantically relevant, due to functional redundancy, excessive cost, or risk mismatch.

This formulation covers both compact and high-recall deployment requirements. When \(k\) is small, the system should prioritize the most critical skill services with the highest marginal gains, thereby adapting to strict context budgets. When \(k\) is larger, the system can select more complementary services to improve task coverage and recall. Therefore, this paper does not focus on automatically determining a single unique bundle size. Instead, it aims to improve the overall task suitability of the skill service bundle under a given service budget and QoS constraints.

2.5 Dual-granularity QoS-aware Utility↩︎

An effective skill service bundle should not only cover the task requirements, but also satisfy the operational constraints of a small LLM agent. This paper characterizes the utility of skill services at two granularities. On the one hand, the system needs to estimate the marginal service suitability of each candidate skill service for the current task. On the other hand, it needs to evaluate the overall coverage, complementarity, redundancy, cost, and risk of a bundle composed of multiple services.

For a candidate service \(s_i \in \mathcal{C}_x\), we define its marginal service suitability as \[m_i = m(x, \rho_x, s_i, A),\] where \(m_i\) measures the marginal usefulness of skill service \(s_i\) under the task request \(x\), the structured requirement \(\rho_x\), and the agent profile \(A\). This score can be interpreted as a fine-grained service discovery signal that determines whether a candidate service should be prioritized under a given budget.

At the bundle level, given a service budget \(k\), the optimal skill service bundle is defined as \[\begin{align} B_k^\ast = &\arg\max_{B \subseteq \mathcal{C}_x,\;|B| \leq k} U(x, \rho_x, B, A), \\ &\text{s.t.} \quad \mathrm{Cost}(B) \leq C_A,\quad \mathrm{Risk}(B) \leq R_A,\quad \mathrm{Tools}(B) \subseteq T_A . \end{align}\] Here, \(\mathrm{Cost}(B)\) denotes the total context cost of the bundle, \(\mathrm{Risk}(B)\) denotes the overall risk, and \(\mathrm{Tools}(B)\) denotes the set of tools required to execute all skill services in the bundle. The utility function \(U(x,\rho_x,B,A)\) jointly considers marginal suitability, task requirement coverage, service complementarity, tool and input-output compatibility, redundancy, cost, and risk: \[\begin{align} U(x,\rho_x,B,A) = & \lambda_1 M(B) + \lambda_2 \mathrm{Cov}(\rho_x,B) + \lambda_3 \mathrm{Comp}(B) \\ & + \lambda_4 \mathrm{Compat}(\rho_x,B,A) - \lambda_5 \mathrm{Red}(B) \\ & - \lambda_6 \mathrm{Cost}(B) - \lambda_7 \mathrm{Risk}(B). \end{align}\] Here, \(M(B)\) aggregates the marginal suitability scores of the skill services in the bundle, for example through a weighted summation or a Noisy-OR formulation. \(\mathrm{Cov}(\rho_x,B)\) measures the extent to which the bundle covers the structured service requirements. \(\mathrm{Comp}(B)\) captures complementarity among services. \(\mathrm{Compat}(\rho_x,B,A)\) measures the compatibility between the service composition and the task input-output requirements, tool permissions, and agent profile. \(\mathrm{Red}(B)\), \(\mathrm{Cost}(B)\), and \(\mathrm{Risk}(B)\) represent redundancy, context cost, and risk penalties, respectively.

This objective function reflects the key distinction of this work. Conventional skill retrieval primarily focuses on the relevance score between an individual skill and a task, and usually returns the top-\(k\) candidates in the ranking. Pure bundle-level methods, in contrast, may overlook the marginal identification of individually critical services. This paper adopts a dual-granularity formulation: skill-level marginal suitability identifies the candidate services that are truly critical for the current task, while bundle-level utility evaluates the coverage, complementarity, redundancy, cost, and risk of service compositions. In other words, a locally relevant skill should not necessarily be included in the final composition. Conversely, a service with a relatively low individual rank may substantially improve the overall utility of a budgeted bundle if it supplies a missing capability.

2.6 Problem Definition↩︎

In summary, the problem studied in this paper is defined as follows. Given a task request \(x\), structured service requirements \(\rho_x\), a small LLM agent profile \(A\), a service budget \(k\), and a large-scale skill service registry \(\mathcal{S}\), the system first obtains a candidate set \(\mathcal{C}_x\) through service discovery and then selects a budgeted skill service bundle \(B_k^\ast\) from this candidate set. The selected bundle should maximize task coverage, marginal service suitability, service complementarity, and execution suitability while satisfying context budget, tool permission, and risk constraints. It should also control redundancy, cost, and potential negative transfer.

This problem definition elevates agent skill selection from fixed top-\(k\) retrieval to requirement-conditioned, budget-controllable, and QoS-aware skill service recommendation and composition. Based on this formulation, the subsequent SkillSelect-Serve framework addresses three key questions: how to discover candidate skill services from a large-scale registry, how to jointly estimate skill-level marginal service suitability and bundle-level composition utility, and how to produce a skill service bundle suitable for small LLM agent execution through a budgeted QoS-aware decision mechanism. This formulation supports multiple deployment settings, including compact-budget, high-recall-budget, and aggressive-budget regimes, allowing the system to provide controllable recommendations according to actual context budgets and risk preferences.

3 Method: SkillSelect-Serve↩︎

Based on the problem definition above, this paper proposes SkillSelect-Serve, a budget-controllable and QoS-aware framework for Skill Service Recommendation and Composition designed for small LLM agents. Unlike conventional skill retrieval or skill routing methods, SkillSelect-Serve does not formulate skill selection as a fixed top-\(k\) ranking problem. Instead, it adopts a service-oriented discover–calibrate–project paradigm. It first transforms raw skill documents into Skill Service Profiles with explicit service attributes. It then uses a lightweight local Micro-Agent Requirement Planner to parse a natural-language task into structured service requirements. Next, it discovers candidate skill services from a large-scale Skill Service Registry. Over the candidate set, it jointly models skill-level marginal service suitability and bundle-level composition quality. Finally, through Budgeted QoS-aware Service Projection, it outputs a skill service bundle suitable for small LLM agents under a given service budget, context budget, and risk constraints.

The design of SkillSelect-Serve is guided by three principles. First, a skill should be modeled as a discoverable, composable, and constraint-aware service, rather than as a plain retrievable document. Second, the system should model service utility at two granularities. Skill-level marginal suitability is used to identify candidate services that are truly critical for the current task, whereas bundle-level calibration evaluates the coverage, complementarity, redundancy, cost, and risk of service compositions. Third, the final recommendation should be budget-controllable, because small LLM agents may operate under different context budgets, tool permissions, and risk preferences across deployment scenarios. Therefore, SkillSelect-Serve unifies task understanding, service discovery, dual-granularity service utility modeling, and budgeted QoS-aware decision-making within a service computing framework.

3.1 Framework Overview↩︎

Given a task request \(x\), a small LLM agent profile \(A\), a service budget \(k\), and a large-scale skill service registry \(\mathcal{S}\), SkillSelect-Serve aims to output a budgeted skill service bundle: \[B_k^\ast = \{s_{i_1}, s_{i_2}, \ldots, s_{i_m}\}, \quad B_k^\ast \subseteq \mathcal{S}, \quad |B_k^\ast| \leq k .\] Here, \(k\) denotes the maximum number of skill services that can be loaded in the current deployment scenario. Unlike fixed top-\(k\) retrieval, SkillSelect-Serve does not simply select the first \(k\) skills from a retrieval ranking. Instead, under the same service budget, it selects more useful skill services by considering task requirements, service profiles, marginal suitability, bundle-level calibration, and QoS constraints. This formulation supports different budget settings, including compact, high-recall, and aggressive modes, allowing the system to provide controllable recommendations according to the context budget and risk preference of the small LLM agent.

To achieve this goal, SkillSelect-Serve organizes the decision process as an end-to-end service computing pipeline, as shown in Fig. 1. First, the local micro-agent parses the raw task request \(x\) into structured service requirements \(\rho_x\), which explicitly represent the capabilities, tools, input-output types, hard constraints, and risk notes required by the task. Second, the discovery backbone retrieves a candidate set of skill services \(\mathcal{C}_x\) from the registry \(\mathcal{S}\) based on the task request and structured requirements, providing a high-recall candidate space for subsequent recommendation and composition. Third, the system estimates the marginal service suitability of each candidate service using label-free service features, and further performs bundle-level utility and hit calibration over candidate bundles. Finally, budgeted QoS-aware service projection selects the final bundle \(B_k^\ast\) from the candidate services under the given service budget \(k\), by jointly considering marginal suitability, bundle-level calibration, cost, risk, and redundancy control.

This layered design deliberately avoids assigning the entire decision process to any single module. The local micro-agent is responsible for parsing task requirements, but it does not directly output skill IDs. The discovery module narrows the search space, but it does not determine the final recommendation. The skill-level marginal calibrator identifies candidate services with the highest marginal value for the current task. The bundle-level calibrators estimate composition-level coverage, hit likelihood, redundancy, cost, and risk. The budgeted QoS-aware projection then constrains these estimates within the service budget, context budget, and risk range that the small LLM agent can afford. In this way, SkillSelect-Serve transforms skill selection from simple relevance ranking into an interpretable, deployable, and budget-controllable process of skill service recommendation and composition.

3.2 Skill Service Profiling↩︎

SkillSelect-Serve first transforms raw skill documents into structured Skill Service Profiles. For each skill \(s_i\), we construct the following service description: \[p_i = \langle id_i, name_i, desc_i, domain_i, tools_i, inputs_i, outputs_i, tags_i, cost_i, risk_i \rangle .\] Here, \(name_i\) and \(desc_i\) denote the skill name and textual description, respectively; \(domain_i\) denotes the domain to which the skill belongs; \(tools_i\) denotes the set of tools required to execute the skill; \(inputs_i\) and \(outputs_i\) denote the input and output types; \(tags_i\) denotes functional tags; \(cost_i\) denotes the context or token cost; and \(risk_i\) denotes the risk level or risk notes.

The purpose of this profiling step is not to construct a complete formal service contract. Rather, it extracts lightweight service attributes from semi-structured skill documents, enabling subsequent models to explicitly reason about tool dependencies, input-output compatibility, functional coverage, redundancy, cost, and risk. In other words, the Skill Service Profile elevates a skill from an unconstrained text object to a discoverable, comparable, composable, and constraint-aware service unit.

In implementation, the service profile can be obtained through rule-based extraction and lightweight text analysis. For example, tool dependencies can be identified from tool calls, code blocks, or keywords in the skill document. Input and output types can be inferred from file types, data structures, and task descriptions. Risk levels can be estimated from permissions, external calls, file modifications, network access, or high-risk keywords. Token cost can be approximated by the length of the skill document. These structured attributes are then used as service-level features for discovery, bundle construction, and composition modules.

3.3 Local Micro-Agent Requirement Planner↩︎

Natural-language task requests often imply multiple service requirements, including required capabilities, input-output formats, tool dependencies, execution constraints, and potential risks. If skill retrieval is performed only on the raw query, the model may mistake textual similarity for service suitability. Conversely, if an LLM is directly asked to select skill IDs from a large-scale registry, it may produce hallucinated skills, unreproducible choices, or selections that overlook QoS constraints. To address this issue, SkillSelect-Serve introduces a lightweight local Micro-Agent Requirement Planner as a task-to-service requirement interface rather than a final selector. Given a task request \(x\), the micro-agent outputs structured service requirements: \[\rho_x = \langle Cap_x, T_x, I_x, O_x, H_x, R_x \rangle .\] Here, \(Cap_x\) denotes the set of capabilities required by the task; \(T_x\) denotes potential tool requirements; \(I_x\) and \(O_x\) denote the input and output types, respectively; \(H_x\) denotes hard constraints, such as mandatory output formats, prohibited tools, or context limitations; and \(R_x\) denotes risk notes.

It is important to emphasize that the micro-agent does not output skill IDs or directly determine the final bundle. It only parses the natural-language task into structured service requirements and passes these requirements as requirement-conditioned features to subsequent service utility modeling modules. This design has two advantages. On the one hand, it leverages the ability of the small-model agent to interpret task semantics and implicit requirements. On the other hand, it avoids delegating the final discrete service selection entirely to an LLM, thereby reducing the risk of hallucination and unstable decisions. The final skill service bundle is selected over the actual candidate service set through skill-level marginal suitability estimation, bundle-level calibration, and budgeted QoS-aware projection.

In the subsequent composition stage, \(\rho_x\) is used to compute features such as capability coverage, tool matching, input-output matching, hard-constraint satisfaction, and risk awareness. As a result, the decision process of SkillSelect-Serve is no longer based solely on semantic matching between the query and skill text. Instead, it is explicitly conditioned on the service capabilities required by the task.

3.4 Candidate Skill Service Discovery↩︎

Since the skill service registry \(\mathcal{S}\) is large, directly enumerating all possible service compositions over the full service set is computationally infeasible. Therefore, SkillSelect-Serve first performs Candidate Skill Service Discovery to retrieve a high-quality candidate set from the full registry: \[\mathcal{C}_x = D(x,\rho_x,\mathcal{S}), \quad \mathcal{C}_x \subseteq \mathcal{S}, \quad |\mathcal{C}_x| \ll |\mathcal{S}|.\] The objective of the discovery module is to provide high-recall candidates, rather than to generate the final recommendation directly. In practice, it can employ lexical retrieval, dense retrieval, hybrid retrieval, and cross-encoder reranking. These methods first obtain candidate skill services from the large-scale registry and then pass the reranked top-\(n\) candidates to the composition module.

This design differs from conventional top-\(k\) retrieval in that the retrieval ranking is used only for candidate generation. The final output is not a fixed number of skills with the highest retrieval scores. Even if some skills rank highly when considered individually, they may not be appropriate for the final bundle because of functional redundancy, excessive cost, or risk mismatch. Conversely, some lower-ranked skills may improve the overall composition utility by supplying missing capabilities. Therefore, SkillSelect-Serve treats discovery as a high-recall filtering step before service composition, and postpones the final decision to the bundle-level composition stage.

3.5 Candidate Set and Budgeted Bundle Construction↩︎

After obtaining the candidate set \(\mathcal{C}_x\), SkillSelect-Serve does not enumerate the full skill service registry or simply return the top-\(k\) services in the retrieval ranking. Instead, it constructs a local decision space for budgeted recommendation over the candidate service set. This space contains two types of objects: individual candidate skill services, which are used to estimate skill-level marginal service suitability, and candidate service bundles, which are used to model bundle-level composition quality, redundancy, cost, and risk trade-offs.

Let the candidate set returned by the discovery backbone for task \(x\) be \[\mathcal{C}_x = \{s_1, s_2, \ldots, s_n\}.\] For each candidate service \(s_i \in \mathcal{C}_x\), the system retains its retrieval and reranking signals, service profile features, requirement-matching features, cost features, and risk features. These candidate services serve as the basic inputs for subsequent skill-level marginal suitability estimation, enabling the model to assess the marginal usefulness of each service under the current task and agent constraints.

To support bundle-level calibration and budget-aware trade-off analysis, SkillSelect-Serve further constructs a candidate bundle set over \(\mathcal{C}_x\): \[\mathcal{B}_x = \{B_1, B_2, \ldots, B_L\}, \quad B_l \subseteq \mathcal{C}_x .\] In the budget-controllable setting, candidate bundles can also be grouped by the service budget \(k\): \[\mathcal{B}_x^{(k)} = \{B_l \mid B_l \subseteq \mathcal{C}_x,\;|B_l| \leq k\}.\] Here, \(k\) denotes the maximum number of skill services that can be loaded in the current deployment scenario. Different values of \(k\) correspond to different recommendation modes, such as compact, high-recall, or aggressive modes. This design allows the system to select a small number of critical services under a strict context budget, while also supporting higher task coverage and recall under a larger budget.

Since the number of all possible subsets grows exponentially with the size of the candidate set, directly enumerating all combinations in \(\mathcal{C}_x\) is computationally infeasible. Therefore, we construct a diverse candidate bundle set that covers different service budgets, coverage patterns, and redundancy levels. Candidate bundles can be generated through multiple label-free strategies. Prefix-based bundles preserve strong ranking baselines; top-combination bundles explore combinations among high-scoring candidate services; low-redundancy bundles encourage functional complementarity; and stochastic bundles increase compositional diversity during training and calibration. These bundles provide training instances for bundle-level utility and hit calibration, and they also offer an analyzable composition space for subsequent QoS-aware projection.

Each candidate bundle \(B_l\) is represented as a bundle mask: \[\mathbf{m}_l \in \{0,1\}^{|\mathcal{C}_x|},\] where \(m_{l,i}=1\) indicates that candidate service \(s_i\) is included in bundle \(B_l\). Through the bundle mask, the system can compare service bundles of different sizes, compositions, and QoS profiles over the same candidate set. Accordingly, each bundle can be further characterized by bundle-level features, such as aggregated marginal suitability, service coverage, tool and input-output compatibility, domain diversity, selected-rank distribution, redundancy, token cost, and risk exposure.

It is important to note that curated labels or offline utility can be used during training to construct supervision signals for learning skill-level marginal suitability and bundle-level calibration functions. However, during testing and deployment, candidate service selection and bundle construction do not rely on ground-truth labels or oracle utility. All inference inputs are label-free features available at deployment time, including retrieval rank, reranker score, Skill Service Profile, structured requirement matching, tool and input-output compatibility, cost, risk, and redundancy signals. Therefore, the candidate construction process in SkillSelect-Serve supports bundle-level composition modeling while preserving a clean and deployable setting, avoiding the leakage of label-derived signals into the final recommendation decision.

3.6 Dual-granularity Service Utility Modeling↩︎

The core module of SkillSelect-Serve is Dual-granularity Service Utility Modeling, whose structure is shown in Fig. 2. This module expands the composition core in Fig. 1 into two complementary branches. On the one hand, skill-level marginal suitability estimation identifies the marginal suitability of each candidate skill service under the current task and agent constraints, namely whether the service truly supplies a missing capability required by the task. On the other hand, bundle-level utility and hit calibration evaluates the overall quality of a bundle composed of multiple services, including requirement coverage, service complementarity, redundancy, context cost, and risk exposure. Therefore, SkillSelect-Serve does not rely on a single retrieval score or a single bundle scorer. Instead, it integrates per-service marginal evidence with composition-level calibration signals, and finally produces a deployable skill service bundle through Budgeted QoS-aware Projection.

3.6.1 Skill-level Marginal Service Suitability↩︎

Given a task request \(x\), structured service requirements \(\rho_x\), an agent profile \(A\), and a candidate service \(s_i \in \mathcal{C}_x\), SkillSelect-Serve first estimates the marginal suitability of the service for the current task: \[p_i = f_{\mathrm{marg}}(x,\rho_x,s_i,A).\] Here, \(p_i\) denotes the probability or suitability score that skill service \(s_i\) is useful for the current task. This score is not a conventional textual relevance score. Instead, it is a fine-grained service suitability signal that integrates ranking signals, service profiles, and requirement matching. This branch corresponds to the upper part of Fig. 2, where each candidate service is encoded independently, while its suitability estimation is always conditioned on the same task requirements and agent profile.

In implementation, the input to \(f_{\mathrm{marg}}\) contains only label-free features available at deployment time, including retrieval rank, reranker score, service profile features, required-capability matching, tool matching, input-output compatibility, functional tag overlap, token cost, risk level, and constraint features associated with the agent profile. During training, curated positive labels can be used to construct supervision signals. During inference, however, the model does not access any is-positive labels, oracle utility, or label-derived symbolic utility. In this way, marginal service suitability serves as a deployable enhancement to service discovery: within the candidate set provided by the discovery backbone, it further identifies key services that are most likely to be useful for the task.

3.6.2 Bundle-level Utility and Hit Calibration↩︎

Estimating the marginal suitability of individual skill services alone is insufficient to fully characterize the quality of a service composition. Multiple high-scoring services may be functionally redundant, or they may collectively introduce excessive cost and risk. Conversely, services with moderate marginal scores may improve the overall bundle utility through complementarity. Therefore, SkillSelect-Serve further constructs a bundle-level calibration branch to estimate the overall quality of each candidate bundle \(B \subseteq \mathcal{C}_x\).

For each candidate bundle \(B\), the system computes bundle-level features: \[\phi(B,x,\rho_x,A),\] including bundle size, aggregated marginal suitability, service coverage, tool and input-output compatibility, domain diversity, service redundancy, token cost, risk exposure, selected-rank distribution, and requirement-conditioned features. Based on these features, the system learns two calibration functions: \[\hat{U}_B = f_{\mathrm{util}}(\phi(B,x,\rho_x,A)), \quad \hat{H}_B = f_{\mathrm{hit}}(\phi(B,x,\rho_x,A)).\] Here, \(\hat{U}_B\) denotes the bundle-level utility estimate, and \(\hat{H}_B\) denotes the likelihood that the bundle contains a useful service. Unlike the previous oracle symbolic utility, these two calibrators use only label-free bundle features during inference. Their role is not to replace skill-level marginal suitability, but to provide composition-level calibration for the final projection, enabling the system to explicitly control trade-offs among coverage, redundancy, cost, and risk. This branch corresponds to the lower part of Fig. 2. Its core function is to capture composition effects that cannot be represented by skill-level marginal suitability alone, such as service complementarity, accumulated redundancy, context cost, and risk exposure.

3.6.3 Training Signals and Deployable Feature Space↩︎

SkillSelect-Serve can use two types of supervision signals during training. The first is skill-level supervision, which is used to train \(f_{\mathrm{marg}}\) to determine whether a candidate skill service is useful for the current task. The second is bundle-level supervision, which is used to train \(f_{\mathrm{util}}\) and \(f_{\mathrm{hit}}\) to estimate the utility and hit likelihood of candidate bundles. It is important to emphasize that these supervision signals are used only for training or upper-bound analysis. During inference, all model inputs are derived from label-free service features available at deployment time.

This design explicitly separates oracle-derived utility from deployable decision-making. Offline utility can help define training objectives or analyze the candidate-space upper bound, but the final system does not directly use oracle utility to select bundles. As a result, SkillSelect-Serve preserves deployability, which is critical for service computing systems: in actual deployment, the model relies only on task requests, structured requirements, retrieval and reranking scores, service profiles, requirement matching, cost, risk, and redundancy signals.

3.7 Budgeted QoS-aware Service Projection↩︎

After obtaining the skill-level marginal suitability signals and bundle-level calibration signals, SkillSelect-Serve generates the final skill service bundle through Budgeted QoS-aware Service Projection. The detailed procedure of this stage is illustrated in Fig. 3. The objective of this stage is not to select the highest-scoring service set in an unconstrained space. Rather, it aims to select the service bundle that is most suitable for the current small LLM agent under a given service budget \(k\), context budget, risk threshold, and redundancy-control requirement.

For a candidate bundle \(B \subseteq \mathcal{C}_x\), the projection score is defined as \[\begin{align} \mathrm{Score}_k(B) = & \lambda_1 \, \mathrm{Agg}(\{p_i \mid s_i \in B\}) + \lambda_2 \hat{U}_B + \lambda_3 \hat{H}_B \\ & - \lambda_4 \mathrm{Red}(B) - \lambda_5 \mathrm{Cost}(B) - \lambda_6 \mathrm{Risk}(B), \end{align}\] subject to \[|B| \leq k,\qquad \mathrm{Cost}(B) \leq C_A,\qquad \mathrm{Risk}(B) \leq R_A.\] Here, \(\mathrm{Agg}(\{p_i\})\) denotes the aggregation of skill-level marginal suitability scores within the bundle, which can be implemented by top-\(k\) aggregation, weighted summation, or Noisy-OR. \(\hat{U}_B\) and \(\hat{H}_B\) are produced by the bundle-level utility and hit calibrators, respectively. \(\mathrm{Red}(B)\), \(\mathrm{Cost}(B)\), and \(\mathrm{Risk}(B)\) denote redundancy, context cost, and risk penalties. The final output is then given by \[B_k^\ast = \arg\max_{B \subseteq \mathcal{C}_x,\;|B| \leq k} \mathrm{Score}_k(B).\]

In practical deployment, SkillSelect-Serve supports different service-budget regimes, corresponding to the parallel operating points shown on the right side of Fig. 3. Compact mode uses a small budget, for example \(k=3\), and is intended for lightweight recommendation under strict context budgets. Final or high-recall mode uses a moderate budget, for example \(k=5\), to improve recall and utility while maintaining acceptable context cost. Aggressive mode uses a larger budget, for example \(k=6\), for scenarios that require higher recall and can tolerate greater service cost and risk exposure. These modes do not correspond to different models; rather, they are different instantiations of the same budgeted projection mechanism under different budget constraints.

This projection design enables SkillSelect-Serve to explicitly expose the trade-offs among budget, recall, utility, cost, and risk. Compared with fixed top-\(k\) retrieval, SkillSelect-Serve does not simply follow the original retrieval ranking under the same budget. Instead, it reselects services according to marginal suitability and bundle-level calibration. In contrast to previous oracle-calibrated symbolic projection methods, the current clean and deployable projection mechanism uses only label-free deployable signals during inference. Therefore, the final recommendation produced by SkillSelect-Serve preserves the controllability of service composition while avoiding the introduction of label-derived utility into deployment-time decision-making.

3.8 Compact Skill Package for Diagnostic Execution↩︎

As shown in the deployment output part of Fig. 3, the main output of SkillSelect-Serve is a budgeted skill service bundle rather than a conventional ranked list. This bundle can be used as the execution-context input for a small LLM agent, or it can be further converted into a task-specific compact skill package. For each selected skill service, the system can either retain the full skill context or perform extractive adaptation to keep only the fragments most relevant to the current task, such as key execution steps, tool-use instructions, input-output constraints, and risk notes. This module primarily serves as a downstream execution interface for diagnosing the usability of the recommended skill services in small-model execution scenarios.

Given the final bundle \(B^\ast\), the compact package can be represented as \[P_x = \mathrm{Adapt}(x, B^\ast, C_A),\] where \(\mathrm{Adapt}(\cdot)\) selects task-relevant fragments under the context budget \(C_A\) and removes redundant or weakly relevant content. The goal of this step is to provide the small LLM agent with sufficient service knowledge to complete the task, while avoiding redundant or distracting context.

It should be noted that the main focus of this paper is skill service composition, namely how to select a compact, complementary, and low-redundancy variable-size bundle. Compact package generation is a downstream execution interface that converts the composition result into a context representation consumable by the small-model agent. Subsequent execution feedback can further be used to update service reliability, adjust QoS estimates, or improve preference-aware composition, which we regard as extensions toward a closed-loop service computing system.

3.9 Summary↩︎

In summary, SkillSelect-Serve reformulates agent skill selection from fixed-size top-\(k\) retrieval into requirement-conditioned, budget-controllable, and QoS-aware skill service recommendation and composition. Built upon the Skill-as-a-Service representation, the framework uses a local micro-agent to make the service requirements implicit in a task explicit, and performs dual-granularity service utility modeling over the high-recall candidate set provided by the discovery backbone. Unlike methods that rely only on the original retrieval rank or a single bundle scorer, SkillSelect-Serve jointly estimates skill-level marginal service suitability and bundle-level composition quality, and then constrains the model outputs through budgeted QoS-aware projection into a decision space where service budget, context cost, risk, and redundancy are controllable.

This design assigns clear and complementary roles to different modules. The micro-agent parses the implicit capability, tool, input-output, and risk requirements in a natural-language task. The retrieval and reranking modules discover candidate skill services from the large-scale registry. The skill-level marginal calibrator identifies candidate services with the highest marginal value under the same budget. The bundle-level calibrators estimate composition-level utility, hit likelihood, and QoS trade-offs. The budgeted projection ensures that the final recommendation satisfies the service budget, context budget, and risk preferences of the small LLM agent. Therefore, the goal of SkillSelect-Serve is neither to provide the agent with more skills nor to claim that the smallest bundle is always optimal. Instead, it aims to deliver a more effective, controllable, and deployable skill service bundle under a given budget.

4 Experimental Setup↩︎

This section presents the experimental setup, including the Skill Service Registry, task data, compared methods, evaluation metrics, and implementation details. The experimental design is centered on the core question of this paper: under a given service budget and small-agent constraints, whether SkillSelect-Serve can select Skill Services more effectively than fixed top-\(k\) retrieval, while providing interpretable trade-offs among recommendation quality, cost, risk, and downstream execution.

4.1 Skill Service Registry and Task Queries↩︎

We evaluate SkillSelect-Serve on a large-scale Skill Service Registry. The registry contains 35,353 deduplicated skill items, each of which is transformed into a structured Skill Service Profile. The profile includes functional descriptions, tool dependencies, input-output types, functional tags, token cost, risk level, and other QoS-related attributes. The task set contains 586 natural-language task queries, among which 577 queries have evaluable curated positive skill interactions. Overall, the dataset contains 717 positive interactions and 52,647 query-skill training pairs.

Unlike conventional tool-use benchmarks that mainly focus on the correctness of API calls or tool invocation procedures [4], [5], this paper focuses on budgeted service recommendation and composition in a large-scale skill service ecosystem. Each query corresponds to a small-agent task, for which the system needs to discover candidate skill services from the registry and select a skill service bundle under a given service budget. Since the focus of this work is the composition and recommendation stage, all compared methods use the same candidate discovery backbone, ensuring that differences among methods mainly arise from service selection and composition decisions rather than differences in the candidate pool.

4.2 Compared Methods↩︎

We compare four categories of methods.

The first category consists of fixed-budget retrieval baselines. Top-1 Fixed, Top-3 Fixed, and Top-5 Fixed directly use the ranked results returned by the discovery backbone and select the top 1, 3, or 5 skill services, respectively. They represent the conventional top-\(k\) skill retrieval or routing paradigm, where a fixed-length recommendation list is generated according to the relevance score of each individual skill.

The second category is a heuristic adaptive baseline. Heuristic VarSize adaptively determines the bundle size according to candidate ranking scores, redundancy, and thresholding rules. This method does not learn service utility, but it serves as a strong variable-size baseline for examining whether the learned selector provides gains beyond manually designed rules.

The third category includes learning-based ablation variants. Pure Neural Bundle Composer uses only a neural bundle scorer to estimate candidate bundle quality. Dual Bundle Calibrator estimates utility and hit likelihood at the bundle level, allowing us to examine the contribution of bundle-level calibration to composition quality. In addition, Skill-level Marginal Calibrator estimates the marginal service suitability of each candidate skill service for the current task. This branch is a key component of the clean and deployable system proposed in this paper.

The fourth category includes different budget regimes of SkillSelect-Serve. SkillSelect-Serve Compact@3 produces compact recommendations under a service budget of \(k=3\), making it suitable for scenarios with strict context budgets. SkillSelect-Serve Final@5 produces the default high-recall recommendation under \(k=5\). SkillSelect-Serve Aggressive@6 further improves recall and mean utility under \(k=6\), while allowing higher context overhead and potential risk exposure. These three settings are not different models. Rather, they are different instantiations of the same budgeted QoS-aware service projection mechanism under different service budgets.

In addition, we report the candidate-space upper bound to analyze the theoretical limit of the candidate space provided by the current discovery backbone. This upper bound is not a deployable method. Instead, it is used to answer how much recall the composition and recommendation stage can achieve within the current candidate pool, and whether further improvement primarily depends on stronger discovery.

4.3 Evaluation Metrics↩︎

We evaluate the compared methods from four perspectives: recommendation quality, composition quality, QoS trade-offs, and execution behavior.

Bundle Recall measures whether the recommended bundle contains at least one curated positive skill service. For a task \(x\) and a recommended bundle \(B\), the recommendation is considered a hit if \(B\) contains a positive service for the task. This metric reflects whether the system can retrieve a critical skill service under a limited service budget.

Mean Utility measures the overall offline utility of a recommended bundle by jointly considering positive hits, task coverage, redundancy, cost, and diversity. It should be emphasized that this utility is used only for offline evaluation, rather than as an oracle decision signal during deployment. During inference, SkillSelect-Serve uses only label-free service features, such as retrieval rank, reranker score, service profiles, requirement matching, tool and input-output compatibility, cost, risk, and redundancy signals.

Average Bundle Size denotes the average number of skill services recommended for each query. For fixed-budget baselines, this value is equal to the fixed budget \(k\). For heuristic and learned methods, it reflects the actual recommendation cost.

Redundancy measures the degree of functional overlap among skill services within a bundle. Lower redundancy usually indicates less wasted context. However, excessively low redundancy may also correspond to insufficient coverage. Therefore, redundancy should be analyzed jointly with recall and utility.

Cost and Risk Metrics include average service cost, average selected rank, and high-risk services per query. These metrics are used to analyze deployment trade-offs under different budget regimes. We do not interpret them as indicators of single-dimensional superiority. Instead, they explain how SkillSelect-Serve exhibits different cost and risk exposure patterns in compact, high-recall, and aggressive settings.

In the diagnostic execution study, we further report pass rate, average judge score, and non-loss behavior. This experiment is intended to diagnose whether the recommended skill package can assist small-agent execution, rather than to serve as the main state-of-the-art claim of this paper.

4.4 Implementation Details↩︎

The candidate discovery backbone combines lexical retrieval, dense retrieval, and reranking signals. Lexical retrieval can be supported by BM25 [9]; dense semantic matching can be based on sentence-level representation learning [10]; and reranking can employ cross-encoder-style relevance modeling [11]. All composition methods use the same candidate set, which controls for differences in discovery and keeps the experimental focus on budgeted service recommendation and composition.

The marginal service suitability estimator in SkillSelect-Serve takes query-skill-level label-free features as input, including retrieval rank, reranker score, service profile features, requirement-matching features, tool and input-output compatibility, cost, and risk. The bundle-level calibrators estimate bundle utility and hit likelihood using features of candidate bundles, such as aggregated marginal suitability, coverage, redundancy, cost, risk, and rank distribution. During training, curated positive labels can be used to construct supervision signals. During inference, however, the model does not use labels, oracle utility, or label-derived symbolic utility. The calibrators adopt gradient-boosting-style models [12], which are well suited to nonlinear feature interactions and structured service features.

4.5 Artifact Availability↩︎

To support reproducibility, we will release the preprocessing scripts, service-profile construction code, evaluation scripts, and anonymized task-level prediction outputs upon publication. The current arXiv version includes the full experimental protocol, metric definitions, and aggregate results. The raw skill registry contains heterogeneous skill documents collected and normalized for research evaluation; before public release, we will remove private identifiers, unsafe execution traces, and any content that may violate redistribution constraints.

5 Experimental Results↩︎

This section answers five research questions. RQ1 examines whether SkillSelect-Serve outperforms fixed top-\(k\) retrieval under the same service budget. RQ2 analyzes the contribution of different modeling granularities. RQ3 explains the system bottleneck through candidate-space upper-bound analysis. RQ4 studies the trade-offs among budget, cost, risk, and scalability. RQ5 conducts a small-agent execution diagnostic to analyze the relationship between offline recommendation quality and actual execution utility.

5.1 RQ1: Does SkillSelect-Serve Improve Budgeted Skill-Service Recommendation?↩︎

Table 1 reports the main recommendation results. Compared with fixed top-\(k\) baselines, SkillSelect-Serve substantially improves bundle recall and mean utility under the same service budget.

Fig. 4 (a) visualizes the same-budget comparisons in Table 1. In the compact setting with \(k=3\), SkillSelect-Serve Compact@3 improves recall from 0.8163 achieved by Top-3 Fixed to 0.8700, while increasing mean utility from 0.6333 to 0.6901. Since the two methods use the same budget, this improvement cannot be attributed to loading more skills. Instead, it results from more accurate marginal service suitability estimation.

In the high-recall setting with \(k=5\), SkillSelect-Serve Final@5 improves recall from 0.8492 achieved by Top-5 Fixed to 0.8873, and increases mean utility from 0.6672 to 0.7078. This result shows that SkillSelect-Serve can select more useful Skill Services under the same context budget, rather than simply following the retrieval rank.

Heuristic VarSize achieves lower redundancy, indicating that manually designed rules can reduce some redundant services. However, its recall and mean utility are both lower than those of SkillSelect-Serve Final@5. Aggressive@6 achieves the highest recall and mean utility, but it also requires a larger bundle size. Therefore, SkillSelect-Serve should not be interpreted as a single “most compact” strategy. Rather, it is a budget-controllable service recommendation framework: Compact@3 is suitable for strict-budget scenarios, Final@5 serves as the default high-recall setting, and Aggressive@6 is appropriate when a larger context cost is acceptable.

5.2 RQ2: Which Modeling Granularity Matters?↩︎

Table 2 presents the ablation results of different model variants. The goal of this experiment is to analyze the respective contributions of skill-level marginal suitability and bundle-level calibration.

Pure Neural Bundle Composer achieves a recall of 0.7920, indicating that relying only on a neural bundle scorer is insufficient for reliably identifying critical services. Dual Bundle Calibrator improves recall to 0.8354, suggesting that bundle-level utility and hit calibration can improve the estimation of composition quality. However, the main improvement comes from skill-level marginal service suitability. SkillSelect-Serve Compact@3 achieves a recall of 0.8700 with a bundle size of 3, while SkillSelect-Serve Final@5 further improves recall to 0.8873.

These results show that the core of SkillSelect-Serve is not a single bundle scorer, but a dual-granularity design. Skill-level marginal suitability acts as a fine-grained service discovery enhancement, identifying candidate services that are truly critical for the current task. Bundle-level calibration, in contrast, serves as a service composition quality estimator, analyzing trade-offs among coverage, redundancy, cost, and risk. Together, these two components support the final Budgeted QoS-aware Service Projection.

5.3 RQ3: How Close Is SkillSelect-Serve to the Candidate-Space Upper Bound?↩︎

To determine whether the current system bottleneck lies in discovery or in composition and recommendation, we further compute the candidate-space upper bound. Table 3 reports the upper-bound recall under different candidate-pool sizes.

Fig. 4 (b) further explains the source of the remaining recall gap. The candidate-space upper-bound recall increases rapidly from Top-1 to Top-20, but gradually saturates beyond Top-20. SkillSelect-Serve Final@5 achieves a recall of 0.8873, which matches the Top-20 candidate-space upper bound and is close to the Top-100 upper bound of 0.8925. This result indicates that, within the candidate space provided by the current discovery backbone, the composition and projection stages already approach the attainable recall limit. Therefore, further recall improvement is more likely to require stronger candidate discovery, rather than only continued tuning of the bundle composition module.

This analysis also explains why this paper does not attempt to force recall beyond 90% within the current candidate space. For a large-scale Skill Service Registry, system performance is jointly determined by discovery and composition. When the candidate space does not contain a positive service, no downstream composition model can recover that service. Therefore, upper-bound analysis provides an important basis for locating modular bottlenecks in service computing systems.

5.4 RQ4: What Are the Budget, Cost, Risk, and Scalability Trade-offs?↩︎

Beyond recall and utility, a service recommendation system must also account for deployment cost and risk. Table 4 summarizes the efficiency and risk characteristics under different budget regimes.

5pt

Fig. 5 visualizes the trade-offs among budget, cost, risk, and utility summarized in Table 4. Since the fixed top-\(k\) baselines directly follow the retrieval prefix, they exhibit relatively low average service cost, but their mean utility is also comparatively limited. In contrast, SkillSelect-Serve forms a controllable operating frontier. Compact@3 provides a lower-budget choice with moderate cost and risk exposure. Final@5 serves as a balanced default operating point, improving utility and recall at an acceptable additional cost. Aggressive@6 further improves recall and utility, but it also introduces higher service cost and greater high-risk exposure. These results indicate that SkillSelect-Serve should not be interpreted as a single method that dominates all QoS metrics simultaneously. Rather, it provides budget-controllable deployment choices for small LLM agents under different context, cost, and risk preferences.

This trade-off is particularly important for small LLM agents. For tasks with strict context budgets or low-risk requirements, Compact@3 is an appropriate choice. For more complex tasks requiring broader coverage, Final@5 provides a stronger default setting. For exploratory scenarios or applications with high recall demands, Aggressive@6 is more suitable. Therefore, SkillSelect-Serve is better understood as a budget-controllable service recommendation framework rather than a fixed output strategy.

5.5 RQ5: What Happens in Downstream Small-Agent Execution?↩︎

Finally, we conduct a diagnostic execution study to analyze whether the recommended skill package can assist small-agent execution. This experiment is not intended to demonstrate that SkillSelect-Serve comprehensively outperforms top-\(k\) baselines on all downstream execution metrics. Rather, it aims to diagnose the relationship between offline recommendation quality and execution utility.

3pt

The results show that skill packages combined with the plan adapter improve pass rate compared with the no-skill baseline. SkillSelect-Serve Compact@3 + Plan Adapter achieves a pass rate of 0.4000, outperforming both the no-skill baseline at 0.3143 and Top-3 + Plan Adapter at 0.3714. However, Top-3 + Plan Adapter obtains a slightly higher average judge score than SkillSelect-Serve. This observation indicates that better offline skill-service recommendation does not automatically translate into uniformly better downstream execution.

This finding reveals an important recommendation–execution gap. Offline curated positive labels and relevance-oriented utility can measure whether a skill is relevant, but they cannot fully capture planning quality, prompt sensitivity, context interaction, and execution robustness in real execution processes. In the context of a service-oriented agent ecosystem, this result has practical implications: service discovery and service recommendation are necessary, but further improving small-agent execution requires execution-aware service utility learning, runtime feedback, and adaptive service reliability modeling.

5.6 Case Studies↩︎

To further understand the above observations, we analyze several representative cases.

The first case is a success case. In this task, fixed Top-3 retrieval returns multiple skill services that are semantically similar but functionally redundant. In contrast, SkillSelect-Serve Compact@3 selects a lower-ranked service with critical marginal usefulness, thereby supplying the file-processing or data-transformation capability required by the task. This case shows that marginal service suitability can identify key services that are easily overlooked by retrieval rank alone.

The second case is a counter-case. In some execution tasks, Top-3 retrieval returns a generic executable service that may not achieve the highest offline utility, but can still provide a more direct execution path for the small agent when combined with the plan adapter. This explains why Top-3 + Plan Adapter remains competitive in terms of judge score.

The third case is a context pollution case. In high-recall settings, Final@5 or Aggressive@6 can improve bundle recall, but the additionally introduced services may increase the context burden and interfere with small-agent execution. This further indicates that budgeted recommendation should incorporate execution-aware feedback, rather than optimizing offline recall alone.

Overall, the case studies are consistent with the quantitative results. SkillSelect-Serve can better identify critical Skill Services under the same budget and approaches the candidate-space upper bound in the high-recall setting. However, downstream execution is also affected by planning, adaptation, and context interaction. These findings provide a clear direction for future research on execution-aware Skill Service Composition.

6 Discussion↩︎

This section further discusses the design choices, empirical behavior, and system-level implications of SkillSelect-Serve. Unlike Section 6, which focuses on quantitative comparisons, this section examines what these results imply for building deployable Skill Service Recommendation and Composition systems. Specifically, we discuss five questions: what same-budget improvement indicates; why dual-granularity utility modeling is necessary; whether the current system bottleneck lies in discovery or composition; how QoS, clean deployability, and execution diagnostics should be interpreted; and what these findings imply for service-oriented agent ecosystems.

6.1 What Does Same-budget Improvement Tell Us?↩︎

The main results in Table 1 show that the core benefit of SkillSelect-Serve comes from same-budget service selection, rather than from simply increasing the number of loaded skills. In the compact setting with \(k=3\), SkillSelect-Serve Compact@3 uses the same service budget as Top-3 Fixed, yet improves bundle recall from 0.8163 to 0.8700 and mean utility from 0.6333 to 0.6901. In the high-recall setting with \(k=5\), SkillSelect-Serve Final@5 also uses five services, but improves recall from 0.8492 to 0.8873 and mean utility from 0.6672 to 0.7078 over Top-5 Fixed. This comparison rules out the explanation that the model merely loads more skills, and instead indicates that SkillSelect-Serve learns a more effective service selection signal.

This point is particularly important for small LLM agents. For such agents, the service budget is not merely an experimental cutoff, but an operational constraint in actual deployment. Each Skill Service inserted into the prompt consumes context window space and introduces tool instructions, execution steps, examples, constraints, and risk notes. Adding more skills may improve task coverage, but it may also introduce redundant information, conflicting procedures, or context pollution. Therefore, in the small-agent setting, the appropriate evaluation protocol is not to compare recall in an unconstrained manner, but to assess whether a system can select Skill Services with higher marginal value under the same service budget.

This result also suggests that SkillSelect-Serve should not be understood as a selector with a fixed output size. Compact@3, Final@5, and Aggressive@6 are operating points of the same system under different service budgets. Compact@3 is more suitable for strict context budgets or low-cost scenarios. Final@5 serves as a high-recall default setting. Aggressive@6 further improves recall and utility, but requires accepting a higher context cost. In other words, the key objective of SkillSelect-Serve is not to claim a globally optimal bundle size, but to provide a budget-controllable recommendation mechanism that can select an appropriate service budget according to the agent profile and deployment constraints.

6.2 Why Does Dual-granularity Modeling Work?↩︎

The ablation results in Table 2 show that Skill Service Recommendation involves two decision problems at different granularities. The first is service identification: identifying which individual services in the candidate set are truly useful for the current task. The second is service composition: determining whether multiple services can form a bundle with sufficient coverage, controllable redundancy, and acceptable cost and risk. Modeling only one of these granularities is insufficient.

Empirically, Pure Neural Bundle Composer achieves a recall of 0.7920, indicating that relying only on a bundle-level neural score is insufficient for reliably recovering the key services required by the task. Dual Bundle Calibrator improves recall to 0.8354, suggesting that bundle-level utility and hit calibration can improve composition-quality estimation. However, the main improvement comes from skill-level marginal suitability: Compact@3 reaches a recall of 0.8700, and Final@5 further improves recall to 0.8873. This progression shows that bundle-level calibration helps characterize composition quality, but the decisive factor behind same-budget improvement is accurate identification of marginally useful Skill Services at the query-service level.

This result highlights the necessity of the dual-granularity design. The skill-level marginal suitability estimator answers whether a candidate service is useful for the current task. The bundle-level calibrator answers whether a set of services forms a reasonable composition. The former is closer to a fine-grained enhancement of service discovery, whereas the latter is closer to service composition quality estimation. They address different failure modes. If a critical service is not identified, a downstream bundle scorer can hardly recover it. If several high-scoring services are redundant or too costly, individual service scores alone cannot guarantee a usable final bundle.

Therefore, the methodological contribution of SkillSelect-Serve is not the simple stacking of multiple scorers. Instead, it explicitly decomposes service identification and service composition. The skill-level branch improves the identification of critical services. The bundle-level branch provides composition-level calibration for coverage, redundancy, cost, and risk. Budgeted QoS-aware Projection then converts these two types of signals into the final service bundle under a given budget. This structure is consistent with the discovery–composition–recommendation hierarchy in service computing, and it also explains why same-budget improvement is more convincing than gains from a purely variable-size heuristic.

6.3 Where Is the Current System Bottleneck?↩︎

The candidate-space upper-bound analysis in Table 3 further shows that the current system bottleneck no longer lies entirely in the composition layer. The Top-20 candidate-space upper bound is 0.8873, and the Top-100 upper bound is 0.8925, while SkillSelect-Serve Final@5 already achieves 0.8873. This means that, within the candidate space retrieved by the current discovery backbone, Final@5 essentially reaches the attainable limit of the Top-20 candidate space.

This finding has two implications. First, it indicates that SkillSelect-Serve has strong service selection capability within a given candidate space. Once a critical Skill Service has entered the candidate set, Final@5 is highly likely to include it in the final bundle under a limited service budget. Second, it suggests that further recall improvement will increasingly depend on candidate discovery. If a positive service is not retrieved by the discovery stage, neither the marginal estimator nor the bundle-level composer can recover it from a nonexistent candidate set.

This analysis moves the empirical conclusion beyond the observation that one selector obtains a higher score. Instead, it provides a localization of the system bottleneck. For a large-scale Skill Service Registry, overall performance is jointly determined by service profiling, candidate discovery, utility estimation, and final projection. Upper-bound analysis separates the responsibility boundaries between discovery and composition: the current recommendation and composition layer already makes substantial use of the available candidate space, while further improvement requires better service indexing, requirement-service matching, dense retrieval, or reranking, rather than simply increasing the bundle size.

This conclusion also explains why this paper does not frame its objective as blindly exceeding 90% recall under the current setting. The theoretical ceiling of the current candidate space is already close to 0.887–0.893. Rather than pursuing a single numerical improvement, it is more valuable to identify the module that truly limits system performance and to provide a clear direction for subsequent discovery-oriented optimization.

6.4 How Should QoS and Deployability Be Interpreted?↩︎

The QoS results of SkillSelect-Serve should be interpreted as operating trade-offs rather than as a single point that dominates all metrics. Table 4 shows that Final@5 and Aggressive@6 improve recall and mean utility, but they may also introduce higher service cost and greater risk exposure. Compact@3 is more conservative in terms of budget and is suitable for scenarios with strict context constraints. Final@5 is better suited as a default setting when higher task coverage is required. Aggressive@6 is appropriate when high recall is prioritized and higher context cost is acceptable.

This trade-off is necessary for small-agent deployment. In real systems, there is usually no fixed strategy that is simultaneously optimal in terms of recall, cost, risk, and redundancy. Different tasks, agent profiles, and risk preferences correspond to different operating points. Therefore, the role of QoS-aware projection is not to output a bundle that is universally optimal across all scenarios. Instead, it explicitly exposes service budget, cost, risk, and redundancy to the system, enabling the upper-level agent controller or application developer to select an appropriate configuration according to deployment objectives.

Deployability also requires a strict distinction among training supervision, upper-bound analysis, and inference-time decision-making. During development, oracle-calibrated utility can be used to analyze whether high-quality compact bundles exist in the candidate space and to understand the system ceiling. However, if this utility contains label-derived signals, it cannot be used as a decision input during testing or deployment. The main experiments in this paper follow a clean and deployable setting: during inference, the system uses only deployment-visible features, including retrieval rank, reranker score, Skill Service Profile, requirement matching, tool and input-output compatibility, cost, risk, and redundancy. Curated positives and offline utility are used only for training supervision or upper-bound analysis, and they do not directly participate in final bundle selection.

This treatment makes the main claim of this paper more conservative, but also more credible. We do not claim that an optimal compact bundle can be selected by using oracle utility. Instead, the clean results show that, without access to oracle labels, SkillSelect-Serve can still substantially outperform fixed top-\(k\) baselines under the same service budget and approach the candidate-space upper bound in the high-recall setting. This distinction is particularly important for service computing research, because a service recommendation system should not only be effective on offline metrics, but also maintain clear information boundaries among training, validation, and deployment.

6.5 What Does the Execution Diagnostic Reveal?↩︎

The diagnostic execution study in Table 5 reveals a clear but explainable gap between offline skill-service recommendation quality and downstream small-agent execution utility. In the retrieval-sensitive setting, the pass rate of No Skill is 0.3143, while SkillSelect-Serve Compact@3 + Plan Adapter improves it to 0.4000, and Top-3 + Plan Adapter achieves 0.3714. This result shows that skill packages and the plan adapter can indeed improve the execution pass rate of the small-model agent compared with no skill input. However, Top-3 + Plan Adapter obtains a slightly higher average judge score than SkillSelect-Serve, indicating that a strong retrieval baseline remains competitive once it is provided with the same planning interface.

This result should not be interpreted as contradicting the offline recommendation results. Offline recommendation primarily evaluates whether a bundle contains curated positive skills and whether it improves coverage and utility. Execution, in contrast, is also affected by prompt organization, plan quality, model generation capability, task decomposition, and context interaction. A bundle with higher offline utility may not always translate into a smoother execution path in a concrete prompt. Conversely, some generic but executable skills may not be optimal according to offline ranking, yet may be easier for a small model to use directly.

Therefore, the value of the execution diagnostic is not to claim that SkillSelect-Serve already dominates all execution baselines. Rather, it reveals a recommendation–execution gap. Offline relevance-oriented labels can indicate which skills are related to a task, but they cannot fully encode the operability, composability, and contextual stability of these skills in an execution trajectory. For service-oriented agent ecosystems, this finding suggests that the recommendation layer is necessary, but it is not yet a complete execution loop. Future systems should further incorporate execution-aware service utility, learning from runtime outcomes, failure traces, plan quality, and user feedback to determine which Skill Services genuinely improve downstream execution.

6.6 Implications for Service-oriented Agent Ecosystems↩︎

Taken together, the results of SkillSelect-Serve suggest that, as LLM agent skill libraries continue to expand, skills should no longer be managed as ordinary text fragments. Instead, they should be modeled as discoverable, comparable, composable, and constraint-aware Skill Services. A mature Skill Service Registry should not only store skill descriptions, but also maintain service attributes such as functionality, tools, input-output assumptions, cost, risk, requirement matching, and execution feedback.

Within this ecosystem, SkillSelect-Serve serves as the recommendation and composition layer. The local Micro-Agent Requirement Planner makes task requirements explicit, but does not directly select skill IDs. The discovery backbone narrows the candidate space, but does not determine the final bundle. The skill-level marginal estimator identifies critical services. The bundle-level calibrator estimates composition quality. Budgeted QoS-aware Projection then produces a deployable bundle according to the service budget and QoS constraints. This modular division of responsibilities improves interpretability and clarifies future extensions: stronger discovery can increase the candidate-space ceiling, execution feedback can improve service utility estimation, and richer QoS modeling can support more sophisticated deployment strategies.

More broadly, improving the capability of small LLM agents cannot rely solely on longer contexts or larger models. As reusable skill ecosystems become an important infrastructure for agent systems, the central challenge will shift toward service-level governance: how to profile skills, discover candidates, estimate marginal usefulness, compose services, control QoS, and update service reliability from execution feedback. SkillSelect-Serve shows that budget-controllable Skill Service Recommendation is a critical intermediate layer in this process. It transforms a large-scale skill library from a passive text repository into a service-oriented capability space that can be effectively used by small-model agents.

The experimental results support a more restrained but more deployable conclusion. SkillSelect-Serve does not obtain its gains by loading more skills. Instead, it selects Skill Services more effectively under a given service budget. Through dual-granularity modeling, it distinguishes service identification from service composition. Through upper-bound analysis and execution diagnostics, it reveals the current system boundaries and future directions. In this way, agent skill selection is systematically formulated as a requirement-conditioned, budget-controllable, and QoS-aware Skill Service Recommendation and Composition problem, rather than as conventional fixed top-\(k\) retrieval.

6.7 Limitations and Threats to Validity↩︎

The conclusions of this paper should be interpreted within the following boundaries. First, the offline evaluation is mainly based on curated positive skill interactions and bundle-level utility. These signals can measure whether a recommended bundle covers task-relevant Skill Services, but they are not fully equivalent to downstream execution utility. To avoid overinterpretation, this paper positions the small-agent execution experiment as a diagnostic study rather than as a downstream execution state-of-the-art claim. The purpose of this experiment is to verify whether the skill package can be consumed by a small LLM agent and to reveal the gap between offline recommendation quality and actual execution behavior.

Second, the final performance of SkillSelect-Serve is constrained by the candidate space provided by the discovery backbone. When a critical Skill Service is not retrieved into the candidate set, neither the marginal suitability estimator nor the bundle-level calibrator can recover it. For this reason, this paper uses candidate-space upper-bound analysis to distinguish the discovery bottleneck from the composition bottleneck. The results show that Final@5 already approaches the current Top-20 candidate-space upper bound, indicating that further recall improvement requires advances in Skill Service Discovery rather than merely increasing the complexity of the composer.

Third, the QoS results in this paper should be understood as operating trade-offs among budget, recall, cost, risk, and redundancy, rather than as a single point that is optimal across all metrics. Compact@3, Final@5, and Aggressive@6 correspond to different service-budget regimes and are suitable for different small-agent deployment scenarios. Therefore, the objective of SkillSelect-Serve is not to output a fixed bundle that is universally optimal across all scenarios. Instead, it provides a budget-controllable and QoS-aware decision interface, allowing the system to select an appropriate operating point according to context budgets and risk preferences.

Finally, this paper strictly distinguishes clean deployable evaluation from oracle-calibrated analysis. During training, curated labels can be used to construct supervision signals, and upper-bound analysis can be used to determine whether high-quality compact bundles exist in the candidate space. During inference, however, SkillSelect-Serve uses only label-free features available at deployment time, including retrieval rank, reranker score, Skill Service Profile, requirement matching, tool and input-output compatibility, cost, risk, and redundancy signals. This paper does not use oracle-derived utility as a decision signal in the main experiments, thereby avoiding label leakage and ensuring that the main results are consistent with the actual deployment setting.

7 Related Work↩︎

This work is closely related to five lines of research: service computing and QoS-aware composition, mashup and API service recommendation, LLM-enhanced service recommendation, LLM agents and tool/API use, and retrieval, reranking, and bundle recommendation. Compared with these directions, the core positioning of SkillSelect-Serve is to model agent skills as Skill Services with functionality, input-output specifications, tool dependencies, cost, risk, and QoS attributes, and to study requirement-conditioned, budget-controllable, and QoS-aware Skill Service Recommendation and Composition for small LLM agents.

7.1 Service Computing, QoS-aware Composition, and Mashup Recommendation↩︎

Service-oriented computing has long studied how distributed application capabilities can be organized as discoverable, composable, and manageable services. Papazoglou et al. systematically summarized the research challenges of service-oriented computing and emphasized the importance of loosely coupled services for building cross-organization and cross-platform applications [6]. Lemos et al. further surveyed Web service composition from the perspectives of models, languages, tools, and execution mechanisms, showing that service composition involves not only service discovery, but also composition structures, execution constraints, and tool support [13]. Bouguettaya et al. discussed future challenges in service computing from the perspective of service ecosystems, including large-scale service modeling, composition, and governance [8]. These studies provide the foundation for the Skill-as-a-Service formulation adopted in this paper. Although agent skills are not conventional Web services, they can similarly be regarded as service-like capability units with functionality, constraints, dependencies, and operational attributes.

QoS-aware service composition further shows that service selection should not consider functional matching alone, but should also account for non-functional attributes such as cost, latency, reliability, availability, and user constraints. Zeng et al. proposed QoS-aware middleware to support service selection in Web service composition through global QoS utility [7]. Subsequent surveys on QoS-aware service composition also indicate that multi-objective constraints, service-quality modeling, and composition optimization remain central problems in service computing [14]. In mobile or resource-constrained settings, Web service composition must additionally consider contextual resources, execution environments, and device limitations [15]. These studies share the same problem motivation as QoS-aware Skill Service Recommendation in this paper. However, this work focuses on context budgets, tool permissions, and risk constraints of small LLM agents, rather than executable service orchestration in traditional business processes.

Mashup-oriented service recommendation is more closely related to the recommendation setting studied in this paper. This line of research typically recommends one or more Web APIs according to mashup requirements to support mashup development. Early work on service package recommendation selected collaborative services by mining mashup textual descriptions [16]. CSBR formulated mashup development as compositional semantics-based service bundle recommendation and explicitly considered the compositional semantics of service bundles [17]. DySR used dynamic graph neural networks to model service evolution and the requirement-service semantic gap in service bundle recommendation [18]. As Web API ecosystems have expanded, researchers have further incorporated diversity, compatibility, and graph structure. DAWAR recommends diversified and compatible Web APIs based on a correlation graph [19]. SEHGN uses a semantic-enhanced heterogeneous graph network to model Mashup–API relations and API-level semantics [20]. Topic-aware heterogeneous graph methods further combine topic representations with heterogeneous graph structures to improve service recommendation [21]. More recently, PHRec employed a pre-trained heterogeneous information network for mashup-oriented API recommendation [22], while C-DAWAR introduced contrastive learning into diversity-aware Web API recommendation [23]. Related surveys have also summarized the evolution of Web API recommendation from text matching and collaborative filtering to graph neural networks and deep semantic modeling [24].

These studies provide important foundations for service bundle recommendation and mashup-oriented API recommendation. However, they primarily focus on Web APIs, mashup co-invocation histories, or service networks. In contrast, agent skills are service-oriented capability units directly consumed as context by small LLM agents. Each selected Skill Service introduces token cost, tool dependencies, execution constraints, risk notes, and potential context interference. Therefore, agent skill selection cannot be treated as a straightforward extension of API recommendation. It requires explicit modeling of service budgets, small-agent constraints, marginal usefulness, and the recommendation–execution gap.

7.2 LLM-enhanced Service Recommendation↩︎

Recent studies have begun to introduce LLMs into service recommendation to enhance semantic understanding, service representation, and recommendation reasoning. Rong et al. proposed LLM-enhanced representation learning for cold-start service recommendation, where LLMs are used to enrich the semantic representations of services and mashups, and graph self-attention transformers are further incorporated to alleviate interaction sparsity in cold-start scenarios [25]. LLMSRec combines LLM-based service network augmentation with GNN-based structural modeling, using LLMs to expand semantic relations in service networks [26]. LLM-CoSR improves the robustness of noisy service recommendation through LLM-augmented graph contrastive learning [27]. These studies indicate that LLMs are evolving from general-purpose text generators into important components for service representation, semantic augmentation, and graph-enhanced recommendation.

MARS is one of the recent TSC studies most closely related to this work. It targets mashup-oriented service recommendation and integrates semantic enrichment, structure-aware retrieval, and multi-agent collaborative reasoning into a unified pipeline. It also emphasizes multi-stage reasoning over a constrained candidate space, rather than directly asking an LLM to process the full API space [28]. This design is consistent with the motivation of this paper: both lines of work recognize that LLMs can reduce the semantic gap between natural-language requirements and service descriptions, but that controllability requires candidate constraints, structured representations, and modular decision-making.

SkillSelect-Serve is complementary to these LLM-enhanced service recommendation methods, but differs in problem setting. Existing LLM-enhanced service recommendation mainly improves Web service or API representation, service networks, or mashup recommendation reasoning. In contrast, SkillSelect-Serve focuses on the agent skill ecosystem and studies which Skill Services should be loaded by a small LLM agent under a limited context budget. More importantly, the local Micro-Agent Requirement Planner in this paper does not directly recommend skill IDs or generate the final bundle. It only parses a natural-language task into structured service requirements. The final decision is made by deployable marginal service suitability estimation, bundle-level calibration, and Budgeted QoS-aware Projection. This distinction enables the system to benefit from the task-understanding capability of LLMs while preserving trainability, interpretability, and deployment controllability in service selection.

7.3 LLM Agents and Tool/API Use↩︎

Research on LLM agents and tool/API use has advanced language models from pure text generation toward external tool invocation and environment interaction. ReAct interleaves reasoning traces with actions, enabling LLMs to interact with external environments or knowledge sources during reasoning [1]. Toolformer studies how language models can learn, through self-supervision, when to call external APIs, which APIs to call, and how to integrate the returned tool results [3]. HuggingGPT uses an LLM as a controller for task planning, model selection, subtask execution, and result aggregation, demonstrating the ability of LLMs to connect external model ecosystems [2]. ToolLLM and ToolBench provide large-scale tool-use data and evaluation infrastructure, enabling LLMs to learn realistic API-use capabilities [29]. API-Bank systematically evaluates tool-augmented LLMs in API planning, retrieval, and calling [5].

Subsequent research has further extended this direction to massive APIs, real-world RESTful APIs, and scalable tool retrieval. Gorilla improves API-call generation over massive APIs through retriever-aware training and mitigates hallucination under direct prompting [30]. RestGPT connects LLMs to real-world RESTful APIs and uses coarse-to-fine online planning to handle API understanding, planning, parameter formulation, and response parsing [31]. For large-scale tool libraries, iterative-feedback tool retrieval uses LLM feedback over initial retrieval results to reduce the gap between user instructions and tool descriptions [32]. ToolGen represents tool knowledge as special tokens and unifies tool retrieval and tool calling as a generation task [33]. These studies show that LLM tool use is expanding from a small number of manually specified tools to integrated large-scale tool discovery, tool retrieval, and tool invocation.

However, these studies mainly address how LLMs use tools: how to plan tool-use trajectories, generate API calls, parse returned results, or train tool-augmented models. This paper focuses on a complementary problem: when a large-scale reusable skill library already exists, which Skill Services should a small LLM agent load? Unlike a single tool call, SkillSelect-Serve outputs a service bundle to be consumed by a small-model agent. Therefore, it must account for service budget, token cost, tool availability, risk, redundancy, and execution suitability. In other words, this work does not aim to make LLMs call more tools. Instead, it selects a more appropriate service-oriented capability context for small LLM agents under a limited budget.

7.4 Retrieval, Reranking, and Bundle Recommendation↩︎

Retrieval and reranking are fundamental to large-scale skill and service selection. BM25 is a classic lexical retrieval method based on the probabilistic relevance framework [9]. Sentence-BERT generates sentence-level dense embeddings through Siamese and triplet network structures, making large-scale semantic similarity search more efficient [10]. Cross-encoder reranking jointly encodes a query and a candidate to provide more fine-grained relevance estimation over a candidate set [11]. Reciprocal Rank Fusion combines ranking results from multiple retrievers and is widely used in hybrid retrieval [34]. Retrieval-Augmented Generation integrates retrieval with generation for knowledge-intensive tasks, and has also influenced subsequent retrieval-augmented agents and tool retrieval systems [35].

In SkillSelect-Serve, retrieval and reranking are positioned as the Skill Service Discovery stage. Their goal is to provide a high-recall candidate pool from the large-scale Skill Service Registry, rather than to directly determine the final recommendation. Fixed top-\(k\) retrieval assumes that services ranked higher should be loaded first. However, it cannot determine whether multiple services are redundant or complementary, whether they are too costly, or whether a lower-ranked service with high marginal value should be included in the final bundle. Therefore, on top of the discovery backbone, SkillSelect-Serve further performs skill-level marginal suitability estimation, bundle-level composition calibration, and Budgeted QoS-aware Projection.

Bundle recommendation studies how to recommend a set of items rather than a single item. BGCN models user-item, user-bundle, and bundle-item affiliations as a heterogeneous graph to learn both item-level and bundle-level semantics [36]. Recent surveys on bundle recommendation summarize two major tasks, namely discriminative bundle recommendation and generative bundle recommendation, and discuss bundle representation, interaction modeling, bundle generation, and evaluation [37]. Bundle MCR further extends multi-round conversational recommendation to the bundle setting, using multiple interaction rounds to elicit user preferences and narrow the recommendation space [38]. Service package recommendation and mashup API recommendation can also be viewed as special cases of service bundle recommendation, where the goal is to determine whether multiple APIs or services can jointly satisfy mashup requirements [16]–[24].

This paper shares the set-level selection perspective of bundle recommendation, but differs in its constraints and deployment setting. In conventional bundle recommendation, a bundle is typically a set of products, content items, or API packages consumed by a user or application. In this paper, however, a skill service bundle is injected into the context of a small LLM agent and directly affects model reasoning, tool selection, and execution paths. Therefore, the budget is not merely a ranking cutoff, but an operational constraint in small-agent deployment. The dual-granularity design of SkillSelect-Serve also differs from conventional bundle recommendation: skill-level marginal suitability identifies critical services, bundle-level calibration estimates coverage, redundancy, cost, and risk, and Budgeted QoS-aware Projection produces different operating points under explicit deployment constraints.

7.5 Summary and Positioning↩︎

Table 6 summarizes the relationship between SkillSelect-Serve and different lines of related work. Existing studies provide important foundations in service composition, API recommendation, LLM-enhanced representation, tool/API use, retrieval and reranking, and bundle recommendation. However, these directions usually cover only part of the problem. Traditional service composition emphasizes QoS and composition, but it does not target agent skill context. Mashup and API recommendation focuses on Web API selection, but rarely addresses the context budget of small agents. LLM-enhanced service recommendation uses LLMs to improve representation or reasoning, but is typically still oriented toward Web services or APIs. LLM tool-use research emphasizes tool invocation and execution trajectories, but does not directly study service bundle selection. Retrieval and reranking provide candidate discovery, but do not model composition utility. Bundle recommendation focuses on set-level preference, but usually does not model the execution impact of skills as context.

3.5pt

In summary, the novelty of SkillSelect-Serve does not lie in proposing a standalone retriever, tool caller, or bundle recommender. Rather, it lies in unifying several key problems at the intersection of service computing and the LLM agent skill ecosystem. Compared with traditional service computing, this paper extends the service object to Skill Services consumed by small LLM agents. Compared with mashup and API recommendation, it explicitly models service budget, context cost, risk, and the marginal usefulness of skill services. Compared with LLM tool-use methods, it does not focus on tool invocation trajectories, but instead studies deployable service selection from a large-scale Skill Service Registry. Compared with retrieval, reranking, and bundle recommendation, it further connects discovery, dual-granularity utility modeling, QoS-aware projection, and execution diagnostics into a complete system.

Therefore, this paper systematically formulates agent skill selection as a requirement-conditioned, budget-controllable, and QoS-aware Skill Service Recommendation and Composition problem. This positioning inherits the long-standing concerns of service-oriented computing, including discovery, composition, and QoS, while also addressing new challenges introduced by the LLM agent ecosystem, such as reusable skills, small-agent context budgets, and the downstream recommendation–execution gap.

8 Conclusion↩︎

As reusable skills become an important infrastructure for LLM agent systems, agent skill selection is no longer a simple problem of text retrieval or fixed top-\(k\) routing. For small LLM agents, each loaded skill consumes a limited context budget and may introduce tool dependencies, execution steps, risk notes, and contextual interference. Therefore, the key challenge of skill selection is not to retrieve more skills, but to select more useful, controllable, and deployable Skill Services under a limited operational budget. Based on this observation, this paper proposes a Skill-as-a-Service formulation, which models agent skills as service-oriented capability units with functionality, input-output assumptions, tool dependencies, cost, risk, and QoS-related attributes. It further formulates the problem as requirement-conditioned, budget-controllable, and QoS-aware Skill Service Recommendation and Composition.

To address this problem, this paper presents SkillSelect-Serve, a budgeted Skill Service selection framework for small LLM agents. SkillSelect-Serve organizes task requirement understanding, candidate service discovery, dual-granularity service utility modeling, and Budgeted QoS-aware Projection into a deployable pipeline. Specifically, the local Micro-Agent Requirement Planner parses a natural-language task into structured service requirements, but does not directly select skill IDs. Skill-level marginal suitability estimation identifies candidate services with marginal value for the current task. Bundle-level calibration characterizes service coverage, redundancy, cost, and risk. Budgeted QoS-aware Projection then outputs deployable skill service bundles under different service-budget regimes. Through this design, SkillSelect-Serve connects the task-understanding capability of LLMs with discovery, recommendation, composition, and QoS control in service computing.

Experimental results show that the gains of SkillSelect-Serve come from more effective same-budget service selection, rather than from simply increasing the bundle size. In the compact setting with \(k=3\), SkillSelect-Serve Compact@3 improves the recall of Top-3 Fixed from 0.8163 to 0.8700, and increases mean utility from 0.6333 to 0.6901. In the high-recall setting with \(k=5\), SkillSelect-Serve Final@5 improves the recall of Top-5 Fixed from 0.8492 to 0.8873, and increases mean utility from 0.6672 to 0.7078. Further upper-bound analysis shows that Final@5 already approaches the current Top-20 candidate-space upper bound, indicating that SkillSelect-Serve can make substantial use of the candidate services provided by the discovery backbone within the given candidate space. Ablation results further show that skill-level marginal suitability is the key source of same-budget improvement, while bundle-level calibration provides composition-level interpretation and control over coverage, redundancy, cost, and risk trade-offs.

This paper also reveals several important system boundaries in the Skill Service ecosystem for small LLM agents. Candidate-space upper-bound analysis indicates that further improving high-recall performance requires stronger Skill Service Discovery. QoS analysis shows that different service-budget regimes correspond to different trade-offs among cost, risk, and recall. The diagnostic execution study further shows that a recommendation–execution gap remains between offline recommendation quality and downstream execution utility. Overall, this paper demonstrates that transforming agent skill libraries from passive document repositories into governable Skill Service Registries, and performing service recommendation and composition under explicit budget and QoS constraints, is a critical step toward enabling small LLM agents to effectively use large-scale reusable skill ecosystems. Future work should further learn execution-aware service utility from runtime feedback, failure traces, and execution outcomes, thereby closing the loop between Skill Service Recommendation and downstream agent execution.

Acknowledgments↩︎

The authors would like to thank the anonymous colleagues and early readers who provided feedback on the system formulation, experimental design, and manuscript presentation.

References↩︎

---

1. Jingyuan Zheng, Dongjing Wang, Xin Zhang, Haiping Zhang, and Dongjin Yu are with Hangzhou Dianzi University, Hangzhou, China. E-mail: zhengjoy@hdu.edu.cn, dongjing.wang@hdu.edu.cn, zhangxin@hdu.edu.cn, zhanghp@hdu.edu.cn, yudj@hdu.edu.cn.↩︎

2. Butian Huang is with the School of Cyberspace Security, Hangzhou Dianzi University, Hangzhou, China. E-mail: butian@hdu.edu.cn.↩︎

3. Shuguang Deng is with Zhejiang University, Hangzhou, China. E-mail: dengsg@zju.edu.cn.↩︎

4. Corresponding author: Dongjing Wang.↩︎