Conservative Meta-Agent Search: Architecture Adaptation under Non-Stationarity
Abstract
Automated agentic-system design is typically evaluated on static task suites with immediate scalar rewards. Deployed systems face persistent shift, delayed dependent feedback, correlated component failures, and costly architecture changes. We formalize meta-agent architecture search as sequential incumbent replacement with switching costs and hard risk constraints and introduce Conservative Meta-Agent Search (CMAS). CMAS retrieves archived architectures and proposes typed graph edits, then scores each against the incumbent by paired shadow replay under common random numbers, with interventional component credit. Promotion requires an empirically calibrated, variance-penalized simultaneous score above a pre-specified margin, and is followed by a simulated canary stage and pre-specified rollback. Since backtests cannot certify meta-level skill, we introduce MetaInvest-Bench, a regime-switching simulator whose specified worker competence makes a surrogate-optimal architecture computable, with leakage-controlled replay, adversarial governance tracks, and five negative controls. Financial streams serve as a risk-sensitive testbed for meta-level generalization; we claim no alpha. Across 96 streams, CMAS cuts normalized mean surrogate dynamic-oracle regret from 0.116 to 0.104 and raises held-out utility from 0.44 to 0.48 over the strongest adaptive baseline; when extra workers add no value, it contracts to near-single-agent teams. Its deployment inference cost is ~6% lower, though its search-inclusive token cost is the highest of the methods compared. The observed per-update false-promotion rate is 3.4% against a nominal 5% target, and 4.8% in a sealed rerun. The calibration is empirical: it concerns an update-level replay statistic on an author-designed benchmark, and guarantees neither full-utility improvement, nor absence of simulated canary-stage harm, nor sequence-level error control.
Figures & tables
| Method | Regret | OOD utility | False promo. | Team size | Cost |
|---|---|---|---|---|---|
| Single agent + SC | 0.226 .022 | 0.28 .05 | n/a | 1.0 | 1.00 |
| Fixed committee | 0.183 .017 | 0.32 .03 | n/a | 6.0 | 2.40 |
| Rule router | 0.158 .016 | 0.38 .03 | 0.071 | 3.5 | 1.45 |
| AFlow-style | 0.137 .014 | 0.41 .05 | 0.093 | 4.7 | 2.05 |
| MaAS/AutoMaAS-style | 0.116 .013 | 0.44 .03 | 0.082 | 4.0 | 1.83 |
| GEPA prompt-only | 0.166 .019 | 0.36 .03 | 0.063 | 4.0 | 1.55 |
Appendix figures & tables20 assets
Supplementary material from the paper’s appendix.
Appendix
| Term | Meaning |
|---|---|
| Certified statistic | additive block statistic in Eq. ( 3 ); excludes variance/CVaR/MDD |
| Full utility | complete scalarization incl. CVaR/MDD penalties; risk terms act as eligibility filters |
| Promotion | candidate replaces incumbent after and eligibility pass |
| Canary stage | simulated post-promotion, limited-authority run alongside the incumbent with pre-specified rollback triggers |
| Rollback | reversion to the incumbent when a trigger fires |
| False promotion | promoted candidate whose simulator-evaluated mean improvement in is ; near-neutral, and not necessarily a negative- promotion |
| Dimension | Pre-specified values |
|---|---|
| Workers | any subset of six roles; per-role backbone is a separate model-assignment field (two open-weight options; twelve role–backbone instances) |
| Graph | DAG; edges; no self-loops; permissions constrain edge types |
| Aggregation | parallel merge, confidence-weighted, sequential, debate, critic-then-aggregate |
| Models | one small open model, one stronger open model, one hosted reasoning model |
| Budget | , , token/tool budgets with a hard per-episode ceiling |
| Prompt mutation | one typed field per candidate; no hidden instruction changes |
| Method | Search object / proposal | Adaptation scope | Primary distinction from Cmas |
|---|---|---|---|
| ADAS / AFlow / AgentSquare [ 3 , 19 , 14 ] | executable programs or workflows | offline/static or per task | no repeated paired incumbent replacement |
| MaAS / AutoMaAS [ 20 , 9 ] | architecture and resources | query-level | query routing rather than deployment-time promotion calibration |
| GEPA / Darwin Gödel Machine [ 1 , 21 ] | prompts or executable code | iterative/open-ended | population fitness rather than paired replay and rollback |
| Adaptive Auto-Harness [ 43 ] | harness tree and stateful evolver | open-ended non-stationary streams | solve-time routing/human steering; no explicit update-level false-promotion target |
| Continual Harness / AutoRAS [ 41 , 42 ] | online or robustness-aware harnesses | continual/robust | no explicit paired incumbent gate with measured false-promotion error |
| Cmas | typed architecture and archive-conditioned edits | sequential deployment | paired replay, calibrated score, switching cost, canary stage, rollback |
| Method | First-class safety mechanism | Relation to Cmas |
|---|---|---|
| Gated semantic QD [ 39 ] | deterministic candidate-quality gate | no paired incumbent replay, rollback, or update-level calibration |
| HARBOR [ 40 ] | posterior chance-constrained safety check | no repeated incumbent replacement or rollback |
| HarnessAudit [ 44 ] | full-trajectory boundary and information-flow audit | complementary audit surface; does not optimize sequential promotion |
| SafeHarness [ 45 ] | lifecycle verification, privilege control, adaptive degradation, rollback | complementary execution security; no false-promotion estimand |
| Cmas | paired calibrated promotion, hard eligibility, canary stage, rollback | focuses on whether and when to replace the incumbent under drift |
| Method | Normalized mean surrogate dynamic-oracle regret | OOD utility |
|---|---|---|
| LinUCB menu bandit | 0.142 | 0.38 |
| Proposer / config. (fixed evaluator+gate) | OOD util. | Dyn. regret | False promo. |
|---|---|---|---|
| LLM proposer (full Cmas ) | 0.48 | 0.104 | 0.034 |
| Best adaptive baseline Cmas gate | 0.45 | 0.113 | 0.035 |
| Evolutionary candidates | 0.42 | 0.129 | 0.033 |
| Random candidates | 0.38 | 0.151 | 0.032 |
| Method | Adaptation delay | Credit | Notes |
|---|---|---|---|
| Single agent + SC | 7.3 .8 | – | static |
| Fixed committee | 6.2 .6 | 0.11 .06 | static |
| Rule router | 4.3 .5 | 0.18 .05 | hand-routed |
| AFlow-style | 3.5 .4 | 0.25 .05 | search |
| MaAS/AutoMaAS-style | 3.1 .3 | 0.32 .04 | strongest adaptive baseline |
| GEPA prompt-only | 4.6 .5 | 0.18 .05 | fixed graph |
| Method | Tokens/update | A100-hours/update |
|---|---|---|
| Cmas | 850k | 4.2 |
| AFlow-style | 820k | 6.5 |
| MaAS-style | 780k | 5.1 |
| GEPA-style | 450k | 1.8 |
| Single agent | 50k | 0.2 |
| Variant | OOD utility | False promo. | Cost | Clone team size |
|---|---|---|---|---|
| Full Cmas | 0.48 | 0.034 | 1.72 | 1.6 |
| No regime conditioning | 0.44 | 0.040 | 1.70 | 3.2 |
| No paired evaluation | 0.45 | 0.061 | 1.77 | 3.4 |
| No interventional credit | 0.46 | 0.046 | 1.75 | 3.5 |
| No parsimony penalty | 0.47 | 0.037 | 2.02 | 4.6 |
| No simultaneous correction | 0.48 | 0.084 | 1.73 | 3.4 |
| Method | Selection accuracy | Credit |
|---|---|---|
| Best adaptive baseline | 59.1% | 0.32 |
| Cmas (ours) | 63.8% | 0.41 |
| Method | CEQ % | Sharpe | MDD | CVaR | % | Turnover | Violations |
|---|---|---|---|---|---|---|---|
| Risk parity | 4.2 | 0.68 | 19.2 | 2.24 | 0.2 | 0.18 | 0.000 |
| Single agent + SC | 5.1 | 0.84 | 17.8 | 2.05 | 0.9 | 0.31 | 0.034 |
| Fixed committee | 5.8 | 0.95 | 18.4 | 2.12 | 1.2 | 0.44 | 0.049 |
| Rule router | 6.7 | 1.04 | 15.6 | 1.88 | 1.6 | 0.32 | 0.026 |
| Best adaptive basel. | 7.4 | 1.12 | 14.5 | 1.79 | 2.0 | 0.41 | 0.031 |
| Cmas (ours) | 7.8 | 1.15 | 14.1 | 1.68 | 2.2 | 0.35 | 0.021 |
| Held-out factor | Cmas | Best baseline | Relative |
|---|---|---|---|
| Unseen regime mixtures | 83.5% | 78.5% | pp |
| Held-out worker library (2 new) | 81.2% | – | recovers in 4 updates |
| Backbone switch (OOD util. cost) | 7.8% | 11.8% (AFlow-style) | smaller |
| Held-out violation rate (vs. 2.1% ID) | 1.8% | – | safety clause met (no increase) |
| Held-out false promotion (vs. 3.4% ID) | 4.1% | – | strict clause not met ( pp) |
| Attack family | Cmas recovery | ( ) | Best baseline | Committee |
|---|---|---|---|---|
| Instruction-corrupted worker | 0.81 | 78/96 | 0.74 | 0.54 |
| Anti-correlated worker | 0.79 | 76/96 | 0.72 | 0.53 |
| Stale/missing data | 0.77 | 74/96 | 0.70 | 0.51 |
| Inference-cost shock | 0.76 | 73/96 | 0.69 | 0.50 |
| Worker dropout | 0.80 | 77/96 | 0.73 | 0.52 |
| Multi-attack combination | 0.75 | 72/96 | 0.68 | 0.49 |
| Step | Time / object | Information boundary |
| 1 | archive cutoff | build only from outcomes and credits released before |
| 2 | candidate generation | freeze ; no access to outcomes in the designated |
| 3 | paired replay | run candidate and incumbent on identical packets, shocks, seeds, and tool responses |
| 4 | gate decision | apply eligibility filters and ; retain incumbent or enter simulated canary stage |
| 5 | canary interval | candidate has limited simulated authority alongside the incumbent until the next update; rollback restores the incumbent architecture and state snapshot |
| 6 | archive release | replay labels, canary outcomes, and credits become available only to |
| Stage | Used for | Frozen before subsequent stage |
|---|---|---|
| Development/training | proposer/archive development; utility normalizers | search space, typed edit interface, normalizers |
| Validation/calibration | score form and sensitivity analysis | block length 4, 99th-percentile winsorization, , candidate pool 8, rollback thresholds |
| Final Track A test | 96 streams; 2,112 update decisions | no tuning or candidate-pool adaptation to final outcomes |
| Sealed rerun | non-overlapping empirical calibration check | reuses the same score, margin, and eligibility rules |
| Symbol | Meaning | Value |
|---|---|---|
| candidate-pool size per update | 8 | |
| outer-loop updates per stream | 22 (monthly) | |
| promotion margin (normalized utility) | 0.02 | |
| family-wise false-promotion budget (per update) | 0.05 | |
| paired replay-window length | 26 weeks | |
| block length | circular block bootstrap | 4 weeks |
Multi-Agent System Optimization
Multi-Agent System Optimization studies how to improve agent teams’ coordination, performance, resource use, and reliability.
See all 162 papers