Context Engineering Explained: Inside the Framework That Beat Stanford's ACE by 18 Points

For most of 2024 and 2025, the term everyone reached for was prompt engineering: find the right words, the right examples, the right structure, and the model would do what you needed. That framing quietly broke down once people started building agents that ran for dozens of steps, called tools, and had to remember what worked three tasks ago. In June 2025, Shopify CEO Tobi Lutke posted that he preferred a different term, context engineering, and six days later Andrej Karpathy amplified it to a much wider audience [1]. A month later, on July 28, 2025, Gartner made it official in an analyst note titled "Context Engineering Is In, and Prompt Engineering Is Out," predicting that context engineering features would show up in 80 percent of AI application tooling by 2028 [2].

That kind of industry-wide renaming happens constantly and usually means very little. What makes 2026 different is that two concrete, peer-reviewed papers have now shown context engineering is not just a rebrand, it is a measurable technique with its own state of the art, its own competing methods, and its own benchmark numbers. This post walks through both: Agentic Context Engineering, or ACE, from Stanford, SambaNova, and UC Berkeley, presented at ICLR 2026, and Meta Context Engineering, or MCE, a January 2026 paper that beat ACE by a wide margin using a genuinely different architecture.

Here is a video generation prompt built around the same core idea, a bi-level system where one process crafts tools and another uses them, written for a Wan-style video model:

A two-story pastel-toned workshop cutaway, the upper floor where a small robotic arm assembles a glowing tool from scattered blueprint pieces, a chute carrying the finished tool down to the lower floor where a second robotic arm uses it on a workbench and a small score meter ticks upward, camera slowly orbiting the cutaway to reveal both floors working in sync. Clean scientific motion-graphics style, precise geometric shapes, soft pastel lighting, no readable text, no logos, no people, smooth steady camera movement.

Step 1: What Context Engineering Actually Means

Prompt engineering optimizes a single message: the exact phrasing, the examples, the formatting that gets one call to one model to behave. Context engineering operates one level up. It treats everything an agent has access to when it acts, its instructions, its tool descriptions, its memory of past attempts, its retrieved documents, as a system to be deliberately designed and continuously improved, not just typed once and left alone [3].

The distinction matters most once a system stops being single-turn. A chatbot answering one question can get away with a well-crafted prompt. An agent that has to plan a multi-step task, call a handful of tools, read back what happened, and decide what to do next is a different problem entirely: if it fails on step 40, the fix is rarely a better prompt for step 40, it is better information flowing into the agent at every step leading up to it. That is the production challenge context engineering names directly, and it is why 89 percent of AI teams surveyed in mid-2025 said they planned to invest in context management infrastructure within the following year [4].

Both of the papers below take that idea and make it concrete: instead of a human writing and periodically updating an agent's context by hand, an automated process observes how the agent performs, figures out what context was missing or unhelpful, and updates the context itself, closing a loop that used to require a person watching failures and editing files.

It is worth being precise about scope here too, since "context" gets used loosely. In the sense both papers use it, context covers everything an agent's underlying model actually sees at inference time that is not a fixed part of its weights: the system instructions, descriptions of the tools it can call, any retrieved documents, a running summary of what has happened so far in a multi-step task, and any accumulated notes from prior attempts at similar tasks. A single conversation's chat history is a narrow, temporary slice of that. What ACE and MCE are engineering is the much larger, persistent layer that carries lessons forward across many separate tasks and many separate users, which is the part a single well-crafted prompt has no mechanism to capture at all.

Why Earlier Approaches to Self-Improving Context Fell Short

The idea of an AI system improving its own inputs is not new, and it is worth being specific about why the earlier attempts did not stick before explaining why ACE and MCE did.

Retrieval-augmented generation, or RAG, solved a related but different problem: giving a model access to more information than fits in its training data, by fetching relevant documents at query time. RAG is genuinely useful, but it is not context engineering in the sense this post means, because a RAG pipeline typically does not learn from its own mistakes. It retrieves the same way on attempt one hundred as it did on attempt one, unless a person manually tunes the retrieval logic in between.

Agent memory systems, the class of tools that let an agent write notes to itself and read them back later, got closer. But most early memory systems either stored everything indiscriminately, which caused the same brevity-bias and context-collapse failures described below once someone tried to summarize a growing memory store, or stored nothing without a human curator manually deciding what was worth keeping, which does not scale past a handful of tasks.

A separate research thread, sometimes grouped under automated prompt optimization, tools like DSPy and TextGrad, took a more promising angle: treat the prompt itself as a parameter to optimize against a scoring function, the way a model's weights get optimized against a loss function. That line of work is a direct ancestor of both ACE and MCE. What it typically lacked was a principled answer to the brevity-bias problem: an optimizer that scores prompts purely on end-task performance will happily collapse a rich, detailed prompt into a short, generic one if the short one scores nearly as well on the training set, even though the detail it discarded would have mattered on a slightly different task. ACE's specific contribution was recognizing that the update mechanism itself, incremental and itemized rather than wholesale rewriting, is what prevents that collapse, not just a better scoring function.

Step 2: Inside ACE, the Method MCE Had to Beat

Agentic Context Engineering, published by Qizheng Zhang and Changran Hu as equal contributors alongside researchers from Stanford, SambaNova Systems, and UC Berkeley, frames an agent's context as an evolving playbook rather than a single block of instructions [5]. A playbook accumulates, refines, and organizes strategies over time through three repeating steps: generation, where the agent attempts a task and produces a trace of what it tried; reflection, where the system diagnoses what worked and what did not from that trace; and curation, where the diagnosis becomes a small, targeted update to the playbook.

That curation step is the part that makes ACE different from earlier approaches to self-improving prompts. Prior methods tended to fail in one of two predictable ways. The first is brevity bias, where a system that keeps summarizing its own context to save space quietly throws away the specific, hard-won details that made it work in the first place, converging toward a generic, unhelpful summary. The second is context collapse, where repeatedly rewriting the same block of context from scratch causes detail to erode with every pass, the same way a photocopy of a photocopy degrades [5].

ACE avoids both by applying structured, incremental updates: instead of regenerating the whole playbook, it adds, merges, or prunes individual entries, preserving detail that survives across many rounds rather than getting rewritten away. The result, across a set of agentic and domain-specific benchmarks, was a 9.0 percent improvement in application performance over strong baselines, while simultaneously reducing adaptation latency and rollout cost, since a system operating on small incremental updates does not need to reprocess an entire context from scratch every round [5]. On the AppWorld leaderboard specifically, ACE matched the top-ranked production agent's score while running on a smaller open-source model, and it could do this using only natural execution feedback, meaning signals like whether a tool call succeeded or a test passed, with no human-labeled supervision required [5].

Here is a simplified version of that generate, reflect, curate loop, illustrating the incremental-update mechanism rather than reproducing the paper's actual implementation:

python
/code
# A simplified illustration of ACE's generate -> reflect -> curate loop.
# The real method (Zhang et al., ICLR 2026) evolves a structured "playbook"
# of strategies with incremental, itemized updates instead of rewriting
# the whole context each round, which is what avoids brevity bias and
# context collapse.

playbook = []  # list of small, individually tagged strategy notes

def generate(task, playbook):
    """Run the task using the current playbook and return a trace."""
    used_notes = [note for note in playbook if note["topic"] in task["topics"]]
    success = len(used_notes) >= task["difficulty"]
    return {"task": task, "used_notes": used_notes, "success": success}

def reflect(trace):
    """Diagnose what helped or was missing, without rewriting the playbook."""
    if trace["success"]:
        return None
    missing_topic = trace["task"]["topics"][-1]
    return {"topic": missing_topic, "note": f"handle {missing_topic} explicitly"}

def curate(playbook, new_note):
    """Append or merge a delta instead of erasing prior entries."""
    if new_note and new_note not in playbook:
        playbook.append(new_note)
    return playbook

tasks = [
    {"topics": ["refunds"], "difficulty": 1},
    {"topics": ["refunds", "partial-shipment"], "difficulty": 2},
    {"topics": ["refunds", "partial-shipment", "currency-conversion"], "difficulty": 3},
]

for step, task in enumerate(tasks, start=1):
    trace = generate(task, playbook)
    delta = reflect(trace)
    playbook = curate(playbook, delta)
    print(f"round {step}: success={trace['success']} playbook_size={len(playbook)}")

ACE was accepted as a poster at ICLR 2026 [6], and for the first several months of 2026 it was the strongest published baseline for automated context evolution. That made it the method the next serious attempt would have to beat.

Why AppWorld Was the Right Benchmark to Prove the Point

AppWorld deserves a bit more context than a single leaderboard mention. It is a benchmark built around a simulated world of everyday consumer apps, mail, messaging, banking, ride-hailing, calendars, and an agent has to complete realistic multi-app tasks by calling the appropriate APIs in the right order, handling errors, and confirming the task actually succeeded rather than just producing plausible-looking output. That makes it a meaningfully harder test than a single-turn question-answering benchmark, because success requires the agent to sequence many correct actions in a row, and a single wrong API call partway through can invalidate an otherwise well-reasoned attempt.

Matching the top production-level agent's score on a benchmark like that while running on a smaller open-source model is a specific, checkable claim, not a vague one. It means the gap between a smaller model with well-engineered context and a larger, more expensive model with a static prompt can be closed, at least on this class of task, by the context engineering layer rather than by scaling the underlying model. That is the practical reason ACE mattered before MCE ever existed: it was evidence that context quality can substitute for some amount of raw model scale, which is a much cheaper lever for most teams to pull than switching to a bigger, pricier model.

Step 3: Inside MCE, the Method That Beat It

Meta Context Engineering via Agentic Skill Evolution, published by Haoran Ye, Xuning He, Vincent Arak, Haonan Dong, and Guojie Song and accepted to ICML 2026, takes a different architectural bet [7]. Where ACE evolves the context itself directly, MCE evolves the process that produces context, treating context engineering as a two-tiered problem rather than a one-tiered one.

The two tiers work like this. A meta-level agent analyzes a task specification together with the performance history of past attempts, and from that produces improved skills, reusable procedures made of methodology, executable code, context templates, and dynamic operators, through a process the paper calls agentic crossover: searching historical records of what skills existed, how well they performed, and what they produced, then recombining the strongest ones into new candidates [8]. A base-level agent then executes the current best skill against real training rollouts, producing context as actual files and code with no fixed structural constraints, and reporting back a score the meta-level agent uses to keep refining the skill pool [8].

Here is a toy simulation of that structure, a meta-level process recombining the two best-scoring skills each round while a base-level process evaluates them:

python
/code
# A toy illustration of MCE's bi-level structure (Ye et al., ICML 2026):
# a meta-level agent evolves *skills* (reusable context-engineering
# procedures), and a base-level agent applies the current best skill to
# a task and reports a score the meta-level agent uses for the next
# round of "agentic crossover."

import random

def base_agent_run(skill, task_difficulty):
    """Simulate applying a skill to a task; better skills score higher
    but still have some randomness, like a real evaluation would."""
    return max(0.0, min(1.0, skill["quality"] - task_difficulty * 0.1 + random.uniform(-0.05, 0.05)))

def agentic_crossover(parent_a, parent_b):
    """Combine two successful skills into a new candidate, the way MCE's
    meta-level agent searches its skill history for what to recombine."""
    return {"quality": (parent_a["quality"] + parent_b["quality"]) / 2 + 0.05}

population = [{"quality": 0.4}, {"quality": 0.5}, {"quality": 0.45}]
task_difficulty = 3

for generation in range(5):
    scored = [(skill, base_agent_run(skill, task_difficulty)) for skill in population]
    scored.sort(key=lambda pair: pair[1], reverse=True)
    best_two = [skill for skill, _ in scored[:2]]
    child = agentic_crossover(best_two[0], best_two[1])
    population = best_two + [child]
    print(f"generation {generation}: best_score={scored[0][1]:.3f}")

The practical difference from ACE is that MCE is not just getting better at writing a playbook, it is getting better at writing the procedure that writes the playbook. That extra layer of indirection is expensive to reason about but, according to the paper's results, considerably more powerful.

Why Context as Files and Code, Not Just Text, Matters

One detail in MCE's design is easy to skim past and worth pausing on: the base-level agent produces context "as adaptable files and code, with no structural constraints," rather than a single text blob [8]. Most prior context-optimization work, ACE included, still ultimately produces a block of natural-language text that gets prepended to a prompt. MCE's skills can instead take the shape of an actual small program, a retrieval function, a scoring heuristic, a piece of few-shot example curation logic, rather than only a paragraph of instructions.

That distinction matters because a lot of what makes a real agent pipeline work is not describable purely as advice in a sentence. "Prefer the cheaper API when the request is simple" is advice a text-based playbook can hold. "Route this specific category of request through a fallback function that retries with exponential backoff" is closer to code than prose, and a system limited to text-only context updates has no clean way to express it. By letting the base-level agent emit code as part of its context, MCE can represent a strictly larger space of possible improvements than a text-only playbook can, which is a structural reason to expect it to outperform ACE beyond just having a smarter search process.

What Agentic Crossover Is Actually Doing

The term "agentic crossover" is a deliberate echo of crossover in genetic algorithms, where two parent solutions are combined to produce a child that inherits traits from both, in the hope the child performs better than either parent alone. MCE's meta-level agent searches its own history of previously generated skills, along with the performance each one achieved, and selects promising pairs to recombine, rather than mutating a single skill randomly or starting from scratch each round [8]. This is meaningfully more sample-efficient than either pure random search, which wastes most of its attempts, or pure gradient-style refinement of a single candidate, which can get stuck improving one mediocre idea instead of exploring genuinely different ones. The efficiency numbers in Step 4 below, 13.6 times faster training and 4.8 times fewer required rollouts, are the direct downstream effect of this search strategy: fewer wasted evaluations because the recombination step is already biased toward combining things that worked.

Step 4: The Benchmark Numbers

MCE was evaluated across five genuinely different domains: finance, chemistry, medicine, law, and AI safety, rather than a single narrow coding benchmark, which matters because it is evidence the method generalizes rather than overfitting to one kind of task [8].

Against ACE as the strongest prior baseline, MCE reported an average relative gain over the base model of 89.1 percent in the offline setting, where the skill-evolution process trains ahead of time on a fixed dataset, compared to ACE's 70.7 percent, an 18.4 point improvement. In the online setting, where the system has to adapt as new tasks arrive with no offline training phase, the gap widened considerably: MCE reached 74.1 percent against ACE's 41.1 percent, a 33.0 point improvement [8].

Those accuracy numbers came with real efficiency gains too, not the usual tradeoff where a stronger method costs proportionally more compute. The paper reports MCE training 13.6 times faster than ACE while requiring 4.8 times fewer rollouts to reach its results [8].

One concrete example from the paper's public repository makes the numbers tangible outside of aggregate percentages: on a symptom diagnosis task, applying MCE's skill-evolution process boosted DeepSeek V3.1's accuracy from 45 percent to 70 percent after just 100 training rollouts, a 25 point jump on a real, checkable task rather than an abstract benchmark average [8]. The project also ships this as runnable code, not just a table in a PDF:

bash
/code
# The MCE paper ships real, runnable training code, not just a benchmark
# table. This is the actual entry point from the project's public repo
# for one of its five evaluated domains (symptom diagnosis), which the
# authors report boosts DeepSeek V3.1 from 45% to 70% accuracy after
# 100 training rollouts.
git clone https://github.com/metaevo-ai/meta-context-engineering.git
cd meta-context-engineering
bash scripts/train_symptom_diagnosis.sh

Case Study: Why the Domain Spread Matters

It would be easy to read "five domains" as a footnote, but it is actually the most important methodological choice in the paper. A context-engineering method that only works on coding tasks is really a coding-specific trick wearing a general-sounding name, something the field has seen before with techniques that looked broadly applicable but turned out to only transfer within a narrow task family.

Finance, chemistry, medicine, law, and AI safety share almost nothing in terms of surface structure. A legal reasoning task and a chemistry synthesis task do not look alike at the token level, do not share vocabulary, and do not fail in the same way when an agent gets something wrong. What they share is the underlying shape of the problem MCE is solving: an agent repeatedly attempts a task, generates a trace of what it tried, and there is a scorable notion of whether that attempt succeeded. MCE's meta-level agent does not need domain-specific tuning to work across that spread, because it is not learning chemistry or law directly, it is learning how to write and refine the skills that help a base-level agent learn chemistry or law faster. That is the actual claim behind the term "meta" in Meta Context Engineering, and it is why a 25 point jump on medical symptom diagnosis and an 18.4 point aggregate gain across five unrelated fields are evidence of the same underlying mechanism rather than five unrelated results.

Step 5: Why This Matters Beyond a Leaderboard

It is tempting to file benchmark papers like this under abstract infrastructure news, but the underlying idea, automatically discovering what context an agent needs instead of hand-writing it once, changes what is practical to build. A pipeline like Text2Shorts in Miraflow AI, which turns a topic into a script, the script into scene visuals, and the visuals into a finished video, is exactly the kind of multi-step process where hand-tuned prompts at each stage tend to drift out of sync as the underlying models change. The same is true of AI Clipping, which has to transcribe a long video, judge which moments are actually engaging, and score them, a plan-then-execute shape that closely mirrors the generate-reflect-curate loop both ACE and MCE are built around. Automated context evolution is still mostly a research-stage technique rather than something every product team runs today, but the direction is clear: the manual, one-time prompt tuning that shipped most 2024-era AI features is being replaced by systems that keep improving their own context after launch, the same way a model's weights used to be the only thing anyone thought to keep training.

Consider a concrete version of that AI Clipping example. The pipeline transcribes a long video, then has to judge which segments are likely to perform well as a short, a task that depends heavily on context: what has actually gone viral in a given niche recently, what caption style tends to hold attention on that topic, what clip length works for that particular kind of content. A hand-written prompt for that judgment step, tuned once against a handful of example videos, will drift as trends shift and as the underlying model gets updated. A context store built the way ACE or MCE structure theirs, small individually taggable notes about what worked, refined through a reflect-and-curate loop against real outcomes rather than rewritten by a person every few months, is a closer match to how that judgment actually needs to behave over time. Nothing about applying that idea requires an ICML-level research project; it requires treating the context feeding that judgment step as data worth version-controlling and improving, rather than a paragraph written once and forgotten.

Common Mistakes When Evaluating Context Engineering Claims

A handful of misunderstandings come up constantly once a term crosses over from research papers into general industry usage.

• Treating "context engineering" as a synonym for a bigger prompt or a longer system message. The term specifically describes a system for assembling and maintaining context over time, not the length of any single instruction.
• Assuming any method that claims to "evolve context automatically" is doing what ACE or MCE do. Both papers succeed specifically because they update context incrementally rather than rewriting it wholesale each round, which is the part that is easy to skip when reimplementing the idea quickly.
• Comparing MCE's headline relative-gain percentages to ACE's headline percentage without checking whether both numbers are measured the same way. The 18.4 and 33.0 point gaps reported above come directly from the MCE paper's own offline and online evaluation settings against ACE as the baseline, and different papers sometimes define "relative gain" differently.
• Assuming a method that wins on five research benchmarks will transfer to an arbitrary production agent with zero adaptation. Both papers report strong generalization across their tested domains, but domains like finance, chemistry, medicine, law, and AI safety are still a specific slice of possible tasks, not a guarantee of universal transfer.
• Ignoring the efficiency numbers in favor of only the accuracy numbers. A 13.6x training speedup and a 4.8x reduction in required rollouts are often the more actionable result for a team deciding whether a technique like this is worth adopting at all, since compute and rollout budget are usually the real constraint, not raw achievable accuracy.

Production Best Practices for Adopting Context Engineering

If you are building an agent today rather than a research benchmark, a few practical patterns follow directly from how both papers structure their systems. Store context as small, individually addressable units, files, structured notes, tagged entries, rather than one large undifferentiated block, since both ACE's playbook and MCE's skill pool depend on being able to update, merge, or prune individual pieces without touching the rest. Separate the process that evaluates whether an attempt succeeded from the process that decides what to change, since both papers use a distinct reflection or scoring step before any update happens, rather than letting a single pass do both jobs at once. Prefer natural execution feedback, whether a test passed, whether a tool call errored, over hand-labeled supervision wherever it is available, since ACE explicitly demonstrated this is sufficient and it removes a major bottleneck to iterating quickly. And budget for the offline-versus-online distinction explicitly: MCE's own numbers show a much wider gap over ACE in the online setting, which suggests the harder, more realistic case of adapting on the fly is exactly where a more sophisticated method like this earns its keep, not the easier case of training ahead of time on a fixed dataset.

A Practical Starting Point Without Reimplementing a Research Paper

Most teams do not need to reimplement ACE or MCE from scratch to benefit from the underlying idea, and trying to do so on a first attempt is usually the wrong place to start. A more realistic path looks like this. First, instrument whatever agent or pipeline already exists so that every attempt produces a trace: what context it was given, what it did, and whether the outcome was correct, useful, or accepted, the same generation step both papers rely on. Second, before building any automated update mechanism, spend a week just reading those traces by hand and writing down, in a shared document, the specific patterns behind failures, this is the reflection step, done manually, and it alone tends to surface a surprising amount of low-hanging fruit. Third, once a team has a real backlog of documented failure patterns, convert the most repeated ones into small, individually tagged context entries, files or structured notes rather than edits buried inside a giant system prompt, which is the curation step and the part that sets up everything downstream. Only after that manual loop is running smoothly does it make sense to consider automating any part of it, and even then, automating the reflection step, having a second model diagnose failure traces, tends to pay off before automating full skill evolution does.

That video covers the broader context engineering shift in plain terms, useful background if the prompt-versus-context distinction above is a new idea.

Frequently Asked Questions

Is context engineering just a rebrand of prompt engineering? No. Prompt engineering optimizes a single instruction for a single call. Context engineering treats everything an agent draws on across many calls, instructions, tool descriptions, memory, retrieved documents, as a system to be deliberately designed and continuously updated, which is a different scope of problem entirely.

What is the actual difference between ACE and MCE? ACE evolves the context itself directly through a generate, reflect, curate loop applied to a single-level playbook. MCE adds a second layer above that: a meta-level agent evolves the skills, the reusable procedures, that produce and refine context, rather than editing context directly.

Do I need a research team to use any of this? Not to benefit from the underlying idea. Both papers publish real code, ACE's approach is documented in its ICLR paper and several open reimplementations, and MCE's training scripts are public on GitHub. Most teams will encounter the ideas indirectly, through agent frameworks that adopt them, rather than implementing the papers from scratch.

Why does MCE's advantage grow so much in the online setting? The online setting requires adapting to new tasks as they arrive with no offline training phase, which is a harder and more realistic scenario. MCE's two-tier structure, evolving the skill-generation process itself rather than just the context, appears to compound its advantage specifically when there is no time to pre-train on a fixed dataset first.

Is a 2.8 percentage point aggregate benchmark difference actually meaningful? The reported gaps here are much larger than that, 18.4 points offline and 33.0 points online, plus a concrete 25 point jump on the symptom diagnosis case study. Gaps of that size on evaluations spanning five unrelated domains are a meaningfully different result than a small, potentially noisy benchmark difference.

Where does the term "context engineering" actually come from? Shopify CEO Tobi Lutke used the term in a June 2025 post, Andrej Karpathy amplified it days later, and Gartner formalized it in a July 28, 2025 analyst note predicting it would appear in 80 percent of AI application tooling by 2028.

Conclusion

Context engineering earned its new name the hard way, by becoming a real, measurable technique rather than staying a rebrand of prompt engineering. ACE showed that an agent's context can improve itself through structured, incremental updates instead of hand-editing, avoiding the brevity bias and context collapse that sank earlier attempts. MCE then showed that evolving the process that produces context, not just the context itself, produces a meaningfully larger gain, 18.4 points offline and 33.0 points online, at a fraction of the training cost. Whichever specific method wins the next round of this race, the underlying shift, from static, human-written context to context that keeps improving itself after launch, is the part worth tracking, especially for anyone building the kind of multi-step, tool-using pipelines this technique was designed for. For more on how these underlying agent-building techniques compare in practice, our look at LLM agents and tool use covers the mechanics of how models decide to act in the first place, and our speculative decoding explainer covers the other major lever, inference speed, that determines how usable a context-heavy agent actually feels in production.

References and Sources

[1] Atlan. "What Is Context Engineering? Complete 2026 Guide."

[2] Gartner. "Context Engineering Is In, and Prompt Engineering Is Out."

[3] Sourcegraph. "Context Engineering: A Practical Guide for AI Agents."

[4] Neo4j. "Why AI teams are moving from prompt engineering to context engineering."

[5] Zhang, Q., Hu, C., et al. "Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models." arXiv:2510.04618.

[6] ICLR 2026. "Agentic Context Engineering: Learning Comprehensive Contexts for Self-Improving Language Models (Poster)."

[7] Ye, H., He, X., Arak, V., Dong, H., Song, G. "Meta Context Engineering via Agentic Skill Evolution." arXiv:2601.21557.

[8] metaevo-ai. "meta-context-engineering (GitHub repository)."