[{"content":"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.\nSuch 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.\n1.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.\nA 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.\nThe 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.\n1.3. The Human Origins of Many LLM Writing Patterns LLMs learn statistical, linguistic, rhetorical, and structural regularities from large collections of textual material, much of which ultimately derives from human-produced writing. Books, academic articles, reports, educational materials, technical documents, professional communications, and other forms of written discourse contain recurring practices for defining concepts, organizing arguments, explaining relationships, qualifying claims, and integrating conclusions. LLMs can learn and generate text consistent with these patterns, but their capacity to do so does not make the underlying patterns intrinsically characteristic of AI.\nAt a general level, this relationship can be represented as Human Writing Practices → Written Corpora → LLM Learning → Generated Writing. Similarities between high-quality human writing and LLM-generated writing are consequently unsurprising: both may exhibit conventions that are extensively represented in established written discourse. This produces a fundamental attribution problem. If skilled human writers and LLMs are both capable of systematic exposition, the observation of systematic exposition in a completed article cannot clearly distinguish between them. What the similarity demonstrates most directly may be an LLM\u0026rsquo;s capacity to generate text consistent with established writing practices, rather than evidence that the practice itself is indicative of AI authorship.\n1.4. Good Writing Characteristics Are Not Necessarily AI Characteristics Many characteristics sometimes identified as signs of AI-generated academic writing are also conventional objectives of competent academic writing. Logical organization, clear definitions, consistent terminology, coherent transitions, explicit conceptual relationships, appropriate qualification of claims, consideration of exceptions, and conclusions supported by preceding arguments are examples.\nA progression such as Define → Explain → Qualify → Integrate, for instance, provides a straightforward means of presenting a theoretical concept. The concept is first defined; its meaning and significance are then explained; relevant conditions or limitations are identified; and the concept is subsequently connected to the broader argument. LLMs frequently generate explanations that follow this progression, but the progression itself reflects an established method of exposition. The same reasoning applies to structures such as General Concept → Component Concepts → Relationships → Implications. Their occurrence in AI-generated text does not establish an AI origin because their usefulness as organizational structures predates contemporary LLMs.\nSuch characteristics are therefore more directly informative about the organization, clarity, coherence, and rhetorical construction of a document than about its authorship. Their relevance to authorship attribution must be established separately.\n1.5. The Problem of Inverted Causal Reasoning Authorship judgments become methodologically weak when the relationship between established writing conventions and LLM-generated writing is implicitly reversed. A simplified inference might proceed as follows: LLMs often generate highly structured articles → this article is highly structured → this article was probably generated by an LLM. The difficulty is that this reasoning does not adequately explain why structured writing appears in LLM output in the first place.\nA more complete representation is Established Human Writing Conventions → LLM Learning of Those Conventions → LLM Reproduction of Structured Writing. When a characteristic is well established in human writing and can also be generated by LLMs, its presence alone has limited capacity to distinguish between the two production processes.\nThis does not render structural characteristics irrelevant to authorship assessment. Their evidential value instead depends on whether, and to what extent, they differentiate among competing explanations of textual production. The observation that a characteristic frequently occurs in AI-generated writing is not sufficient if the same characteristic also occurs frequently in comparable competent human writing.\n1.6. Shared Characteristics and Discriminative Value An authorship indicator is useful to the extent that it distinguishes among competing explanations of how a text was produced. A characteristic that occurs frequently in AI-generated writing but rarely in comparable human writing may provide meaningful evidence. By contrast, a characteristic common to both has substantially weaker discriminative value.\nAuthorship assessment can therefore be expressed conceptually as Authorship Evidence ≠ Mere Presence of a Characteristic. The more relevant question is how strongly an observed characteristic distinguishes among plausible authorship processes. If experienced researchers and advanced LLMs both commonly produce clear definitions, systematic arguments, explicit qualifications, and logically organized sections, these characteristics may indicate competent exposition while providing insufficient information to identify whether the text was produced by a researcher, an LLM, or some combination of the two.\nAs LLMs become increasingly capable of generating text that conforms to sophisticated human writing conventions, the observable overlap between human and AI textual characteristics may expand. Where that overlap increases, characteristics shared extensively by both become correspondingly less useful as independent indicators of authorship.\n1.7. Theoretical Writing and Structural Regularity The genre, purpose, and conceptual requirements of a document must also be considered when structural regularity is interpreted. Theoretical writing ordinarily requires consistency among concepts, definitions, propositions, and relationships. If researchers establish a conceptual hierarchy such as Occupation → Task → Subtask → Skill, subsequent sections should preserve those relationships. Similarly, a framework organized around a process such as Requirements → Skill Selection → Execution → Evaluation → Reallocation may require repeated reference to the same concepts as different conditions and applications are examined.\nStructural regularity may consequently arise from the theory being communicated rather than from the mechanism used to produce the prose. Repeated terminology, parallel explanations, progressive development, and systematic synthesis can all result from the need to preserve relationships established within a framework. Attributing such regularity primarily to AI generation therefore risks explaining in terms of the writing mechanism what may be more directly attributable to the conceptual structure of the subject itself.\n1.8. Terminological Consistency and Formulaic Generation Terminological consistency should likewise be distinguished from formulaic textual generation. General writing advice may encourage lexical variation, but theoretical and technical writing often requires stable terminology when particular expressions designate specifically defined constructs. If task, subtask, skill, human skill, agentic skill, and skill allocation refer to distinct concepts within a theoretical framework, their repeated use can preserve conceptual precision. Substituting alternative expressions merely to create lexical variety could introduce ambiguity or imply distinctions that the framework does not intend.\nConceptually necessary terminological repetition is therefore different from unnecessary repetition of sentence structures, transition phrases, paragraph templates, or rhetorical constructions. The former may be a requirement of rigorous theoretical writing; the latter may provide contextual information about how a text was produced. Even substantial formulaic regularity, however, cannot independently establish AI authorship. Standardized human writing procedures, institutional templates, editorial guidelines, collaborative practices, and deliberate stylistic choices can produce comparable patterns.\n1.9. Structural Regularity as Contextual Evidence Structural characteristics may nevertheless contribute to authorship assessment when treated as contextual and probabilistic evidence rather than decisive indicators. Unusually uniform paragraph lengths, nearly identical rhetorical sequences across numerous sections, recurring transition constructions, unnecessary restatement of conclusions, or equivalent levels of elaboration for concepts of substantially different importance may increase the plausibility of templated or AI-assisted production.\nSuch characteristics become more informative when the degree of regularity exceeds what can reasonably be explained by the subject matter, theoretical framework, publication format, or disciplinary convention. Even then, alternative explanations need to be considered. Researchers may deliberately employ standardized article structures, work from institutional templates, follow controlled writing procedures, collaborate through systematic editorial processes, or impose explicit requirements for consistency across sections. Structural regularity should therefore receive evidential weight only after plausible alternative explanations have been considered. No individual structural characteristic is, by itself, sufficient to establish a particular authorship process.\n1.10. Intellectual Origin and Textual Production Human–AI collaborative writing introduces a further distinction between intellectual construction and textual construction. Intellectual construction concerns the origin and development of concepts, propositions, theoretical relationships, arguments, analytical decisions, and substantive conclusions. Textual construction concerns the formulation and refinement of sentences, paragraphs, sections, transitions, and other forms of linguistic expression.\nThese activities can be distributed differently between humans and AI systems. Researchers may formulate an entire theoretical framework, establish its concepts and relationships, determine its propositions, and then use an LLM to produce an initial textual explanation that they subsequently review, correct, reorganize, and approve. In another workflow, researchers may write the manuscript themselves and use an LLM for linguistic refinement, restructuring, condensation, expansion, or stylistic editing.\nThese production processes differ substantially even though the completed documents may display similar observable characteristics. An article can contain considerable AI-generated prose while remaining strongly human-directed in its intellectual construction. Conversely, the fact that sentences were written directly by a human does not by itself establish that every underlying conceptual contribution originated with that writer. Authorship assessment therefore becomes more precise when intellectual and textual contributions are examined separately rather than treated as a single undifferentiated category.\n1.11. Human–AI Writing as a Continuum Contemporary writing processes are more accurately represented as a continuum than as a binary distinction between human-written and AI-written text. Possible configurations include fully human drafting, human drafting followed by AI editing, iterative human–AI co-writing, AI drafting from a detailed human-developed framework followed by substantial human revision, and predominantly AI generation with comparatively limited human intervention.\nThis continuum can be represented as Human Writing ← Human-Led AI Assistance ← Iterative Human–AI Construction → AI Drafting with Human Refinement → Predominantly AI Generation. Observable characteristics of the finished document may not reveal its exact position on this continuum. A heavily revised AI draft can acquire characteristics associated with human academic writing, whereas a highly standardized human manuscript may display characteristics commonly attributed to LLMs. Likewise, an LLM working from detailed researcher-developed instructions may reproduce a predetermined theoretical structure with considerable consistency.\nThe completed document consequently provides only partial evidence about the sequence of human and AI contributions, their relative importance, and the processes through which the text was ultimately produced.\n1.12. Production Provenance and Stylistic Inference When the objective is to determine how an academic article was actually produced, direct evidence of the production process is generally more informative than stylistic interpretation of the completed document. Manuscript versions, tracked revisions, drafting histories, research notes, prompts, AI interaction records, document metadata, author correspondence, version-control records, and explicit descriptions of writing procedures can provide evidence directly related to textual provenance.\nStylistic analysis operates differently: it attempts to infer production history from properties of the resulting text. As skilled human writers and advanced LLMs increasingly produce overlapping linguistic and structural characteristics, such inference necessarily involves substantial uncertainty. The evidential distinction can be summarized as Production Evidence → Stronger Basis for Authorship Attribution, whereas Textual Characteristics → Probabilistic and Context-Dependent Basis for Authorship Attribution.\nStylistic assessment can therefore contribute to an evaluation of possible authorship, but the strength of its conclusions should remain proportional to the discriminative value of the characteristics on which those conclusions depend.\n1.13. A General Principle for Assessing AI Authorship A general framework for evaluating possible AI authorship can be represented as Observed Characteristic → Alternative Explanations → Discriminative Value. First, an observable feature is identified, such as structural regularity, repeated transitions, conceptual consistency, uniform paragraph organization, or another linguistic pattern. Second, plausible explanations for that feature are considered. These may include AI generation, skilled human writing, disciplinary conventions, theoretical requirements, institutional templates, collaborative editing, or deliberate standardization. Third, the analysis considers whether the characteristic meaningfully distinguishes among those explanations.\nUnder this framework, a characteristic should not receive substantial evidential weight simply because it commonly appears in LLM-generated text. What matters is whether its occurrence differs sufficiently across plausible human and AI production processes to support attribution. This principle is especially important when evaluating logical organization, conceptual consistency, clear definitions, systematic argumentation, explicit qualification, and similar characteristics that are both common outputs of advanced LLMs and established objectives of high-quality human academic writing.\n1.14. Structural Quality as Evidence of Writing Practice Rather Than Authorship The increasing ability of LLMs to generate text consistent with sophisticated writing conventions makes it important to distinguish between the origin of a writing characteristic and its reproduction by AI. Characteristics historically developed through human academic and professional writing can now appear in texts produced by either humans or computational systems. Their reproduction by LLMs does not, in itself, transform them into AI-specific characteristics.\nThe distinction can be summarized as follows: A characteristic reproduced by AI is not necessarily a characteristic originating from AI. Highly structured exposition, logical progression, terminological consistency, conceptual qualification, systematic synthesis, and explicit relationships among concepts may therefore be interpreted more appropriately, in the first instance, as characteristics of particular writing practices or standards of exposition rather than as indicators of a particular author type. They become relevant to authorship attribution only to the extent that additional evidence shows the observed pattern to be more consistent with one production process than with plausible alternatives.\n1.15. Conclusion Attributing AI authorship from academic writing requires a clear distinction between what a document looks like and how it was produced. LLMs frequently generate highly structured, logically consistent, systematic, and carefully qualified prose. These characteristics, however, are not unique to LLMs, and many reflect established conventions of human academic and professional writing represented extensively in the textual materials from which LLMs learn. It is therefore insufficient to infer AI authorship primarily from the observation that an article is highly organized, consistently follows a theoretical logic, repeatedly uses defined terminology, or systematically develops its propositions. In theoretical research, the same characteristics may arise from disciplined conceptual construction, academic writing conventions, terminological precision, or requirements imposed by the framework itself.\nStructural and linguistic characteristics can contribute to probabilistic authorship assessment, particularly when multiple unusual patterns occur together and cannot be adequately explained by genre, subject matter, editorial practice, or deliberate standardization. Their evidential significance nevertheless depends on their capacity to distinguish AI production from plausible human alternatives. A more appropriate assessment therefore separates writing characteristics, intellectual construction, textual construction, and production provenance, while recognizing that human–AI writing encompasses numerous intermediate configurations rather than a simple human-versus-AI distinction.\nThe central theoretical principle can consequently be stated as follows: the reproduction of established human writing conventions by Large Language Models does not convert those conventions into reliable indicators of AI authorship. The more extensively a writing characteristic is shared by competent human writers and LLMs, the less that characteristic alone can distinguish between human and AI textual production.\n","permalink":"https://www.zhumengyao.com/notes/insight-textual-features-alone-are-not-reliable-indicators-of-ai-or-human-authorship/","summary":"\u003ch2 id=\"11-the-problem-of-inferring-authorship-from-writing-characteristics\"\u003e1.1. The Problem of Inferring Authorship from Writing Characteristics\u003c/h2\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e","title":"Textual Features Alone Are Not Reliable Indicators of AI or Human Authorship"},{"content":"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.\nConditions 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.\n","permalink":"https://www.zhumengyao.com/notes/agentic-ai-understanding-large-scale-asynchronous-training/","summary":"\u003ch2 id=\"definition-of-large-scale-asynchronous-training\"\u003eDefinition of Large-scale Asynchronous Training\u003c/h2\u003e\n\u003cp\u003eLarge-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.\u003c/p\u003e","title":"Understanding Agentic AI: Large-scale Asynchronous Training"},{"content":"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.\nConditions 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.\n","permalink":"https://www.zhumengyao.com/notes/agentic-ai-understanding-vulnerability-discovery/","summary":"\u003ch2 id=\"definition-of-llm-vulnerability-discovery\"\u003eDefinition of LLM Vulnerability Discovery\u003c/h2\u003e\n\u003cp\u003eLLM 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.\u003c/p\u003e","title":"Understanding Agentic AI: LLM Vulnerability Discovery"},{"content":"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.\nConditions 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.\n","permalink":"https://www.zhumengyao.com/notes/agentic-ai-understanding-long-horizon/","summary":"\u003ch2 id=\"definition-of-long-horizon-tasks\"\u003eDefinition of Long-Horizon Tasks\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e","title":"Understanding Agentic AI: Long-Horizon Tasks"},{"content":"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\u0026rsquo;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.\nConditions 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\u0026rsquo;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.\n","permalink":"https://www.zhumengyao.com/notes/agentic-ai-understanding-training-environment-scaling-for-end-to-end-expert-work/","summary":"\u003ch2 id=\"definition-of-training-environment-scaling-for-end-to-end-expert-work\"\u003eDefinition of Training Environment Scaling for End-to-End Expert Work\u003c/h2\u003e\n\u003cp\u003eTraining 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\u0026rsquo;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.\u003c/p\u003e","title":"Understanding Agentic AI: Training Environment Scaling for End-to-End Expert Work"},{"content":"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\u0026rsquo; work, propose or compare alternative approaches, debate decisions, coordinate subsequent actions, and jointly refine intermediate or final results.\nFundamental 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.\n","permalink":"https://www.zhumengyao.com/notes/agentic-ai-understanding-agent-member/","summary":"\u003ch3 id=\"definition-of-agent-member\"\u003eDefinition of Agent Member\u003c/h3\u003e\n\u003cp\u003eAn 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\u0026rsquo; work, propose or compare alternative approaches, debate decisions, coordinate subsequent actions, and jointly refine intermediate or final results.\u003c/p\u003e","title":"Understanding Agentic AI: Agent Member"},{"content":"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.\nConditions 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.\nSimilarities 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.\nDifferences 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\u0026rsquo;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.\nThe 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.\n","permalink":"https://www.zhumengyao.com/notes/agentic-ai-understanding-agent-network/","summary":"\u003ch2 id=\"definition-of-agent-network\"\u003eDefinition of Agent Network\u003c/h2\u003e\n\u003cp\u003eAn 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.\u003c/p\u003e","title":"Understanding Agentic AI: Agent Network"},{"content":"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\u0026rsquo;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.\nConditions 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\u0026rsquo;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\u0026rsquo;s actions or intermediate results can influence the subsequent actions, decisions, or results of other members.\n","permalink":"https://www.zhumengyao.com/notes/agentic-ai-understanding-agent-team/","summary":"\u003ch2 id=\"definition-of-agent-team\"\u003eDefinition of Agent Team\u003c/h2\u003e\n\u003cp\u003eAn 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\u0026rsquo;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.\u003c/p\u003e","title":"Understanding Agentic AI: Agent Team"},{"content":"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.\nConditions 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.\nIdentification 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:\nAlgorithm: 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.\n","permalink":"https://www.zhumengyao.com/notes/agentic-ai-understanding-dynamically-engineered-skill/","summary":"\u003ch2 id=\"definition-of-dynamically-engineered-skill\"\u003eDefinition of Dynamically Engineered Skill\u003c/h2\u003e\n\u003cp\u003eA 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.\u003c/p\u003e","title":"Understanding Agentic AI: Dynamically Engineered Skill"},{"content":"Definition of Skill Repository A skill repository is a managed collection of reusable skills available to an AI agent for performing different tasks and subtasks. It can contain both pre-installed skills supplied as part of the agent’s default capabilities and custom skills that have been subsequently developed, tested, validated, and approved for reuse. Rather than requiring the agent to consider every available skill directly during every task, the repository provides an organized source from which a task-relevant subset of skills can be retrieved. For a skill repository $\\mathcal{S}={s\\_1,s\\_2,\\ldots,s\\_n}$, where $\\mathcal{S}$ (skill repository) represents the complete collection of available skills and each $s\\_i$ (reusable skill) represents an individual skill, a new task $\\tau$ (target task) can be used as the basis for task-aware skill retrieval. Retrieval may use skill metadata, semantic matching, keyword or metadata search, capability matching, constraint filtering, ranking, or combinations of these methods to derive $\\mathcal{S}\\_{\\tau}\\subseteq\\mathcal{S}$, where $\\mathcal{S}\\_{\\tau}$ (task-relevant skill set) contains the skills considered sufficiently relevant or potentially useful for the particular task. For more complex repositories or tasks, this retrieval and filtering process may be delegated to a specialized skill-selection subagent operating within its own context window, allowing it to examine the task requirements and available skill descriptions without unnecessarily occupying the main agent’s working context. The resulting task-relevant skill set can then be made available to the main agent, which dynamically determines which skill to invoke for a particular subtask or execution state as the task progresses. The repository therefore serves not merely as storage, but as an organized and extensible skill-management layer supporting skill registration, discovery, retrieval, selection, reuse, and continued expansion across different agentic tasks.\nConditions for a Skill Repository to Hold A skill repository holds when there is an identifiable and maintained collection of reusable skills that can be systematically registered, described, discovered, retrieved, and made available to an AI agent across multiple tasks. Each stored skill $s\\_i$ should have sufficient skill metadata to support discovery and compatibility assessment, such as its name, description, intended capability, applicable task or subtask types, expected inputs and outputs, dependencies, required tools, constraints, or other relevant properties. Skills admitted to the repository should also satisfy defined validation and approval requirements appropriate to the application, so that inclusion indicates that the skill has reached an acceptable state for subsequent reuse rather than representing an arbitrary temporary instruction generated during a single execution. The repository should support one or more retrieval and matching mechanisms capable of reducing the complete skill collection $\\mathcal{S}$ to a task-relevant candidate set $\\mathcal{S}\\_{\\tau}$, without requiring exact wording between a task and a skill description; semantic retrieval, metadata filtering, capability matching, ranking, and related methods can therefore be combined according to the scale and requirements of the repository. A dedicated skill-selection subagent may perform this filtering when separation of context, specialization, or repository scale makes delegation useful, but such a subagent is an optional architectural mechanism rather than a defining requirement of the repository itself. Finally, retrieval of $\\mathcal{S}\\_{\\tau}$ should not require all retrieved skills to be activated: the main agent should be able to select and invoke an appropriate skill dynamically when the corresponding subtask, condition, or execution state arises. Under these conditions, the skill repository functions as a persistent and reusable capability source from which task-specific skill availability can be constructed without exposing the entire skill collection to every task execution.\n","permalink":"https://www.zhumengyao.com/notes/agentic-ai-understanding-skill-repository/","summary":"\u003ch2 id=\"definition-of-skill-repository\"\u003eDefinition of Skill Repository\u003c/h2\u003e\n\u003cp\u003eA skill repository is a managed collection of reusable skills available to an AI agent for performing different tasks and subtasks. It can contain both pre-installed skills supplied as part of the agent’s default capabilities and custom skills that have been subsequently developed, tested, validated, and approved for reuse. Rather than requiring the agent to consider every available skill directly during every task, the repository provides an organized source from which a task-relevant subset of skills can be retrieved. For a skill repository $\\mathcal{S}={s\\_1,s\\_2,\\ldots,s\\_n}$, where $\\mathcal{S}$ (skill repository) represents the complete collection of available skills and each $s\\_i$ (reusable skill) represents an individual skill, a new task $\\tau$ (target task) can be used as the basis for task-aware skill retrieval. Retrieval may use skill metadata, semantic matching, keyword or metadata search, capability matching, constraint filtering, ranking, or combinations of these methods to derive $\\mathcal{S}\\_{\\tau}\\subseteq\\mathcal{S}$, where $\\mathcal{S}\\_{\\tau}$ (task-relevant skill set) contains the skills considered sufficiently relevant or potentially useful for the particular task. For more complex repositories or tasks, this retrieval and filtering process may be delegated to a specialized skill-selection subagent operating within its own context window, allowing it to examine the task requirements and available skill descriptions without unnecessarily occupying the main agent’s working context. The resulting task-relevant skill set can then be made available to the main agent, which dynamically determines which skill to invoke for a particular subtask or execution state as the task progresses. The repository therefore serves not merely as storage, but as an organized and extensible skill-management layer supporting skill registration, discovery, retrieval, selection, reuse, and continued expansion across different agentic tasks.\u003c/p\u003e","title":"Understanding Agentic AI: Skill Repository"},{"content":"Definition of Agentic Task An agentic task is a composite task performed by an AI agent through a structured combination of multiple subtasks, where each subtask represents a distinct part of what needs to be accomplished and is fulfilled by an appropriate reusable skill. An agentic task can be represented as $\\tau=({T}\\_{\\tau},{S}\\_{\\tau},{R}\\_{\\tau},{M}\\_{\\tau})$, where $\\tau$ (agentic task) denotes the complete task to be performed, ${T}\\_{\\tau}={t_1,t_2,\\ldots,t_n}$ (subtask set) contains the subtasks that collectively constitute the task, ${S}\\_{\\tau}={s_1,s_2,\\ldots,s_m}$ (skill set) contains the reusable skills available for fulfilling those subtasks, ${R}\\_{\\tau}$ (execution relations) specifies how the subtasks and their corresponding skills are organized and performed sequentially, iteratively, recursively, or through an appropriate combination of these patterns, and ${M}\\_{\\tau}$ (evaluation metrics) contains the task-specific measures used to determine whether intermediate results and the overall task outcome satisfy the expected requirements. For each subtask $t_i$ (subtask), an appropriate skill $s_j$ (reusable skill) may be selected from predefined skills or dynamically engineered during task execution when an existing skill does not adequately address the subtask.\nConditions for an Agentic Task to Hold For an agentic task to hold, the task should be sufficiently compositional and execution-oriented to require or meaningfully support decomposition into one or more identifiable subtasks whose coordinated performance contributes to the completion of the overall task. Each required subtask $t_i \\in {T}\\_{\\tau}$ should have an applicable skill $s_j \\in {S}\\_{\\tau}$, either predefined and reusable from an existing skill set or dynamically engineered when no suitable existing skill is available, so that the agent has a viable means of performing the required work. The execution relations ${R}\\_{\\tau}$ should provide sufficient structure for determining how execution proceeds among subtasks, including when a subsequent subtask should begin, when an earlier subtask should be revisited, when repeated refinement is necessary, or when additional subtasks should be introduced during execution. The evaluation metrics ${M}\\_{\\tau}$ should also provide sufficiently clear criteria for assessing whether each relevant output $o_i$ and, ultimately, the overall task outcome meet the expected requirements. Accordingly, an agentic task holds when its necessary subtasks can be identified or dynamically determined, suitable skills can be assigned or engineered to fulfill them, their execution can be coordinated through appropriate sequential, iterative, or recursive relations, and their resulting outputs can be evaluated and progressively used to guide the task toward satisfactory completion.\n","permalink":"https://www.zhumengyao.com/notes/agentic-ai-understanding-agentic-task/","summary":"\u003ch2 id=\"definition-of-agentic-task\"\u003eDefinition of Agentic Task\u003c/h2\u003e\n\u003cp\u003eAn agentic task is a composite task performed by an AI agent through a structured combination of multiple subtasks, where each subtask represents a distinct part of what needs to be accomplished and is fulfilled by an appropriate reusable skill. An agentic task can be represented as $\\tau=({T}\\_{\\tau},{S}\\_{\\tau},{R}\\_{\\tau},{M}\\_{\\tau})$, where $\\tau$ (agentic task) denotes the complete task to be performed, ${T}\\_{\\tau}={t_1,t_2,\\ldots,t_n}$ (subtask set) contains the subtasks that collectively constitute the task, ${S}\\_{\\tau}={s_1,s_2,\\ldots,s_m}$ (skill set) contains the reusable skills available for fulfilling those subtasks, ${R}\\_{\\tau}$ (execution relations) specifies how the subtasks and their corresponding skills are organized and performed sequentially, iteratively, recursively, or through an appropriate combination of these patterns, and ${M}\\_{\\tau}$ (evaluation metrics) contains the task-specific measures used to determine whether intermediate results and the overall task outcome satisfy the expected requirements. For each subtask $t_i$ (subtask), an appropriate skill $s_j$ (reusable skill) may be selected from predefined skills or dynamically engineered during task execution when an existing skill does not adequately address the subtask.\u003c/p\u003e","title":"Understanding Agentic AI: Agentic Task"},{"content":"Definition of Callable Skills Callable skills in Agentic AI are skills that an AI agent can actively invoke during task execution when their capabilities, procedures, or instructions are relevant to the requirements of the current task. A callable skill typically represents a defined unit of task-supporting capability, such as retrieving information, analyzing content, processing data, generating or modifying an artifact, validating an output, interacting with a tool, or carrying out a specialized workflow. Describing a skill as callable emphasizes that the skill is not merely defined, documented, or known to the agent, but is available through an invocation mechanism that allows the agent to activate it and use its prescribed functionality as part of the ongoing workflow. Callable skills may be selected from a broader runtime skill catalog according to the task instructions, detected requirements, current context, intermediate results, and execution conditions. Multiple callable skills may therefore be invoked sequentially, conditionally, or in combination to support different subtasks, while skills that are available but irrelevant to the current task can remain unused.\nConditions for Callable Skills to Hold in Agentic AI A skill can be treated as callable when the agent can identify it, determine when its use is appropriate, invoke it through an available mechanism, provide the information or inputs required for its execution, and receive or otherwise use its resulting output within the task workflow. Its required dependencies must also be satisfied: for example, necessary tools, resources, permissions, interfaces, contextual information, and execution capabilities must be available under the current runtime conditions. Merely defining a skill or including it in a broader skill repository does not necessarily make it callable; there must be a usable connection between the agent’s task-execution process and the skill itself. A callable skill does not need to be invoked in every task, nor does being callable mean that it is currently relevant. Rather, callability indicates that the skill is operationally available for invocation if the agent determines that the task requirements and applicable conditions justify its use. If required inputs, permissions, dependencies, or execution mechanisms are unavailable, the skill may remain defined or discoverable but should not be considered callable under those particular runtime conditions.\n","permalink":"https://www.zhumengyao.com/notes/agentic-ai-understanding-callable-skills/","summary":"\u003ch2 id=\"definition-of-callable-skills\"\u003eDefinition of Callable Skills\u003c/h2\u003e\n\u003cp\u003eCallable skills in Agentic AI are skills that an AI agent can actively invoke during task execution when their capabilities, procedures, or instructions are relevant to the requirements of the current task. A callable skill typically represents a defined unit of task-supporting capability, such as retrieving information, analyzing content, processing data, generating or modifying an artifact, validating an output, interacting with a tool, or carrying out a specialized workflow. Describing a skill as callable emphasizes that the skill is not merely defined, documented, or known to the agent, but is available through an invocation mechanism that allows the agent to activate it and use its prescribed functionality as part of the ongoing workflow. Callable skills may be selected from a broader runtime skill catalog according to the task instructions, detected requirements, current context, intermediate results, and execution conditions. Multiple callable skills may therefore be invoked sequentially, conditionally, or in combination to support different subtasks, while skills that are available but irrelevant to the current task can remain unused.\u003c/p\u003e","title":"Understanding Agentic AI: Callable Skills"},{"content":"Definition of Instruction Space An instruction space is the organized set of instructions that may govern, constrain, guide, or otherwise influence the behavior of an AI agent. It can be represented as $I = \\{i_1, i_2, \\ldots, i_n\\}$, where $I$ denotes the instruction space and each $i_j \\in I$ denotes a unit instruction expressing an individual rule, requirement, constraint, preference, procedure, condition, or behavioral direction that the agent can interpret and apply. The instruction space may contain instructions originating from different authorized sources or functional levels, such as system instructions $I^{S}$, user instructions $I^{U}$, task instructions $I_{\\tau}$, and skill or workflow instructions $I^{K}$, with these instruction sets forming relevant parts of the broader space, for example $I^{S}, I^{U}, I_{\\tau}, I^{K} \\subseteq I$. The elements of $I$ do not necessarily have equal authority, applicability, or effect: some instructions may apply generally, others only to a particular task $\\tau$, state $z_t$, or runtime condition, and some may be overridden, disabled, superseded, or rendered inapplicable according to the governing instruction hierarchy and applicable conditions. Thus, $I$ represents the broader space of instructions potentially relevant to agent behavior, while an active instruction set $I^{*}_{\\tau,t} \\subseteq I$ can represent the instructions that actually govern or guide the agent for task $\\tau$ at execution step $t$.\nConditions for an Instruction Space to Hold An instruction space $I$ can be considered to hold for an AI agent when its constituent instructions are available to, accessible by, or otherwise represented within the agent’s operative instructional environment and are capable of being considered under the applicable authority, scope, and runtime conditions. This does not require every $i_j \\in I$ to be active simultaneously; rather, the space may contain both currently applicable and conditionally applicable instructions. Let $\\alpha(i_j, \\tau, z_t, E_t) \\in \\{0,1\\}$ denote whether instruction $i_j$ is applicable to task $\\tau$ under agent state $z_t$ and runtime environment $E_t$, and let $\\lambda(i_j, I)$ represent the effect of instruction priority, authorization, conflict resolution, overriding, or disabling rules. The operative instruction set may then be expressed abstractly as $I^{*}_{\\tau,t} = \\{i_j \\in I \\mid \\alpha(i_j, \\tau, z_t, E_t) = 1 \\land \\lambda(i_j, I) = 1\\}$. Accordingly, the instruction space continues to hold even when some instructions are inactive, provided that the space itself remains defined and available; what changes with the task and runtime conditions is the subset of instructions that actually governs, constrains, or guides the agent’s current behavior.\nExplore Instruction Space Relevant Concepts Unit Instruction A unit instruction is an individual instruction within an instruction space ${I}$ that expresses a distinct direction, requirement, constraint, preference, condition, or other guidance for an AI agent when performing a task. For a user task $\\tau$, the user’s task instruction at step $t$ can be represented as ${I}^{U}\\_{\\tau,t}={I}^{E}\\_{\\tau,t}\\cup{I}^{I}\\_{\\tau,t}={i\\_1,i\\_2,\\ldots,i\\_{n\\_t}}$, where each $i\\_j$ is a unit instruction, ${I}^{E}\\_{\\tau,t}$ contains explicit unit instructions directly stated by the user, and ${I}^{I}\\_{\\tau,t}$ contains implicit unit instructions indirectly expressed by the user and identified through instruction detection, such as semantic matching or contextual interpretation. A unit instruction does not need to correspond to a separate sentence or command; it represents a distinct instructional meaning that can be identified as part of the user’s broader task instruction. Because additional instructions or instructional meanings may arise or become identifiable as the task proceeds, the user’s task instruction can change over time, so ${I}^{U}\\_{\\tau,t+1}$ may include new unit instructions that were not included or identified at an earlier step.\n","permalink":"https://www.zhumengyao.com/notes/agentic-ai-understanding-instruction-space/","summary":"\u003ch2 id=\"definition-of-instruction-space\"\u003eDefinition of Instruction Space\u003c/h2\u003e\n\u003cp\u003eAn instruction space is the organized set of instructions that may govern, constrain, guide, or otherwise influence the behavior of an AI agent. It can be represented as $I = \\{i_1, i_2, \\ldots, i_n\\}$, where $I$ denotes the instruction space and each $i_j \\in I$ denotes a unit instruction expressing an individual rule, requirement, constraint, preference, procedure, condition, or behavioral direction that the agent can interpret and apply. The instruction space may contain instructions originating from different authorized sources or functional levels, such as system instructions $I^{S}$, user instructions $I^{U}$, task instructions $I_{\\tau}$, and skill or workflow instructions $I^{K}$, with these instruction sets forming relevant parts of the broader space, for example $I^{S}, I^{U}, I_{\\tau}, I^{K} \\subseteq I$. The elements of $I$ do not necessarily have equal authority, applicability, or effect: some instructions may apply generally, others only to a particular task $\\tau$, state $z_t$, or runtime condition, and some may be overridden, disabled, superseded, or rendered inapplicable according to the governing instruction hierarchy and applicable conditions. Thus, $I$ represents the broader space of instructions potentially relevant to agent behavior, while an active instruction set $I^{*}_{\\tau,t} \\subseteq I$ can represent the instructions that actually govern or guide the agent for task $\\tau$ at execution step $t$.\u003c/p\u003e","title":"Understanding Agentic AI: Instruction Space"},{"content":"Definition of Runtime Skill Catalog A runtime skill catalog in Agentic AI is the collection of skills that are available to an AI agent for consideration and use while it is actively performing a task. Each skill represents a defined capability, procedure, workflow, or set of instructions for handling a particular type of requirement or subtask, such as information retrieval, document analysis, data processing, content generation, validation, or interaction with an external tool. The catalog provides the agent with an organized set of possible skills from which relevant ones can be identified and selected according to the current task, rather than requiring every available skill to be applied. It may contain skills that are permanently available in the agent’s environment as well as skills that become available dynamically because of the current configuration, connected tools, user permissions, task context, or other runtime conditions. In this sense, the runtime skill catalog describes the agent’s currently accessible skill space: it indicates what skills the agent can potentially use at a particular point during execution, while the actual skills triggered for a task form only a task-relevant subset of that catalog.\nConditions for the Runtime Skill Catalog to Hold in Agentic AI A runtime skill catalog holds when the agent has access, during task execution, to a defined and discoverable set of skills whose availability and applicability can be determined from the current runtime environment. For a skill to meaningfully belong to the catalog, the agent should be able to identify the skill and obtain sufficient information about what it does, when it should be used, what inputs or resources it requires, and any constraints governing its use. The skill must also be operationally available under the current conditions; for example, required tools, resources, permissions, dependencies, or execution capabilities must either already be available or be obtainable through an explicitly supported procedure. The catalog does not require every listed skill to be relevant to every task, because skill selection occurs after the agent interprets the current requirements and determines which available skills correspond to them. Its contents may therefore remain fixed for an execution session or change dynamically as tools are connected, permissions change, additional skills are discovered or loaded, or environmental conditions change. If a nominally defined skill cannot be discovered, accessed, interpreted, or executed under the current runtime conditions, it should not normally be treated as an immediately usable member of the agent’s runtime skill catalog, even if that skill exists elsewhere in the broader system.\n","permalink":"https://www.zhumengyao.com/notes/agentic-ai-understanding-runtime-skill-catalog/","summary":"\u003ch2 id=\"definition-of-runtime-skill-catalog\"\u003eDefinition of Runtime Skill Catalog\u003c/h2\u003e\n\u003cp\u003eA runtime skill catalog in Agentic AI is the collection of skills that are available to an AI agent for consideration and use while it is actively performing a task. Each skill represents a defined capability, procedure, workflow, or set of instructions for handling a particular type of requirement or subtask, such as information retrieval, document analysis, data processing, content generation, validation, or interaction with an external tool. The catalog provides the agent with an organized set of possible skills from which relevant ones can be identified and selected according to the current task, rather than requiring every available skill to be applied. It may contain skills that are permanently available in the agent’s environment as well as skills that become available dynamically because of the current configuration, connected tools, user permissions, task context, or other runtime conditions. In this sense, the runtime skill catalog describes the agent’s currently accessible skill space: it indicates what skills the agent can potentially use at a particular point during execution, while the actual skills triggered for a task form only a task-relevant subset of that catalog.\u003c/p\u003e","title":"Understanding Agentic AI: Runtime Skill Catalog"},{"content":"Definition of Agentic AI Agentic AI refers to an approach to artificial intelligence in which an AI system is designed not only to generate responses but also to pursue defined objectives by determining and performing actions within an operational environment. An agentic AI system may interpret a task, reason about what needs to be accomplished, plan or select appropriate actions, use available tools and information sources, execute individual steps, evaluate intermediate results, and determine subsequent actions according to the current state of the task. Depending on its design, these activities may include searching for information, analyzing data, interacting with software, generating or modifying files, calling external tools, coordinating multiple operations, or requesting additional information when necessary. The defining characteristic of agentic AI is therefore not simply the use of a large language model, but the organization of AI capabilities into a goal-directed process in which reasoning and action can be connected across multiple steps. The degree of autonomy can vary substantially: some agentic AI systems operate within tightly predefined workflows, while others are given greater flexibility to determine how an objective should be achieved.\nConditions for Agentic AI to Operate For an AI system to operate agentically, it generally requires a defined objective or task, instructions or rules governing its behavior, access to the information and capabilities necessary for performing relevant actions, and some mechanism for determining what should happen as execution progresses. The system must be able to connect its current task state with an appropriate next action rather than treating every interaction as an isolated response. Depending on the application, this may involve reasoning, planning, task decomposition, tool selection, memory or state management, result evaluation, error handling, fallback mechanisms, and decisions about whether to continue, revise, retry, switch methods, request assistance, or terminate the workflow. Not every agentic AI system requires all of these capabilities, and their implementation can range from relatively simple predefined procedures to more adaptive workflows in which the agent selects actions dynamically. The important condition is that the system can use available instructions, information, tools, and execution results to determine and perform actions that contribute to accomplishing the specified objective within established constraints.\n","permalink":"https://www.zhumengyao.com/notes/agentic-ai-understanding-agentic-ai/","summary":"\u003ch2 id=\"definition-of-agentic-ai\"\u003eDefinition of Agentic AI\u003c/h2\u003e\n\u003cp\u003eAgentic AI refers to an approach to artificial intelligence in which an AI system is designed not only to generate responses but also to pursue defined objectives by determining and performing actions within an operational environment. An agentic AI system may interpret a task, reason about what needs to be accomplished, plan or select appropriate actions, use available tools and information sources, execute individual steps, evaluate intermediate results, and determine subsequent actions according to the current state of the task. Depending on its design, these activities may include searching for information, analyzing data, interacting with software, generating or modifying files, calling external tools, coordinating multiple operations, or requesting additional information when necessary. The defining characteristic of agentic AI is therefore not simply the use of a large language model, but the organization of AI capabilities into a goal-directed process in which reasoning and action can be connected across multiple steps. The degree of autonomy can vary substantially: some agentic AI systems operate within tightly predefined workflows, while others are given greater flexibility to determine how an objective should be achieved.\u003c/p\u003e","title":"Understanding Agentic AI: Agentic AI"},{"content":"Definition of Fallback Instructions Fallback instructions in the context of agentic AI are predefined alternative instructions that specify how an AI agent should proceed when its primary instructions, preferred method, or intended workflow cannot be successfully performed. They provide the agent with an alternative path toward the same task objective rather than allowing the process to stop unnecessarily when the preferred approach encounters a limitation or failure. The fallback instructions may simplify the original procedure, relax nonessential requirements, use a different available tool or information source, substitute an alternative method, or produce a more limited but still useful result. For example, if the primary instructions require an agent to retrieve information from a specialized external tool that is unavailable, fallback instructions might direct the agent to use another approved information source or complete only the parts of the task that can be reliably performed. Fallback instructions therefore serve as a form of predefined contingency guidance: the primary instructions describe how the task should preferably be performed, while the fallback instructions describe an acceptable alternative when that preferred approach is not feasible. Importantly, fallback instructions do not necessarily represent an inferior method; they represent a secondary method selected because the conditions required for the primary method are not satisfied.\nConditions for Fallback Instructions to Hold Fallback instructions should take effect only when predefined conditions indicate that the primary instructions cannot be successfully, reliably, or appropriately performed. Such conditions may include the unavailability of a required tool or resource, missing information that is necessary for the primary procedure, repeated failure of an attempted operation, an output that does not satisfy specified requirements, technical or environmental limitations, conflicting constraints, insufficient capabilities, or restrictions that prevent the preferred action from being carried out. The triggering condition should ideally be defined clearly enough that the agent can distinguish between a genuine inability to follow the primary instructions and an ordinary difficulty that can still be resolved within the primary procedure. In particular, fallback instructions should not normally be activated merely because the alternative method is easier, faster, or requires less effort if the primary instructions remain feasible and are explicitly preferred. Once the relevant fallback condition holds, the agent can transition from the primary instructions to the corresponding fallback instructions and continue pursuing the original objective within the alternative procedure\u0026rsquo;s permitted scope. If the fallback instructions themselves cannot be performed, the agent may proceed to another explicitly defined fallback level, request necessary information or assistance, or report that the task cannot be completed under the available conditions.\nPrimary and Fallback Instructions in Agentic Skill Engineering Primary instructions and fallback instructions are both essential components of robust agentic skill engineering because they jointly define how an agent should perform a task under both intended and alternative execution conditions. The primary instructions should be attempted first because they represent the preferred workflow designed to achieve the expected result. If these instructions cannot be successfully performed because of tool unavailability, missing information, execution failure, capability limitations, environmental constraints, or other predefined conditions, the corresponding fallback instructions can then be triggered to provide an alternative execution path. This conditional transition allows the predefined workflow to continue progressing toward the expected result rather than terminating immediately when a particular step or method becomes infeasible. From this perspective, the inclusion of fallback instructions can be regarded as part of a dynamic continuity mechanism within an agentic skill: although the fallback instructions themselves are predefined, their activation occurs dynamically in response to conditions encountered during execution. By enabling the agent to move from a preferred execution path to an alternative viable path when necessary, this mechanism can improve workflow continuity, robustness, and adaptability while reducing avoidable abrupt interruptions before the expected result has been achieved.\n# Pseudo-Algorithm: Primary–Fallback Execution for a Downstream Task Input: Downstream Task T Agentic Skill(s) S AI Agent A Supporting LLM(s) M 1. Apply the applicable skill(s) S to perform T with agent A supported by LLM(s) M. 2. Execute the Primary Instructions defined for T. 3. Evaluate whether the primary execution succeeds according to the predefined requirements. 4. If successful: → Return the Expected Result for T. 5. If unsuccessful: Check whether a predefined Fallback Condition holds → If so, trigger the corresponding Fallback Instructions → Execute the Alternative Path for T → Evaluate the Result 6. If the fallback execution succeeds: → Return the Expected Result for T. Else: → Trigger another defined fallback, if available → Otherwise, return the best valid result or report the unresolved limitation. Explore the Relevant Concepts AI Agent\nAn AI agent is LLM-supported software designed to interpret and follow dynamic instructions to perform different downstream tasks. For a particular task, the agent may operate under predefined default requirements while also determining newly specified or detected requirements from the user’s task instructions, provided context, intermediate results, and conditions encountered during execution. These requirements can correspondingly give rise to predefined default subtasks and newly detected subtasks, which are dynamically combined to form the complete task to be performed. Newly detected requirements and subtasks can be determined through multiple methods, including explicit instruction parsing, rule-based identification, contextual inference, classification, and semantic matching. Semantic matching can be particularly effective because it makes direct use of the LLM’s language-understanding capabilities to determine whether different expressions represent the same, overlapping, related, or distinct requirements and subtasks, rather than relying only on identical wording or fixed keywords. Based on task-specific and user-defined standards, this analysis can be conducted at different levels of granularity, from identifying broad task requirements and major subtasks to distinguishing finer-grained requirements, constraints, conditions, and individual operations. The practical capabilities of an AI agent can improve as its supporting LLM becomes more capable of language understanding, reasoning, tool use, and result evaluation; as human-designed workflows are progressively refined and optimized; and as more relevant, accurate, and sufficiently detailed contextual information is provided for the agent to comprehend and perform the task. The effectiveness of an AI agent therefore depends on the combined quality of its supporting LLM, instructions, requirement and subtask identification methods, workflow design, available tools and resources, contextual information, and mechanisms for dynamically adapting execution to the specific task and user requirements.\n# Pseudo-Algorithm: LLM-Supported AI Agent Execution for a Downstream Task Input: Downstream Task T User Task Instructions I Provided Context C Predefined Default Requirements R_default Predefined Default Subtasks U_default Agentic Skill(s) S Available Tool(s) and Resource(s) G AI Agent A Supporting LLM(s) M Evaluation Criteria E 1. Initialize the task execution for T using A supported by M. 2. Analyze I and C to identify the requirements for T: → Retain applicable predefined default requirements R_default → Identify newly specified or detected requirements R_new → Identify constraints, conditions, dependencies, and expected outputs → Resolve overlapping, equivalent, related, or conflicting requirements where necessary 3. Construct the complete requirement set: R = Combine(R_default, R_new) 4. Determine the subtasks required to satisfy R: → Retain applicable predefined default subtasks U_default → Derive newly required subtasks U_new from R, I, C, and task conditions → Remove redundant or semantically equivalent subtasks → Identify dependencies and required execution order 5. Construct the complete task structure: U = Organize(U_default, U_new) 6. Determine the execution method for each subtask: → Select and apply relevant Agentic Skill(s) S → Select appropriate Tool(s) and Resource(s) G where required → Use M for language understanding, reasoning, generation, tool-use decisions, semantic matching, and result evaluation as appropriate 7. Execute the subtasks in the required order. 8. During execution: → Observe intermediate results and encountered conditions → Detect newly emerging requirements, constraints, or subtasks → If material changes are detected: Update R Update U Adjust the remaining execution path 9. Evaluate intermediate and final results against E and the complete requirement set R. 10. If the result satisfies the required criteria: → Return the completed result for T. 11. If the result does not satisfy the required criteria: → Identify the unsatisfied requirement(s) or failed subtask(s) → Determine whether execution can be revised, retried, or redirected → Apply an alternative method, skill, tool, or fallback path where available → Re-execute the affected subtask(s) → Re-evaluate the result 12. If further valid execution paths remain: → Continue Steps 7–11 as required. 13. Otherwise: → Return the best valid result obtainable → Report any unresolved requirement, limitation, or execution failure. Primary Instructions\nPrimary instructions are the principal set of instructions that define how an AI agent should perform an entire task, including the task objective, its constituent components or subtasks, their relationships and execution requirements, and the preferred execution path through which the expected result should be pursued. Their natural counterpart is fallback instructions, or more generally alternative instructions, which provide other execution paths when the primary path cannot be successfully followed or when multiple approaches are intentionally being explored. In established agentic skills, primary instructions may represent a preferred or widely verified method whose effectiveness in producing the expected type of result has already been demonstrated, while fallback instructions provide alternative methods for maintaining task execution when the primary method becomes infeasible or unsuccessful. However, primary instructions do not necessarily imply that the corresponding method has already been established as the best method. For tasks in which the final result, optimal procedure, or relative effectiveness of different approaches is not known in advance, an agentic skill may instead support dynamic exploration of multiple predefined or dynamically constructed execution paths. These paths can be assessed using predefined evaluation metrics or success criteria, allowing the agent to compare their outcomes and identify a more effective method through execution and evaluation. In such cases, the primary instructions may initially represent one preferred or candidate method among several possible approaches rather than a permanently established procedure, and the agentic skill can progressively determine which execution path is most effective for achieving the task objective.\n","permalink":"https://www.zhumengyao.com/notes/agentic-ai-understanding-fallback-instructions/","summary":"\u003ch2 id=\"definition-of-fallback-instructions\"\u003eDefinition of Fallback Instructions\u003c/h2\u003e\n\u003cp\u003eFallback instructions in the context of agentic AI are predefined alternative instructions that specify how an AI agent should proceed when its primary instructions, preferred method, or intended workflow cannot be successfully performed. They provide the agent with an alternative path toward the same task objective rather than allowing the process to stop unnecessarily when the preferred approach encounters a limitation or failure. The fallback instructions may simplify the original procedure, relax nonessential requirements, use a different available tool or information source, substitute an alternative method, or produce a more limited but still useful result. For example, if the primary instructions require an agent to retrieve information from a specialized external tool that is unavailable, fallback instructions might direct the agent to use another approved information source or complete only the parts of the task that can be reliably performed. Fallback instructions therefore serve as a form of predefined contingency guidance: the primary instructions describe how the task should preferably be performed, while the fallback instructions describe an acceptable alternative when that preferred approach is not feasible. Importantly, fallback instructions do not necessarily represent an inferior method; they represent a secondary method selected because the conditions required for the primary method are not satisfied.\u003c/p\u003e","title":"Understanding Agentic AI: Fallback Instructions"}]