The Agent Factory Problem: Governing AI Systems That Create and Evolve Other Agents

By AexoreX Systems Research The Intelligence, Research & Institutional Publication of AexoreX Systems

Executive Summary

Artificial intelligence (AI) is evolving beyond systems that merely answer questions or complete individual tasks. AI agents can now utilize tools, follow workflows, and execute multi-step activities. Further research is exploring methods for agents to create reusable subagents and enhance their performance through feedback.

This progress presents a new opportunity for enterprises: systems that can build and manage digital workers, eliminating the need to design every digital worker from scratch.

However, creating an agent does not automatically result in a reliable, secure, or authorized worker. An agent may perform well in testing but fail in a different environment. It might access unnecessary information or produce incorrect results while reporting success. New agents may also inherit risks from their originating system.

These challenges are amplified when one AI system can create other agents, which can then create or coordinate additional agents. The central question is no longer solely about building more capable AI. Instead, the focus shifts to controlling the entire process through which AI capabilities are created, tested, approved, deployed, monitored, and modified.

This article examines the emerging concept of the AI agent factory, detailing its potential benefits, risks, and the governance requirements for enterprise use. It also proposes an architectural direction for AEOS QUANTUM, the enterprise intelligence operating platform under development as part of the AexoreX Systems vision. This proposed architecture is a design direction, not a claim of current implementation.

From AI Agents to Agent Factories

An AI agent is a system designed to achieve a goal by using a model, tools, and a set of instructions. Depending on its design, an agent may search for information, process documents, operate software, or complete multiple steps within a workflow.

An agent factory extends this concept. Instead of creating each agent manually, an agent factory is a system designed to facilitate the creation, testing, organization, and improvement of agents for various tasks.

For example, consider a company requiring digital workers for research, customer support, document review, and business reporting. A traditional approach might involve a team configuring each digital worker separately. An agent factory could assist the company in generating specialized agents from approved task descriptions, testing their capabilities, and preparing them for review before deployment. The factory might also identify capabilities that can be reused across different tasks, thereby reducing repetitive work and simplifying the expansion of digital operations.

However, a crucial distinction exists: a system capable of creating agents does not inherently know which agents are useful, safe, or suitable for actual business operations. Agent creation is merely the initial step; reliable evaluation and controlled deployment are equally vital.

Current Research: AgentFactory

The 2026 research paper "AgentFactory: A Self-Evolving Framework Through Executable Subagent Accumulation and Reuse" investigates a method for preserving successful task solutions as executable subagent code. This framework stores reusable subagents and refines them using execution feedback, rather than relying solely on written descriptions of past experiences. This research provides an example of how an agent system can accumulate and reuse capabilities over time. It does not, however, establish that all forms of autonomous agent creation are reliable or safe in every business environment. (Source: ACL Anthology, 2026)

The broader implication is clear: reusable capabilities can enhance the efficiency of AI systems, but their quality must still be tested in their intended operational environments.

The Reuse and Evolution Problem

One of the most promising aspects of agent development is the ability to reuse successful work. For instance, if a research agent has already learned to organize public information into a structured report, a future task might require this same capability. Instead of rebuilding the entire process, an agent factory could reuse the existing component.

This offers three potential benefits: - **Less repeated work:** Successful components can be reused across multiple tasks. - **More consistent processes:** Approved components can adhere to the same documented procedures. - **Faster development:** New agents can be assembled from capabilities that have already been tested.

However, reuse also introduces new risks. A component that functioned well in one context might fail in another. A change that improves performance on one task could reduce reliability on a different task. Furthermore, a component might contain outdated assumptions or access requirements that are no longer appropriate. For example, a research subagent designed to read public documents should not automatically gain permission to access confidential company files merely because another agent possesses that permission. Similarly, an agent that successfully completes a reporting task should not automatically be authorized to publish the report externally.

The factory must differentiate between a capability that can be reused and an authority that must be granted separately.

Improvement Is Not Unrestricted Self-Modification

The term "self-evolving AI" can encompass several different approaches, including: - Reusing previously successful task solutions. - Refining instructions based on feedback. - Creating new specialized subagents. - Evaluating different agent designs. - Modifying executable code or workflows.

These approaches do not carry the same risk level. A system that reuses an approved component differs significantly from a system that can alter its own code, expand its permissions, and deploy new agents without independent review.

Therefore, enterprises should ask a more precise question than whether an agent can improve itself. They should ask: What can the system change, how are those changes tested, and who or what authorizes the changed system to operate? This question directly addresses the problem of authority.

The Authority Problem: Creating an Agent Does Not Authorize It

Consider an AI system that creates a new digital worker to assist with business communications. This new worker might be technically capable of reading messages, preparing replies, and sending emails. But should it be allowed to send messages to customers without approval? Should it access confidential information? Should it create additional agents?

These are not merely questions of intelligence; they are questions of authority. A system may be capable of performing an action without having permission to do so. This distinction is central to enterprise governance.

Capability Versus Authority

• **Capability** describes what a system *can* do.
• **Authority** defines what it is *permitted* to do.

For example: - **Capability:** Read a document. **Authority question:** Is the agent allowed to access this document? - **Capability:** Prepare an email. **Authority question:** Is the agent allowed to send it, or only draft it? - **Capability:** Create another agent. **Authority question:** Is agent creation permitted for this task? - **Capability:** Access a business application. **Authority question:** Which functions and data may the agent use? - **Capability:** Change an existing workflow. **Authority question:** Who approves the change? - **Capability:** Execute a financial or business transaction. **Authority question:** Is additional human approval required?

An agent factory should not decide these questions solely by asking its own AI model whether an action is appropriate. The governing system must apply defined rules and permissions. For higher-risk activities, human review of proposed actions may be necessary before execution. This is particularly important when one agent creates another; the new agent should not inherit broad authority simply because its parent agent has access to certain tools.

The Principle of Least Privilege

A valuable security principle is to grant each system only the access it requires to perform its assigned work. An agent created for public research may need access to approved public sources, but it does not automatically need access to internal customer records. An agent designed to draft reports may need permission to create documents, but not necessarily permission to publish them.

This same principle should apply to the agent factory itself. The ability to create a new agent should not automatically include the authority to approve, deploy, and supervise that agent. These responsibilities should be separated where appropriate. An agent factory may create a capability, but a separate governance process should determine if, where, and under what conditions that capability can be used.

The Containment Problem: Permissions Alone Are Not Enough

While giving an agent limited permissions is necessary, it may not be sufficient. A system can have valid permission yet still cause an unwanted result within the scope of that permission. For instance, an agent authorized to update a document might accidentally overwrite important information. Another agent allowed to read public websites could encounter malicious instructions designed to influence its behavior. An agent might also initiate an operation that continues even after the original task has been canceled.

These examples illustrate why authorization and containment are distinct: - **Authorization** determines which actions are permitted. - **Containment** limits what can happen if something goes wrong.

A controlled agent environment may require several safeguards: - Restricting access to approved tools and data. - Limiting the scope and duration of each task. - Separating development, testing, and production environments. - Preventing generated code from running without appropriate checks. - Limiting the number of additional agents that can be created. - Monitoring activity and detecting unexpected behavior. - Providing a reliable mechanism to stop or isolate an agent. - Checking whether stopping an agent also halts its related operations.

These controls become more critical when agent factories can rapidly produce numerous agents. Without adequate controls, the number of agents could grow faster than the organization's ability to understand and manage them.

The Problem of Inherited Risk

An agent factory might reuse an existing component containing a security weakness. If this component is copied into many new agents, the same weakness can proliferate. Similarly, an agent might create a subagent that uses a third-party tool or service. The parent agent's own controls may not fully govern activities within that separate environment.

This means an enterprise must understand not only individual agents but also their relationships. It should be possible to answer questions such as: - Which agent created this subagent? - Which approved components does it use? - What permissions does it have? - Which external systems can it access? - Which tasks depend on it? - What happens if the component is found to be unsafe?

These are lifecycle and dependency-management questions, not solely model-performance questions.

The Evidence Problem: An Agent's Report Is Not Proof

Suppose an agent reports that it successfully completed a task. Is this sufficient to trust the result? Not necessarily. The agent may misunderstand the task, report an incomplete result, or fail to recognize that an external system rejected its request. A generated report might describe the agent's intended actions rather than what actually occurred. For enterprise use, the system requires independently verifiable evidence.

What Useful Evidence Can Include

Depending on the task, evidence may include: - The original task request. - The version of the agent that performed the task. - The permissions and policies active at the time. - The tools and external systems involved. - The actions requested and the responses received. - The results of independent tests. - Any human approval required. - The final state of the relevant system. - Errors, exceptions, and recovery actions.

Not every task demands the same level of evidence. A low-risk internal summary may require less documentation than an action that modifies business records or communicates externally on behalf of a company. Evidence requirements should align with the associated risk.

Testing Must Be Independent of the Agent's Own Claims

An agent should not be deemed reliable simply because it evaluates itself positively. For example, an agent created to summarize research could be tested against a set of documents with known facts. Reviewers could check if it accurately represents the source material and distinguishes verified information from uncertainty. An agent designed to modify software could be tested in an isolated environment before being permitted to affect a production system. An agent intended to communicate with customers could first be limited to drafting messages for human review.

The key is to test the actual outcome, not merely the agent's explanation of that outcome. Self-reporting can offer useful information but should not be treated as independent proof. This distinction becomes even more critical when one agent evaluates another. A second AI system may aid in evaluation, but it might share similar weaknesses with the system being evaluated. For higher-risk work, organizations should consider independent checks, deterministic rules, external system confirmation, and human review where appropriate.

The Emerging Enterprise Landscape

Several major technology providers are developing infrastructure for building, operating, and governing AI agents. Their approaches vary, and no single platform should be assumed to solve every agent-factory problem. The following examples illustrate market direction but do not constitute a ranking of vendors.

Microsoft Agent 365

Microsoft announced the general availability of Agent 365 for commercial customers on May 1, 2026. The platform focuses on observing, governing, and securing agents across an organization. Microsoft has also described efforts to improve the discovery and management of agents operating across different environments. Some related capabilities were announced as previews rather than generally available features. (Source: Microsoft Security Blog)

**Why it matters:** Organizations need visibility into which agents exist, what they can access, and how they interact with business systems.

Google Gemini Enterprise Agent Platform

Google Cloud announced the Gemini Enterprise Agent Platform in April 2026, followed by updates to its capabilities. Google described services for building, deploying, and managing agents, including Agent Runtime and Agent Identity. Its July 29, 2026, update stated that several capabilities, including these services, were available. Availability can still depend on the specific service and configuration. (Source: Google Cloud)

**Why it matters:** Agent development requires support from operational infrastructure, identity controls, and mechanisms to manage deployed systems.

AWS Amazon Bedrock AgentCore

AWS provides AgentCore services for building, connecting, and operating AI agents. In September 2026, AWS announced a new AgentCore Runtime designed to support agent workloads with managed infrastructure, session isolation, and more efficient resource use. Availability and regional support depend on the specific runtime version and configuration. (Source: AWS)

**Why it matters:** Enterprise agents need a controlled environment in which they can execute tasks, interact with other systems, and operate reliably.

What These Developments Mean

These platforms demonstrate that enterprise agent infrastructure is expanding beyond mere model access and prompt design. Identity, runtime environments, observability, permissions, and lifecycle management are becoming crucial components of the broader ecosystem.

However, these products should not be interpreted as proof that fully autonomous, self-evolving agent factories are already a solved problem. Building an agent, operating an agent, and governing a system that creates other agents are related but distinct challenges. A mature enterprise architecture may need to connect all three.

A Proposed AEOS QUANTUM Digital Labor Factory

The following outlines a proposed architectural direction for AEOS QUANTUM, detailing how AexoreX Systems could approach this problem as the platform evolves. This is a design concept, not a statement that all components are currently available or implemented. The objective is to separate the creation of digital capabilities from the authority to use them.

Layer 1 — Digital Labor Specification

Every proposed digital worker begins with a defined purpose. The specification should detail: - What task it is intended to perform. - What inputs it may receive. - What output it should produce. - What it must not do. - Which systems it may need to access. - When human review is required. - How success will be measured.

A clear specification reduces ambiguity before development begins.

Layer 2 — Digital Labor Generation

An AI model may assist in creating the proposed agent, its instructions, its workflow, or its supporting code. The generation process should utilize approved tools and templates where possible. The output should be treated as a proposed component, not as an automatically trusted production system. Creating an agent should not grant it operational authority.

Layer 3 — Capability Registry

Each generated agent should have a record detailing its identity, purpose, version, dependencies, and status. For example, an organization might classify agents as: - In development. - Under evaluation. - Approved for limited use. - Approved for defined production tasks. - Suspended. - Retired.

The registry should also record which components were reused and which agent or process created the new component. This supports traceability and helps identify the impact of a defective component.

Layer 4 — Independent Evaluation

Before an agent is approved for operational use, it should be tested against its specification. Evaluation may include: - Accuracy. - Task completion. - Reliability across different inputs. - Compliance with defined restrictions. - Security and access boundaries. - Resistance to misleading instructions. - Resource use and execution time. - Correct handling of errors.

Testing should be proportionate to the task's risk. A component that only prepares an internal draft may require a different approval process than one that can change records or trigger external actions. Passing an evaluation should only establish that the agent met the defined criteria under the tested conditions. It should not be treated as proof that the agent will never fail.

Layer 5 — Authority and Approval

This layer determines what the agent is permitted to do. Approval should be based on the task, the system's capabilities, the data involved, the risks, and the organization's policies. Possible controls include: - Read-only access. - Permission to prepare drafts. - Permission to execute a limited set of actions. - Mandatory approval before external or high-impact actions. - Automatic rejection of prohibited actions. - Suspension when required conditions are not met.

The approval process should remain separate from agent generation wherever practical. An AI system may recommend that an agent is ready for deployment, but this recommendation should not automatically grant the agent additional permissions.

Layer 6 — Controlled Execution

Approved agents should operate through controlled execution environments and approved connections to external systems. The environment should enforce the permitted scope of each task. It should also support monitoring, error handling, and appropriate stop or hold mechanisms. A stop request must be evaluated across relevant execution paths; stopping one agent does not necessarily cancel a task already accepted by another service. For this reason, organizations need to consider the state of ongoing operations, not only the status of the agent process.

Layer 7 — Evidence Ledger

The system should maintain an appropriate record of important decisions and actions. This may include the agent version, task specification, applicable policy, approval record, execution events, evaluation results, and confirmed outcome. The goal is to make important actions traceable. A log is not automatically trustworthy merely because it exists; its integrity, access controls, retention, and relationship to external system records must also be considered. For higher-risk actions, independent confirmation may be needed to establish whether the intended result actually occurred.

Layer 8 — Lifecycle Governance

An agent's approval should not endure indefinitely without review. Its permissions or approval status may need to change when: - Its code or instructions change. - Its dependencies are updated. - Its access requirements change. - A new security weakness is discovered. - Its evaluation results become outdated. - Its intended purpose changes. - It repeatedly fails to meet required standards.

The organization should be able to suspend or retire an agent and review any related components that depend on it. A new version should not automatically inherit production approval simply because an earlier version was approved. The proposed AEOS QUANTUM approach treats Digital Labor as a managed lifecycle, not as a collection of independent AI tools.

The Human Role in an Increasingly Autonomous Enterprise

A digital labor factory may automate parts of agent creation, testing, and deployment preparation. However, automation does not eliminate the need to define responsibility. Organizations must still determine who owns a business process, who approves high-impact actions, and who is accountable when a system fails.

Human involvement does not necessarily mean manually reviewing every low-risk action. Instead, human control can be concentrated where judgment, accountability, or significant consequences demand it. For example: - A low-risk research agent may operate within an approved scope. - A reporting agent may prepare a document automatically but require review before publication. - An agent proposing a significant business change may need explicit approval. - A system that detects a policy violation may be required to stop and escalate the issue.

This approach allows for beneficial automation while preserving clear responsibility. The level of autonomy should depend on the task, the available evidence, the controls in place, and the consequences of failure. It should not depend solely on how capable the underlying AI model appears to be.

A Practical Rule

Automate within approved boundaries. Escalate when those boundaries are unclear or exceeded. This rule is simple, but its consistent application requires defined policies, enforceable controls, and reliable evidence.

What Enterprises Should Measure

An agent factory should not be judged solely by the number of agents it creates. A high number of agents might indicate productivity, but it could also signal duplication, unnecessary complexity, or uncontrolled growth. Enterprises should measure both benefits and risks.

**Area | Example Question** ---|--- **Productivity** | Does reuse reduce the time needed to complete a task? **Quality** | Do generated agents meet defined performance requirements? **Reliability** | How often do they fail under realistic conditions? **Security** | Do they stay within approved access boundaries? **Authority** | Can unauthorized actions be prevented or rejected? **Evidence** | Can important outcomes be independently verified? **Lifecycle** | Can unsafe or outdated agents be suspended quickly? **Cost** | Does the benefit justify development and operating costs? **Human oversight** | Are approval requirements followed consistently? **Accountability** | Can the organization identify who approved the agent and its intended use?

These measures should be defined before deployment where possible and reviewed as the system evolves. A factory that quickly creates agents but cannot explain their permissions, performance, dependencies, or operational history is not necessarily an effective enterprise system. The objective is not to maximize the number of digital workers, but to create useful digital capabilities that can be trusted within clearly defined boundaries.

A Practical Starting Point for AexoreX Systems

AexoreX Systems does not need to start by building a fully autonomous factory that creates and deploys agents without human involvement. A more practical initial approach is a small, controlled Digital Labor Factory for an internal business process.

For instance, AexoreX Newsroom could serve as an initial use case. A controlled workflow could help with: - Preparing research briefs from approved sources. - Checking whether important claims have supporting evidence. - Drafting articles for editorial review. - Preparing publication metadata. - Creating social media drafts for different channels. - Checking links and required fields. - Recording approval and publication status.

Initially, this workflow could leverage existing AI tools and no-code automation services, without automatically creating new agents at every stage. The first version could use a small set of clearly defined digital workers with limited responsibilities. Once the workflow is reliable, AexoreX could evaluate which components are reusable and whether generating additional specialized agents would provide real benefits. New components should be tested and reviewed before gaining access to production workflows. Publication, external communications, and other consequential actions should remain subject to appropriate approval rules.

This approach offers a practical way to explore agent factories without assuming a complete enterprise-grade system already exists. It also creates an opportunity to learn from real workflows before designing more complex architecture.

Build Evidence Before Expanding Autonomy

A sensible development sequence would be: - **Stage 1 — Assisted Digital Labor:** AI helps people prepare work, but humans review the results. - **Stage 2 — Reusable Digital Labor:** Successful workflows and components are documented and reused. - **Stage 3 — Evaluated Digital Labor:** New or changed components must pass defined tests before approval. - **Stage 4 — Governed Execution:** Approved agents can perform specific actions within controlled boundaries. - **Stage 5 — Governed Agent Creation:** The system can help create new agents, while evaluation, authorization, and deployment remain controlled processes.

This is a proposed maturity path, not a claim about the current implementation status of AEOS QUANTUM. The principle is to increase autonomy only when evidence and controls justify it.

The Future: From Digital Workers to Digital Labor Factories

The long-term opportunity is significant. Organizations may eventually use systems that create specialized digital workers, test their performance, combine approved capabilities, and improve workflows based on observed results. Such systems could help enterprises adapt more quickly to changing needs.

A business might require a new research capability, a document-processing workflow, or a specialized agent for an internal operation. An agent factory could help produce and evaluate the necessary component, rather than requiring every task to begin with manual development.

However, several challenges persist: - Generated agents must work reliably outside the narrow conditions in which they were tested. - Organizations need to prevent the uncontrolled growth of agents and permissions. - Evaluation must provide meaningful evidence, not solely rely on the agents' own claims. - Changes to agents and their dependencies must be managed throughout their lifecycles. - Organizations must retain clear accountability for actions taken on their behalf.

These challenges are not resolved simply by using a more capable AI model. They demand an architecture that integrates intelligence with identity, policy, execution controls, monitoring, and evidence. The most valuable agent factory may therefore not be the one that creates the largest number of agents. It may be the one that creates the right capabilities, demonstrates they meet required standards, and ensures they operate only within their approved authority.

The AEOS QUANTUM Perspective

AEOS QUANTUM is envisioned as an enterprise intelligence operating platform that connects, governs, and coordinates enterprise capabilities rather than replacing every existing system. Within this vision, a Digital Labor Factory could become a means to create and manage digital workers while maintaining clear distinctions between capability and authority.

The proposed architecture follows a simple sequence: Specify → Generate → Evaluate → Authorize → Execute → Verify → Govern.

Evidence should support this entire sequence. A system should not assume a generated agent is safe because it was created by a trusted model. It should not assume an agent is authorized because it passed a performance test. And it should not assume a task succeeded because the agent reported success.

These distinctions lead to three core principles: - **Capability ≠ Authority:** Being able to perform an action does not mean being permitted to perform it. - **Authorization ≠ Containment:** Permission controls must be supported by safeguards that limit unintended effects. - **Self-Report ≠ Evidence:** An agent's explanation of its actions should not replace independent verification where verification is required.

Together, these principles provide a foundation for considering Digital Labor as an enterprise capability that must be governed throughout its lifecycle. The long-term vision is not merely an AI system that can create more AI systems. It is an enterprise architecture in which new digital capabilities can be created and reused without losing control over who or what may use them, how they operate, and how their results are verified. This is the distinction between an agent factory and a governed Digital Labor infrastructure.

Conclusion: The Factory Must Be Governed, Too

AI agents are becoming easier to build, connect, and operate. Research into reusable subagents also points toward systems that can accumulate and refine capabilities over time. These developments create opportunities for organizations to expand digital work and reduce repetitive effort.

However, the ability to create more agents also introduces a new governance challenge. Every new agent raises questions about its purpose, quality, access, dependencies, authority, and accountability. When agents can create other agents, these questions extend across the entire creation and execution process.

Enterprises therefore need more than just agent generation. They require a method to define requirements, evaluate capabilities, assign permissions, control execution, preserve evidence, and manage changes throughout the agent lifecycle. For AexoreX Systems, this constitutes the central design challenge behind a proposed Digital Labor Factory for AEOS QUANTUM.

The future of enterprise AI should not be measured solely by how much intelligence a system can create. It should also be measured by how responsibly that intelligence can be used. The goal is not unlimited autonomy, but useful autonomy within clear, testable, and enforceable boundaries.

This article presents research-based analysis and a proposed architectural direction. It does not claim that AexoreX Systems or AEOS QUANTUM has already implemented the described Digital Labor Factory capabilities.