AutoMaAS: Self-Evolving LLM Architectures

• AutoMaAS is a framework that automatically designs and continuously adapts multi-agent LLM workflows via query-dependent architecture search and dynamic operator management.
• It achieves 1.0–7.1% performance improvements and 3–5% cost reductions over state-of-the-art methods by leveraging real-time feedback and adaptive cost optimization.
• The system employs operator fusion, elimination, and decision tracing to enhance interpretability and enable effective multi-agent collaboration.

AutoMaAS most explicitly denotes the framework "AutoMaAS: Self-Evolving Multi-Agent Architecture Search for LLMs," a system that automatically designs and continuously adapts LLM-based multi-agent workflows through query-dependent architecture selection, operator evolution, cost-aware optimization, online feedback, and decision tracing (Ma et al., 3 Oct 2025). In arXiv usage, however, the label also appears in a broader family of automation problems: "AutoMaAS-style" mobility-platform simulation, automated workflow orchestration, resilient Kubernetes autoscaling, predictive cloud scaling, Monitoring-as-a-Service, and model-driven cloud deployment (Kucharski et al., 2020, Reda et al., 27 Feb 2026, Soulé et al., 26 May 2025, Lanciano et al., 2021, Tundo et al., 2023, Bhattacharjee et al., 2019).

1. Scope of the term

The most specific referent of the name is the 2025 LLM paper, but adjacent papers use the same label or explicitly map their own systems onto it. This produces a research landscape in which "AutoMaAS" names both a concrete framework and a recurrent automation pattern spanning architecture search, orchestration, monitoring, autoscaling, and platform control (Ma et al., 3 Oct 2025, Soulé et al., 26 May 2025, Tundo et al., 2023, Reda et al., 27 Feb 2026).

Paper	Automated object	Role of "AutoMaAS"
"Auto-Meta" (Kim et al., 2018)	gradient-based meta-learner architecture	automated meta-learning architecture search
"MaaSSim" (Kucharski et al., 2020)	two-sided mobility-platform simulation	foundation for "AutoMaAS-style" research
"Automated Probe Life-Cycle Management for Monitoring-as-a-Service" (Tundo et al., 2023)	probe deployment and undeployment	Monitoring-as-a-Service AutoMaAS framework
"Streamlining Resilient Kubernetes Autoscaling with Multi-Agent Systems via an Automated Online Design Framework" (Soulé et al., 26 May 2025)	resilient HPA Multi-Agent System design	AutoMaAS refers to the same idea as KARMA
"AutoMaAS" (Ma et al., 3 Oct 2025)	LLM multi-agent architecture search	explicit framework name
"Autonoma" (Reda et al., 27 Feb 2026)	end-to-end workflow automation	fits AutoMaAS if understood as automated multi-agent assistance

Chronologically, the literature moves from automated meta-learning architecture search in "Auto-Meta" (Kim et al., 2018), to model-driven and predictive cloud automation (Bhattacharjee et al., 2019, Lanciano et al., 2021), to automated monitoring control planes (Tundo et al., 2023), to automated multi-agent autoscaling and workflow automation (Soulé et al., 26 May 2025, Reda et al., 27 Feb 2026), and finally to an explicit self-evolving architecture-search formulation for LLM agents (Ma et al., 3 Oct 2025). This suggests that the term has converged around automation of structure itself: not only executing a workflow, but selecting, composing, revising, and sometimes generating the components that execute it.

2. AutoMaAS as self-evolving architecture search for LLM multi-agent systems

In its explicit 2025 formulation, AutoMaAS is a framework for automatically designing and continuously adapting multi-agent systems powered by LLMs (Ma et al., 3 Oct 2025). The paper frames the problem as a neural-architecture-search-style problem for LLM agents: given a query $q$ and answer target $a$, the system should not commit to one static workflow for all inputs, but should learn a query-dependent distribution over architectures and evolve that distribution over time.

The framework is built around an agentic supernet $\mathcal{A}=\{\pi,\mathcal{O}\}$, where $\mathcal{O}$ is the operator pool and $\pi$ is the conditional distribution used to assemble a workflow for a given query. The paper argues that prior automated design methods are limited by three properties: a one-size-fits-all search for a single best architecture per dataset or domain, a fixed operator pool that cannot create new capabilities automatically, and a fixed penalty coefficient for cost that does not reflect changing deployment conditions (Ma et al., 3 Oct 2025). AutoMaAS addresses those limitations through four modules identified in the abstract: automatic operator generation, fusion, and elimination based on performance-cost analysis, dynamic cost-aware optimization with real-time parameter adjustment, online feedback integration for continuous architecture refinement, and enhanced interpretability through decision tracing mechanisms.

Operationally, the system receives a query $q$, routes it through a query-dependent controller $Q_\phi$, samples an architecture from the supernet, executes the resulting multi-agent workflow, computes both performance and cost signals, incorporates explicit or implicit feedback, and then updates both the architecture distribution and the operator pool (Ma et al., 3 Oct 2025). The result is not a fixed agent pipeline but a continuously refreshed architecture distribution.

3. Core mechanisms: operator evolution, cost adaptation, feedback, and tracing

The first core mechanism is dynamic operator lifecycle management. Operator quality is formalized through a health score,

$$H(O_i) = \alpha \cdot f_i + \beta \cdot p_i + \gamma \cdot e_i ,$$

where $f_i$ is usage frequency, $p_i$ is performance contribution, and $a$0 is cost efficiency (Ma et al., 3 Oct 2025). When operators frequently co-occur and have sufficiently high correlation, AutoMaAS attempts fusion through

$a$1

with a reported correlation threshold of 0.6. Elimination uses a sliding-window criterion based on average health and redundancy coverage. The paper reports fused examples such as CoT + Self-Refine, Debate + Ensemble, and ReAct + Code-Test (Ma et al., 3 Oct 2025).

The second mechanism is multi-objective dynamic cost optimization. Rather than applying a single static penalty, the framework constructs a dynamic cost tensor

$a$2

whose dimensions include TokenCost, APICost, Latency, FailureRate, and PrivacyRisk. These are weighted by adaptive coefficients,

$a$3

so the effective cost changes with system load, query priority, and deployment conditions (Ma et al., 3 Oct 2025). This makes cost context-sensitive rather than fixed.

The third mechanism is online feedback integration. AutoMaAS aggregates explicit feedback from user ratings, implicit feedback from signals such as session duration or follow-up queries, and system feedback from success and resource utilization. The operator sampling distribution is then updated with an EMA-style rule,

$a$4

with reported hyperparameters $a$5, $a$6, $a$7, and a health window size of 100 queries (Ma et al., 3 Oct 2025). This is the paper’s main sense of self-evolving: architecture search continues after deployment.

The fourth mechanism is decision tracing and interpretability. Explanations are generated via

$a$8

combining a decision trace template, query features, historical performance, and cost analysis (Ma et al., 3 Oct 2025). The paper also defines counterfactual performance and cost comparisons and uses attention visualization to identify which query features influenced operator choice. In this formulation, interpretability is part of the search loop rather than an external audit step.

4. Experimental profile of the explicit AutoMaAS framework

The evaluation covers six benchmarks: GSM8K, MATH, HumanEval, MBPP, MultiArith, and GAIA, with metrics spanning exact-match or Pass@1 accuracy, token consumption, API calls, wall-clock time, total inference cost in USD, cost per query, cross-dataset transfer, and operator-evolution statistics (Ma et al., 3 Oct 2025). The baselines include Single-agent methods such as CoT and Tree-of-Thoughts, Hand-crafted multi-agent methods such as LLM-Debate, AgentVerse, MultiPersona, LLM-Blender, DyLAN, MacNet, and Reflexion, and Automated design methods such as ADAS, AFlow, AgentSquare, AutoAgents, GPTSwarm, and HuggingGPT.

Benchmark	AutoMaAS	Strongest baseline in table
GSM8K	95.4	AFlow 91.2
MATH	57.1	51.3
HumanEval	97.2	90.9
MBPP	88.8	81.7
MultiArith	98.8	96.2
GAIA	20.7	18.0

The headline result is 1.0–7.1% performance improvement together with 3–5% inference cost reductions relative to state-of-the-art methods (Ma et al., 3 Oct 2025). In the main table, AutoMaAS shows an average cost of 58%, compared with 61% for AFlow and 63%–68% for other automated baselines. The paper’s interpretation is that the framework improves quality while allocating fewer resources.

The ablation study attributes substantial value to each module. Removing dynamic lifecycle drops accuracy by 3.1%; removing online feedback drops it by 2.4%; removing multi-objective cost optimization reduces accuracy by 1.8% and raises cost; removing operator fusion reduces accuracy by 1.7%; removing operator elimination reduces it by 1.3%; removing priority adaptation reduces it by 1.2%; and using a fixed operator pool is the worst case, reducing accuracy by 3.6% (Ma et al., 3 Oct 2025). The operator statistics report 12 fused operators, 8 eliminated operators, and 15 modified operators; the strongest fusion, CoT + Self-Refine, improved accuracy by 4.2% and reduced token consumption by 18%.

The transfer results are also explicit. Models trained on GSM8K transfer to MATH with only 1.2% performance degradation, retain 85% of the cost-reduction benefit, and continue to improve performance in cross-LLM evaluation using Claude-3.5-Sonnet and GPT-4 (Ma et al., 3 Oct 2025). The paper additionally reports that simple arithmetic queries often use lightweight single-operator solutions, more difficult reasoning tasks trigger 3–4 operator collaborations, and code tasks benefit from fused operators such as Code-Test-Refine. This supports the paper’s claim that task-dependent resource allocation is a central reason for the joint gains in accuracy and cost.

5. AutoMaAS-style systems in workflow automation, cloud control, monitoring, and autoscaling

Beyond the explicit LLM framework, several papers use closely related ideas to automate orchestration and control at other layers of the stack. These systems differ in object and mechanism, but all move from manually assembled control logic toward declarative or learned composition of specialized components (Reda et al., 27 Feb 2026, Soulé et al., 26 May 2025, Lanciano et al., 2021, Tundo et al., 2023, Bhattacharjee et al., 2019).

System	Automated object	Reported result
Autonoma (Reda et al., 27 Feb 2026)	hierarchical workflow execution	97% task completion; 98% successful handoff
KARMA (Soulé et al., 26 May 2025)	resilient Kubernetes HPA MAS	90.9% success rate; 33.0 s recovery time
OpenStack predictive auto-scaling (Lanciano et al., 2021)	forecast-enhanced scaling	2.02–2.16 ms average response times
Monitoring AutoMaAS (Tundo et al., 2023)	automated probe life-cycle	about 1.5 seconds for three probes on containers
CloudCAMP (Bhattacharjee et al., 2019)	model-driven deployment and migration	15–20 minutes for first-time deployment

Autonoma is a hierarchical multi-agent framework for end-to-end workflow automation from natural language prompts, with a Coordinator, Planner, Supervisor, and specialized worker agents such as Researcher, Coder, Browser, File Manager, Computer, and Reporter (Reda et al., 27 Feb 2026). The system runs in a secure LAN-only environment, accepts text, voice, images, and files, supports English and Arabic, and reports a 97% task completion rate, 98% successful inter-agent task handoffs, 1–2 seconds frontend latency, 100% multilingual switching success without page reloads, and 0 breaches detected in penetration tests. The paper explicitly argues that coordination should be separated from execution.

KARMA, described as Kubernetes Autoscaling with Resilient Multi-Agent system, is the automated HPA MAS design framework that the paper associates with AutoMaAS (Soulé et al., 26 May 2025). Its four phases are digital twin modeling from cluster traces, simulation-based agent training with roles and missions, behavior analysis and explainability, and transfer to the real cluster. The defender side is decomposed into four roles—Bottleneck Manager, DDoS Manager, Failure Manager, and Resource Manager—trained with MAPPO inside a PettingZoo digital twin. The paper reports 90.9% success rate, 85.7% latency compliance, 5.9% pending requests, 33.0 s recovery time, 90.7% service availability, 94.9% digital-twin accuracy with the MLP transition model, convergence in 950 episodes, 1.5 hours training overhead, 96.2% alignment score, and 89.4% clustering purity.

The OpenStack Monasca work formulates predictive auto-scaling as a forecast-enhanced policy loop rather than a fully learned controller (Lanciano et al., 2021). The implementation uses the last 20 minutes of cluster history to forecast the target metric 15 minutes ahead, writes that value back into Monasca as a predictive metric, and applies threshold-based policy: scale out when predicted average CPU usage reaches 80% for 3 consecutive observations, scale in when actual average CPU usage falls to 15% for 3 consecutive observations, with a 20 minutes cooldown and 6 minutes boot delay. Under the reported workload, the static policy yields 43.67 ms average response time, whereas predictive policies obtain 2.02 ms for LR, 2.07 ms for MLP, and 2.16 ms for RNN.

The Monitoring-as-a-Service AutoMaAS framework automates probe deployment and undeployment from declarative monitoring claims (Tundo et al., 2023). Its formal core includes monitoring claims $a$9, monitoring units $\mathcal{A}=\{\pi,\mathcal{O}\}$0, a Probe Catalog, and three stateless controllers: API Service, Monitoring Claim Controller, and Monitoring Unit Controller, with a Cloud Bridge for platform-specific actuation. The stated algorithmic complexities are $\mathcal{A}=\{\pi,\mathcal{O}\}$1, $\mathcal{A}=\{\pi,\mathcal{O}\}$2, and $\mathcal{A}=\{\pi,\mathcal{O}\}$3. In the prototype, deploying three PostgreSQL probes on containers takes about 1.5 seconds, deployment-time recovery from hard errors takes under 1 second, and VM-based deployment of 30 probes takes around 10 minutes.

CloudCAMP is a model-driven, GUI-based self-service framework that transforms partial application specifications into deployable Infrastructure-as-Code through a knowledge-base-backed MDE pipeline (Bhattacharjee et al., 2019). The architecture includes Business User Modeling, Configurator, Enactor, and Knowledge Base, and it uses a WebGME DSML with relationship types such as hostedOn, connectsTo, deleteFrom, and migrateTo. In a user study with 16 teams of 3 students, the median perceived difficulty ratings were 72.2% for manual effort, 71.6% for scripting effort, and 30.9% for CloudCAMP; deployment required 300 lines of code and migration 550 lines of code under the manual/scripted conditions, whereas CloudCAMP is described as reducing the same deployment to about 15–20 minutes for first-time users and migration to 10–15 minutes.

6. Precursors, neighboring domains, and conceptual boundaries

Two earlier lines of work are especially relevant as precursors. Auto-Meta applies progressive neural architecture search to the architecture of a gradient-based meta-learner, using PNAS to search CNN cells and Reptile as the first-order meta-learning algorithm (Kim et al., 2018). The paper formulates the joint optimization problem as

$\mathcal{A}=\{\pi,\mathcal{O}\}$4

and reports 74.65% accuracy on 5-shot 5-way Mini-ImageNet, described as an 11.54% improvement over MAML. Although it is not a multi-agent system, it is explicitly framed as automated meta-learning architecture search, making it a direct antecedent for treating learner structure—not only parameters—as the object of automation.

In urban mobility, MaaSSim is an agent-based simulator for two-sided mobility platforms that the paper explicitly characterizes as relevant to platform-based Mobility-as-a-Service (AutoMaAS-style) systems (Kucharski et al., 2020). Its architecture consists of travellers, drivers, and the platform, implemented as SimPy processes over a microscopic road-network representation. The framework exposes user-pluggable decision functions such as f_trav_out, f_trav_mode, f_driver_out, f_driver_decline, f_driver_repos, and f_match; the default matching rule is closest idle driver. The paper emphasizes that driver participation can evolve endogenously over repeated daily simulations, producing a dynamic equilibrium as drivers opt out when revenues are low and return as fleet size shrinks and incomes rise. The system is therefore not itself an AutoMaAS algorithm, but it is a modular testbed for studying matching, control, competition, learning, and ride pooling under heterogeneous behavior.

Several recurring misconceptions are corrected directly by the source papers. MaaSSim is not itself an AutoMaAS algorithm but a simulator that can host such mechanisms (Kucharski et al., 2020). KARMA is the actual framework name in the resilient Kubernetes paper, and AutoMaAS there refers to the automated design of the HPA Multi-Agent System (Soulé et al., 26 May 2025). Autonoma is a full workflow automation system whose fit to AutoMaAS depends on whether the term is taken to mean an automated multi-agent assistant system (Reda et al., 27 Feb 2026). The Monasca work is not “purely AI-driven” but a forecast-enhanced policy loop (Lanciano et al., 2021). CloudCAMP does not replace tools like Ansible; it generates the artifacts that such tools execute (Bhattacharjee et al., 2019). This suggests that "AutoMaAS" is best understood not as a uniquely standardized acronym, but as a family of research programs centered on automated architecture, orchestration, and lifecycle control across heterogeneous computational systems.