Every context-optimization method — GEPA, Dynamic Cheatsheet, ACE — is a hand-built machine with its biases welded in. This paper stops hand-building the machine. A meta-agent evolves the method as an executable skill, a base agent runs it to grow context as files and code, and the pair beats every fixed harness on all five domains it touches.
You just shipped the best context-optimization system of 2025. It is ACE — Agentic Context Engineering — and it works like a small newsroom: a Generator attempts tasks, a Reflector reads the transcripts and extracts lessons, a Curator merges those lessons into a growing playbook that gets pasted into every future prompt. On FiNER, a brutal financial entity-tagging benchmark, it lifts your model from 58.0% to 71.0%. You are feeling good.
Then you point the same system at Symptom2Disease — a medical benchmark where a patient describes symptoms in plain language and the model names one of 22 diseases — and something embarrassing happens. Plain in-context learning, the dumbest possible baseline, just pasting raw training examples into the prompt, scores 84.4%. Your sophisticated reflection pipeline scores 79.2%. Run ACE online, adapting as test samples stream past, and it scores 62.3% — which is 1.4 points below the base model doing nothing at all. The machinery you built to accumulate insight is actively subtracting it.
Nothing is broken. ACE is running exactly as designed. The problem is the design itself — and this chapter is about learning to see that problem as a structural fact about every context-engineering method ever hand-built, not as a bug in one of them.
Symptom2Disease has an unusual property: its training and test instances are semantically near-identical. A patient describing strep throat in the test set sounds almost exactly like a patient describing strep throat in the training set. The single most useful context you can hand the model is the raw examples themselves — verbatim, uncompressed, unreflected-upon. ACE's whole pipeline is built on the opposite premise: that raw experience should be processed — reflected on, abstracted into lessons, curated into bullets. On this task, every processing step moves the context further from the thing that actually helps. The reflection machinery does not merely fail to add value; it adds noise, one distilled lesson at a time, in place of the verbatim examples that would have scored ten points higher.
Now flip the benchmark. On FiNER, raw examples are nearly useless — there are 139 entity types with long-tail disambiguation rules, and no small set of verbatim examples covers them. What wins there is exactly what ACE does: repeated reflection that accumulates rules and edge cases into a dense playbook. Same method, opposite verdict. The method did not change. The task structure changed, and the method's built-in assumptions stopped matching it.
Here is the reframe this paper makes, and it is worth sitting with because the rest of the lesson builds on it. Think of every possible way of representing and optimizing context as a point in a vast design space. One axis: how verbose the learned context is, from a one-line rule to an 86K-token knowledge base. Another axis: how the optimization proceeds — full rewrites versus incremental appends, instance-at-a-time versus batch-level, rigid schema versus free-form files. GEPA occupies one point in this space. Dynamic Cheatsheet occupies another. ACE occupies a third. Each was placed there by human intuition and stays there forever.
Each fixed method is a frozen point: click one to see the bet it makes and the benchmark where that bet loses. MCE is not a point — it is the orange search trail, free to settle anywhere the task rewards.
The question Meta Context Engineering (MCE) asks is almost impolite in its simplicity: why is a human choosing the point? We stopped hand-designing features when learned features beat them. We stopped hand-designing neural architectures when searched architectures matched them. Context engineering in early 2026 is where those fields were before their meta-move: a collection of hand-crafted heuristics, each excellent inside its home domain and blind outside it. MCE performs the same meta-move on context engineering itself — it makes the method the thing that gets learned.
Concretely, MCE runs two agents in a loop. A meta-level agent maintains and evolves a skill — an executable folder of instructions and code that specifies how to represent and optimize context for this task. A base-level agent executes the current skill: it reads training rollouts, learns from the failures, and writes the actual context — not into a fixed schema, but as arbitrary files and Python code in a workspace. The meta-agent watches which skills produced contexts that generalized, reasons over the full history of past skills and their scores, and composes better skills. Skills and contexts co-evolve.
One promise to hold this lesson to: by Chapter 10 you will read an actual skill that MCE evolved for FiNER — an eight-phase error-analysis methodology with anti-patterns and reasoning chains, discovered without a human writing any of it — and you will be able to explain not just what it does but why the evolution process converged on it, down to the specific overfitting signal (a 4.5% train/validation gap) that triggered its key design shift.
Before you can search a design space, you have to write down what its points are. Chapter 0 waved at "ways of representing and optimizing context." This chapter pins that down with the paper's central formal object — the context function — and it is worth building slowly, because once you see it, every context-engineering system you have ever met becomes a special case of one equation.
A query arrives — call it x. Maybe it is a sentence from a financial filing that needs an entity tag; maybe it is a patient's symptom description. Before the LLM sees x, something assembles the text that will surround it: a system prompt, maybe some retrieved reference material, maybe a few examples, maybe a checklist of rules. That assembled surrounding text is the context. The thing that assembles it — whatever pipeline of lookups, filters, and formatters runs between "query arrives" and "prompt is ready" — is a function. It eats a query and returns a context. The paper names it c, so the context for query x is c(x).
The paper then splits every context function into two kinds of ingredient, and this split is the load-bearing distinction of the whole formalism:
| Ingredient | Symbol | What it is | Everyday analogy |
|---|---|---|---|
| Static components | ρ (rho) — a set ρ₁ … ρm | The stored material: system prompts, knowledge bases, rule lists, example collections, code libraries. It exists before any query arrives and does not depend on the query. | The books on a consultant's shelf. |
| Dynamic operators | F — a chain F₁ … Fk | The query-conditioned transformations: retrieve, select, filter, format, compose. Each takes what the previous step produced, looks at the query, and reshapes the material. | What the consultant does when your question arrives: pull two books, skip to the relevant chapters, summarize them for you. |
Written out, the context function is the operator chain applied to the static material, conditioned on the query:
Read the little circle ∘ as "then": apply F₁ first, feed its output to F₂, and so on through Fk. Every symbol now has a home: x is the incoming query, ρ is the shelf of stored material, each F is one step of the assembly line, and c(x) is the finished context that lands in the prompt next to x.
The power of the formalism is how much it unifies. Walk through the familiar systems:
| System | ρ (static) | F (dynamic) | So c(x) is… |
|---|---|---|---|
| A fixed system prompt | One block of text ρ₀ | Identity — do nothing | The constant function: same context for every query |
| Few-shot prompting | A pile of examples | Identity (paste them all) | Constant again — just a bigger constant |
| RAG | A document store | One operator: retrieve top-k by similarity to x | Genuinely query-dependent: different documents per query |
| ACE's playbook | The bullet playbook | Identity at inference (paste the whole playbook); the learning loop edits ρ between queries | Constant at any moment, but ρ drifts over time |
| A full agentic pipeline | Knowledge bases + code | Chained: detect query type → retrieve → filter by rules → compose sections | A little program that runs per query |
Two things jump out of that table. First, the design space is enormous — any set of files crossed with any executable pipeline is a valid (ρ, F) pair. Second, the systems people actually build cluster in tiny corners of it: mostly constant functions and single-retrieval functions, because those are the shapes a human can design and debug by hand.
A FiNER-style query is waiting on the left. Toggle operators to change the pipeline and watch what context gets assembled from the static components ρ. Notice the assembled context — and its token cost — change shape with every toggle.
A search needs a score. The paper scores a whole context function — not one context — by how well the frozen model performs when using it. Let fθ be the LLM with frozen weights θ; on query x it produces the answer ŷ = fθ(x, c(x)) — "the model's output given the query and whatever context c assembled for it." The objective J(c) is task performance averaged over data:
In words, symbol by symbol: ℓ is a loss — how wrong the model's answer ŷi was compared to the true answer yi (the minus sign flips "low loss" into "high score"). R is a reward when there is no labeled answer, only an environment signal — did the code run, did the task complete. Either way, J asks one question: if the model consults this particular context function on every query, how well does it do? The goal of all context engineering, compressed to four characters of math, is c* = argmax J(c): find the context function with the best score.
Now the punchline the formalism was built for. Prior methods do optimize c — but each one first freezes the shape of (ρ, F) and only optimizes inside that frozen shape. GEPA freezes the shape to "one short prompt, rewritten wholesale" and searches over rewrites. Dynamic Cheatsheet and ACE freeze it to "a flat list of items, appended and lightly edited" and search over items. Nobody searches over the shape itself: whether context should be one file or ten, whether retrieval should be keyword or embedding or none, whether updates should be per-instance or batch-level, whether the pipeline should include a validation script. Those choices — the ones that decided the Symptom2Disease disaster in Chapter 0 — are made by human intuition, once, forever.
MCE's move, formally stated: introduce a second learnable object, the skill s, which is an executable specification of how to build and improve a context function. Given a skill, a base-level agent executes it against training data and produces a context function cs = (ρs, Fs) — the subscript s recording that this context function is whatever that skill's procedure produced. Search over skills, and you are searching over the shape of context engineering, not just its contents. That two-level search is the next chapter.
Chapter 1 ended with two learnable objects on the table: the context function c (what gets learned) and the skill s (how it gets learned). This chapter is about the exact relationship between them — a nested, two-level optimization — and about the one subtle choice inside it that keeps the whole system honest: which dataset scores which level.
Suppose you only optimize c directly, the way every prior method does. You pick a procedure — say ACE's reflect-and-curate loop — run it on training data, and out comes a context. The procedure itself is fixed, so if its built-in assumptions mismatch the task, no amount of running it harder helps. You saw this in Chapter 0: ACE on Symptom2Disease does not need more epochs; it needs to be a different procedure. One-level optimization can polish the contents of a bad shape, but it can never change the shape.
MCE's formulation splits the search into an inner problem and an outer problem:
Unpack it from the inside out, because that is the order it runs in. The inner problem (right side): given one particular skill s — one particular methodology for building context — find the best context function that methodology can produce, where "best" is scored on the training data, Jtrain. This is the base agent's job: execute the skill, learn from training rollouts, write the context. The outer problem (left side): across all possible skills in the space S, find the skill whose best-resulting context scores highest on the validation data, Jval — data the inner loop never optimized against. This is the meta-agent's job.
The analogy the paper itself draws is the deepest way to remember this. In ordinary machine learning we long ago separated learned parameters (weights, found by gradient descent on training data) from architecture and training algorithm (found by humans, or by meta-learning / AutoML / neural architecture search, judged on validation data). MCE lifts that exact decoupling one level of abstraction higher — to a regime where the ML model itself is already trained and frozen, and the "parameters" being learned are text and code:
| Classical ML | MCE | |
|---|---|---|
| Inner loop learns… | Weights, via gradient descent | The context function (files + code), via an agent executing a skill |
| Outer loop searches… | Architectures / hyperparameters | Skills — executable CE methodologies |
| Inner scored on… | Training loss | Jtrain: performance of the context on training rollouts |
| Outer scored on… | Validation metric | Jval: performance of the finished context on held-out data |
| The frozen substrate | — (weights are the thing being learned) | The LLM's weights θ — never touched |
Watch one full MCE iteration circulate: the meta-agent (outer ring) issues a skill; the base agent (inner ring) executes it against training rollouts and emits a context; the context is scored on validation data, and only that validation score flows back to the meta-agent.
The train/val split across the two levels is not bookkeeping; it is the mechanism that stops the meta-agent from evolving skills that cheat. Work through a concrete miniature. Suppose after three iterations the skill database holds three skills, each already executed by the base agent, each with two scores:
| Skill | Its methodology, in one line | Jtrain | Jval | Gap |
|---|---|---|---|---|
| s₁ | "Write one general rule per error category" | 78.0 | 72.0 | 6.0 |
| s₂ | "Memorize a pattern for every training mistake" | 95.5 | 68.0 | 27.5 |
| s₃ | "Extract rules, then prune any rule that only fires on one example" | 81.0 | 74.5 | 6.5 |
Do the arithmetic a selector would do. If the outer loop selected on Jtrain, it would crown s₂ at 95.5 — the skill that literally memorizes the training set. Its 27.5-point collapse from train to validation (95.5 − 68.0) is the signature of overfitting: patterns keyed to specific training sentences, worthless on new ones. Selecting on Jval instead crowns s₃ at 74.5 — a skill that scores 14.5 points lower on training data than s₂ but 6.5 points higher where it counts. The validation set acts as the exam neither loop studied for; it is the only score that measures what we actually want, which is generalization.
Separating the two levels gives each loop a cleaner job than either could do alone. The base agent never has to wonder whether its methodology is right — it just executes the current skill as well as possible against training feedback. The meta-agent never touches individual training examples — it reasons over (skill, resulting context, train score, val score) records, a far smaller and more informative space. And because the interface between them is a folder of instructions and code, either level can be swapped independently: a better meta-search strategy, a more capable base agent, without rewriting the other side.
One honest caveat the formalism makes visible: the inner problem is itself only approximately solved. The base agent is an LLM agent, not an exact optimizer — c*s is "the best context this agent managed under this skill," not a mathematical optimum. The outer loop inherits that noise: a good skill can post a mediocre score because the base agent had a bad run. MCE's answer, coming in Chapter 6, is elitist selection — keep the best-so-far context ever found, so a noisy iteration can waste time but never destroy progress.
The outer loop searches over "skills." That word has to carry a lot of weight, so this chapter makes it fully concrete: what is physically inside a skill, why this particular representation — and not prompts, not functions, not whole programs — is the right unit for evolution to act on.
In MCE, a skill is literally a directory in the base agent's workspace, anchored by a SKILL.md file. The idea is lifted from Anthropic's agent skills convention — organized folders of instructions, scripts, and resources that an agent discovers and loads when relevant — but here the folder is not written by a human. It is written, and rewritten, by the meta-agent. Analyzing the skills MCE actually evolved, the paper finds they converge on five kinds of content:
Expand each part. Everything below is drawn from the actual best skill MCE evolved for FiNER — Chapter 10 walks the full text.
The learning procedure, written as instructions the base agent will follow: a core philosophy ("abstract principles over specific examples"), an eight-phase workflow (load existing context → categorize errors → generalize → synthesize → refine → add reasoning chains → document anti-patterns → write output files), and success criteria. This is the part a prompt could almost express — but the phases reference the scripts and templates below, which a prompt could not contain.
Code the base agent runs during learning: batch error-pattern extraction over rollout logs, LLM-call orchestration (the FiNER skill chains three calls: error analysis → rule generalization → reasoning-chain creation), embedding-based similarity analysis for deduplication. Because a skill can ship code, an evolved methodology can include computation no prompt could perform.
Skeletons for the context files the base agent will produce: decision frameworks (step 1: what type of entity is this?), disambiguation rule formats, gap-driven refinement checklists. Templates encode the shape the learned context should take — the FiNER skill mandates three files: reasoning-chains.md, semantic-principles.md, tag-reference.md.
Functions and checklists that assess context quality before it ships: "does each rule explain why, not just what?", "would this work on a similar but different example not in training?", measured generalization checks. This is the skill auditing its own output — the anti-overfitting immune system that the Chapter 2 validation gap taught the evolution to grow.
The F side of the context function, as code: retrieval functions that select and compose context per query — keyword-based section extraction, embedding similarity matching, rule-based detection of error-prone cases. A skill does not just decide what to store; it can write the program that decides what each query gets shown.
Hold that anatomy against Chapter 1's formalism and the mapping is exact: parts 3 and the knowledge the scripts produce become the static components ρ; part 5 is the operator chain F; parts 1, 2, and 4 are the procedure for learning (ρ, F) from data. A skill is a complete, executable answer to "how should context engineering work for this task" — which is exactly the thing prior methods hard-coded.
LLM-driven evolutionary computation existed before MCE, and knowing what it evolved makes the novelty precise. Prior work evolved solutions (prompts, textual answers, numerical parameters), functions (heuristics in FunSearch-style systems, reward functions), and programs (search algorithms, neural architectures, agent workflows). MCE introduces skills as a new, higher rung on that ladder, and the paper argues the rung matters for three reasons:
| Advantage | What it means mechanically | What breaks without it |
|---|---|---|
| Unified co-evolution | Instructions, code, templates, and validators live in one folder and evolve together — a methodology change can bring its matching script and validator in the same mutation. | Fragmented frameworks that evolve prompts and code separately drift out of sync: the new instruction references a function that was never updated. |
| Modular interface | The skill plugs into a generic agent harness (read folder, follow it). The agent architecture never changes; only the folder does. | Evolving the agent itself — its loop, its tools — destabilizes everything at once; nothing stays fixed enough to compare across iterations. |
| Agentic genetic operators | A folder can be inspected: the meta-agent can grep ancestor skills, read their phase 3 but not their phase 6, and splice components selectively. | Opaque units (a single long prompt, a compiled program) force all-or-nothing recombination — crossover degenerates to "pick one parent." |
The paper is explicit that MCE's instantiation bets on two 2025–2026 shifts in how agents are built, and both matter for why this works now and did not work in 2023. First, agent architectures moved from rigid multi-agent scaffolds — a hand-wired Generator here, a Reflector there — toward unified, self-looping frameworks with maximal agency and a minimal general tool set, where domain specificity is injected through loadable skills rather than architectural surgery. MCE's meta-level design is exactly that: one general agent, no scaffolding, task specificity carried entirely by the evolving skill folder. Second, coding toolkits and file-system access became the standard harness for serious agents, because a Turing-complete language offers maximal design flexibility and code is inherently verifiable — you can run it and see. MCE's base-level design space — context as files and code, next chapter after next — is that trend taken to its logical end.
One more consequence worth naming: skills inherit progressive disclosure for free. An agent loads a skill's details into context only when relevant — the SKILL.md summary first, scripts only when invoked. That means a library of evolved skills for many domains can coexist without each one paying the context cost of the others, which is the seed of the cross-domain future work in Chapter 11.
Evolution needs a variation operator — something that produces new candidates from old ones. Classical genetic algorithms use fixed rules: cut two parent strings at a random point, swap the halves. MCE replaces the fixed rule with a reasoning agent, and this chapter works out exactly what that agent sees, what it does, and why "crossover performed by deliberation" behaves differently from crossover performed by chance.
At iteration k, the meta-agent's raw material is the skill database — a folder summarizing everything that has happened so far. Formally, Hk−1 = {(si, ci, Jitrain, Jival)} for i = 1 … k−1: every past skill, the context function it produced when the base agent executed it, and both scores. Read the tuple as a full experimental record: method tried, artifact produced, how it did in practice, how it did on the exam. The new skill is produced by one operator:
where τ (tau) is the task specification — the task description, data format, and evaluation criteria, the one piece of human-written input the system gets. And CROSSOVER here is not a formula. It is an agent session: the meta-agent reads τ, browses the history folder with ordinary file tools, and writes a new skill folder.
The contrast with classical operators deserves a table, because it is the paper's second-listed contribution and easy to under-appreciate:
| Classical crossover (e.g. genetic algorithm) | Agentic crossover (MCE) | |
|---|---|---|
| Parents | Exactly two, sampled by fitness | Any subset of all past skills — the whole history is readable |
| Recombination rule | Fixed and content-blind: cut points, swaps | Chosen per iteration by reasoning over content: "phase structure from skill 3, the dedup script from skill 1, drop skill 4's retrieval idea — its val score says it hurt" |
| Uses performance how? | Only to select parents | Reads train and val scores as diagnostic evidence — e.g. spotting a train/val gap and prescribing anti-overfitting machinery in the child |
| Can explain itself? | No | Yes — the child skill's own text records the diagnosis ("the previous iteration captured 29 specific patterns, but the 4.5% gap indicates overfitting…") |
The deepest difference is the third row. A classical operator can only exploit fitness — better parents get picked more often. A deliberative operator can interpret fitness: the pattern of scores across the history is evidence about the task, and the meta-agent reasons over that evidence the way a scientist reasons over experimental results. When the paper's authors analyzed the evolved skills, they found three recurring behaviors that only make sense for an interpreting operator: the skills dynamically adjust autonomy and granularity (some prescribe rigid step-by-step workflows, others delegate broad discretion to the base agent, depending on what the history rewarded); they tailor context verbosity to task and model capacity (concise rules for simple tasks or small generators, detailed explanations otherwise); and the meta-agent monitors train/validation signals to detect overfitting and steers the next skill accordingly.
Six iterations of the outer loop. Bars are validation scores; the staircase is the best-so-far context MCE keeps. Click an iteration to read what the meta-agent tried and what its crossover reasoning took from the history. Iterations 3 and 5 regress — and are discarded by elitist selection, not fed forward.
The paper prints excerpts from the actual evolution, and the shift between the first skill and the winning skill is the clearest window into what deliberative search does. The initial skill — generated from the task specification alone, before any feedback existed — reads like a competent textbook plan: "Phase 2: Analyze Tag Semantics and Distinguishing Features… extract key distinguishing features for each tag category. Focus on: linguistic cues… numeric patterns… contextual dependencies. Phase 3: Extract Decision Rules Per Tag Category…" Systematic, sensible, and biased in a way nobody could see yet: it optimizes for coverage of patterns, with nothing guarding against memorizing them.
Several iterations later, after the 29-pattern context posted its 4.5% train/val gap, the meta-agent's crossover produced a skill whose opening paragraph is a diagnosis: "The previous iteration captured 29 specific patterns, but the 4.5% train/val gap indicates overfitting to training examples. This iteration prioritizes: 1. Abstract principles over specific examples… 2. Semantic reasoning chains — how should the model think about classification, not just what to answer. 3. Cross-example patterns — identify themes across multiple errors rather than isolated mistakes." Notice what happened: the optimization target of the methodology itself changed — from "collect more patterns" to "generalize from errors" — because the search operator could read the scoreboard and understand what it meant. No fixed recombination rule produces that move. Chapter 10 walks the complete winning skill this arc converged to.
Drop down a level. The meta-agent has just written skill sk; now the base agent must execute it and produce an actual context function. This chapter is the Concept + Realization core of the method: what is physically in the base agent's workspace, what data flows through one execution, and what it means — concretely, in bytes on disk — for "context" to be files and code rather than a prompt string.
One base-agent execution is the function call ck = ENGINEER(τ, sk ; c*k−1, Rk). Four inputs, each a directory or file the agent can open:
| Input | What it physically is | Role in the execution |
|---|---|---|
| τ — task specification | A document: task description, data format, evaluation criteria | The unchanging ground rules |
| sk — the current skill | The folder from Chapter 3: SKILL.md + scripts + templates | The methodology to follow this iteration |
| c*k−1 — best context so far | A directory of files and code — last iteration's winner | Warm start: refine the champion, do not start from zero |
| Rk — training rollouts | A log: {(xi, ŷi, evali)} — each training query, what the generator answered using the current best context, and whether it was right | The feedback: where the champion context still fails |
The rollouts deserve a pause, because they are the only place task feedback enters the system. Before the base agent runs, the harness programmatically evaluates c*k−1 on the training set: every query is answered by the generator LLM using the current best context, and every answer is scored. The base agent therefore opens its workspace to a log that says, concretely: "with the context we have, question 141 was answered MaximumBorrowingCapacity, truth was DebtInstrumentFaceAmount, wrong." Hundreds of those lines. Its job, under the skill's methodology, is to turn that error log into a better context.
The agent interacts with its workspace through a standard tool set: {Read, Write, Edit, Bash, Glob, Grep, TodoWrite}. Nothing bespoke — the same seven general tools that power ordinary coding agents (the paper instantiates both agents on the Claude Agent SDK, and notes compatibility with frameworks like LangChain DeepAgents). This is a design position, not laziness: all task specificity lives in the skill, so the harness can stay generic. Contrast ACE, where the division of labor — Generator, Reflector, Curator, each with its own prompt and its own slot in a fixed pipeline — is the architecture. In MCE the architecture is "an agent with file tools," and everything ACE hard-wired becomes content the evolution can rewrite.
What does the output look like? A designated directory. For FiNER, the evolved winner is three markdown files plus retrieval code. In simplified form, the whole artifact:
context/ — what the base agent actually wrote (FiNER, simplified)context/ ├── reasoning-chains.md # step-by-step decision procedures, e.g. "STEP 1: dollar amount, │ # percentage, or non-numeric? STEP 2: if dollar -> facility, debt │ # instrument, or balance? ..." — a walkable flowchart in text ├── semantic-principles.md # generalizable rules + anti-patterns ("Tranche/term loan => a debt │ # instrument's principal, NOT a borrowing capacity") ├── tag-reference.md # condensed per-tag quick reference for all 139 entity types └── retrieval.py # the dynamic operator F: query -> which sections to include
And the dynamic side — the code that turns those static files into a per-query context. First the idea in three lines, then the fuller shape:
retrieval.py — minimal form: the context function c(x) as codedef get_context(query): return load("reasoning-chains.md") + relevant_sections(query) + load("tag-reference.md")
retrieval.py — the same function, real shape: rules + composition logicdef relevant_sections(query): sections = [] if has_dollar_amount(query): # rule-based detection of error-prone cases sections.append(section("semantic-principles.md", "facility-type-resolution")) if mentions_rate_or_percent(query): sections.append(section("semantic-principles.md", "rate-type-rules")) sections += embed_topk(query, all_sections, k=3) # embedding similarity as fallback return dedupe(sections) def get_context(query): # the callable interface the harness requires: return compose( # query -> context, validated after every execution load("reasoning-chains.md"), relevant_sections(query), load("tag-reference.md"))
That get_context(query) signature is a hard contract. To let rollouts and evaluations call the context function programmatically, the harness requires the base agent to implement callable interfaces with predefined input-output signatures, and it validates them after every base-agent execution — an agent that writes broken code fails validation and the iteration scores accordingly. This is the verifiability half of the files-and-code bet: unlike a prompt, code either runs or it does not, and the harness checks.
Press play: rollouts stream in from the left, the agent (following the skill) batches errors, edits the context directory, and the validator stamps the callable interface before anything ships to evaluation.
One operational difference from ACE hides most of the efficiency results coming in Chapter 8, so plant it now. ACE learns instance-at-a-time: one sample → reflect → curate a delta → append; repeat hundreds of times, each step an LLM pipeline invocation seeing one example and no global view. The MCE base agent learns batch-level: it opens the whole rollout log, greps it, groups hundreds of errors by underlying cause (or writes a script to do so in parallel), and then makes a small number of coherent edits to the context with the full picture in view. Same feedback, opposite granularity. Batch-level is why MCE can restructure and prune ("this whole section overfits — rewrite it as one principle") where ACE can only append and locally patch — and it is why MCE will turn out to need 4.8× fewer rollouts and 13.6× less wall-clock time to reach a better context.
You now have both agents. What remains is the loop that runs them — and it is deliberately, almost provocatively simple. The entire orchestration of MCE is a classical (1+1) evolution strategy: one parent, one offspring per generation, keep the better. This chapter walks the algorithm line by line and then examines why so simple a strategy suffices when its variation operator can think.
Meta Context Engineering — the complete outer loop# Require: task spec τ, data D = D_train ∪ D_val, iteration budget K H ← {} # skill database: every (skill, context, train score, val score) c_best ← empty # best context function found so far for k = 1 … K: # — meta level: evolve one new skill — s_k ← CROSSOVER(τ, H) # Ch 4: the meta-agent reads the history, writes a skill folder # — base level: execute the skill into a context — R_k ← ROLLOUT(c_best, D_train) # evaluate the champion on training data -> error log c_k ← ENGINEER(τ, s_k; c_best, R_k) # Ch 5: base agent follows s_k, edits files & code # — evaluation and bookkeeping — J_train ← J(c_k, D_train); J_val ← J(c_k, D_val) H ← H ∪ {(s_k, c_k, J_train, J_val)} # everything is remembered, including failures if J_val(c_k) > J_val(c_best): c_best ← c_k # elitist selection: champion only ever improves return c_best and its skill
Three lines carry all the weight. ROLLOUT before ENGINEER: feedback is always gathered by running the current champion, so the base agent always works on the actual frontier of failure, not on stale errors. H grows unconditionally: a failed skill is not deleted — it becomes evidence. Chapter 4's crossover reads failures as instructively as successes ("skill 4's retrieval idea correlated with a val drop — avoid it"). Elitist selection on Jval: the champion is replaced only by a strictly better validation score, so the best-so-far curve is monotone. A disastrous iteration wastes budget; it cannot destroy progress.
Step through eight iterations. Each offspring's validation score lands as a bar; the champion staircase only moves up. Watch iterations where the offspring loses — the bar falls below the line and the staircase holds flat.
In classical evolutionary computation, a (1+1)-ES is the weakest reasonable strategy: with one parent and blind mutation, it explores a single trajectory and gets stuck in local optima; that is why real systems maintain populations, islands, Pareto fronts. GEPA, for instance, maintains a genetic Pareto frontier of prompts precisely to avoid local optima. So why can MCE get away with the minimal loop?
Because the population lives in the database, not in the parent. A blind (1+1)-ES sees only its current champion; MCE's crossover reads all of H every iteration — every skill ever tried, with both scores. The information a population normally carries (what directions have been explored, what worked, what failed) is carried by the history instead, and exploited by reasoning rather than by sampling. The paper is candid that fancier search — populations of skills, Pareto fronts over accuracy and context length — "may further improve performance"; the (1+1) choice is a simplicity baseline that already wins. There is also a budget reality: one iteration costs a full base-agent execution plus a training-set evaluation, so a population of ten skills per generation would cost ten times the rollouts. The history-informed single track buys population-like memory at single-track price.
One engineering detail the paper flags, easy to miss and load-bearing for trust in the results: read/write permissions of both agents are strictly scoped by role and iteration. The base agent can read its skill, the prior best context, and this iteration's rollouts — it cannot read the validation set, so it cannot tune the context against the exam. The meta-agent can read the skill database with its validation scores — but it never touches raw validation examples either; it sees scores, not answers. The bi-level firewall from Chapter 2 is enforced by file permissions, which is exactly the kind of guarantee a files-and-workspace design makes cheap to provide.
Theory over; scoreboard time. The evaluation is unusually broad for a context-engineering paper — five benchmarks in five genuinely different domains, chosen so that no single inductive bias could win everywhere. Which is, of course, the point: the fixed-harness baselines don't win everywhere, and where each one stumbles tells you exactly which bet it made.
| Benchmark | Domain | The task | Metric |
|---|---|---|---|
| FiNER | Finance | Tag tokens in XBRL financial filings with one of 139 entity types — dense long-tail disambiguation rules | pass@1 accuracy |
| USPTO-50k | Chemistry | Retrosynthesis: given a product molecule, predict the precursor reactants | exact-match accuracy |
| Symptom2Disease | Medicine | Map a patient's plain-language symptom description to one of 22 diseases | pass@1 accuracy |
| LawBench (charge prediction) | Law | Predict the criminal charge from a Chinese legal case description | micro-F1 |
| Aegis2.0 | AI safety | Classify prompts as safe/unsafe and name the violation category — run with a lightweight Qwen3-8B generator, as guardrails demand | F1 |
Setup, for fairness bookkeeping: the generator (the model that actually answers, during training and test) is DeepSeek-V3.1 everywhere except Aegis2.0's Qwen3-8B; every baseline uses the same initial prompts and a training budget no smaller than MCE's; ACE runs its official implementation for 5 offline epochs. MCE's two agents run on MiniMax-M2.1 (a confound Chapter 9 will kill properly). Baselines: plain ICL, MIPROv2 (Bayesian instruction+demo optimization), GEPA (reflective prompt evolution, brevity bias), Dynamic Cheatsheet (additive test-time memory), and ACE (the agentic playbook, prior state of the art).
All five benchmarks, every method, offline and online. F1 scores are shown ×100 to share an axis. Toggle the setting; tap a benchmark column to highlight its story. MCE (orange) is first on all five in both settings.
| Method | FiNER | USPTO50k | Symptom2Disease | LawBench | Aegis2.0 | Avg. rel. gain |
|---|---|---|---|---|---|---|
| Base model | 58.0 | 6.0 | 63.7 | 0.36 | 0.54 | — |
| ICL | 64.0 | 9.0 | 84.4 | 0.57 | 0.59 | 32.1% |
| MIPROv2 | 69.0 | 14.0 | 73.1 | 0.60 | 0.59 | 48.6% |
| GEPA | 66.0 | 15.0 | 70.8 | 0.69 | 0.76 | 61.5% |
| ACE | 71.0 | 18.0 | 79.2 | 0.65 | 0.68 | 70.7% |
| MCE | 75.0 | 20.0 | 89.2 | 0.70 | 0.80 | 89.1% |
The headline is the bottom row: first place on all five. But the more instructive reading is the runner-up churn, underlined above — the second-best method is a different harness on almost every benchmark, and each silver medal is a bias meeting a task that happens to agree with it:
| Benchmark | What the task rewards | Which fixed bias profits | Which fixed bias suffers |
|---|---|---|---|
| FiNER | Deep reflection and pattern abstraction over 139 long-tail rules — imitating examples is not enough | ACE (71.0): its reflect-curate loop accumulates exactly such rules | ICL (64.0) and GEPA (66.0): raw demos can't cover the tail; a concise prompt can't hold 139 rule sets |
| Symptom2Disease | Raw verbatim examples — train and test are semantic near-twins | ICL (84.4): pasting examples is the ideal strategy | ACE (79.2): every reflection step processes away the verbatim signal |
| Aegis2.0 | Concise instructions a small 8B generator can absorb | GEPA (0.76): brevity bias finally pays | ACE (0.68): an 80K-token playbook drowns a lightweight model |
Now the key observation: MCE beats each specialist inside its own specialty. It out-reflects ACE on FiNER (75.0 vs 71.0), out-examples ICL on Symptom2Disease (89.2 vs 84.4 — its evolved skill discovered that raw-example retention was the winning representation and kept it, adding a retrieval layer on top), and out-brevities GEPA on Aegis2.0 (0.80 vs 0.76, with a compact context tuned to the small model). It is not that MCE has a better bias; it is that MCE finds the task's bias instead of bringing its own.
Online, methods process the test stream sequentially and are scored on each instance's first sight — no second chances, no separate training pass. Adaptation machinery must pay its way immediately. It does not always: ACE online on Symptom2Disease scores 62.3, below the 63.7 base model — the Chapter 0 disaster in the wild — and Dynamic Cheatsheet manages 0.53 on Aegis2.0, a hair under base's 0.54. MCE stays first everywhere: FiNER 68.0, USPTO50k 20.0, Symptom2Disease 76.4, LawBench 0.66, Aegis2.0 0.63; average relative gain 74.1% versus ACE's 41.1% and DC's 35.8%. (Remember from Chapter 6: online MCE runs a fixed spec-generated skill — even without iterative evolution, the fully agentic files-and-code base layer alone carries it past every fixed pipeline.)
Two calibration notes so the numbers stay trustworthy in your head. First, "average relative gain" weights benchmarks with tiny bases heavily: USPTO50k's climb from 6.0 to 20.0 is a 233% relative gain that dominates the 89.1% average — which is why Chapter 8 re-derives that average by hand, term by term, so you can see exactly how it is built. Second, the margins over ACE on raw scores are moderate offline (4.0 on FiNER, 2.0 on USPTO50k, 0.05 on LawBench) and large where biases actively backfire (10.0 on Symptom2Disease, 0.12 on Aegis2.0). MCE's superiority is consistency plus the absence of failure modes, not a uniform blowout — and its efficiency edge, coming next, is arguably the more dramatic result.
Accuracy is one column of the ledger. This chapter reads the other four — how long the learned contexts are, how much performance each token buys, how well contexts survive being handed to weaker models, and what the training run costs. These are the results that make MCE interesting as an engineering proposition, and several of the numbers are startling.
Recall the two frozen bets: GEPA's outputs settle at roughly 1–2K tokens no matter the task; ACE's playbooks balloon to ~80K tokens after five epochs (with 200 training instances) no matter the task. MCE's evolved contexts, task by task: its two best FiNER contexts are 1.5K and 20K tokens; LawBench lands at 44K; USPTO-50k at 86K. One method, a 57× spread in context length — because the skill decides length per task, and the evolution tunes the skill. Chemistry genuinely needs a big reaction knowledge base; a small generator on a safety task genuinely needs brevity; MCE writes both.
Every point is a learned context: x = its length in tokens (log scale), y = FiNER accuracy when the generator uses it. The teal trail is ACE's playbook growing across epochs; orange points are MCE's two champions. Up and to the left is better. The shaded bands are the biases: GEPA's brevity zone, ACE's bloat zone.
Walk the FiNER scatter's four labeled points, because they compress the whole argument. At matched ~1.5K-token length, MCE-S scores 73% where ACE (step 20 of epoch 1) scores 65% — eight points from the same budget. At the other end, MCE-L reaches 75% with 20K tokens, while ACE after five full epochs sits at 70% with 79K tokens — more accuracy from a quarter of the context. And ACE's own trajectory is the quiet indictment: epoch 1, 12K tokens, 71%; epoch 2, 23K tokens, 69%; epoch 5, 79K tokens, 70%. The playbook grows six-fold while accuracy goes sideways — additive curation keeps appending, but appending stopped helping after epoch 1.
The paper attributes MCE's per-token quality to two properties you already met in Chapter 5. Global view: the base agent sees the whole context when editing, so it restructures and refines — merge these rules, delete that redundant section — instead of blindly appending. Batch-level feedback: it aggregates hundreds of rollouts before updating, so each edit reflects a population of errors, not the noise of one. Together they produce coherent, non-redundant context; ACE's instance-at-a-time additive loop structurally cannot do either.
Here is a deployment question with real money attached: can you learn a context with an expensive model and serve it with a cheap one? The paper trains contexts with DeepSeek-V3.1 (671B-class) as generator, then hands them unchanged to three smaller models. Scores, with the average relative drop from the DeepSeek version of the same method:
| Generator | Method | FiNER | Symptom2Disease | LawBench | Avg. rel. drop |
|---|---|---|---|---|---|
| Llama3.3-70B | ACE | 71.0 | 68.4 | 0.19 (base 0.24!) | 28.1% |
| MCE | 74.0 | 82.1 | 0.27 | 23.6% | |
| Qwen3-8B | ACE | 63.0 | 72.2 | 0.32 | 23.6% |
| MCE | 71.0 | 80.2 | 0.45 | 17.1% | |
| Gemma3-4B | ACE | 64.0 | 51.4 (base 51.9) | 0.00 | 48.3% |
| MCE | 65.0 | 70.3 | 0.03 | 43.4% |
MCE degrades less at every size — 4–7 points less relative drop — and avoids ACE's ugliest transfer failure: on Llama3.3-70B, ACE's LawBench context drags the model to 0.19, below the 0.24 it scores with no context at all. An 80K-token playbook optimized against DeepSeek's error patterns is, to a 70B model, mostly noise it cannot digest. The paper credits MCE's edge to the same two properties as before, now wearing transfer hats: compact contexts are easier for small models to process, and batch-level, restructured knowledge is less overfit to the training generator's idiosyncrasies. The Gemma3-4B row is the flag-plant: with MCE context, a 4B model gains 172.6% relative over its base — strong-to-weak context transfer as a working, zero-gradient form of knowledge distillation.
Finally the run cost, on FiNER. Five epochs of ACE: 25.8 hours. Five epochs of MCE: 1.9 hours — 25.8 / 1.9 = 13.6× faster. Rollout efficiency: MCE reaches 95% training accuracy at 450 rollouts (counting both training and validation inference); ACE peaks at 94% after 2169 — 2169 / 450 = 4.8× more, for a lower peak. The mechanism is Chapter 5's batch-level superpower cashing out: where ACE spends an LLM-pipeline invocation per instance (generate → reflect → curate, hundreds of times, sequentially), MCE's base agent either reads the error log directly and edits files — no heavy scaffolding at all — or writes a script that parallelizes reflection across the whole batch. Same feedback signal, a fraction of the serial LLM calls.
Chapter 7 promised the 89.1% average would be rebuilt term by term. Relative gain per benchmark is (MCE − base) / base:
Run the same arithmetic on ACE's row (71.0, 18.0, 79.2, 0.65, 0.68) and you get 22.4 + 200.0 + 24.3 + 80.6 + 25.9 = 353.2, mean 70.6% ≈ 70.7% — the paper's number again. Two things you now know that a headline reader does not: the averages check out exactly, and one term (USPTO's 233%) contributes over half the total — the honest summary is "consistently first everywhere, with relative-gain averages amplified by the hardest benchmark's tiny base."
A result this broad invites two suspicious questions. One: MCE has two levels — how much does each actually contribute? Two: MCE's agents run on a different model (MiniMax-M2.1) than the baselines' pipelines — is the win just a smarter model leaking knowledge in? The paper answers both with clean experiments on FiNER, and the answers refine how you should think about the whole method.
Three variants, each removing one ingredient. MCE w/o skills: the base agent gets no methodology at all — just the workspace, the rollouts, and its own judgment. MCE w/ a fixed skill: the meta-agent writes one skill from the task specification before seeing any feedback, and it never evolves. Full MCE: skills evolve across iterations. (Full evolution is structurally inapplicable online — single-pass streaming leaves no room for outer-loop iterations — so the online column compares only the first two.)
| Variant (FiNER) | Offline | Online | What the number isolates |
|---|---|---|---|
| Base model, zero-shot | 58.0 | 58.0 | The floor |
| ACE (best fixed harness) | 71.0 | 64.0 | The prior state of the art |
| MCE w/o skills | 73.0 | 67.0 | Fully agentic base layer alone |
| MCE w/ a fixed skill | 71.0 | 68.0 | Spec-only methodology, no learning signal |
| MCE, evolving skills | 75.0 | — | The full bi-level loop |
Work the ladder bottom-up, because each rung is a finding. Rung one: the skill-less base agent beats ACE — 73.0 vs 71.0 offline, 67.0 vs 64.0 online. Sit with that: an agent with file tools, code, and rollout logs, following no prescribed methodology whatsoever, outperforms the best hand-designed CE pipeline in the literature. The paper's inference: fully agentic context optimization is effective without any manual scaffolding — a large share of MCE's edge comes from tearing the scaffolding out, not from what replaced it. Rung two: a fixed skill is a gamble. At 71.0 offline it underperforms the skill-less agent by two points — a methodology written from the task spec alone, never corrected by feedback, can constrain the agent in wrong directions (across the other benchmarks in Table 1 this variant's rank swings widely; online it happens to edge ahead, 68.0 vs 67.0). A skill helps only when its quality is verified. Rung three: evolution pays. 75.0 vs 73.0 — the outer loop's learn-from-validation cycle adds the final two points, and adds them on top of an already state-of-the-art base.
Now the sharper worry. MCE's meta- and base-agents run MiniMax-M2.1, an agentic model; the baselines' reflector/curator roles run DeepSeek-V3.1. Maybe MCE wins because M2.1 is simply smarter, and its knowledge leaks into the learned context? The falsification test is elegant: give the baseline the same model. Swap ACE's Reflector and Curator to MiniMax-M2.1 and re-run FiNER offline:
| ACE checkpoint | DeepSeek-V3.1 reflector/curator | MiniMax-M2.1 reflector/curator |
|---|---|---|
| Epoch 1 | 12K tokens → 71% | 38K tokens → 69% |
| Epoch 2 | 23K tokens → 69% | 90K tokens → 69% |
| Final | 79K tokens → 70% | 114K tokens → 67% |
The "smarter" model makes ACE worse. M2.1 writes more verbose reflections, so the playbook bloats faster — 38K tokens after one epoch, 114K by the end — and training terminates early (epoch 3, step 73) because the playbook exceeds the context window. Final accuracy drops from 70% to 67%. Three points of loss, from three epochs fewer and 35K tokens more.
Read the logic of the falsification carefully, because it is a pattern worth stealing for your own experiments. If MCE's gains came from M2.1's knowledge, then injecting M2.1 into ACE's pipeline should have helped ACE. It hurt instead — therefore the gain is not the model; it is the methodology that decides what a capable model's output does to the context. Inside ACE's additive harness, M2.1's verbosity becomes bloat. Inside MCE's harness — where the agent restructures with a global view — the same verbosity becomes well-organized files. The harness determines whether capability compounds or clogs.
Assemble the chapter's evidence into one causal story. The base layer's agency (files, code, batch-level global view) contributes the largest share — it alone beats every fixed harness. Skill evolution contributes a reliable additional margin — and, from Chapter 8, most of the efficiency story (the skills learn to avoid wasted work: 450 rollouts vs 2169). Fixed skills without evolution are variance, not value. And model capability is a prerequisite, not an explanation. That decomposition is exactly what you would want to know before building one of these systems: invest first in the agentic base layer, then in the evolution loop, and never assume a stronger model substitutes for either.
Everything so far described the machine. This chapter reads its output. What follows is the best skill MCE evolved for FiNER — the artifact behind the 75.0 in every earlier table — walked phase by phase. Two reasons to go this slowly. First, Feynman's rule: if you cannot re-create it, you do not understand it, and by the end you should be able to write this skill yourself. Second, it is quietly remarkable as pedagogy: an evolutionary loop, optimizing only a validation number, independently rediscovered half a machine-learning curriculum — overfitting, regularization, error analysis, curriculum design — expressed as instructions to an agent.
Context from the run's history (Chapter 4's showcase): the previous iteration's skill had collected 29 specific patterns and posted a 4.5% train/validation gap. The new skill opens with that diagnosis and declares its philosophy — error-driven generalization: analyze prediction errors, extract generalizable principles (not examples), prune overfitted content while building on existing knowledge, and focus on why errors occur at a semantic level. Then it prescribes eight phases. Step through them:
Step through the actual methodology the meta-agent wrote. Each phase shows what the base agent does and the real content from the skill.
Phases 2–4 are where the skill earns its keep, so work one real example end to end — the skill's own. The rollout log shows the generator repeatedly answering MaximumBorrowingCapacity when the truth was DebtInstrumentFaceAmount. A naive fix (the previous skill's habit) memorizes the instance:
BAD — too specific, example-dependent (what caused the 4.5% gap)"Tranche A loan facility of up to $16.0 million" -> DebtInstrumentFaceAmount
Useful only if the test set mentions Tranche A and sixteen million dollars. The evolved skill instead demands the reasoning failure behind the error — its taxonomy names four: superficial pattern matching (seeing "$X facility" and jumping to a capacity tag without deeper analysis), missing semantic distinction (capacity vs current state vs debt instrument), context blindness (ignoring discriminating words like "outstanding principal balance" vs "principal amount"), and category confusion (rate types, debt-value types). This error is superficial pattern matching, and the generalizable rule targets the category, not the instance:
GOOD — the generalizable principle the skill extracts insteadIf the facility is a TRANCHE or TERM LOAN (not revolving), it represents
a specific debt instrument principal, NOT a flexible borrowing capacity.
Key indicators: "Tranche A/B", "term loan", "loan facility" (vs "credit facility")
One rule now covers every tranche and term loan in the test set. Phase 4 then synthesizes across errors: grouping "Tranche A → FaceAmount," "Term loan → FaceAmount," "Revolving credit → Maximum," "Note Purchase Agreement → Maximum" into a single Facility Type Resolution framework — the facility's name tells you its tag category — collapsing what would have been dozens of memorized patterns into one decision rule with three branches.
Phase 6 adds explicit decision chains to the context — "STEP 1: what TYPE of entity is this? [dollar amount / percentage / non-numeric] → STEP 2: if dollar → what CATEGORY of instrument? → STEP 3…" — forcing the generator to walk categories before answering instead of pattern-matching surface strings. The skill's own label for this is "anti-overfitting measure," which is exactly what it is: constraining the hypothesis space to semantic reasoning paths. Phase 7 documents anti-patterns — negative knowledge, what NOT to conclude, each with the wrong answer, the right answer, and the reasoning:
Anti-Pattern 2 — "outstanding" does not mean what it seemsPROBLEM: Seeing "outstanding" and selecting CurrentBorrowingCapacity
without considering what is outstanding.
WRONG: "$60 million outstanding under the Revolving Credit Facility" -> CurrentBorrowingCapacity
RIGHT: "$60 million outstanding under the Revolving Credit Facility" -> DebtInstrumentCarryingAmount
REASONING: "Outstanding under [facility]" refers to the debt instrument's
carrying amount, not the facility's capacity. The phrasing "under the
facility" indicates the debt, not the facility itself.
Notice the quality bar hiding in that block: the anti-pattern encodes a distinction — "outstanding under a facility" is a property of the debt, not the facility — subtle enough that human XBRL taggers get it wrong. The evolution surfaced it because the errors surfaced it.
The skill's Implementation Guidance section is code — the base agent runs a three-call pipeline over the error batch, and this is the part no prompt-shaped method could represent:
The skill's own orchestration — errors in, principles outfrom utils.llm import call_llm errors = [e for e in detailed_results if not e['is_correct']] # CALL 1 — error analysis: group by underlying REASONING FAILURE, not by wrong answer themes = call_llm(f"Analyze these {len(errors)} errors… Group by underlying reasoning failure. For each group, describe the cognitive mistake and propose ONE generalizable rule that would prevent this entire class of errors.") # CALL 2 — generalization: strip a specific pattern down to its principle rule = call_llm(f"Convert this specific pattern into a generalizable rule: {pattern}. What is the underlying principle? Express it without mentioning the example.") # CALL 3 — reasoning chains: build the step-by-step decision procedure chain = call_llm(f"Create a step-by-step reasoning chain for: {decision_point}. 3-5 steps that force explicit thinking about category boundaries.")
Then Phase 8 writes the three-file context you saw in Chapter 5 — reasoning-chains.md, semantic-principles.md, tag-reference.md — and the skill closes with a self-audit checklist ("does this rule explain why, not just what? would it work on an example not in training?") and success criteria whose last line is the whole philosophy in one sentence: validation accuracy improves while training accuracy may slightly decrease (reduced overfitting). The skill is explicitly willing to score worse on data it has seen to score better on data it has not. An evolutionary search, optimizing one number, wrote a bias-variance tradeoff into an instruction file.
Place the method among its neighbors, because the neighborhood is on this site. The survey Gleam Harness Optimization draws the whole ladder — prompts → playbooks → skills → workflows → optimizer code — and MCE is its Chapter 3. One rung down sits ACE (sibling veanor, worth reading as this paper's protagonist-turned-baseline): ACE evolves the content of context inside a fixed harness; MCE evolves the harness. One rung sideways sit ADAS and AFlow, which evolve agent workflows — code that wires LLM calls together — using a meta-agent or MCTS; MCE's distinction is evolving skills, a unit that bundles methodology, code, templates, and validators for a still-more-general agent to execute. And the skills abstraction itself has its own veanor: SkillOS treats skills as a managed operating layer; MCE treats them as a genome. Related in spirit across the field: Reflexion and TextGrad pioneered natural-language feedback as optimization signal; GEPA showed reflective prompt evolution can beat RL; Dynamic Cheatsheet opened test-time memory. MCE is the argument that all of these are points a meta-search should range over.
Three, and they are informative rather than defensive. Reasoning-intensive tasks: MCE shines where the bottleneck is domain knowledge acquisition and pattern organization — its learnable skills capture data characteristics and structure them. Where the bottleneck is multi-step reasoning (math, hard agentic control), existing hand-crafted harnesses built on iterative trials and systematic reflection are already well-matched, and MCE "may not offer advantages." Long, complex trajectories: batch-level agentic analysis struggles with fine-grained credit assignment inside very long rollouts — which action of two hundred caused the failure? The paper notes this is a limit of current agentic models, expected to soften as they improve, but today it bounds the method. The agentic-model prerequisite: from Chapter 9 — the whole design presumes an agent that reliably writes valid files and code. Below that capability bar, there is no base level to speak of.
Skill evolution beyond CE: prior evolutionary systems targeted solutions, heuristics, or programs; skills are a higher-order, integrated abstraction, and evolving them could generalize to other agentic capabilities entirely — MCE is among the first systems to evolve skills rather than merely write them. Co-evolving context use: today's generator does one-shot inference against the assembled context (a deliberate constraint for fair comparison); since the context is files, an agentic generator that browses those files at answer time is the natural next step — evolve the reading skill alongside the writing skill. Composition via progressive disclosure: skills load into context only when relevant, so libraries of evolved skills across domains can coexist cheaply — opening skill transfer and cross-domain composition as concrete research questions.
| Object | Definition | Remember it as |
|---|---|---|
| Context function c(x) = (Fk ∘…∘ F1)(x; ρ) | Static components ρ assembled by query-conditioned operators F into the model's context | The consultant's shelf plus what she does with it per question |
| Objective J(c) | Task performance of frozen fθ when every query is answered with c's context (negative loss, or expected reward) | "How good is the model with this shelf?" |
| Skill s | Executable folder: methodology + scripts + templates + validators + dynamic operators | The genome; the recipe development executes |
| Bi-level problem | Outer: skill maximizing Jval of the inner result. Inner: best context under that skill on Jtrain | Architecture search, one abstraction level above frozen LLMs |
| Agentic crossover sk = CROSSOVER(τ, H) | Meta-agent reads the full skill database and composes a child skill by deliberate recombination | A scientist reading all past lab notebooks, not a coin-flip cut-and-splice |
| Base execution ck = ENGINEER(τ, sk; c*k−1, Rk) | Agent with {Read, Write, Edit, Bash, Glob, Grep, TodoWrite} edits the context directory from batch rollout feedback; callable interface validated | Warm-started, batch-level, verifiable file editing |
| Orchestration | History-informed (1+1)-ES; elitist selection on validation score | One track, monotone champion, population memory lives in H |
| Number | Value | Where derived |
|---|---|---|
| Offline avg. relative gain | MCE 89.1% vs ACE 70.7% (hand-checked) | Ch 8 |
| Online avg. relative gain | MCE 74.1% vs ACE 41.1% | Ch 7 |
| Gain over SOTA per benchmark | 5.6% → 53.8%, mean 16.9% | Ch 8 |
| Context length range | 1.5K → 86K tokens, task-adaptive | Ch 8 |
| Efficiency | 73% @ 1.5K vs ACE 65% @ same; 75% @ 20K vs ACE 70% @ 79K | Ch 8 |
| Training cost | 1.9h vs 25.8h (13.6×); 450 vs 2169 rollouts (4.8×) | Ch 8 |
| Transfer drop (strong→weak) | MCE 17–43% vs ACE 24–48% relative | Ch 8 |
| Ablation ladder (FiNER offline) | base 58.0 → ACE 71.0 → agent-only 73.0 → +evolution 75.0 | Ch 9 |
The Feynman close. If a colleague asks what this paper did, here is the sixty-second version you can now defend line by line: every context-optimization method is a frozen bet about task structure, and the bets visibly fail out-of-domain — ACE under ICL on Symptom2Disease. MCE unfreezes the bet: it formalizes context assembly as a function, splits learning into an inner loop (an agent executes a skill to write context as files and code) and an outer loop (a meta-agent evolves the skill by reading the full history of skills and scores), and selects on validation to force generalization. The result is first place on five domains in both settings, contexts whose length adapts 57-fold to the task, 13.6× cheaper training, better strong-to-weak transfer — and, most tellingly, machine-written methodologies (error taxonomies, anti-patterns, reasoning chains) that read like a good ML practitioner's playbook, because a validation score taught an agent to become one.