---
title: 'AutoMaAS: Self-Evolving LLM Architectures'
url: https://www.emergentmind.com/topics/automaas
type: topic
---

# AutoMaAS: Self-Evolving LLM Architectures

AutoMaAS most explicitly denotes the framework "AutoMaAS: Self-Evolving Multi-Agent Architecture Search for Large Language Models," 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 [2510.02669]. 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 [2011.12827; 2603.19270; 2505.21559; 2111.02133; 2309.11870; 1904.02184].

## 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 [2510.02669; 2505.21559; 2309.11870; 2603.19270].

| Paper | Automated object | Role of "AutoMaAS" |
|---|---|---|
| "Auto-Meta" [1806.06927] | gradient-based meta-learner architecture | automated meta-learning architecture search |
| "MaaSSim" [2011.12827] | two-sided mobility-platform simulation | foundation for "AutoMaAS-style" research |
| "Automated Probe Life-Cycle Management for Monitoring-as-a-Service" [2309.11870] | probe deployment and undeployment | Monitoring-as-a-Service AutoMaAS framework |
| "Streamlining Resilient Kubernetes Autoscaling with Multi-Agent Systems via an Automated Online Design Framework" [2505.21559] | resilient HPA Multi-Agent System design | AutoMaAS refers to the same idea as KARMA |
| "AutoMaAS" [2510.02669] | LLM multi-agent architecture search | explicit framework name |
| "Autonoma" [2603.19270] | 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" [1806.06927], to model-driven and predictive cloud automation [1904.02184; 2111.02133], to automated monitoring control planes [2309.11870], to automated multi-agent autoscaling and workflow automation [2505.21559; 2603.19270], and finally to an explicit self-evolving architecture-search formulation for LLM agents [2510.02669]. 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 large language models [2510.02669]. 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 [2510.02669]. 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 [2510.02669]. 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 \(e_i\) is cost efficiency [2510.02669]. When operators frequently co-occur and have sufficiently high correlation, AutoMaAS attempts fusion through
$$
O_{fused} = \phi_{LLM}(\mathcal{P}_{fusion} \cup \{O_i, O_j\} \cup \mathcal{H}_{i,j}) ,
$$
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** [2510.02669].

The second mechanism is **multi-objective dynamic cost optimization**. Rather than applying a single static penalty, the framework constructs a dynamic cost tensor
$$
\mathbf{C}(G, q, t) = [c_1, c_2, ..., c_D]^T ,
$$
whose dimensions include **TokenCost**, **APICost**, **Latency**, **FailureRate**, and **PrivacyRisk**. These are weighted by adaptive coefficients,
$$
w_d(t) = w_{d,base} \cdot \exp(\eta_d \cdot \Delta_d(t)) ,
$$
so the effective cost changes with system load, query priority, and deployment conditions [2510.02669]. 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,
$$
\pi_{\ell}^{new}(O) = (1-\mu) \pi_{\ell}^{old}(O) + \mu \cdot \pi_{\ell}^{target}(O) ,
$$
with reported hyperparameters \(\alpha_{fb}=0.01\), \(\mu=0.1\), \(\gamma=0.5\), and a health window size of **100 queries** [2510.02669]. 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
$$
E(G, q) = \phi_{explain}(\mathcal{T}_{decision} \cup \mathcal{F}_{query}(q) \cup \mathcal{H}_{performance}(G) \cup \mathcal{C}_{cost}(G)) ,
$$
combining a decision trace template, query features, historical performance, and cost analysis [2510.02669]. 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 [2510.02669]. 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 [2510.02669]. 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%** [2510.02669]. 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** [2510.02669]. 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 [2603.19270; 2505.21559; 2111.02133; 2309.11870; 1904.02184].

| System | Automated object | Reported result |
|---|---|---|
| Autonoma [2603.19270] | hierarchical workflow execution | 97% task completion; 98% successful handoff |
| KARMA [2505.21559] | resilient Kubernetes HPA MAS | 90.9% success rate; 33.0 s recovery time |
| OpenStack predictive auto-scaling [2111.02133] | forecast-enhanced scaling | 2.02–2.16 ms average response times |
| Monitoring AutoMaAS [2309.11870] | automated probe life-cycle | about 1.5 seconds for three probes on containers |
| CloudCAMP [1904.02184] | 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** [2603.19270]. 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 [2505.21559]. 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 [2111.02133]. 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 [2309.11870]. Its formal core includes monitoring claims \(mc=(I,op,t)\), monitoring units \(mu=(host,mus,C)\), 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 \(O(|I|+|P|)\), \(O(pchanges)\), and \(O(pchanges+errors)\). 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 [1904.02184]. 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 [1806.06927]. The paper formulates the joint optimization problem as
$$
\min_{A,\theta} \sum_{j} \mathcal{L} \big (D_{j}^{Te}, U(D_{j}^{Tr},\theta;A) \big ) ,
$$
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 [2011.12827]. 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 [2011.12827]. **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 [2505.21559]. **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 [2603.19270]. The Monasca work is **not “purely AI-driven”** but a **forecast-enhanced policy loop** [2111.02133]. **CloudCAMP** does **not replace tools like Ansible**; it generates the artifacts that such tools execute [1904.02184]. 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.

Source: https://www.emergentmind.com/topics/automaas