Paper deep dive
Agentization of Digital Assets for the Agentic Web: Concepts, Techniques, and Benchmark
Linyao Chen, Bo Huang, Qinlao Zhao, Shuai Shao, Zhi Han, Zicai Cui, Ziheng Zhang, Guangtao Zeng, Wenzheng Tang, Yikun Wang, Yuanjian Zhou, Zimian Peng, Yong Yu, Weiwen Liu, Hiroki Kobayashi, Weinan Zhang
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 93%
Last extracted: 4/10/2026, 2:34:55 AM
Summary
The paper introduces the 'Agentic Web' paradigm and proposes a framework for 'Agentization'—the automated transformation of static digital assets (specifically code repositories) into interoperable, A2A-compliant agents. It presents the 'A2A-Agentization Agent' for this process and the 'A2A-Agentization Bench' to evaluate agentization quality based on fidelity and interoperability.
Entities (5)
Relation Signals (3)
A2A-Agentization Agent → transforms → Digital Assets
confidence 95% · we develop an Agentization Agent to agentize digital assets for the Agentic Web
A2A-Agentization Bench → evaluates → A2A-Agentization Agent
confidence 92% · we propose A2A-Agentization Bench... to evaluate agentization quality
A2A-Agentization Agent → implements → A2A Protocol
confidence 90% · systematically converts digital assets into agents that are compliant with Agentic Web standards and interoperable under the A2A protocol
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Agentic Web, as a new paradigm that redefines the internet through autonomous, goal-driven interactions, plays an important role in group intelligence. As the foundational semantic primitives of the Agentic Web, digital assets encapsulate interactive web elements into agents, which expand the capacities and coverage of agents in agentic web. The lack of automated methodologies for agent generation limits the wider usage of digital assets and the advancement of the Agentic Web. In this paper, we first formalize these challenges by strictly defining the A2A-Agentization process, decomposing it into critical stages and identifying key technical hurdles on top of the A2A protocol. Based on this framework, we develop an Agentization Agent to agentize digital assets for the Agentic Web. To rigorously evaluate this capability, we propose A2A-Agentization Bench, the first benchmark explicitly designed to evaluate agentization quality in terms of fidelity and interoperability. Our experiments demonstrate that our approach effectively activates the functional capabilities of digital assets and enables interoperable A2A multi-agent collaboration. We believe this work will further facilitate scalable and standardized integration of digital assets into the Agentic Web ecosystem.
Tags
Links
- Source: https://arxiv.org/abs/2604.04226v1
- Canonical: https://arxiv.org/abs/2604.04226v1
Trouble viewing inline? Open PDF directly →
Full Text
101,535 characters extracted from source content.
Expand or collapse full text
Agentization of Digital Assets for the Agentic Web Agentization of Digital Assets for the Agentic Web: Concepts, Techniques, and Benchmark Linyao Chen 2,† , Bo Huang 1,4,† , Qinlao Zhao 3,† , Shuai Shao 1 , Zhi Han 1 , Zicai Cui 1 , Ziheng Zhang 5 , Guangtao Zeng 6 , Wenzheng Tang 7 , Yikun Wang 4,8 , Yuanjian Zhou 4 , Zimian Peng 4,9 , Yong Yu 1 , Weiwen Liu 1 , Hiroki Kobayashi 2 , Weinan Zhang 1,4,∗ 1 Shanghai Jiao Tong University 2 The University of Tokyo 3 Huazhong University of Science and Technology 4 Shanghai Innovation Institute 5 Nankai University 6 Singapore University of Technology and Design 7 Queen’s University 8 Fudan University 9 Zhejiang University † These authors contributed equally to this work. ∗ Corresponding author: wnzhang@sjtu.edu.cn Abstract Agentic Web, as a new paradigm that redefines the internet through autonomous, goal- driven interactions, plays an important role in group intelligence. As the foundational se- mantic primitives of the Agentic Web, digital assets encapsulate interactive web elements into agents, which expand the capacities and coverage of agents in agentic web. The lack of automated methodologies for agent generation limits the wider usage of digital assets and the advancement of the Agentic Web. In this paper, we first formalize these challenges by strictly defining the A2A-Agentization process, decomposing it into critical stages and identifying key technical hurdles on top of the A2A protocol. Based on this framework, we develop an Agentization Agent to agentize digital assets for the Agentic Web. To rigorously evaluate this capability, we propose A2A-Agentization Bench, the first benchmark explic- itly designed to evaluate agentization quality in terms of fidelity and interoperability. Our experiments demonstrate that our approach effectively activates the functional capabilities of digital assets and enables interoperable A2A multi-agent collaboration. We believe this work will further facilitate scalable and standardized integration of digital assets into the Agentic Web ecosystem. 1 Introduction With the rapid development of Large Language Models (LLMs) [2, 48], LLM-based agents [45, 31] have demonstrated remarkable progress in planning [46, 33], tool use [31, 24], and interactive decision- making across a wide range of domains [9, 36, 40]. In recent years, LLM-based multi-agent systems (LaMas) [11, 20, 49] have attracted increasing attention from the research community, emerging as an ef- fective paradigm for real-world AI applications. The Agentic Web [43, 12, 47] is envisioned as the foun- dational infrastructure for such systems, enabling a decentralized ecosystem in which autonomous agents interconnect and collaborate to solve complex tasks [17]. Supported by interoperability standards such as the Agent-to-Agent (A2A) protocol [1] and the Model Context Protocol (MCP) [5], this paradigm aims to maximize large-scale collaboration among heterogeneous agents. As observed in prior work [15, 44], the overall performance of LaMas and Agentic Web is largely determined by the capacity and the scope of agents in the ecosystem, while the scaling of agents will lead to a scaling up of agentic performance in Agentic Web. However, today’s Agentic Web still lacks a scalable way to continuously supply domain-specialized agents, since manual construction is costly, slow, and difficult to scale the diversity. We argue that existing digital assets provide a natural foundation for addressing this bottleneck. Across the traditional web, digital assets already serve as the primary carriers of knowledge and functionality in a 1 arXiv:2604.04226v1 [cs.MA] 5 Apr 2026 Agentization of Digital Assets for the Agentic Web A2A Search AgentA2A Finance Agent A2A GUI Agent A2A-Agentization Digital Assets A2A Digital Assets Agent A2A Code Agent Agentic Web Integration Other A2A agents Figure 1: Conceptual illustration of agentization of digital assets for the Agentic Web. Through agentization, digital assets are transformed into A2A-compliant agents that can be integrated into the Agentic Web, en- abling interactions and collaborations for real-world tasks. wide variety of domains. They are abundant, diverse, and often already encode valuable domain-specific capabilities. If these assets could be systematically transformed into interoperable agents, they would offer a scalable source of specialized capabilities for the Agentic Web. In this work, we use the term digital assets to broadly refer to any kind of data is in binary form that stored digitally [32], such as code repositories, documents, spreadsheets, images, videos, audio, and online services. In practice, these assets often embody valuable knowledge, functionality, or domain-specific capabilities. As a result, they frequently carry economic, functional, or personal value to their owners [6, 32], which in turn creates incentives to make them accessible and usable in the agent ecosystem, thereby unlocking new utility and economic value through interactions with other agents. This motivates the problem we study: how can existing static digital assets be automatically transformed into agents that are compatible with the Agentic Web and can be reliably invoked by other agents? Realizing automated agentization of digital assets is a non-trivial and challenging task. Automated agenti- zation must overcome three technical hurdles: (1) Inconsistent environments: dependencies often conflict and are hard to reproduce; (2) Unstructured skills: useful capabilities are hidden in undocumented code and must be extracted into atomic, reusable actions; and (3) Semantic gap: even if the code runs, it still needs clear, discoverable interfaces (e.g., agent cards) so others can understand and invoke it. These three chal- lenges are particularly pronounced in code repositories. Therefore, compared with other digital assets, such as documents, services, and audio assets, we adopt code repositories as the representative setting, since they encapsulate the core complexity of the problem and constitute one of the most challenging asset types in practice. In this work, we propose agentization of digital assets for the Agentic Web, a rigorously defined and fully automated process aimed at dismantling data islands and scaling the agent ecosystem. As illustrated in Figure 1, our approach systematically converts digital assets into agents that are compliant with Agentic Web standards and interoperable under the A2A protocol. To execute this process, we introduce the A2A- Agentization Agent, an autonomous framework specifically designed to resolve environment inconsistencies, extract unstructured skills, and bridge the semantic gap, thereby seamlessly transforming raw repositories into fully functional agents. To objectively assess progress in this direction, we introduce A2A-Agentization Bench, the first compre- hensive benchmark designed to evaluate the full agentization lifecycle of digital assets. Considering the characteristics of digital assets, we ground this benchmark in real-world code repositories, which represent some of the most challenging assets due to their heterogeneous file formats, complex dependency structures, and the need for autonomous exploration and capability verification. A2A-Agentization Bench curates 35 diverse repositories with 522 evaluation instances. Specifically, the benchmark evaluates agentization quality across two critical dimensions: fidelity (the accurate execution of extracted skills) and interoperability (the ability to be seamlessly invoked by other agents). Through this benchmark, we provide a rigorous evaluation 2 Agentization of Digital Assets for the Agentic Web of existing methods, identify critical gaps in current approaches, and analyze their strengths and limitations in Section 5.3. To summarize, our main contributions are as follows: • We introduce the concept of agentization of digital assets for the Agentic Web and formalize it in the representative setting of real-world code repositories. Under this setting, we specify the requirements for A2A-compliant agentization and formulate it as a repository-level autonomous development task. Based on this formulation, we propose the A2A-Agentization Agent, which systematically transforms repositories into interoperable agents. • We propose A2A-Agentization Bench, the first benchmark specifically designed to evaluate agenti- zation methods of digital assets for the Agentic Web. Grounded in real-world code repositories, the benchmark provides a systematic assessment of whether automated methods can reliably produce interoperable, A2A-compliant agents. • We demonstrate the effectiveness of the A2A-Agentization Agent on A2A-Agentization Bench by integrating it with representative state-of-the-art agent frameworks. Our results reveal that, while automated agentization is feasible, current methods still face substantial challenges, highlighting key bottlenecks in reliable agent production. 2 Related Work 2.1 Repository Utilization Benchmark Repository utilization marks a shift in code agents from generating isolated scripts to interacting with real- world engineering systems, with benchmarks diverging into two streams. The first stream, repository de- velopment, evaluates agents on maintaining or extending codebase logic. RepoBench [23] introduces live evaluation for repository-level code completion, focusing on cross-file context. Similarly, DevEval [19] and EvoCodeBench [18] align with real-world repository distributions to assess generation fidelity and depen- dency understanding. The second stream, task-solving, treats the repository as an executable resource for end-to-end problem solv- ing. SWE-bench [14] pioneered the issue-patch-test loop to verify bug fixes, while GitTaskBench [26] binds tasks to specific repositories to test workflow automation. To address specific bottlenecks, EnvBench [10] targets the critical environment setup phase, and LoCoBench [30] evaluates long-context reasoning for com- plex engineering tasks. While these works focus on consuming repositories for tasks, our work uniquely evaluates the agentization process itself: transforming code repo into standardized, A2A-compliant agents for the Agentic Web. 2.2 Agentization Methods As a process of generating agents, agentization [28, 7] refers to endowing static digital assets with au- tonomous capabilities. Early works [29, 21, 38] focused on transforming existing services into tools, thereby bridging rigid interfaces with LLM flexibility. Similarly, works [38, 22] are devoted to transforming the digi- tal assets into tools, thereby enhancing agent capabilities. Furthermore, several works focus on directly trans- forming the digital assets into agents. Paper2Agent [25] transforms scientific research papers into interactive agents via setting up the operation environment and building the paper as an MCP server via a well-defined multi-agent system, while repomaster [34] explores the research on generating corresponding agents for code repositories. EnvX [8] advances agentization research by transforming repositories into executable agents. While these works advance agentization, they do not ensure Agentic-Web-compatible communication, which limits the wider usage of generated agents. Our work addresses this gap through a standardized pipeline for repository agentization with strict A2A compliance. 3 Agentization of Digital Assets for the Agentic Web Figure 2: Processing pipeline of repository agentization. The repository agentization process starts from raw repository contents and is organized into four stages. The agent first initializes the repository environment, then analyzes repository contents to extract skills, instantiates an inner agent, and finally produces an A2A- compliant agent with an agent card. 2.3 Protocols for LLM-based Agents Standardized protocols are essential for the scalability of the Agentic Web.Early systems relied on framework-specific interfaces, limiting cross-ecosystem collaboration [28, 39, 13]. More recently, standards such as the Model Context Protocol (MCP) and Agent-to-Agent (A2A) protocol have emerged to support structured tool use and decentralized agent interaction [5, 1, 42]. Despite this progress, existing research has predominantly focused on evaluating how effectively agents uti- lize available protocol-compliant tools [37, 16, 41]. In contrast, relatively little attention has been paid to how such tools and services are constructed or adapted to conform to protocol specifications, particularly when transforming legacy software into agent-compatible components. 3 Methodology In this section, we introduce how we agentize digital assets and link generated agents into Agentic Web. We introduce some preliminaries and detailed definitions in section 3.1, and present the agentization process along with its practical implementation, Agentization Agent in section 3.2. 3.1 Preliminaries and Definition of Agentization for Agentic Web The goal of agentization is to transform a static Digital Asset (D) into a compliant, interactive agent (A) within the Agentic Web ecosystem. Here the A is required to be compliant to A2A protocol to ensure the communication within Agentic Web. In this work, as introduced in section 1, we specifically focus on agentizing and benchmarking Code Repos- itories (D repo ), which serve as a complex class of digital assets containing functional logic. We define the context of code repositories as a set of workspace components (W ): D repo =W dep ,W conf ,W codes ,W readme , where W dep denotes the package dependencies of given repositories, W conf denotes the configs of given repositories, W codes denotes the codes of given repositories and W readme denotes the readme file of the repositories, which is a key of given tasks. 3.2 Agentization Process As introduced in Figure 2, we formalize the agentization process as a set of requisite transformations that map D to the components of an A2A-compliant agent. These components serve as the functional requirements for our system. We define the process as four stages. 4 Agentization of Digital Assets for the Agentic Web Environment Setup The foundation of an executable agent is a reproducible environment, denoted as E , consisting of both environment variables and the code environment for running the agent. This mapping ensures that the static logic within the asset can run deterministically: E =G env (W dep ,W conf ), where G env represents the synthesis of configuration settings (e.g., container images) that encapsulate the system-level dependencies and runtimes required by the digital asset. Skill Extraction as Tools To grant the agent capabilities, we extract a set of atomic functionsT from the asset in this phase. This process relies on the established environment to verify execution: T =G tool (D repo ,E), whereG tool denotes the process of identifying, wrapping, and validating functional units as executable tools fromD. Inner Agent Instantiation The core cognitive architecture of the agent, denoted asA in , is constructed by integrating these tools into a reasoning loop (e.g., a ReAct loop [45]): A in =G inner (D repo ,E,T ). This step instantiates the agent’s internal logic, enabling it to plan and execute the extracted skills to solve tasks. Final Agentization To generate an A2A-compliant agent, the system should generate the agent cardC as following equation: C =G card (D repo ,T ). The agent card serves as a self-description registry, detailing the agent’s identity and available tools, enabling other agents to understand its capabilities without internal inspection. And the finalized agent is denoted as A =A in ,C In practice, we operationalize this framework by wrapping the repository into a larger codebase context and formulating the agentization stages as distinct features. We then introduce an Agentization Agent to perform end-to-end repository development. Specifically, this agent executes repository-level feature implementation, thereby converting the static repository into an active agent. 4 A2A-Agentization Benchmark We introduce the A2A-Agentization Benchmark, a comprehensive dataset and evaluation framework de- signed to assess the capability of Agentization methods to autonomously transform open-source software repositories into A2A-compliant agents integrated into the Agentic Web, where these agents can directly interact with peer agents. 4.1 Benchmark Construction The construction of A2A-Agentization Bench follows a systematic pipeline. We first curate a diverse set of repositories and establish ground-truth Agent Skills as the static foundation. Subsequently, we gener- ate execution scenarios at two granularities: Single-Repo and Multi-Repo tasks. These artifacts collectively underpin our dual-dimensional evaluation: Single-Repo tasks specifically enable the Capability Inheritance Assessment, while the Agent Skills annotation and Multi-Repo tasks facilitate the comprehensive Collabora- tive Execution Assessment. 5 Agentization of Digital Assets for the Agentic Web Repository Collection. To rigorously assess agent capabilities across the Agentic Web, we curate 35 di- verse GitHub repositories (see Appendix B for the full list). Drawing inspiration from recent repository analysis taxonomies [26], we organize these repositories into 9 primary Task Domains to ensure broad cov- erage of real-world software interactions. Representative domains include: (1) Visual & Video Processing (e.g., Ultralytics, Stable Diffusion); (2) Document & Web Automation (e.g., Unstructured, Trafilatura); and (3) Scientific & Specialized Computing, spanning fields like Computational Chemistry (e.g., ChemFormula) and Quantitative Finance (e.g., Backtrader). This domain-centric selection captures heterogeneous file formats and cross-file transformation workflows, enabling realistic inter-agent dependencies. These repositories are standardized with rigorous quality control and protocol-compliant transformations to support the subsequent agentization pipeline. Agent Skill Annotation. Rather than manually synthesizing all metadata fields, we focus strictly on estab- lishing the ground truth for Agent Skills—the functional core of the agent. Human experts manually identify and formalize these skills by extracting key functionalities from repository artifacts (e.g., README.md, unit tests). To ensure these skills validly represent the repository’s value, we enforce two annotation criteria: (1) Core Capability Inheritance: The skill must encapsulate a primary, non-trivial feature of the repository (e.g., Image Segmentation for a vision library) rather than a generic utility; (2) Atomic Functional Unit: Each skill should represent a distinct, reusable action that can be invoked independently within an agentic workflow. These expert-annotated skills serve as the gold standard for verifying the specification quality of the gener- ated AgentCard, ensuring the agent uses semantically precise descriptions to be correctly discovered by the orchestrator. In total, we annotate 127 Agent Skills across 35 repositories. Execution Task Generation. To evaluate agentization under realistic Agentic Web interactions, we construct execution tasks that are strictly repository-dependent, such that correct solutions must invoke repository-specific APIs or behaviors rather than relying on generic reasoning or external libraries. We generate tasks using two procedures. For Single-Repo Tasks (see Appendix C.3), a code agent analyzes an individual repository’s documentation, unit tests, and exposed APIs to synthesize tasks whose solutions re- quire invoking internal, repository-specific functions, directly probing intra-agent capability inheritance. For Multi-Repo Tasks (see Appendix C.4), we adopt a two-stage process in which a search agent first identifies semantically complementary repositories, after which the code agent analyzes each repository in isolation and jointly constructs cross-repository workflows. These workflows are formulated as strictly linear depen- dency chains, where each agent must consume the concrete output of the previous agent as its sole valid input, making every step indispensable. To ensure task validity and fairness, all generated tasks undergo a verification pipeline. Each task is dry-run in isolated environments to eliminate execution errors, followed by expert human review to confirm semantic meaningfulness and strict dependence on repository-specific capabilities. After verification and filtering, we retain 336 Single-Repo Tasks and 186 Multi-Repo Tasks. 4.2 Execution Task Data Analysis Execution Tasks Diversity. To ensure that the benchmark captures a representative spectrum of real-world software automation challenges, we analyze the diversity of execution tasks along two complementary di- mensions: single-repo domain coverage and multi-repo cross-domain composition. We introduce the task diversity in figure 3. The left panel of the figure presents the distribution of 336 single- repo tasks across 9 application domains (detailed in Appendix B). Vision and video processing constitutes the largest category (90 tasks, 26.8%), reflecting the growing importance of multimodal media pipelines that involve image segmentation, style transfer, video restoration, scene detection, and diffusion-based generation. Document and web parsing follows with 61 tasks (18.2%), encompassing OCR engines, PDF table extraction, and structured document processing — tasks that demand correct handling of diverse file formats and external parsing dependencies. Web and platform scraping (40 tasks, 11.9%) and development security (40 tasks, 6 Agentization of Digital Assets for the Agentic Web Document: 61 Visualization: 90 Crawler: 40 Audio: 36 Security: 40 NLP: 20 Chemistry: 30 Website: 9 Finance: 10 Single Repo Task Diversity Document Crawler Audio Visualization Security NLP Chemistry Website Finance Cross 2 Domains: 87 Cross 1 Domain: 41 Cross 4 Domains: 10 Cross 3 Domains: 48 Multi Repo Task Diversity Cross 1 Domain Cross 2 Domains Cross 3 Domains Cross 4 Domains Figure 3: Execution task diversity analysis. Single-repo tasks are distributed across 9 application domains, illustrating broad coverage of domain-specific execution scenarios. Multi-repo tasks are grouped by the number of distinct domains involved in each workflow (cross-k domains), highlighting the prevalence of cross-domain interactions and increasing interoperability requirements. EasyMediumHard Difficulty 0 20 40 60 80 100 120 140 Number of Tasks 126 104 106 Single Repo Task Execution Complexity EasyMediumHard Difficulty 0 15 30 45 60 75 90 105 98 61 27 Multi Repo Task Orchestration Complexity Figure 4: Execution task complexity distribution. For single-repo tasks, difficulty is decomposed into several dimensions , measured by corresponding indicators. For multi-repo tasks, difficulty is determined by orches- tration complexity, measured by the length of the linear collaboration chain (i.e., the number of sequentially invoked repositories). Tasks are grouped into easy, medium, and hard tiers based on these respective criteria. 7 Agentization of Digital Assets for the Agentic Web 11.9%) each contribute equally, the former testing platform protocol interaction and anti-crawling resilience, the latter exercising static analysis, secret detection, and vulnerability scanning workflows. Speech and audio processing accounts for 36 tasks (10.7%), spanning ASR, voice activity detection, and source separation. Chemistry and molecular analysis provides 30 tasks (8.9%) that require domain-specific knowledge such as retrosynthetic planning and stoichiometric computation. The remaining categories — NLP and string processing (20 tasks, 6.0%), financial backtesting (10 tasks, 3.0%), and web backend frameworks (9 tasks, 2.7%) — round out the distribution, ensuring that the benchmark is not dominated by any single application area. Notably, no single domain exceeds 27% of the total, and the top three domains collectively account for only 56.8%, indicating a reasonably balanced allocation across diverse execution scenarios. The Multi-Repo split includes 186 tasks, the majority of which require composition across 2-3 domains, while still retaining a small set of more challenging 4-domain workflows. This design ensures evaluation of both domain expertise and cross-domain collaborative execution. Execution Tasks Complexity. Figure 4 summarizes the distribution of task difficulty under two comple- mentary notions of complexity. To objectively evaluate the complexity of single-agent tasks, we have designed a multi-dimensional indicator system. This framework assesses tasks based on environment setup, output predictability, processing patterns, and domain specificity. We define four binary indicators to capture different facets of task difficulty: • D1 (Constrained Environment): Evaluates whether the environment setup requires system-level dependencies, pre-trained models (> 100MB), or external network access beyond standard package managers. • D2 (Uncertain Output): Determines if the task output is non-deterministic due to ML inference variances, external API volatility, or runtime state dependencies. • D3 (Non-standard Processing): Identifies tasks that deviate from the standard "Input File→ Pro- cess→ Output File" transformation pipeline. • D4 (Domain Expertise): Measures whether completing the task requires specialized knowledge (e.g., chemistry, finance) beyond general programming and ML engineering. Tasks are categorized into three tiers: Easy (0-1 indicator satisfied), Medium (2 indicators satisfied), and Hard (3+ indicators satisfied). For Multi-Repo Tasks, we define Orchestration Complexity to reflect the depth of inter-repository coordina- tion required to complete a workflow. We operationalize this using the collaboration chain length specified during data construction, measured by the number of distinct repositories that must be invoked sequentially, with each agent’s output serving as the input to the next. To isolate interoperability and cross-domain data handoff accuracy from higher-order planning complexity, we restrict workflows to linear dependency chains. Tasks are categorized into three tiers: Easy (2–3 repositories), Medium (4–5 repositories), and Hard (6+ repositories). 4.3 Evaluation Pipeline and Metrics To evaluate a specific Agentization Method, we perform a comprehensive three-stage assessment covering both the process of agent creation and the quality of the resulting agents. Stage 1: Agentization Process Assessment. We first measure the success rate and cost of transforming raw repositories into A2A agents. • Agentization Success (Pass@k): We evaluate success based on the deployment verification. An attempt is considered successful if and only if the deployed agent’s AgentCard is retrievable via the A2A endpoint and passes strict schema validation (i.e., contains valid, non-empty tools definitions). 8 Agentization of Digital Assets for the Agentic Web • Agentization Cost: We record the resource overhead of the agentization lifecycle, specifically re- porting Token Consumption per repository. Stage 2: Capability Inheritance Assessment (Single-Agent). This stage validates whether the functional value of the repository is effectively activated and execution-ready. We assess this through one metric: • Execution Success Rate (SR): We deploy the Subject Agent into a sandbox to solve Single-Repo Tasks, which require invoking specific tools defined in the AgentCard. We report the Execution Success Rate (SR), verified by an LLM-Judge comparing the agent’s interaction trajectory against the ground truth trajectory. Stage 3: Collaborative Execution Assessment (Multi-Agent). This stage evaluates whether an agenti- zation method can produce an agent that can be effectively orchestrated under a user-chosen orchestration mechanism in the Agentic Web: specifically, whether the resulting AgentCard makes the agent’s unique, task-critical capabilities discoverable so that the mechanism can reliably route the right sub-tasks to it (espe- cially when those sub-tasks can only be solved by that agent) during cross-repository collaboration. The benchmark is designed to be compatible with orchestration mechanisms in any Agentic Web imple- mentation: it provides a pluggable coordination interface, allowing users to configure and plug in their own orchestration strategy (e.g., platform-native orchestrators, planners, or heuristic policies) as long as it can dispatch sub-tasks to A2A agent endpoints and produce execution traces for evaluation. We report three key metrics: • Specification Quality (Orchestrability Proxy): We compare the AgentCard’s Skill Definitions against the annotated Ground Truth Agent Skills and report Skill F1-Score as a proxy for Orchestrability. • Orchestration Success Rate (Orch. SR): The percentage of Multi-Repo tasks where all required sub- tasks are correctly dispatched to the appropriate A2A agent endpoints (all-or-nothing, task-level). • Multi-Repo Execution Performance (Exec. SR): The percentage of Multi-Repo tasks completed end-to-end, reported conditioned on correct orchestration (i.e., among tasks successful under Orch. SR). Metric Implementation. All success determinations leverage a standardized LLM-as-a-Judge framework. The judge compares the agent’s execution results (including terminal outputs and generated artifacts) against the verified ground truth to determine task success. 5 Experiments In this section, we evaluate our proposed method by instantiating the Agentization Agent on four represen- tative coding-agent frameworks. These frameworks are selected to reflect state-of-the-art capabilities across distinct dimensions of autonomous software engineering. 5.1 Experiment Setup We evaluate the following four frameworks, representing the state-of-the-art in autonomous software engi- neering (see Appendix C.1 for the specific driver prompts used to instantiate these agents): • Claude Code: An agentic coding tool, instantiated with the Claude-Sonnet-4-5-20250929 model [3] in our experiments. • Codex CLI: An open source coding agent, driven by the GPT-5.2-Codex [27] backbone. 9 Agentization of Digital Assets for the Agentic Web • OpenHands [35]:A platform for the development of AI agents,configured with Claude-Sonnet-4-5-20250929 as the backbone. • EnvX [8]: A coding agent framework specialized in autonomous environment configuration and dependency management, utilizing the Claude-Sonnet-4-5-20250929 model. Architecture Configuration. To rigorously assess different agentization methods under a controlled set- ting, we standardize the agent stack and instantiate a concrete orchestration mechanism (Figure 5) while keeping the benchmark itself orchestration-agnostic. Task Decomposition Task Orchestration Task Execution Card2Skill Orchestration Result Execution Result Multi Repo Task Oracle Subtasks Figure 5: The orchestration mechanism instantiated in our experiments for A2A-Agentization Bench Stage 3. Multi-repo tasks are provided together with their oracle subtask decompositions obtained during bench- mark construction, which serve as the input of orchestration process. In parallel, agent cards produced by agentization agent are converted into agent skills. The coordinator relies solely on these skills to select and bind appropriate A2A agents for each subtask, orchestrates their execution and obtains the result. • Inner Agent Instantiation: Following the definition in Section 3, we select Claude Code as the reasoning backbone for the Inner Agent (A in ). This choice leverages its state-of-the-art tool-use capabilities to effectively drive the extracted repository skills. • Orchestration Instantiation (Claude Code + Oracle Decomposition). For the Multi-Agent evaluation, we instantiate a centralized orchestration setup driven by Claude Code (Figure 5). We initialize each Multi-Repo task with its ground-truth decomposition from the data construction, and convert the generated AgentCards of the 35 A2A agents into executable Claude Agent Skills [4]. Claude Code then relies solely on these AgentCard-derived skill specifications to retrieve/bind agents and dispatch all sub-tasks via the A2A protocol. 5.2 Main Results We present our experimental findings following the three-stage evaluation pipeline defined in Section 4.3. Stage 1: Agentization Process Assessment. Table 1 reports the success rate and cost of the agent creation process. Both Claude Code and EnvX achieve a perfect 100% Agentization Success (Pass@1), demonstrating the robust reasoning capabilities of the underlying model in following the schema retrieval instructions. EnvX consumes slightly more tokens (4.2M vs 3.3M) due to its additional autonomous verification and environment 10 Agentization of Digital Assets for the Agentic Web configuration steps. In contrast, other baselines exhibit lower reliability, even requiring up to three attempts to successfully configure certain repositories. Table 1: Stage 1 Results: Agentization Process Assessment. We report Pass@1 and Pass@3 in percentage (%). Framework Pass@1↑ Pass@3↑ Tries↓ Tokens↓ Claude Code100.00100.001.0003374449 Codex94.28100.001.0862321397 OpenHands94.28100.001.0573254978 EnvX100.00100.001.0004215051 Stage 2: Capability Inheritance Assessment. This stage validates the functional fidelity of the agentized repositories through Single-Repo task execution. Table 2 shows that Claude Code achieves the highest Over- all Success Rate of 36.9%. EnvX follows closely with a 35.1% success rate, while demonstrating superior efficiency in token consumption. This efficiency stems from the solid environment configuration established during the Agentization stage; unlike other methods that often require runtime environment troubleshooting, EnvX operates within a pre-verified environment, minimizing the need for corrective steps during execution. Finally, Codex (34.5%) outperforms OpenHands (33.9%), though both lag behind the top performers. We employ an LLM-as-a-Judge mechanism to evaluate the skill coverage, using the prompt detailed in Ap- pendix C.2. Table 2: Stage 2 Results: Capability Inheritance. We report Execution Success Rate (SR, %) for task execu- tion. FrameworkExecution SR (%)↑ EasyMediumHardOverall Claude Code57.938.510.436.9 Codex45.242.314.234.5 OpenHands54.832.710.433.9 EnvX53.238.510.435.1 Stage 3: Collaborative Execution Assessment. Finally, we evaluate the agents’ Orchestrability in a multi- agent environment where the central Orchestrator is kept fixed. We first measure Skill F1 as a metric of Specification Quality, evaluating how effectively the Agentization method constructs an Agent Card to present its functionalities. This metric is calculated by comparing the generated skill descriptions against the Ground Truth agent capabilities. As shown in Table 3, both EnvX (66.2%) and Claude Code (63.0%) achieve high Skill F1 scores, suggesting superior self-description capabilities. This high specification quality correlates positively with Orchestration Success Rate (Orch. SR). Notably, in Hard scenarios requiring long-chain reasoning, agents with higher Skill F1 scores (EnvX and Claude Code) maintain significantly higher robustness (44.4%) compared to others (≈25-30%). However, regarding final Execution Success Rate (Exec. SR), OpenHands achieves the highest Overall Execution SR (46.2%) despite having the lowest Orchestration SR (65.1%). This result reinforces the findings from the Capability Inher- itance Assessment (Stage 2), highlighting the exceptional robustness of the OpenHands execution engine, which remains highly effective even in complex collaborative settings. Table 3: Skill Specification Quality: Precision, Recall, and F1 (in %). FrameworkPrecision↑Recall↑F1↑ Claude Code70.470.463.0 Codex50.047.842.1 OpenHands65.269.759.9 EnvX69.874.066.2 11 Agentization of Digital Assets for the Agentic Web Table 4: Stage 3 Results: Collaborative Execution. We report Orchestration SR (Orch., %) and Execution SR (Exec., %). Collaboration Chain Length: Easy=2–3, Med=4–5, Hard=6+. EasyMediumHardOverall FrameworkOr.SR↑ Ex.SR↑ Or.SR↑ Ex.SR↑ Or.SR↑ Ex.SR↑ Or.SR↑ Ex.SR↑ Claude Code81.648.067.239.344.47.471.539.2 Codex83.754.159.032.825.97.467.240.3 OpenHands81.663.354.134.429.611.165.146.2 EnvX83.761.257.423.044.411.169.441.4 5.3 Analysis Based on the experimental results, we further analyze the failure patterns across the agent’s lifespan. Our comparative analysis identifies three critical optimization directions for Agentization, aiming to resolve bot- tlenecks spanning from environment configuration and skill construction to autonomous self-description. Challenge 1: Environment Pre-configuration. Failures in environment pre-configuration stem from the inability to resolve system dependencies, manifesting as Startup Failures, A2A Schema Non-compliance, or most frequently, Unusable Skills. These failures force agents into costly runtime troubleshooting or raw terminal usage (hand-crafting), which significantly inflates token consumption. This operational overhead is starkly illustrated by the aizynthfinder trajectory, wherein an unconfigured environment forced the agent to expend 6.5 minutes executing 22 distinct package management operations (see Appendix A.1). Such toolchain misalignments ultimately necessitated a disproportionate synchroniza- tion of over 150 packages merely to resolve a single dependency, underscoring the severity of the debugging loop. Challenge 2: Skill Construction. Failures in skill construction arise from unverified alignment between generated code and repository implementation, typically appearing as Hallucinated APIs (non-existent functions) or Incorrect Signatures. The segment-anything trajectory exemplifies this fragility: the segment_with_points tool repeatedly rejected valid semantic inputs due to a type signature mismatch (expecting objects but receiving strings) (see Appendix A.2). Unable to resolve this misalignment, agents are forced to abandon encapsulated skills in favor of unstable raw code generation. This failure mode proves systemic, with analysis revealing that 100% of segmentation tool calls failed due to similar implementation defects, driving the bypass of efficiency-enhancing abstractions. Challenge 3: Capability Specification. This challenge concerns the construction of the Agent Card, which serves as the agent’s functional profile and advertisement on the Agentic Web. Failures in self-description bottleneck collaboration by blurring tool implementation with functional advertisement. Generic descriptions prevent the Orchestrator from distinguishing specific agent roles. This is prominently evident in OpenHands (Table 4), where dispatch failures stem from two distinct mechanisms. First, semantic blurring caused the incorrect deployment of the speechbrain_agent due to broad advertisements that overshadowed the specialized spleeter_agent (see Appendix A.3). Second, structural indistinguishability occurred where chemlib and chemformula shared identical "Generic repository agent" profiles. These ambiguities force the orchestrator to abandon deterministic role matching in favor of error-prone heuristic guessing. 6 Conclusion In this paper, we study the supply-side challenge of the Agentic Web and conceptualize agentization as the process of transforming digital assets, such as passive software repositories, into interoperable agents. We outline a basic agentization workflow and use it to systematically examine the difficulties encountered when activating real-world code repos. Our extensive experiments reveal that successful agentization hinges on three critical pillars: robust Environment pre-configuration, reliable Skill Construction, and clear self- description to enable effective multi-agent collaboration. By identifying these core challenges, we provide 12 Agentization of Digital Assets for the Agentic Web a roadmap for future research to bridge the gap between isolated software tools and a fully interconnected Agentic Web. References [1] A2A Project. Agent2agent (A2A) protocol. https://a2a-protocol.org/v0.3.0/, 2025. [2] Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. Gpt-4 technical report. arXiv preprint arXiv:2303.08774, 2023. [3] Anthropic. Claude sonnet 4.5 system card. https://w.anthropic.com/claude-sonne t-4-5-system-card, October 2025. [4] Anthropic. Agent skills. https://platform.claude.com/docs/en/agents-and-too ls/agent-skills/overview, 2025. [5] Anthropic. Model context protocol (MCP). https://modelcontextprotocol.io/docs, 2025. [6] Natalie M Banta. Property interests in digital assets: The rise of digital feudalism. Cardozo L. Rev., 38: 1099, 2016. [7] Guangyao Chen, Siwei Dong, Yu Shu, Ge Zhang, Jaward Sesay, Börje F. Karlsson, Jie Fu, and Yemin Shi. Autoagents: A framework for automatic agent generation, 2024. URL https://arxiv.org/ abs/2309.17288. [8] Linyao Chen, Zimian Peng, Yingxuan Yang, Yikun Wang, Wenzheng Tom Tang, Hiroki H Kobayashi, and Weinan Zhang. Envx: Agentize everything with agentic ai. arXiv preprint arXiv:2509.08088, 2025. [9] Xiang Deng, Yu Gu, Boyuan Zheng, Shijie Chen, Samuel Stevens, Boshi Wang, Huan Sun, and Yu Su. Mind2web: Towards a generalist agent for the web, 2023. URL https://arxiv.org/abs/2306 .06070. [10] Aleksandra Eliseeva, Alexander Kovrigin, Ilia Kholkin, Egor Bogomolov, and Yaroslav Zharov. En- vbench: A benchmark for automated environment setup. arXiv preprint arXiv:2503.14443, 2025. [11] Taicheng Guo, Xiuying Chen, Yaqi Wang, Ruidi Chang, Shichao Pei, Nitesh V Chawla, Olaf Wiest, and Xiangliang Zhang. Large language model based multi-agents: A survey of progress and challenges. arXiv preprint arXiv:2402.01680, 2024. [12] Zihan Guo, Yuanjian Zhou, Chenyi Wang, Linlin You, Minjie Bian, and Weinan Zhang. Betaweb: Towards a blockchain-enabled trustworthy agentic web. arXiv preprint arXiv:2508.13787, 2025. [13] Sirui Hong, Mingchen Zhuge, Jonathan Chen, Xiawu Zheng, Yuheng Cheng, Jinlin Wang, Ceyao Zhang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, et al. Metagpt: Meta programming for a multi- agent collaborative framework. In The twelfth international conference on learning representations, 2023. [14] Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. Swe-bench: Can language models resolve real-world github issues?arXiv preprint arXiv:2310.06770, 2023. [15] Yubin Kim, Ken Gu, Chanwoo Park, Chunjong Park, Samuel Schmidgall, A Ali Heydari, Yao Yan, Zhihan Zhang, Yuchen Zhuang, Mark Malhotra, et al. Towards a science of scaling agent systems. arXiv preprint arXiv:2512.08296, 2025. [16] Fei Lei, Yibo Yang, Wenxiu Sun, and Dahua Lin. Mcpverse: An expansive, real-world benchmark for agentic tool use. arXiv preprint arXiv:2508.16260, 2025. 13 Agentization of Digital Assets for the Agentic Web [17] Guohao Li, Hasan Hammoud, Hani Itani, Dmitrii Khizbullin, and Bernard Ghanem. Camel: Commu- nicative agents for" mind" exploration of large language model society. Advances in Neural Information Processing Systems, 36:51991–52008, 2023. [18] Jia Li, Ge Li, Xuanming Zhang, Yihong Dong, and Zhi Jin. Evocodebench: An evolving code genera- tion benchmark aligned with real-world code repositories. arXiv preprint arXiv:2404.00599, 2024. [19] Jia Li, Ge Li, Yunfei Zhao, Yongmin Li, Huanyu Liu, Hao Zhu, Lecheng Wang, Kaibo Liu, Zheng Fang, Lanshen Wang, et al. Deveval: A manually-annotated code generation benchmark aligned with real-world code repositories. In Findings of the Association for Computational Linguistics: ACL 2024, p. 3603–3614, 2024. [20] Xinyi Li, Sai Wang, Siqi Zeng, Yu Wu, and Yi Yang. A survey on llm-based multi-agent systems: workflow, infrastructure, and challenges. Vicinagearth, 1(1):9, 2024. [21] Yaobo Liang, Chenfei Wu, Ting Song, Wenshan Wu, Yan Xia, Yu Liu, Yang Ou, Shuai Lu, Lei Ji, Shaoguang Mao, et al. Taskmatrix. ai: Completing tasks by connecting foundation models with millions of apis. Intelligent Computing, 3:0063, 2024. [22] Zijie Lin, Yiqing Shen, Qilin Cai, He Sun, Jinrui Zhou, and Mingjun Xiao. Autop2c: An llm-based agent framework for code repository generation from multimodal content in academic papers. arXiv preprint arXiv:2504.20115, 2025. [23] Tianyang Liu, Canwen Xu, and Julian McAuley. Repobench: Benchmarking repository-level code auto-completion systems. arXiv preprint arXiv:2306.03091, 2023. [24] Weiwen Liu, Xu Huang, Xingshan Zeng, Xinlong Hao, Shuai Yu, Dexun Li, Shuai Wang, Weinan Gan, Zhengying Liu, Yuanqing Yu, Zezhong Wang, Yuxian Wang, Wu Ning, Yutai Hou, Bin Wang, Chuhan Wu, Xinzhi Wang, Yong Liu, Yasheng Wang, Duyu Tang, Dandan Tu, Lifeng Shang, Xin Jiang, Ruiming Tang, Defu Lian, Qun Liu, and Enhong Chen. Toolace: Winning the points of llm function calling, 2025. URL https://arxiv.org/abs/2409.00920. [25] Jiacheng Miao, Joe R Davis, Yaohui Zhang, Jonathan K Pritchard, and James Zou. Paper2agent: Reimagining research papers as interactive and reliable ai agents. arXiv preprint arXiv:2509.06917, 2025. [26] Ziyi Ni, Huacan Wang, Shuo Zhang, Shuo Lu, Ziyang He, Zhenheng Tang, Sen Hu, Bo Li, Chen Hu, Binxing Jiao, et al. Gittaskbench: A benchmark for code agents solving real-world tasks through code repository leveraging. In Proceedings of the AAAI Conference on Artificial Intelligence, volume 40, p. 32564–32572, 2026. [27] OpenAI. Introducing GPT-5.2-codex. https://openai.com/index/introducing-gpt-5 -2-codex/, December 2025. [28] Joon Sung Park, Joseph O’Brien, Carrie Jun Cai, Meredith Ringel Morris, Percy Liang, and Michael S Bernstein. Generative agents: Interactive simulacra of human behavior. In Proceedings of the 36th annual acm symposium on user interface software and technology, p. 1–22, 2023. [29] Yujia Qin, Shihao Liang, Yining Ye, Kunlun Zhu, Lan Yan, Yaxi Lu, Yankai Lin, Xin Cong, Xiangru Tang, Bill Qian, et al. Toolllm: Facilitating large language models to master 16000+ real-world apis. arXiv preprint arXiv:2307.16789, 2023. [30] Jielin Qiu, Zuxin Liu, Zhiwei Liu, Rithesh Murthy, Jianguo Zhang, Haolin Chen, Shiyu Wang, Ming Zhu, Liangwei Yang, Juntao Tan, et al. Locobench: A benchmark for long-context large language models in complex software engineering. arXiv preprint arXiv:2509.09614, 2025. [31] Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Eric Hambro, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. Toolformer: Language models can teach them- selves to use tools. Advances in Neural Information Processing Systems, 36:68539–68551, 2023. 14 Agentization of Digital Assets for the Agentic Web [32] Alp Toygar, CE Rohm Jr, and Jake Zhu. A new asset type: digital assets. Journal of International Technology and Information Management, 22(4):7, 2013. [33] Guanzhi Wang, Yuqi Xie, Yunfan Jiang, Ajay Mandlekar, Chaowei Xiao, Yuke Zhu, Linxi Fan, and Anima Anandkumar. Voyager: An open-ended embodied agent with large language models, 2023. URL https://arxiv.org/abs/2305.16291. [34] Huacan Wang, Ziyi Ni, Shuo Zhang, Shuo Lu, Sen Hu, Ziyang He, Chen Hu, Jiaye Lin, Yifu Guo, Ronghao Chen, Xin Li, Daxin Jiang, Yuntao Du, and Pin Lyu. Repomaster: Autonomous exploration and understanding of github repositories for complex task solving, 2025. URL https://arxiv.or g/abs/2505.21577. [35] Xingyao Wang, Boxuan Li, Yufan Song, Frank F Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, et al. Openhands: An open platform for ai software developers as generalist agents. arXiv preprint arXiv:2407.16741, 2024. [36] Yikun Wang, Zuyan Liu, Ziyi Wang, Han Hu, Pengfei Liu, and Yongming Rao. Geovista: Web- augmented agentic visual reasoning for geolocalization. arXiv preprint arXiv:2511.15705, 2025. [37] Zhenting Wang, Qi Chang, Hemani Patel, Shashank Biju, Cheng-En Wu, Quan Liu, Aolin Ding, Alireza Rezazadeh, Ankit Shah, Yujia Bao, et al. Mcp-bench: Benchmarking tool-using llm agents with com- plex real-world tasks via mcp servers. arXiv preprint arXiv:2508.20453, 2025. [38] Georg Wölflein, Dyke Ferber, Daniel Truhn, Ognjen Arandjelovic, and Jakob Nikolas Kather. Llm agents making agent tools. In Proceedings of the 63rd Annual Meeting of the Association for Computa- tional Linguistics (Volume 1: Long Papers), p. 26092–26130, 2025. [39] Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, et al. Autogen: Enabling next-gen llm applications via multi-agent conver- sations. In First Conference on Language Modeling, 2024. [40] Tianqi Xu, Linyao Chen, Dai-Jie Wu, Yanjun Chen, Zecheng Zhang, Xiang Yao, Zhiqiang Xie, Yongchao Chen, Shilong Liu, Bochen Qian, Anjie Yang, Zhaoxuan Jin, Jianbo Deng, Philip Torr, Bernard Ghanem, and Guohao Li. CRAB: Cross-environment agent benchmark for multimodal lan- guage model agents. In Wanxiang Che, Joyce Nabende, Ekaterina Shutova, and Mohammad Taher Pile- hvar (eds.), Findings of the Association for Computational Linguistics: ACL 2025, p. 21607–21647, Vienna, Austria, July 2025. Association for Computational Linguistics. ISBN 979-8-89176-256-5. doi: 10.18653/v1/2025.findings-acl.1113. URL https://aclanthology.org/2025.findings -acl.1113/. [41] Yunhe Yan, Shihe Wang, Jiajun Du, Yexuan Yang, Yuxuan Shan, Qichen Qiu, Xianqing Jia, Xinge Wang, Xin Yuan, Xu Han, et al. Mcpworld: A unified benchmarking testbed for api, gui, and hybrid computer use agents. arXiv preprint arXiv:2506.07672, 2025. [42] Yingxuan Yang, Huacan Chai, Yuanyi Song, Siyuan Qi, Muning Wen, Ning Li, Junwei Liao, Haoyi Hu, Jianghao Lin, Gaowei Chang, et al. A survey of ai agent protocols. arXiv preprint arXiv:2504.16736, 2025. [43] Yingxuan Yang, Mulei Ma, Yuxuan Huang, Huacan Chai, Chenyu Gong, Haoran Geng, Yuanjian Zhou, Ying Wen, Meng Fang, Muhao Chen, et al. Agentic web: Weaving the next web with ai agents. arXiv preprint arXiv:2507.21206, 2025. [44] Yingxuan Yang, Chengrui Qu, Muning Wen, Laixi Shi, Ying Wen, Weinan Zhang, Adam Wierman, and Shangding Gu. Understanding agent scaling in llm-based multi-agent systems via diversity. arXiv preprint arXiv:2602.03794, 2026. [45] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik R Narasimhan, and Yuan Cao. React: Synergizing reasoning and acting in language models. In The eleventh international conference on learning representations, 2022. 15 Agentization of Digital Assets for the Agentic Web [46] Shunyu Yao, Dian Yu, Jeffrey Zhao, Izhak Shafran, Thomas L. Griffiths, Yuan Cao, and Karthik Narasimhan. Tree of thoughts: Deliberate problem solving with large language models, 2023. URL https://arxiv.org/abs/2305.10601. [47] Chaoyun Zhang, Liqun Li, He Huang, Chiming Ni, Bo Qiao, Si Qin, Yu Kang, Minghua Ma, Qingwei Lin, Saravan Rajmohan, et al. Ufo 3 : Weaving the digital agent galaxy. arXiv preprint arXiv:2511.11332, 2025. [48] Peiyuan Zhang, Guangtao Zeng, Tianduo Wang, and Wei Lu. Tinyllama: An open-source small lan- guage model. arXiv preprint arXiv:2401.02385, 2024. [49] Yiqun Zhang, Hao Li, Chenxu Wang, Linyao Chen, Qiaosheng Zhang, Peng Ye, Shi Feng, Daling Wang, Zhen Wang, Xinrun Wang, et al. The avengers: A simple recipe for uniting smaller language models to challenge proprietary giants. arXiv preprint arXiv:2505.19797, 2025. 16 Agentization of Digital Assets for the Agentic Web A Case Study In this section, we present a collection of representative execution trajectories and examples that illustrate the diverse failure modes and decision-making challenges analyzed in the case studies. A.1 Case 1: Environment Pre-configuration Listing 1: Aizynthfinder Agent Environment Configuration Trajectory (Simplified) # ------------------------------ # 1. Attempting Standard Pip (Failed) # ------------------------------ # Error: No such file or directory [VENV_PATH]/bin/pip install python-docx # Error: No such file or directory .venv/bin/pip install python-docx # Error: No module named ’pip’ inside venv .venv/bin/python3 -m pip install python-docx # ------------------------------ # 2. Switching to ’uv’ Tool & Partial Fixes # ------------------------------ # Verified ’uv’ package manager availability which uv # Installed successfully, but environment mismatch occurred later uv pip install python-docx # ------------------------------ # 3. Manual Path Patching # ------------------------------ # Action: Manually injected library path into run_retroplanning.py # Code inserted: sys.path.insert(0, "/path/to/aizynthfinder") # Failed: Fixed first import error, but hit ModuleNotFoundError for ’rdchiral’ python3 run_retroplanning.py # Cleanup: Removed lines 17-19 to revert to a clean state sed -i ’17,19d’ run_retroplanning.py # ------------------------------ # 4. Dependency Reset # ------------------------------ # Attempted to install current package (failed/incomplete) source .venv/bin/activate && uv pip install -e . # Major Action: Triggered massive uninstall (170 pkgs) and reinstall (15 pkgs) uv sync # Re-installed core dependencies after sync source .venv/bin/activate && uv pip install rdchiral rdkit aizynthfinder # Re-installed ’python-docx’ into the specific venv python uv pip install python-docx --python .venv/bin/python3 A.2 Case 2: Skill Construction Listing 2: The provided trajectory exemplifies the fragility of skill construction. "index": 1, "timestamp": "2026-01-07T15:06:00.574575", "type": "AssistantMessage", "data": "content": [ 17 Agentization of Digital Assets for the Agentic Web "text": "I’l segment the dog from the background using the Segment Anything Model with the point prompt you provided." ], "model": "claude-sonnet-4-5-20250929", "parent_tool_use_id": null, "error": null , "index": 2, "timestamp": "2026-01-07T15:06:01.596017", "type": "AssistantMessage", "data": "content": [ "id": "toolu_011zcKdQ6vnc2gRjJhREtDpi", "name": "mcp__repo__segment_with_points", "input": "image_path": "/tmp/a2a_agent_05gvew92/dog.jpg", "point_coords": "[[500, 400]]", "point_labels": "[1]", "model_type": "vit_h" ], "model": "claude-sonnet-4-5-20250929", "parent_tool_use_id": null, "error": null A.3 Case 3: Capability Specification Listing 3: Spleeter Agent Agentcard configured by OpenHands "capabilities": "streaming": false , "defaultInputModes": [ "text/plain", "audio/mpeg", "audio/wav" ], "description": "AI-powered audio source separation agent using Spleeter.", "name": "spleeter_audio_separation_agent", "version": "1.0.0" B Repositories Used to Build the A2A-Agentization Benchmark The repositories are organized by domain, as described below. 1) Document and Web Parsing with OCR • Tesseract: A classic open-source OCR engine primarily written in C++, featuring multilingual support and a large ecosystem. GitHub: https://github.com/tesseract-ocr/tesseract • EasyOCR: An out-of-the-box OCR solution based on PyTorch, supporting more than 80 languages and suitable for rapid integration. GitHub: https://github.com/JaidedAI/EasyOCR • textract: A unified interface for extracting plain text from almost any document format (e.g., Word, PDF), often relying on external engines. GitHub: https://github.com/deanmalmgren/textract • tika-python: Python bindings for Apache Tika, enabling text and metadata extraction via the Tika REST service. GitHub: https://github.com/chrismattmann/tika-python • camelot: A library for structured table extraction from PDF documents. GitHub: https://github.com/camelot-dev/camelot • python-docx2txt: A utility for extracting text and images from .docx files. GitHub: https://github.com/ankushshah89/python-docx2txt 18 Agentization of Digital Assets for the Agentic Web • Unstructured: An LLM-oriented document processing pipeline supporting ETL, chunking, and structured representations. GitHub: https://github.com/Unstructured-IO/unstructured 2) Web and Platform Scraping for Text Acquisition • trafilatura: A tool for extracting main content and metadata from web pages, supporting command- line and batch processing. GitHub: https://github.com/adbar/trafilatura • yt-dlp: A multi-site audio and video downloader supporting YouTube and other platforms. GitHub: https://github.com/yt-dlp/yt-dlp • youtube-transcript-api: A library for retrieving YouTube subtitles and auto-generated captions without requiring an API key. GitHub: https://github.com/jdepoix/youtube-transcript-api • MediaCrawler: A crawler framework for collecting content and comments from platforms such as Xiaohongshu, Douyin, Kuaishou, Bilibili, Weibo, Tieba, and Zhihu. GitHub: https://github.com/NanmiCoder/MediaCrawler 3) Speech and Audio Processing (ASR, VAD, Separation, End-to-End Systems) • speechbrain: A PyTorch-based speech processing toolkit supporting ASR, TTS, keyword spotting, and related tasks. GitHub: https://github.com/speechbrain/speechbrain • ESPnet: An end-to-end speech processing toolkit covering ASR, TTS, and speech translation. GitHub: https://github.com/espnet/espnet • silero-vad: A pretrained voice activity detection (VAD) model optimized for real-time usage. GitHub: https://github.com/snakers4/silero-vad • spleeter: A music source separation tool for isolating vocals and accompaniment using pretrained models. GitHub: https://github.com/deezer/spleeter 4) Vision and Video Processing and Generation • Segment Anything (SAM): A general-purpose, promptable image segmentation model. GitHub: https://github.com/facebookresearch/segment-anything • Ultralytics: Official implementations and toolchains for the YOLO family, including object detec- tion, segmentation, and pose estimation. GitHub: https://github.com/ultralytics/ultralytics • AnimeGANv3: A framework for converting photos and videos into anime-style imagery. GitHub: https://github.com/TachibanaYoshino/AnimeGANv3 • transparent-background: A background removal tool based on the InSPyReNet architecture. GitHub: https://github.com/plemeri/transparent-background • Bringing Old Films Back to Life: A system for old film restoration, published at CVPR 2022. GitHub: https://github.com/raywzy/Bringing-Old-Films-Back-to-Life • PySceneDetect: A library for video shot boundary detection and scene transition analysis. GitHub: https://github.com/Breakthrough/PySceneDetect 19 Agentization of Digital Assets for the Agentic Web • moviepy: A Python-based video editing framework supporting clipping, concatenation, effects, and text overlays. GitHub: https://github.com/Zulko/moviepy • ffmpeg-python: Python bindings for FFmpeg, including support for complex filter graphs. GitHub: https://github.com/kkroening/ffmpeg-python • Stable Diffusion (CompVis): A diffusion-based text-to-image generation model. GitHub: https://github.com/CompVis/stable-diffusion 5) Development Security and Vulnerability Detection • Bandit (PyCQA): A static analysis tool for identifying common security issues in Python code- bases. GitHub: https://github.com/PyCQA/bandit • trufflehog: A tool for discovering and verifying leaked secrets in source code repositories and commit histories. GitHub: https://github.com/trufflesecurity/trufflehog • sqlmap: An automated tool for detecting and exploiting SQL injection vulnerabilities and database takeover. GitHub: https://github.com/sqlmapproject/sqlmap • Bolt (s0md3v): A scanner designed to detect Cross-Site Request Forgery (CSRF) vulnerabilities. GitHub: https://github.com/s0md3v/Bolt 6) NLP, String Processing, and Prompt Engineering • RapidFuzz: A high-performance library for fuzzy string matching and similarity measurement. GitHub: https://github.com/rapidfuzz/RapidFuzz • prompt-optimizer: A tool for optimizing prompts to improve the quality and effectiveness of LLM interactions. GitHub: https://github.com/linshenkx/prompt-optimizer 7) Chemistry, Molecular Analysis, and Synthesis Planning • AiZynthFinder: A retrosynthetic planning system for organic chemistry based on Monte Carlo Tree Search. GitHub: https://github.com/MolecularAI/aizynthfinder • ChemFormula: A utility for parsing chemical formulas, computing molecular weights, and format- ting outputs. GitHub: https://github.com/molshape/ChemFormula • chemlib: A general-purpose Python library for chemical calculations, periodic table access, and stoichiometry. GitHub: https://github.com/harirakul/chemlib 8) Web, Backend, and General Frameworks • bottle: A lightweight Python web microframework that can be deployed as a single-file application. GitHub: https://github.com/bottlepy/bottle 9) Financial Backtesting • backtrader: A quantitative trading strategy backtesting framework supporting multiple data feeds, commissions, visualization, and optimization. GitHub: https://github.com/mementum/backtrader 20 Agentization of Digital Assets for the Agentic Web C Prompts C.1 Agentization Prompt This section presents the prompts used to invoke four distinct frameworks for the agentization process. Claude Code IMPORTANT: You are working in repository directory: cwd CRITICAL: All commands MUST be executed in the repository directory. Always prefix your commands with: cd cwd && For example: - cd cwd && uv sync - cd cwd && source .venv/bin/activate - cd cwd && python -m pytest This ensures that virtual environments (.venv) and all generated files are created in the correct repository location. Now, carefully read the content in agentify_md_path and generate an agent according to its requirements and instructions. Specific requirements: 1. Read the agentify.md file completely and understand all phase requirements 2. Execute systematically according to Phases 1-4 in the documentation: - Phase 1: Environment Setup (remember to cd cwd before uv sync!) - Phase 2: Repository Analysis - Phase 3: Agent Setup & Customization - Phase 4: Testing and Deployment 3. Generate all required files: - skills.json (skill configuration) - repo_func.md (repository documentation) - .env (environment configuration) - Other necessary configuration files 4. Set default port to: target_port 5. Verify after completing each phase 6. Use Claude Agent SDK as the agent execution engine Please explain each step in detail and provide test verification results after completion. Codex IMPORTANT: You are working in repository directory: $this.cwd CRITICAL: All commands MUST be executed in the repository directory. Always prefix your commands with: cd $this.cwd && For example: - cd $this.cwd && uv sync - cd $this.cwd && source .venv/bin/activate - cd $this.cwd && python -m pytest 21 Agentization of Digital Assets for the Agentic Web This ensures that virtual environments (.venv) and all generated files are created in the correct repository location. Now, carefully read the content in $this.agentifyMdPath and generate an agent according to its requirements and instructions. Specific requirements: 1. Read the agentify.md file completely and understand all phase requirements 2. Execute systematically according to Phases 1-4 in the documentation: - Phase 1: Environment Setup (remember to cd $this.cwd before uv sync !) - Phase 2: Repository Analysis - Phase 3: Agent Setup & Customization - Phase 4: Testing and Deployment 3. Generate all required files: - skills.json (skill configuration) - repo_func.md (repository documentation) - .env (environment configuration) - Other necessary configuration files 4. Set default port to: $this.targetPort 5. Verify after completing each phase 6. Use Codex SDK as the agent execution engine Please explain each step in detail and provide test verification results after completion. Openhands IMPORTANT: First, create an isolated Python virtual environment in the current workspace using uv (if it doesn’t exist): 1. Check if .venv directory already exists 2. If not, run: uv venv .venv --seed -p 3.12 3. Activate the virtual environment: source .venv/bin/activate 4. Verify Python interpreter: which python (should point to workspace’s . venv/bin/python) 5. All subsequent operations MUST be executed in the activated virtual environment Then, carefully read the requirements in agentify_md_path, generate a todo list. Following the todo list and requirements, automatically execute the related operations to build an a2a agent in this workspace . After building, carefully check the agent’s functionality, ensure all skills are correctly loaded, and test with test_client script to ensure each skill is available. The .env template is located in templates/, default port is port NOTE: All dependency installations should use ’uv pip install’, and all commands must be executed in the activated virtual environment. EnvX You are an expert A2A agent developer. Your task is to help build an A2A- compliant agent from a code repository by following the comprehensive agentify guide. 22 Agentization of Digital Assets for the Agentic Web ## Working Directory: cwd CRITICAL: You are working in repository directory: cwd All bash commands MUST be executed in the repository directory. Always prefix your commands with: cd cwd && Examples: - cd cwd && uv sync - cd cwd && source .venv/bin/activate && python -m pytest This ensures that virtual environments (.venv) and all generated files are created in the correct repository location. ## Your Capabilities: - Read and analyze repository code and documentation - Create and edit Python files (agent.py, config.py, skills.json, etc.) - Execute bash commands for testing and verification - Search and grep code to understand structure ## Agentify Guide Location: agentify_md_path ## Your Task: Carefully read the content in agentify_md_path and generate an agent according to its requirements and instructions. ## Specific Requirements: 1. ** Read the agentify.md file completely ** and understand all phase requirements 2. ** Execute systematically ** according to Phases 1-4 in the documentation : - Phase 1: Environment Setup (remember to cd cwd before uv sync!) - Phase 2: Repository Analysis - Phase 3: Agent Setup & Customization - Phase 4: Testing and Deployment 3. ** Generate all required files: ** - skills.json (skill configuration) - repo_func.md (repository documentation) - .env (environment configuration) - Other necessary configuration files 4. ** Set default port to: ** target_port 5. ** Test as you go ** - verify each phase before moving to the next 6. ** Be thorough ** - complete all phases from environment setup to testing 7. ** Always use cd cwd && ** before any bash command ## Implementation Notes: - The agent template uses Claude Agent SDK as the execution engine - skills.json defines repository functions exposed as agent skills - Always verify file paths and imports before creating configurations ## Your Workflow: 1. Read and understand the agentify.md guide 2. Analyze the target repository structure 23 Agentization of Digital Assets for the Agentic Web 3. Follow each phase in the guide systematically 4. Create all required files and configurations 5. Test the agent thoroughly Start by carefully reading the agentify.md file, then proceed phase by phase. Please explain each step in detail and provide test verification results after completion. C.2 Agent skill Judge Prompt Prompt: Skill Coverage Judgement. This prompt judges whether a test skill is covered by a target skill set, based on actual capability. Prompt: Skill Coverage Judgement "role": "evaluator", "instruction": "You are a strict but pragmatic evaluator. Your task is to determine whether the Test Skill is covered (i.e., contained) by the Target Skill Set at the level of actual capability.", "rules": [ "One-to-one correspondence is not required. A test skill may map to one or multiple target skills.", "Partial matching is allowed only if the core capability is covered.", "Name similarity alone is insufficient; judgement must be based on functionality, descriptions, tags, and examples.", "The output must be valid JSON only, with no additional text." ], "output_format": "hit": "0 or 1" , "inputs": "test_skill": "json.dumps(q, ensure_ascii=False)", "target_skill_set": "json.dumps(tgt, ensure_ascii=False)" C.3 Single-Repo Data Generation Prompts Prompt 1: Repository Capability Analysis and Task Ideation. This prompt requests a structured capa- bility summary of the repository and a set of lightweight, file-producing evaluation tasks. Prompt 1: Repository Capability Analysis and Task Ideation Repository location: <path> Path requirement: - Use absolute paths for every file you read or write. - Do not use relative paths, including dot-prefixed paths. 24 Agentization of Digital Assets for the Agentic Web Output file: - Write the repository capability summary to: <path> Tasks: 1) Read the repository README and determine the primary capabilities and intended usage. 2) Identify whether the repository provides a ready-to-run demo. - If a demo exists, document how to run it and what output artifact it produces. 3) Propose 10 simple evaluation tasks that test whether a code agent can use the repository effectively. - Each task must be executable end-to-end and must produce a concrete artifact file (audio/video/image/pdf/csv preferred; structured JSON is acceptable). - Avoid training procedures and other compute-intensive workflows. - Do not request a narrative "understanding" or an architecture overview as the final output. - Prefer tasks aligned with the repository demo(s), reusing demo inputs when applicable. - Specify expected inputs and a clear target artifact for each task. - Tasks must not require Docker. - Tasks must not require external APIs or secret keys. Write the capability summary and the 10 proposed tasks to: <path> Prompt 2: Task Specification and Feasibility Validation. This prompt converts the proposed tasks into reproducible task files and validates feasibility by executing each task once. Prompt 2: Task Specification and Feasibility Validation Path requirement: - Use absolute paths for every file you read or write. - Do not use relative paths, including dot-prefixed paths. For the 10 tasks you proposed (Task 1-10), create one task specification file per task: <path> For each task, you must: 1) Provide a precise task description (inputs, required operations, and expected artifact). 2) Execute the task yourself once to confirm it is feasible and can be completed successfully. 3) Define an objective success criterion based on the produced artifact file. If a task requires input files, store them under: <path> Use the following task specification format: 1. Task Description 2. Detailed Inputs 3. Your Execution Trace (not shown to the evaluated agent; write step-by- step commands and outputs) 25 Agentization of Digital Assets for the Agentic Web 4. Expected Output (the artifact file and key properties used for validation) Environment requirement: - Create and activate a new conda environment named repo_name. - If conda is installed at a fixed absolute location, reference it explicitly (for example, <path>). - Install any required tools via pip within that environment. Prompt 3: Judge Standard Extraction from Verified Runs. This prompt extracts concrete evaluation steps and a standardized expected response from verified execution logs. Prompt 3: Judge Standard Extraction Path requirement: - Use absolute paths for every file you read or write. - Do not use relative paths, including dot-prefixed paths. Execute tasks 1-10 again, and extract the major execution steps from the run logs using the format: Step1: action 1, Output 1 Step2: action 2, Output 2 ... Requirements: 1) Each action must be a concrete operation (exact commands, scripts, and tools used), not a vague description. Save to: <path> 2) Also record: - What the final artifact looks like, and - What the agent should say when delivering the artifact in its final response. Save to: <path> 3) If you cannot complete a task, delete the entire task folder for that task (do not claim completion). 4) After validation, delete the repo_name conda environment. Prompt 4: Consolidation into a Single JSON Dataset. This prompt consolidates all validated tasks into a single structured JSON file suitable for downstream benchmark ingestion. Prompt 4: JSON Consolidation Path requirement: - Use absolute paths for every file you read or write. - Do not use relative paths, including dot-prefixed paths. Consolidate all tasks into a single JSON file: <path> Each task entry must follow this schema: "task_id": "repo_name_task_task_num", "task_category": "single_agent", 26 Agentization of Digital Assets for the Agentic Web "task_description": "the description of the task", "fuzzy_description": "fuzzy description of the task", "input_parts": [ "kind": "text", "text": "the description of the task" , "kind": "file", "file": "path": "<path>", "mime_type": "..." ] C.4 Multi-Repo Data Generation Prompts Multi-Repo Task Generation Search Agent Prompt Your task now is: based on a set of GitHub repositories I provide, construct multiple ‘multi-hop tasks.’ Specifically, for this round, generate 3 tasks, each with exactly 3 hops (3-step chains). No need to generate too many tasks. Core requirements: Try to ensure each hop corresponds to a different repository. Each task must require multiple steps/rounds to complete. Every step must explicitly specify: which repository is used, what action is performed, what output is produced. The final result must be verifiable (e.g., files, logs, script return codes, data structures, etc.). The task granularity should be as fine as possible, not vague or hand-wavy . Because the chosen repositories will likely involve many file types, an example could be: the first repository takes an input file, processes it, and passes the output artifact to later repositories. In that case, how to obtain the initial input file from the first repository becomes very important. For this ‘where do the files come from’ part, I want you to draw inspiration from each repository’s README and tests. Ideally, you should directly obtain file ideas from the repositories’ tests (or example assets), rather than asking me to provide missing files. You may ask me to fetch the initial file if needed, but do not give me choices. Treat me like a robot with no autonomy; tell me exactly where 27 Agentization of Digital Assets for the Agentic Web to get the file. If the initial file still requires me to create or choose it myself, then forget it, that’s too troublesome. Important rules: We may have many repositories; you do not need to parse them all at once. You may first infer the general domain/purpose from repository names, then select the most valuable repositories that are most likely to be composable into tasks. For the repositories you select, you may further inspect README, examples, tests, etc., to gain deeper understanding. If information is insufficient, do not fabricate. Directly abandon that task idea instead of making things up. Output format requirements (important) When outputting: You may first write 1-3 short paragraphs in natural language describing your thoughts/insights. Then you must output a valid large JSON: The final output must be a JSON array (list) as the top-level structure: [...]. Each element in the array is an object (dict) with the following structure : The top level has only one key: "multi_hop_tasks". The value of "multi_hop_tasks" is an array. To keep granularity clear, each object contains only 1 task (i.e., the " multi_hop_tasks" array length must be 1). For multiple tasks, add more elements to the top-level array, for example: [ "multi_hop_tasks": [ "task_name": "...", "goal": "...", "repo_used": [ "name": "...", "guessed_domain": "...", "reason_selected": "...", "core_capabilities": "...", "i/o": "...", "interfaces": "CLI | API | script | demo" ], 28 Agentization of Digital Assets for the Agentic Web "required_repos": ["repoA", "repoB", "..."], "multi_hop_logic": "Full chain explanation: repoA -> repoB -> repoC ...", "steps": [ "step": 1, "using_repo": "repoA", "action": "...", "expected_output": "...", "why_this_repo": "..." , "step": 2, "using_repo": "repoB", "action": "...", "expected_output": "...", "why_this_repo": "..." ], "final_artifact": "...", "verification": [ "Check whether ... file exists", "Check whether output JSON contains field ...", "Check whether logs contain keyword ...", "Check whether script return code is 0" ] ] , "multi_hop_tasks": [ "...task 2..." : "..." ] , "multi_hop_tasks": [ "...task 3..." : "..." ] ] Additional requirements: Each task must clearly explain what the multi-hop logic is (e.g., repoA produces data -> repoB analyzes/optimizes/verifies -> repoC visualizes /deploys). Tasks should be diverse, don’t make them all the same pattern. Do not assume repository capabilities; if uncertain, either ask questions or make conservative inferences. When there are many repos, you may prioritize the most key/potential ones rather than processing all. 29 Agentization of Digital Assets for the Agentic Web Okay-now you can start classification and processing based on the repositories below. This will be hard; you don’t need to rush. You can think slowly, iterate repeatedly, and search repeatedly. [Repositories Provided] Document/Web parsing & OCR Tesseract: classic open-source OCR engine in C++, multilingual, broad ecosystem. (https://github.com/tesseract-ocr/tesseract ) EasyOCR: PyTorch OCR, out-of-the-box, 80+ languages. Good for quick integration. (https://github.com/JaidedAI/EasyOCR ) textract: unified interface to extract text from ‘almost any document’ ( Word/PDF/etc., often via external engines). (https://github.com/ deanmalmgren/textract ) tika-python: Python bindings for Apache Tika, calls Tika REST to extract text/metadata. (https://github.com/chrismattmann/tika-python ) camelot: structured table extraction from PDFs. (https://github.com/ camelot-dev/camelot ) python-docx2txt: extract text and images from .docx. (https://github.com/ ankushshah89/python-docx2txt ) Unstructured: document ETL/chunking/structuring pipelines for LLMs. (https ://github.com/Unstructured-IO/unstructured ) Web/platform crawling & text acquisition trafilatura: extract main content and metadata from webpages; CLI/batch supported. (https://github.com/adbar/trafilatura ) yt-dlp: multi-site audio/video downloader (YouTube etc.). (https://github. com/yt-dlp/yt-dlp ) youtube-transcript-api: fetch YouTube captions/auto-captions without an API key. (https://github.com/jdepoix/youtube-transcript-api ) MediaCrawler: crawler for Xiaohongshu/Douyin/Kuaishou/Bilibili/Weibo/Tieba /Zhihu, etc. (https://github.com/NanmiCoder/MediaCrawler ) Speech/audio processing (ASR/VAD/separation/end-to-end speech) 30 Agentization of Digital Assets for the Agentic Web speechbrain: PyTorch speech toolkit (ASR/TTS/KWS, etc.). (https://github. com/speechbrain/speechbrain ) ESPnet: end-to-end speech toolkit (ASR/TTS/ST, etc.). (https://github.com/ espnet/espnet ) silero-vad: pretrained voice activity detection. (https://github.com/ snakers4/silero-vad ) spleeter: music source separation (vocals/accompaniment), pretrained. ( https://github.com/deezer/spleeter ) Vision/video processing & generation segment-anything (SAM): general promptable segmentation model. (https:// github.com/facebookresearch/segment-anything ) Ultralytics: official YOLO toolchain for detection/segmentation/pose, etc. (https://github.com/ultralytics/ultralytics ) AnimeGANv3: photo/video anime stylization. (https://github.com/ TachibanaYoshino/AnimeGANv3 ) transparent-background: background removal matting based on InSPyReNet. ( https://github.com/plemeri/transparent-background ) Bringing-Old-Films-Back-to-Life: old film restoration (CVPR 2022). (https ://github.com/raywzy/Bringing-Old-Films-Back-to-Life ) PySceneDetect: video shot boundary / transition detection. (https://github .com/Breakthrough/PySceneDetect ) moviepy: Python video editing (cut/concat/effects/text, etc.). (https:// github.com/Zulko/moviepy ) ffmpeg-python: Python bindings for FFmpeg (incl. complex filters). (https ://github.com/kkroening/ffmpeg-python ) Stable Diffusion (CompVis): text-to-image diffusion model. (https://github .com/CompVis/stable-diffusion ) Dev security / vulnerability detection 31 Agentization of Digital Assets for the Agentic Web Bandit: static security scanner for Python code. (https://github.com/PyCQA /bandit ) trufflehog: find and verify leaked secrets in repos/history. (https:// github.com/trufflesecurity/trufflehog ) sqlmap: automated SQL injection testing and database takeover. (https:// github.com/sqlmapproject/sqlmap ) Bolt (s0md3v): CSRF scanner. (https://github.com/s0md3v/Bolt ) NLP/string processing & prompt engineering RapidFuzz: high-performance fuzzy matching/string similarity metrics. ( https://github.com/rapidfuzz/RapidFuzz ) prompt-optimizer: prompt optimizer for writing higher-quality prompts. ( https://github.com/linshenkx/prompt-optimizer ) Chemistry/molecules & synthesis planning AiZynthFinder: MCTS-based retrosynthesis planning. (https://github.com/ MolecularAI/aizynthfinder ) ChemFormula: parse chemical formulas, compute molar mass, formatting, etc. (https://github.com/molshape/ChemFormula ) chemlib: general chemistry computations/periodic table/stoichiometry, etc. (https://github.com/harirakul/chemlib ) Web/backend & general frameworks bottle: lightweight Python web micro-framework (single-file usable). ( https://github.com/bottlepy/bottle ) Financial backtesting backtrader: quantitative strategy backtesting framework (data feeds/ commission/plotting/optimization, etc.). (https://github.com/mementum/ backtrader ) Multi-Repo Task Generation Code Agent Prompt code_agent_answer_generation_prompt = """ 32 Agentization of Digital Assets for the Agentic Web You are a ** Code Execution Agent ** . A collaborating Search/Task Agent will construct ** multi-hop tasks ** for you based on a set of GitHub repositories, and ** your responsibility is to actually execute these tasks in the local code repositories, verify feasibility, and record execution traces ** . Your primary objective is: ** to audit whether these tasks are reproducible and executable in the current environment ** , rather than "forcing all steps to run no matter what." Your core workflow is: Read the current directory’s ‘data.json‘ -> execute the tasks step by step using the code in ‘code_repos/‘ -> produce real intermediate artifacts (‘artifact/‘) and execution logs (‘traj_log/‘) -> write the final JSON (‘artifact/data_execution.json‘). If, during execution, you discover that the task itself has serious issues or cannot be reasonably continued, you may ** terminate early at an appropriate step ** , and clearly explain the reason in the results. ## 0. Working Directory & File Layout (Hard Constraints) You always work in a directory structured roughly as follows: . |-- artifact/ # Intermediate state files & final result JSON ( data_execution.json) |-- code_repos/ # All GitHub repositories live here | |-- code-repo-A | |-- code-repo-B | ‘-- code-repo-C |-- data.json # Multi-hop task descriptions generated by the Search/Task Agent ‘-- traj_log/ # Step-level debug logs of the execution process Conventions (VERY IMPORTANT): - All multi-hop tasks you need to execute come from ‘./data.json‘. - All code must be run inside ‘./code_repos/<repo_name>/‘. - All intermediate and final artifacts must be written to ‘./artifact/‘. - All execution logs must be written to ‘./traj_log/‘ (you may choose the internal structure, but paths must be traceable in the final JSON). ## 1. Structure of data.json and Field Semantics The overall structure of ‘data.json‘ looks roughly like this: "multi_hop_tasks": [ "task_name": "...", "goal": "...", "repo_used": [ "name": "...", "guessed_domain": "...", "reason_selected": "...", 33 Agentization of Digital Assets for the Agentic Web "core_capabilities": "...", "i/o": "...", "interfaces": "CLI | API | script | demo" ], "required_repos": ["repoA", "repoB", "..."], "multi_hop_logic": "High-level natural language description of the multi-hop data flow: repoA -> repoB -> ...", "steps": [ "step": 1, "using_repo": "repoA", "action": "...", "expected_output": "...", "why_this_repo": "..." , "step": 2, "using_repo": "repoB", "action": "...", "expected_output": "...", "why_this_repo": "..." ], "final_artifact": "...", "verification": [ "Check whether ... file exists", "Check whether output JSON contains field ...", "Check whether script exit code is 0" ] ] Key fields (brief explanations): - ‘multi_hop_tasks‘: A list where each element is an independent multi-hop task (in practice, you are usually given only one). - ‘goal‘: The overall intent of the task, helping you understand what the pipeline is trying to achieve. - ‘repo_used‘: A list describing the repositories involved, intended to give you a rough understanding of each repo’s capabilities: - ‘name / guessed_domain / reason_selected / core_capabilities / i/o / interfaces‘: These are upstream summaries and ** for reference only ** ; the ground truth is always the actual repository files, README, and tests. - ‘required_repos‘: The repositories actually required for this task, typically consistent with ‘using_repo‘. - ‘multi_hop_logic‘: A high-level description of the data flow (e.g., " download video -> scene detection -> editing"). After execution, you must output ‘multi_hop_flow‘ in the results; you may reference this field but do not need to copy it verbatim. - ‘steps‘: The ordered list of concrete steps you must execute: - ‘step‘: Step index (1, 2, 3, ...). 34 Agentization of Digital Assets for the Agentic Web - ‘using_repo‘: The repository to use for this step, corresponding to ‘./ code_repos/<using_repo>/‘. - ‘action‘: A human-language instruction that you must translate into concrete executable commands/scripts. - ‘expected_output‘: The ideal output, used to judge success. - ‘why_this_repo‘: Why this repository is used, to clarify design intent. - ‘final_artifact‘: A natural language description of the ideal final output. You should aim to approximate this and record the actual artifact path in your results. - ‘verification‘: A task-level verification checklist. In ‘data_execution. json‘, you must mark each item as pass / fail / not_applicable, with brief evidence. ## 2. Environment & Tooling Conventions (uv) Before being provided to you, all repositories ** are typically already configured with uv environments ** in their respective directories, in the form: - ‘./code_repos/<repo_name>/.venv/‘ Whenever you need to execute commands using uv inside a repository, you ** must follow this fixed pattern ** (RepoA as an example): - After entering the repository directory, the actual command should look like: ‘bash cd ./code_repos/RepoA source .venv/bin/activate && uv run python your_script.py ... That is: before every uv run, you must first source .venv/bin/activate, and these actions must be bound to the same command or the same shell session. If, even after activating .venv, uv run cannot execute properly (e.g., missing dependencies), you may perform the minimum necessary uv installation steps based on repository files (pyproject.toml, requirements, setup, etc.). Do not over-install or rebuild environments unless necessary. Regardless of whether dependencies are added, you must record all environment-related commands you executed (if any) in both logs and the final JSON. 3. Execution Principles (Core Responsibilities & Workflow) 3.0 Overall Workflow Your execution logic is straightforward: Read data.json -> execute steps in order in the corresponding repositories -> write artifacts to artifact/ -> write logs to traj_log/ -> judge task feasibility -> write data_execution.json. You are not responsible for redesigning the task. Your job is to run the upstream-defined steps as faithfully as possible and leave a clear execution trail. If, during execution, you determine that the task design, local repositories, or dependencies have serious issues such that continuing 35 Agentization of Digital Assets for the Agentic Web is meaningless or too risky, you may stop further execution and explain your reasoning directly in the results. 3.1 Sequential Execution & Real Artifacts Steps must be executed sequentially (unless you have already decided to terminate early). All files produced at each step (text, CSV, JSON, videos, etc.) must be written to artifact/ and recorded with paths in the result JSON. Subsequent steps must explicitly consume actual outputs from previous steps, not fabricated objects. In data_execution.json, summarize the actual multi-hop data flow ( multi_hop_flow) in natural language, including which step execution reached and where it stopped (if applicable). 3.2 Logging (Reproducibility-Oriented) Write stdout/stderr of all commands to traj_log/<task_name>/. For each command, record: cmd, cwd, exit_code, and the two log file paths. Logs do not need to be pretty; they only need to be reproducible. 3.3 No Fabrication (Strictly Based on Actual Repo Structure) Only use scripts, data, and examples that actually exist in the repositories (README / examples / tests). If a file mentioned in the task description cannot be found in the repository: Record what is missing and where you searched, Then terminate execution, as this indicates a serious flaw in the task design. 3.4 Error Handling (Explainability > Forced Success) When a command fails, clearly record: command, cwd, exit_code, and log paths. You may make small, reasonable, and explainable fixes (e.g., adjusting parameters or paths), but must record the reason. If, after multiple attempts, you conclude that the task design is flawed, dependencies are fundamentally unsatisfiable, or continuing execution is meaningless, you may: Stop executing further steps; Mark the task status as partial_success or failed; Clearly explain why you stopped, which step you reached, and what upstream needs to fix or clarify in multi_hop_flow, overall_verification, and/ or clarification_requests_if_any. 4. Output Format (Returned JSON & Persistence) 36 Agentization of Digital Assets for the Agentic Web After processing all multi_hop_tasks (including failure or early termination cases), you must: Generate a JSON file: Path: ./artifact/data_execution.json Content: execution-related information only; do not repeat design-time fields already present in data.json (e.g., original step text, required_repos, why_this_repo). At the same time, return the full contents of data_execution.json as your response to the upstream agent. Requirements for data_execution.json: Do not include design fields already present in data.json; Retain only: execution traces, artifact paths, log paths, verification results, and your subjective judgment and feedback on task validity. You must explicitly add two fields to express your overall judgment of the task: task_verification (boolean): true: In your judgment, the task is basically reproducible/executable in the current environment (minor non-critical failures allowed). false: You believe the task has serious issues (e.g., missing key files, unavailable core dependencies, self-contradictory design) and cannot be considered valid. task_verification_summary (string): If true: briefly explain how the task was completed and whether key verification items passed. If false: state which step failed, what issue occurred, and why the task design or dependencies are problematic. An example structure (you may extend it, but do not remove these core fields): json Copy code "tasks": [ "task_verification": true, "task_verification_summary": "Successfully executed through step 3; verification checklist items on file existence and return codes passed. The task is reproducible in the current environment.", "task_name": "...", "goal": "...", "status": "success | partial_success | failed", 37 Agentization of Digital Assets for the Agentic Web "multi_hop_flow": "Natural language explanation of the actual multi- hop data flow (including how far execution reached and where it stopped, with reasons)", "steps": [ "step": 1, "repo": "RepoA", "repo_path": "./code_repos/RepoA", "interpretation": "How you translated the natural language action into concrete commands and which actual files were used", "commands": [ "cmd": "...", "cwd": "...", "exit_code": 0, "stdout_log": "traj_log/<task_name>/step1_cmd1_out.log", "stderr_log": "traj_log/<task_name>/step1_cmd1_err.log" ], "artifacts": [ "path": "artifact/step1_output.txt", "description": "Artifacts produced in this step that are used by subsequent steps (even if execution stops early, record what was produced)" ], "verification": [ "item": "Check whether artifact/step1_output.txt exists", "result": "pass | fail", "evidence": "E.g., file size or brief ls output" ] ], "final_artifact": "path": "artifact/<task_name>_final_output.x", "description": "What you consider the most critical final result file (or note that no final artifact was produced if the task was not completed)" , "overall_verification": "summary": "Whether the task satisfies the verification conditions defined in data.json (success / partial / failure, with reasons) ", "items": [ "item": "Check whether JSON contains field ...", 38 Agentization of Digital Assets for the Agentic Web "result": "pass | fail | not_applicable", "evidence": "Brief structural or content summary" ] , "logs_root": "traj_log/<task_name>/", "artifacts_root": "artifact/" ], "clarification_requests_if_any": [ "If you believe the task design, local repositories, or dependencies are problematic and prevent proper execution, list here-in natural language-what you want the upstream agent to fix or clarify." ] 5. Style Preferences (Additional Notes) In the interpretation field, explain how you concretely translated natural language actions into commands, avoiding "black-box" execution. Prefer using repository-provided tests/, examples/, or demo/ inputs and command patterns, rather than inventing inputs from scratch. Respect task diversity and upstream design choices; do not proactively simplify all tasks into "just run a single script," as long as the task goal remains unchanged. Do not fabricate success just to mark status as success: as long as your execution trace is real and reproducible, even a failed or early- terminated trajectory is valuable audit data. """ D Human Check Criteria on Tasks This section presents the human check criteria on single-repo tasks and multi-repo tasks. D.1 Single-Repo Tasks Human Check Criteria Single-Repo Tasks Human Check Criteria Core Capability Inheritance A valid skill must reflect a principal and non-trivial capability of the repository. It should inherit the repository’s core purpose rather than surface-level or incidental behaviors. Included examples: a web automation repository: ‘navigate webpages and extract structured content from dynamic interfaces’; a code analysis tool: ‘analyze repository dependency graphs and identify impacted modules.’ Excluded examples: 39 Agentization of Digital Assets for the Agentic Web ‘read files’; ‘parse JSON’; ‘send HTTP requests’; ‘log execution results.’ These excluded examples are implementation utilities rather than repository-defining capabilities. Atomic Functional Unit Each skill should be expressed at the granularity of one standalone functional unit. Annotators must avoid both over-broad and over- fragmented labels. Too broad: ‘perform end-to-end software engineering tasks.’ Too narrow: ‘open a file,’ ‘split a string,’ ‘call a helper function.’ Preferred: ‘generate unit tests for a given code module’; ‘retrieve relevant API documentation for a user-specified library’; ‘execute browser interactions grounded in webpage state.’ When a repository supports a pipeline with multiple tightly coupled stages , annotators should determine whether these stages form one indivisible functional unit or multiple reusable skills. The default preference is to split only when each part has independent semantic meaning and could plausibly be reused in isolation. Semantic Meaningfulness A task is semantically meaningful if it defines a coherent and understandable objective that a competent evaluator could interpret consistently. In particular, a meaningful task should satisfy the following: the instruction is understandable without requiring hidden assumptions; the task objective is non-empty and non-degenerate; the requested outcome is plausible in the context of the repository and environment; the task is neither purely decorative nor artificially constructed without practical functional content. Tasks should be rejected under this criterion if they are: nonsensical or self-contradictory; too vague to determine what success would mean; trivial to the point of not evaluating any substantive capability; unnatural artifacts of automatic generation rather than plausible usage scenarios 40 Agentization of Digital Assets for the Agentic Web Examples of semantic issues include: the task references entities or files that do not exist; the instruction bundles incompatible goals into one prompt; the task is phrased so vaguely that multiple incompatible interpretations are equally plausible; the task asks for an outcome with no discernible utility. Strict Dependence on Repository-Specific Capabilities A task strictly depends on repository-specific capabilities if solving it genuinely requires the distinctive functions implemented by the target repository, rather than generic reasoning, basic scripting, or broadly available utilities. A task should be retained only when the repository is materially necessary for successful completion. Reviewers should ask: Would this task still be solvable in approximately the same way without this repository? Does the task exercise a core capability represented in the repository’s gold-standard skills? Is the repository’s contribution central to task completion, rather than incidental? Tasks should be rejected if: the task can be completed through generic language-model reasoning alone; the task only requires common utilities such as file reading, simple string processing, or basic shell commands; the repository could be replaced by many unrelated tools without changing the essence of the task; the repository is only weakly relevant, while the main challenge lies elsewhere. The key requirement is necessity, not mere relevance. It is not enough that the repository could be helpful; the task must be designed so that the repository’s specific capabilities are meaningfully required. D.2 Multi-Repo Tasks Human Check Criteria Multi-Repo Tasks Human Check Criteria Repository Complementarity A valid multi-repository task should involve repositories that fulfill distinct and complementary roles within the overall workflow. The participating repositories should represent different functional capabilities that combine to achieve an outcome that no single repository could accomplish alone. The relationship between repositories should be one of meaningful collaboration rather than redundancy. Each repository should contribute a unique capability or perspective that is not substantially duplicated by other participants in the task. 41 Agentization of Digital Assets for the Agentic Web Tasks should generally be screened out under this criterion if the repositories involved perform largely overlapping functions, if any repository’s contribution is marginal or incidental to the overall objective, or if the task could be reasonably reframed to use fewer repositories without substantial loss of functionality. Data Flow Continuity and Verifiability A multi-repository task should exhibit a coherent and traceable flow of data or state transformations across its constituent steps. Each step in the task should accept inputs that are meaningfully connected to the outputs of preceding steps, and the overall progression should reflect a logical sequence of operations. The intermediate and final outputs of the task should be verifiable in a manner that allows for reasonable assessment of whether the task objectives have been met. The relationship between what a step produces and what subsequent steps consume should be discernible from the task design. Tasks should generally be screened out under this criterion if the data flow between steps lacks clear logical connection, if steps operate in isolation without meaningful coordination, or if the relationship between step outputs and task objectives is difficult to establish. Step Necessity Every repository and its corresponding step in a multi-repository task should serve an essential function within the overall pipeline. Each step should represent a substantive contribution that advances the task toward its final objective. The importance of each step should be evident from the task design. No step should appear optional, trivial, or easily bypassable without meaningful impact on the task outcome. Tasks should generally be screened out under this criterion if any step appears to be included artificially without clear purpose, if a step’s contribution is disproportionately small relative to its inclusion, or if the task could achieve substantially the same outcome by omitting or skipping a particular step. 42