1.1. The Problem of Inferring Authorship from Writing Characteristics

The increasing use of Large Language Models (LLMs) in academic and professional writing has generated considerable interest in determining whether a document was written by a human, generated by AI, or produced through some form of human–AI collaboration. Such judgments are often made from observable features of the completed text. Highly organized structures, consistent terminology, systematic argumentation, balanced explanations, regular paragraph patterns, explicit qualifications, and clearly formulated conclusions, for example, are sometimes interpreted as indications of LLM generation.

Such interpretations require caution. The occurrence of characteristics commonly observed in LLM-generated text does not establish that those characteristics originated with LLMs, nor does their presence necessarily constitute strong evidence of AI authorship. Many features now associated with AI-generated writing were established conventions of academic, scientific, technical, and professional communication long before generative AI became widely available. A fundamental distinction must therefore be maintained between characteristics of writing and evidence of authorship. A characteristic can describe how a document is written without reliably identifying the process by which it was produced.

1.2. Writing Structure and Authorship Are Different Dimensions

Writing structure concerns the organization and presentation of content; authorship concerns the process through which that content is intellectually developed and textually produced. The two dimensions may be related, but the former does not directly determine the latter.

A theoretical article, for example, may introduce a problem, define important concepts, establish relationships among them, develop propositions, identify qualifications, examine implications, and conclude by integrating the argument. Such organization may be highly systematic precisely because systematic organization is appropriate for communicating a theoretical framework. Human researchers have long relied on explicit organization, logical progression, stable conceptual definitions, recurring terminology, and synthesis to make complex arguments intelligible.

The ability of LLMs to produce similarly organized articles therefore does not make structural organization an inherently AI-specific characteristic. In particular, the proposition LLMs frequently produce highly structured writing must be distinguished from the substantially stronger proposition highly structured writing is likely to have been produced by an LLM. The first proposition may be valid without providing sufficient grounds for accepting the second.

Definition of Large-scale Asynchronous Training

Large-scale asynchronous training is a machine-learning training approach in which a large amount of computational work is distributed across many workers, devices, machines, or training processes that can perform and contribute training operations without requiring every participant to remain synchronized at each step. In conventional tightly synchronized training, participating workers commonly perform computation and then wait at coordination points so that their results can be aggregated before the next shared training step proceeds. In an asynchronous approach, different workers may instead generate training data, compute updates, evaluate model behavior, process experience, or perform other parts of the training workflow at different rates, while their outputs are collected and incorporated according to the design of the training system. This can be particularly valuable for large and heterogeneous training workloads—including reinforcement learning, agentic training, distributed model optimization, and workloads involving environments or tools with variable response times—because faster workers do not necessarily have to remain idle while waiting for slower ones. At large scale, asynchronous training can therefore improve computational utilization, throughput, scalability, and tolerance of variable workloads, although it also introduces challenges such as stale training information, uneven worker progress, coordination complexity, inconsistent model versions, and the need to determine how asynchronously generated data or updates should influence the continuously evolving model.

Conditions for Large-Scale Asynchronous Training to Hold

For a training process to qualify as large-scale asynchronous training, training computation should first be meaningfully distributed across a sufficiently large collection of computational resources or concurrent training processes, while at least some important portions of those processes are allowed to progress and contribute results without strict step-by-step global synchronization. Workers may operate on different data, environments, tasks, model replicas, trajectories, or stages of a training pipeline, and differences in their execution speed should not necessarily require the entire training system to wait for the slowest participant before useful work can continue. The system must nevertheless provide mechanisms for coordinating these independently progressing activities, such as distributing current or periodically refreshed model parameters, collecting generated experiences or computed results, determining when and how those results are incorporated into training, tracking model and data versions, and controlling the effects of excessively stale or incompatible information. It should also maintain sufficient consistency and training stability so that the efficiency gained from asynchronous execution does not cause uncontrolled divergence or substantially degrade the quality of learning. Under these conditions, large-scale describes the distribution of substantial training workloads across many computational resources or concurrent processes, while asynchronous describes the relaxation of strict global synchronization so that different parts of the training system can make progress at different times while still contributing coherently to the overall learning process.

Definition of LLM Vulnerability Discovery

LLM vulnerability discovery is the systematic process of identifying, examining, and validating weaknesses, failure conditions, exploitable behaviors, or insufficient protections in a large language model (LLM) $M$ that may reduce the reliability, safety, robustness, or effectiveness of the model when it is used as the reasoning and decision-making foundation of an AI agent $A$. The process may examine how the LLM responds to different inputs $x$, operates under different execution conditions $c$, and produces model outputs $y=M(x\mid c)$ in order to identify circumstances under which its behavior becomes incorrect, inconsistent, unreliable, insufficiently protected, or otherwise undesirable. Such vulnerabilities may become particularly important in agentic applications because individual model weaknesses can affect planning, reasoning, coding, tool use, information processing, evaluation, and subsequent decisions across multiple execution steps. Systematically discovering and understanding these vulnerabilities can therefore provide evidence for improving the model, its surrounding safeguards, and the design of the agentic system, thereby increasing the efficiency and reliability of AI agents when performing both simple and long-horizon tasks $\tau$, including coding, professional work, and learning tasks.

Conditions for LLM Vulnerability Discovery to Hold

For LLM vulnerability discovery to hold, the process should systematically examine the LLM $M$ under sufficiently relevant and varied inputs $x$ and execution conditions $c$, observe the resulting model outputs $y$, and identify behaviors that provide meaningful evidence of a weakness, failure condition, exploitable behavior, or insufficient protection. A suspected vulnerability should be distinguishable from an isolated or incidental undesirable output by examining whether the behavior can be reproduced, consistently triggered under identifiable conditions, or otherwise supported by sufficient evidence to establish a meaningful weakness in the model or its use within an AI agent. The discovery process should also consider the practical consequences of the identified vulnerability for relevant tasks $\tau$, including whether it can impair reasoning, planning, coding, information processing, tool use, evaluation, decision-making, or other capabilities required for simple or long-horizon task execution. The process does not necessarily require every discovered vulnerability to have the same severity, cause, or remediation method; rather, it should establish a sufficiently clear relationship between particular conditions and undesirable model behavior so that the identified vulnerability can be analyzed, evaluated, and, where appropriate, addressed through model improvement, safeguards, agent design, or other mitigation measures.

Definition of Long-Horizon Tasks

A long-horizon task $\tau_H$ for agentic AI $A$ is a task whose successful completion requires an AI agent to sustain goal-directed reasoning and action across an extended execution trajectory $H_{\tau}=\{a_1,a_2,\ldots,a_T\}$, where each action $a_t$ represents an operation performed at execution step $t$, and where intermediate actions, results, and decisions can influence subsequent parts of the task. Rather than being completed through a single model response or a small number of largely independent operations, $\tau_H$ typically involves multiple interdependent subtasks $S_{\tau}=\{s_1,s_2,\ldots,s_n\}$ that may require planning, information gathering, reasoning, tool use, execution, intermediate evaluation, revision, and integration of partial results. During execution, the agent maintains a task state $x_t$ representing relevant information about progress at step $t$, including completed work, intermediate outputs, available information, unresolved requirements, environmental conditions, and other context needed to determine subsequent actions. The execution trajectory may be sequential, parallel, conditional, iterative, or recursive and may change as new information, intermediate results, errors, or environmental conditions emerge. Examples include developing and testing a substantial software system, conducting a multi-stage research project, analyzing and integrating information from many sources, or completing a professional workflow involving multiple tools and intermediate deliverables. The defining characteristic of $\tau_H$ is therefore the requirement for sustained and coherent agentic execution across an extended sequence of interdependent states and actions, placing continuing demands on goal maintenance, planning, contextual continuity, state management, tool use, intermediate evaluation, adaptation, and error recovery.

Conditions for a Long-Horizon Task to Hold

For a task to qualify as a long-horizon task $\tau_H$ for agentic AI $A$, achieving its task objective $g_{\tau}$ should depend on maintaining meaningful continuity across a sufficiently extended execution trajectory $H_{\tau}$, with dependencies connecting multiple subtasks $S_{\tau}$, actions $a_t$, intermediate results, and task states $x_t$. Earlier actions or results should meaningfully inform, constrain, enable, or alter later actions, requiring the agent to preserve relevant information and continuously relate its current state to $g_{\tau}$. The agent should be required to make or revise decisions during execution rather than follow only a fixed sequence of independent operations, and the trajectory may require responses to intermediate successes, failures, newly discovered information, changing conditions, or unexpected outcomes. Successful completion should consequently depend on capabilities such as maintaining the overall objective, tracking task progress, managing dependencies, selecting and using appropriate tools, evaluating intermediate outcomes, adapting plans, recovering from errors, and integrating distributed intermediate work into a coherent final result. The duration of $\tau_H$, number of generated tokens, or computational cost alone does not determine whether the task is long-horizon; the essential condition is that successful completion depends on sustained, coherent, and adaptive agentic execution across an extended and meaningfully interdependent task trajectory.

Definition of Training Environment Scaling for End-to-End Expert Work

Training environment scaling for end-to-end expert work refers to systematically expanding the number, diversity, realism, complexity, and operational capacity of training environments $E$ in which a large language model $M$, intended for agentic applications $A$, learns to perform complete professional tasks that require sustained expert-level work across extended execution trajectories. Given an expert task $\tau$ and its sequence of interdependent subtasks $S\_{\tau}=\{s\_1,s\_2,\ldots,s\_n\}$, an environment $E$ provides the task context, information sources, tools, resources, constraints, feedback mechanisms, and executable conditions through which $M$ can learn to progress from the initial objective to a completed and evaluated outcome. For long-horizon coding tasks $\tau\_C$, such environments may include software repositories, codebases, development tools, documentation, dependency systems, execution sandboxes, test suites, debugging facilities, and evaluation mechanisms, allowing the model to perform activities such as understanding requirements, inspecting existing code, planning modifications, implementing changes, executing and testing software, diagnosing failures, revising solutions, and validating the final implementation. For long-horizon research tasks $\tau\_R$, the environments may provide research questions, literature collections, databases, search and retrieval capabilities, analytical tools, computational resources, intermediate evidence, and evaluation mechanisms, allowing the model to progressively formulate research directions, gather and examine information, compare evidence, conduct analyses, revise interpretations, synthesize findings, and construct a final research output. Scaling $G(E)$ expands these environments across task volume, task diversity, difficulty, execution length, domain coverage, tool availability, environmental variation, and feedback opportunities so that $M$ gains experience with a broader range of realistic end-to-end trajectories rather than learning primarily from isolated responses or narrowly bounded subtasks. The overall purpose is to develop the model’s capacity to maintain objectives, manage intermediate states and dependencies, use tools appropriately, respond to changing information, recover from failures, evaluate its own progress, and integrate many connected operations into coherent expert work suitable for agentic execution.

Conditions for Training Environment Scaling for End-to-End Expert Work to Hold

For training environment scaling for end-to-end expert work to hold, the scaled environment collection $G(E)$ should provide sufficiently varied and operationally meaningful opportunities for $M$ to learn complete expert tasks $\tau$ through extended sequences of connected actions, with both long-horizon coding tasks $\tau\_C$ and long-horizon research tasks $\tau\_R$ represented when both constitute intended agentic capabilities. The environments should preserve meaningful relationships among the subtasks $S\_{\tau}$, so that earlier decisions, actions, tool results, generated artifacts, and evaluation outcomes can influence later stages of execution and require the model to maintain relevant task state across the trajectory. Scaling should produce substantive increases in dimensions such as the number and diversity of tasks, domains, difficulty levels, trajectory lengths, tools, resources, environmental states, and failure conditions, while retaining enough realism for learned capabilities to transfer to the professional settings targeted by the agentic applications $A$. Each environment $E$ should provide sufficient interaction and feedback for the model to observe the consequences of its actions and, where appropriate, evaluate intermediate results, revise unsuccessful approaches, and continue toward the task objective. Coding environments should support meaningful interaction with executable software and development workflows, while research environments should support meaningful interaction with information, evidence, analytical resources, and research workflows. The training process should also expose $M$ to variation in how expert tasks unfold, including incomplete information, intermediate failures, changing contextual information, alternative solution paths, and dependencies extending across multiple stages. Under these conditions, $G(E)$ represents genuine training environment scaling when the expansion increases the breadth, depth, realism, and executable complexity of the model’s training experience in ways that strengthen its ability to carry end-to-end expert work from an initial objective through sustained agentic execution to a completed and evaluated outcome.

Definition of Agent Member

An agent member $(A\_i)$ is an individual agent instance that belongs to an agent team $(\mathcal{A}\_{\tau})$, an agent network $(\mathcal{N})$, or another multi-agent organizational structure and contributes to the execution of its assigned or dynamically determined work. Depending on the organizational structure and current execution requirements, an agent member may work individually or collaboratively with other agent members on a single subtask $(\tau\_j)$, multiple subtasks $(\mathcal{T}\_i)$, a complete task $(\tau)$, or, where its scope of responsibility is sufficiently broad, parts or the entirety of a project $(P)$. An agent member may also be assigned or dynamically assume a particular role $(r\_i)$ and corresponding responsibilities $(q\_i)$, such as planning, information retrieval, analysis, execution, coordination, review, evaluation, supervision, or integration. Its participation does not need to remain fixed throughout execution: the work, role, responsibilities, relationships, and actions $(a\_{i,t})$ of an agent member may change according to the current task or project state, available information, intermediate results, environmental conditions, interactions with other members, and relevant contextual information. When operating collaboratively, an agent member may communicate with other members, exchange intermediate results and contextual information, request or provide feedback, review and critique other members’ work, propose or compare alternative approaches, debate decisions, coordinate subsequent actions, and jointly refine intermediate or final results.

Fundamental Characteristics of a Valid Agent Member

For an agent member $(A\_i)$ to be considered a valid member of an agent team $(\mathcal{A}\_{\tau})$ or agent network $(\mathcal{N})$, it should exist as an identifiable agent instance with a meaningful functional relationship to the task, project, or multi-agent organization in which it participates. It should have an assigned, selected, or dynamically determined scope of participation through one or more subtasks, tasks, roles, responsibilities, actions, or project-level functions, and its activities should meaningfully contribute to the execution, coordination, evaluation, refinement, or completion of the relevant work. The agent member should be capable of taking actions $(a\_{i,t})$ within its available capabilities, permissions, tools, information, and execution environment, while adapting its actions when its assigned work, role, responsibilities, task state, or surrounding context changes. Where collaboration is required, it should also be capable of participating in the relevant interactions with other agent members rather than operating as an entirely disconnected instance. An agent instance does not become an agent member merely because it exists or is technically available; membership requires that it be incorporated into the relevant agent team or agent network with an actual or intended functional role, responsibility, task participation, interaction relationship, or other meaningful contribution toward the shared task or project objective.

Definition of Agent Network

An agent network $(\mathcal{N})$ is a large-scale organization of multiple agent instances that collectively support the execution of a complex project $(P)$ composed of many tasks $(\mathcal{T}\_{P}=\{\tau\_1,\tau\_2,\ldots,\tau\_m\})$. The participating agents $(A\_i\in\mathcal{N})$ may differ in their roles $(r\_i)$, capabilities $(c\_i)$, responsibilities $(q\_i)$, available tools or resources, and relationships with other agents. Unlike a task-scale agent team, an agent network does not require all agents to participate in the same task or to communicate continuously with one another. Instead, different subsets of agents $(\mathcal{N}\_{\tau,t}\subseteq\mathcal{N})$ may become relevant to different tasks at different execution steps $(t)$, and their participation, coordination, and interaction patterns may change as the project progresses. Some agents may perform specialized tasks independently, some may coordinate across task boundaries, and some may temporarily form smaller collaborative configurations for particular tasks. The network therefore provides a broader organizational structure through which many agents, tasks, capabilities, and inter-agent relationships can be dynamically arranged to support the overall project objective.

Conditions for an Agent Network to Hold

An agent network $(\mathcal{N})$ should hold when a complex project $(P)$ requires or supports the organized participation of multiple agent instances across a collection of tasks $(\mathcal{T}\_{P})$, rather than concentrating all participating agents on a single task. The agents should have meaningful functional relationships within the broader project, such as differentiated roles, capabilities, responsibilities, task assignments, communication pathways, coordination dependencies, or resource-sharing relationships. It is not necessary for every agent to interact directly with every other agent, and different agents may remain inactive or irrelevant to particular tasks. Instead, task-specific subsets $(\mathcal{N}\_{\tau,t})$ may be selected, instantiated, activated, or reorganized according to the current project state $(S\_t)$, task requirements $(R\_{\tau,t})$, available information $(I\_t)$, environmental conditions $(E\_t)$, and relevant context $(C\_t)$. An agent network is therefore characterized by project-level scope, multiple participating agents distributed across multiple tasks, heterogeneous or differentiated agent functions, and a network of relationships through which agents or subsets of agents can be coordinated as project requirements evolve.

Similarities Between Agent Team and Agent Network

Both an agent team $(\mathcal{A}\_{\tau})$ and an agent network $(\mathcal{N})$ organize multiple agent instances around a shared higher-level objective and allow individual agents to contribute through different roles, capabilities, subtasks, actions, or forms of interaction. In both structures, agent participation does not need to remain static: assignments, roles, communication relationships, and responsibilities may change according to task or project states, intermediate results, available information, environmental changes, and contextual conditions. Both can support communication, information exchange, coordination, review, critique, delegation, and iterative refinement, and both may allow multiple agents to work on different subtasks or on the same problem when redundancy, comparison, or alternative reasoning is useful. Their common foundation is therefore the organized use of multiple agent instances whose combined activities contribute to an objective that would otherwise be performed by one agent or by less coordinated independent agents.

Differences Between Agent Team and Agent Network

The principal difference between an agent team $(\mathcal{A}\_{\tau})$ and an agent network $(\mathcal{N})$ concerns their organizational scope, immediate objective, participation structure, and interaction intensity. An agent team is primarily task-scale and is organized around a particular target task $(\tau)$, which may contain multiple subtasks $(\mathcal{T}\_{\tau})$, whereas an agent network is project-scale and supports a broader project $(P)$ containing many tasks $(\mathcal{T}\_{P})$. Agent-team membership is therefore more closely tied to meaningful participation in the target task, while network membership can include agents whose capabilities are relevant to the broader project even when they are not currently active in a particular task. Agent-team members also generally interact more intensively because they share the same immediate task objective and may repeatedly exchange intermediate results, review and critique one another’s work, debate alternatives, coordinate dependencies, and jointly refine results. In an agent network, interaction can be more selective and distributed: agents working on unrelated tasks may have little or no direct communication, while particular subsets of agents may interact intensively when required.

The two structures can also differ in role and capability diversity, structural relationships, formation, and reconfiguration. Although both may contain agents with different roles and capabilities, an agent network can support broader heterogeneity across different functional domains, tools, resources, permissions, and responsibilities required by the overall project, whereas an agent team generally contains the roles and capabilities needed for its particular task. Relationships within an agent team are primarily determined by the requirements and evolving state of that task, while an agent network may additionally contain broader task dependencies, delegation relationships, supervisory relationships, communication pathways, shared-resource relationships, and temporary collaboration links across different tasks. An agent team may be dynamically formed, expanded, reduced, reorganized, or dissolved according to the needs of a particular task, while an agent network can persist across many tasks and provide a larger organizational structure from which different task-specific agent subsets are formed. Accordingly, an agent team $(\mathcal{A}\_{\tau,t})$ may operate as a localized collaborative configuration within an agent network $(\mathcal{N})$, such that $\mathcal{A}\_{\tau,t}\subseteq\mathcal{N}$, although an agent team does not necessarily require a pre-existing agent network. The distinction is therefore primarily between task-scale, interaction-intensive collaboration in an agent team and project-scale organization, distributed participation, and broader agent relationships in an agent network.

Definition of Agent Team

An agent team $(\mathcal{A}\_{\tau})$ is a task-scale configuration of multiple agent instances that collaboratively perform a single task $(\tau)$ comprising multiple subtasks $(\mathcal{T}\_{\tau}=\{\tau\_1,\tau\_2,\ldots,\tau\_m\})$. Each agent instance $(A\_i\in\mathcal{A}\_{\tau})$ can participate in the execution of one or more subtasks $(\tau\_j\in\mathcal{T}\_{\tau})$ or assume a particular role $(r\_i)$ that contributes to performing the target task. The relationship between agent members and subtasks does not need to follow a fixed one-agent–one-subtask assignment: different agent members may perform different subtasks, multiple agent members may perform the same subtask, one agent member may participate in several subtasks, and these responsibilities may change as execution progresses. During task execution, agent members can take different actions $(a\_{i,t}\in\mathcal{U}\_{\tau,t})$ at execution step $(t)$, where $\mathcal{U}\_{\tau,t}$ represents the actions available to the team at that step. Such actions may include performing a subtask, communicating with other members, sharing contextual information or intermediate results, proposing an approach, requesting feedback, reviewing or critiquing another member’s work, comparing competing results, debating a decision, revising an intermediate result, coordinating subsequent actions, or contributing to the final task result. The agent team therefore represents an interaction-intensive form of task execution in which multiple agent members contribute through potentially different, overlapping, or changing responsibilities while collaboratively pursuing completion of the same target task.

Conditions for an Agent Team to Hold

An agent team $(\mathcal{A}\_{\tau})$ should hold when a single target task $(\tau)$ is performed through the coordinated participation of multiple agent members $(A\_1,A\_2,\ldots,A\_n)$ and can be decomposed into or operationally involve multiple subtasks $(\tau\_1,\tau\_2,\ldots,\tau\_m)$. At least two agent members should meaningfully participate in task execution, with each participating member contributing through one or more assigned, selected, or dynamically determined subtasks or roles rather than merely existing as an inactive agent instance. Their actions $(a\_{i,t})$ should contribute to the progression, evaluation, coordination, or refinement of the shared task, and the members should have opportunities for substantive interaction, such as exchanging information and intermediate results, reviewing or critiquing one another’s work, proposing alternatives, resolving disagreements, coordinating dependencies, or jointly refining results. The mapping between agent members, roles, subtasks, and actions may remain flexible and change over execution steps $(t)$ according to the current task state $(s\_t)$, available information $(I\_t)$, environmental conditions $(E\_t)$, and relevant background context $(C\_t)$. Accordingly, an agent team is distinguished from a simple collection of independently operating agents by the presence of a shared target task, meaningful participation by multiple agent members, task-level coordination, and collaborative interactions through which one member’s actions or intermediate results can influence the subsequent actions, decisions, or results of other members.

Definition of Dynamically Engineered Skill

A dynamically engineered skill is a new reusable skill constructed during the execution or preparation of an agentic task when a required subtask cannot be adequately fulfilled by any compatible reusable skill already available in the agent’s skill database. For an agentic task $\tau$ with a subtask $t_i$, let $\mathcal{S}={s_1,s_2,\ldots,s_m}$ denote the existing skill database, where each $s_j$ (existing reusable skill) represents an available skill that can potentially be applied to different tasks and subtasks. Before engineering a new skill, the agent determines whether at least one $s_j\in\mathcal{S}$ is sufficiently compatible with the requirements of $t_i$. This compatibility does not require the skill and subtask to use identical wording; rather, the skill should provide the capabilities, instructions, procedures, tools, input-output handling, and other relevant characteristics needed to perform the subtask as expected. If no existing skill satisfies the required compatibility conditions, a new skill $s_{\mathrm{new}}$ (dynamically engineered skill) can be constructed specifically to fulfill $t_i$. Although $s_{\mathrm{new}}$ originates from the requirements of a particular subtask, it should, where appropriate, be defined at a sufficiently general and modular level so that it can subsequently be stored in the skill database and reused for compatible subtasks in other agentic tasks rather than being unnecessarily reconstructed each time a similar requirement occurs.

Conditions for a Dynamically Engineered Skill to Hold

A dynamically engineered skill holds when a required subtask $t_i$ has been identified, its relevant requirements can be determined with sufficient clarity, and systematic examination of the existing skill database $\mathcal{S}$ indicates that no available skill is sufficiently compatible with those requirements. The absence of an appropriate skill should represent a meaningful capability or procedural gap rather than merely a difference in naming, wording, description, or minor configuration, because an existing reusable skill should normally be preferred when it can reliably fulfill the subtask directly or through permitted adaptation. A new skill should therefore be engineered only when the incompatibility is sufficiently important that using existing skills would prevent the subtask from being performed as required or would fail relevant evaluation criteria. The resulting $s_{\mathrm{new}}$ should contain sufficiently defined instructions, procedures, requirements, inputs, outputs, applicable conditions, or other necessary components for performing the target subtask, and its scope should be sufficiently coherent to represent a reusable capability rather than a one-time collection of instructions tied unnecessarily to a single task instance. Once constructed and appropriately validated, $s_{\mathrm{new}}$ can be added to $\mathcal{S}$, thereby extending the available skill database and allowing future compatible subtasks to reuse the newly engineered skill.

Identification of the Need for a Dynamically Engineered Skill

The need to engineer a new reusable skill can be identified through a skill filtering and compatibility assessment that compares the requirements of the target subtask $t_i$ against the existing skills in $\mathcal{S}$. The agent can first obtain the relevant metadata $M(s_j)$ (skill metadata) of each existing skill $s_j$, which may include its name, description, intended function, applicable task or subtask types, expected inputs and outputs, required tools, constraints, dependencies, and other information useful for determining its applicability. Different filtering methods can then be applied individually or in combination. Semantic matching can use the language-understanding capability of the supporting LLM to determine whether the meaning and requirements of $t_i$ correspond sufficiently closely to the capabilities represented by $M(s_j)$, even when different terminology or expressions are used. Metadata search can retrieve candidate skills whose names, descriptions, tags, capabilities, input-output specifications, or other metadata correspond to characteristics of the subtask. Additional rule-based filtering, constraint checking, capability matching, ranking, or evaluation methods can further eliminate incompatible candidates and identify the most appropriate remaining skills. This process can be represented simply as the following pseudo-algorithm:

Algorithm: Identify or Dynamically Engineer a Reusable Skill

Input:
    t_i      — Target Subtask
    S        — Existing Skill Database {s_1, ..., s_m}

1. Identify the requirements of t_i.

2. For each existing reusable skill s_j in S:
       Retrieve M(s_j) — Skill Metadata.

3. Apply F(t_i, M(s_j)) — Compatibility Filtering,
   using one or more methods such as:
       - semantic matching,
       - metadata search,
       - rule-based filtering,
       - constraint checking,
       - capability matching.

4. Evaluate the compatible candidate skills.

5. If a sufficiently compatible existing skill s_j is identified:
       Select s_j — Existing Reusable Skill.
   Else:
       Engineer s_new — Dynamically Engineered Skill
       for the requirements of t_i.

6. Validate s_new when a new skill has been engineered.

7. Add the validated s_new to S so that it can be
   reused for compatible subtasks in future agentic tasks.

Output:
    s_j or s_new — Reusable Skill for t_i

where $F$ (compatibility filtering function) represents one or more filtering methods, such as semantic matching, metadata search, rule-based filtering, constraint checking, or capability matching. A new reusable skill should therefore be engineered only after the available skill database has been examined with appropriate filtering methods and no existing skill has been found to provide sufficient compatibility with the target subtask.