AgentFactory: Self-Evolving Executable Agents
- AgentFactory is a self-evolving framework that converts task solutions into executable Python subagent code rather than relying on textual artifacts.
- It orchestrates a Meta-Agent, Skill System, and Workspace Manager to generate, refine, and safely deploy reusable subagents in procedural workflows.
- Empirical benchmarks reveal reduced orchestration tokens compared to ReAct and textual self-evolution methods, emphasizing improved efficiency and reusability.
Searching arXiv for the specified AgentFactory paper and closely related framework papers to ground the article.
AgentFactory is a self-evolving framework for large-language-model-based agents in which successful task solutions are preserved as executable Python subagent code rather than as textual reflections, prompt edits, or reasoning traces. Its central claim is that executable subagents can be reused, run, inspected, and refined more reliably than textual memories in complex procedural workflows. The framework therefore treats prior success as a growing library of portable capabilities: subagents are accumulated, improved through execution feedback, documented with standardized SKILL.md files, and exported to any Python-capable system (Zhang et al., 18 Mar 2026).
1. Problem setting and conceptual shift
AgentFactory is motivated by a limitation that the paper attributes both to standard agent frameworks and to earlier self-evolution methods. Frameworks such as LangChain or AutoGPT support agent execution, but are described as largely static in the sense that knowledge gained during one run does not persist in a reusable form. Self-evolution methods such as Reflexion or Self-Refine do retain prior experience, but they do so as textual artifacts—reflections, summaries, or reasoning traces—which the paper argues are too weak for reliable task re-execution in complex real-world settings (Zhang et al., 18 Mar 2026).
The framework is therefore organized around a deliberate transition from textual recollection to executable reuse. The paper characterizes this as a shift from textual experience to executable capability:
This is particularly relevant for tasks that decompose into recurring procedural subtasks, including web search, file manipulation, audio transcription, document generation, browser automation, plotting, and data analysis. In that framing, what persists is not merely a description of how a task was solved, but the operational logic itself (Zhang et al., 18 Mar 2026).
A common misconception is to treat AgentFactory as a memory system in the usual prompt-engineering sense. The paper instead presents it as a persistent executable memory model: reusable capabilities are stored as code, re-run on later tasks, and revised when execution feedback reveals brittleness or incompleteness (Zhang et al., 18 Mar 2026).
2. Architecture and control structure
AgentFactory is structured around three main components: a Meta-Agent, a Skill System, and a Workspace Manager (Zhang et al., 18 Mar 2026).
The Meta-Agent is the central orchestrator. It analyzes the task, decomposes it into subproblems, creates subagents, runs subagents, checks results, modifies subagents based on feedback, and saves mature subagents. A notable design choice is that the Meta-Agent does not expose the entire tool set to every subagent; instead, it selects and allocates relevant tools to each subagent. The paper presents this as a way to reduce search space and keep subagents focused (Zhang et al., 18 Mar 2026).
The Skill System unifies operations into three levels:
- Meta skills:
create_subagent,get_skill_description,run_subagent,modify_subagent,finish,list_saved_subagents,view_subagent_code - Tool skills:
web_search,web_reading,browser_automation,shell_command - Subagent skills: dynamically generated executable Python scripts that are saved when successful and refined later when needed
This arrangement gives AgentFactory a layered control structure in which orchestration primitives, built-in tools, and accumulated executable subagents are all treated as skills, but with different roles in the lifecycle (Zhang et al., 18 Mar 2026).
The Workspace Manager executes each task in its own isolated workspace directory. The paper associates this with sandboxing, safe code execution, non-interference between tasks, and containment of failures during modification or testing. Successful results and improved subagents are then promoted from the workspace into the persistent skill library (Zhang et al., 18 Mar 2026).
3. Subagent lifecycle and persistent accumulation
The framework is formalized as a three-phase pipeline:
This sequence defines the lifecycle of a subagent and the mechanism by which AgentFactory accumulates capabilities over time (Zhang et al., 18 Mar 2026).
During Install, the system handles tasks that cannot be solved by existing skills. The Meta-Agent identifies required capabilities, decomposes the task into subproblems, and uses create_subagent to generate specialized Python scripts. If execution succeeds, the resulting subagent is saved as pure Python code together with a SKILL.md file documenting functionality, parameters, and usage (Zhang et al., 18 Mar 2026).
During Self-Evolve, the system attempts reuse before regeneration. The Meta-Agent calls list_saved_subagents to retrieve candidate subagents relevant to a new task, runs them on the new variant, and inspects execution feedback if performance is inadequate. It then invokes modify_subagent to update the code—for example by adding error handling, broadening supported cases, improving parsing, or restructuring logic—and validates the modified version on the current task. The refinement loop is therefore execution-feedback-driven and operates directly on runnable code rather than on prompt text (Zhang et al., 18 Mar 2026).
During Deploy, mature subagents are exported as standalone Python modules. Because they are pure Python and accompanied by standardized SKILL.md documentation, they can be used outside the AgentFactory runtime. The paper explicitly lists deployment modes that include standalone execution and integration with systems such as LangChain, AutoGen, and Claude Code. It further states that an external system can read the SKILL.md documentation and invoke the subagent scripts without modifying the host framework (Zhang et al., 18 Mar 2026).
The cumulative effect is what the paper calls continuous capability accumulation: new tasks create new subagents, similar future tasks reuse them, failed subagents are refined, and improved versions replace older ones. This suggests a model of agent growth in which the library itself becomes a progressively more operationalized substrate for later work (Zhang et al., 18 Mar 2026).
4. Empirical evaluation
The evaluation asks whether executable subagent reuse reduces orchestration effort. The benchmark consists of two batches of 15 tasks each. Batch 1 contains diverse real-world tasks, including web information retrieval, plotting, browser automation, audio processing, document generation, and coding tasks. Batch 2 is a transfer set with the same overall structure but different specifics, such as housing sentiment versus electric vehicle sentiment, Stanford CS231n versus MIT 6.S191, Tokyo itinerary versus Paris itinerary, Bitcoin price versus Ethereum price, and Tetris versus Snake (Zhang et al., 18 Mar 2026).
The baselines are ReAct, which solves everything from scratch, and Self-Evolving Agent with Textual Experience, which saves summaries of what worked or failed and retrieves text memories later. The main metric is average output tokens per task for the orchestrating model only, excluding subagent-internal LLM usage. Lower token counts indicate that the orchestrator had to do less work and that reuse was more effective (Zhang et al., 18 Mar 2026).
| Method | Task setting | Opus 4.6 | Sonnet 4.6 |
|---|---|---|---|
| ReAct | Batch 1 | 8298 | 6893 |
| ReAct | Batch 2 | 7022 | 7029 |
| Self-Evolving Agents | Batch 1 (from scratch) | 8608 | 8163 |
| Self-Evolving Agents | Batch 2 (w/ saved) | 6210 | 8223 |
| AgentFactory | Batch 1 (from scratch) | 4324 | 9199 |
| AgentFactory | Batch 2 (w/ saved) | 2971 | 3862 |
The reported pattern is strongest for saved-subagent reuse in Batch 2. With Opus 4.6, AgentFactory reduces orchestration tokens to 2971, compared with 6210 for textual self-evolution and 7022 for ReAct. With Sonnet 4.6, AgentFactory reaches 3862 in Batch 2, compared with 8223 for textual self-evolution and 7029 for ReAct. The paper interprets these results as evidence that executable subagents are more reusable than text memories and that the value of the saved library increases over time (Zhang et al., 18 Mar 2026).
The paper also highlights an additional observation for Opus 4.6 in Batch 1: AgentFactory records 4324 tokens, compared with 8298 for ReAct. The authors argue that this suggests that even within the first batch, the model can begin reusing subagents created earlier in the same batch (Zhang et al., 18 Mar 2026).
5. Demonstrations, scope, and limitations
Two qualitative demonstrations illustrate the framework’s intended mode of operation. In the first, a README-generation subagent evolves over three runs. Run 1 is hardcoded for a specific project; Run 2 attempts dynamic LLM-based path parsing but retains a fragile fallback; Run 3 replaces the parsing with regex-based extraction. The example is used to show that AgentFactory can notice limitations and harden the code over time (Zhang et al., 18 Mar 2026).
In the second demonstration, AgentFactory creates subagents including Audio Transcriber, QQ Music Player, and later Document Creator. The workflow is then moved into Claude Code, where the external agent reads the SKILL.md files and directly reuses those subagents to solve a new audio-described document task. The example is intended to demonstrate saving, reuse, portability, and cross-system transfer (Zhang et al., 18 Mar 2026).
The framework’s current strengths are procedural workflows that are web-based or otherwise executable in Python environments. The paper also identifies limitations. Because the system autonomously generates and executes code, it raises safety concerns. The built-in shell_command tool includes security checks for destructive operations, but the paper still states that caution is needed. Browser automation and web interaction must be used with authorization and in compliance with terms of service. The code-based subagents can also fail on edge cases or require further refinement (Zhang et al., 18 Mar 2026).
Future work is described as extending the framework toward non-web applications through the integration of Vision-LLMs for GUI-based interactions. This suggests an intended expansion from predominantly web and Python-executable workflows toward broader interface-mediated task environments (Zhang et al., 18 Mar 2026).
6. Relation to the broader “factory” family of agent frameworks
Within recent agent-systems literature, “factory” has become a recurring design metaphor, but it is used for different outputs. AgentFactory itself is centered on executable subagent accumulation and reuse (Zhang et al., 18 Mar 2026). Closely related work uses the same metaphor for modular agent construction, dynamic agent instantiation, graph orchestration, trustworthy evolution, and synthetic agent-data production.
AgentForge is a lightweight modular framework for constructing LLM-driven autonomous agents through a composable skill abstraction, a unified LLM backend interface, and a declarative YAML-based configuration system. Its skill composition is formalized as a directed acyclic graph, and the paper positions it as a production-ready foundation for building, evaluating, and deploying agents (Jafari et al., 19 Jan 2026).
AOrchestra treats agent creation itself as the core runtime operation. It models any agent as the four-tuple —Instruction, Context, Tools, Model—and uses an orchestrator that decides between Delegate(\Phi) and Finish(y), thereby spawning task-specific executors on demand. In that sense, the system is “agent factory” like because the orchestrator repeatedly manufactures workers with customized recipes (Ruan et al., 3 Feb 2026).
MASFactory shifts the factory metaphor from standalone agents to executable multi-agent workflows. It models multi-agent systems as directed computation graphs with explicit control flow, message flow, and state flow, and introduces Vibe Graphing as an intent-to-structure-to-instantiation pipeline for compiling natural-language design intent into executable graph specifications (Liu et al., 6 Mar 2026).
Safactory extends the factory idea to trustworthy autonomous intelligence at infrastructure scale. It combines a Parallel Simulation Platform for trajectory generation, a Trustworthy Data Platform for storage and experience extraction, and an Autonomous Evolution Platform for asynchronous reinforcement learning and on-policy distillation, thereby reframing evaluation, data governance, and model evolution as a closed loop (Chen et al., 7 May 2026).
FABRIC applies the same logic to data generation rather than to runtime execution. It is a modular, LLM-only framework for synthesizing machine-checkable agentic records, including task specifications, tool definitions, policy pseudocode, dialogues, and execution traces, through pipelines such as RecordSynth, DAGFirstGeneration, MultiTurnDialogueSynth, and AgenticRecordRollout (Verma et al., 20 Oct 2025).
Additional domain-specialized variants extend the pattern further. El Agente Forjador autonomously forges, validates, and reuses scientific tools for quantum simulation through stages of tool analysis, tool generation, task execution, and solution evaluation (Zhang et al., 16 Apr 2026). “Agent Factories for High Level Synthesis” uses a two-stage pipeline in which multiple autonomous optimization agents first optimize sub-kernels and then explore global hardware transformations under an ILP-guided selection process (Bhandwaldar et al., 26 Mar 2026). This suggests that the term “AgentFactory” now names not a single architectural doctrine, but a family of systems in which capabilities are manufactured, accumulated, or orchestrated as reusable computational assets.
7. Significance
AgentFactory’s distinctive contribution is not a new prompting pattern or a new static framework interface, but a change in what the system chooses to preserve. By storing successful solutions as executable subagent code, the framework turns prior success into a portable and revisable operational artifact rather than a textual hint. Its empirical results are reported in terms of lower orchestration-token usage, and its qualitative demonstrations emphasize portability across frameworks and progressive hardening of reusable modules (Zhang et al., 18 Mar 2026).
For researchers, the framework is notable as a concrete formulation of persistent executable memory. For practitioners, it proposes a lifecycle in which task decomposition, subagent generation, feedback-driven modification, and export are integrated into one reusable loop. In the broader literature, related factory-style systems manufacture agents, workflows, tools, trajectories, or datasets; AgentFactory’s specific niche is the accumulation and reuse of executable subagents as the primary unit of agent self-evolution (Zhang et al., 18 Mar 2026).