9 Open-Source Self-Improving AI Agent Frameworks (2026)

You ship an agent, it works, and then it stops getting better. Every fix is you, by hand, editing a prompt at midnight. The promise of a self-improving agent is that the loop closes itself: the system watches its own failures and rewrites its own prompts, memory, or weights, so the next improvement does not depend on you being awake.

A self improving agent updates its own prompts, memory, tools, or weights from feedback, so quality climbs across iterations without a human rewriting the system each time. The interesting work here is open source, which matters because you can inspect the loop, audit what changes, and avoid betting your stack on a black box.

This roundup covers nine open-source frameworks, grouped by what they actually change. Some optimize prompts, some accumulate memory, one updates weights, and a few search for whole new agent designs. Each gets its own section with the mechanism, the best use case, and honest install notes, so you can match one to your problem.

This is a tooling inventory, not a theory piece. If you want the conceptual version, how the loop works and which deployed systems genuinely run it, read recursive self-improvement in AI. Here the question is narrower and more practical: which repo do you pip install on Monday, and what does its license and maintenance status commit you to.

TL;DR

• Self-improvement in shipping open-source frameworks means one of four mechanisms: optimizing the prompt, editing the agent’s own memory or skills, changing the tools it can call, or rewriting the workflow itself. Nothing here retrains weights in production.
• Install-ready today: DSPy for prompt and demonstration optimization, Trace for general parameter optimization, Reflexion for verbal self-critique. TextGrad works but has been static since mid-2025, so treat it as stable rather than actively developed.
• Research-grade, not production-ready: SEAL, ADAS, the Darwin Gödel Machine and EvoAgentX are published systems with public repos, useful to read and risky to depend on.
• Every one of them needs the same thing to be safe: a frozen benchmark the agent cannot edit, scored before and after each change. Without it “self-improving” is unfalsifiable.
• Pick on licence and maintenance signal, not on the demo. All nine are permissively licensed, but commit recency varies by more than a year across the set.

What Makes an Agent Self-Improving?

Self-improvement takes four forms. The frameworks differ in which part of the agent they rewrite, and that choice drives cost, risk, and how much lift you get. Naming the four mechanisms first makes the nine frameworks below easy to place instead of a confusing pile of repos.

The first mechanism is prompt and instruction optimization: the agent’s weights stay frozen, but its prompts and few-shot examples get tuned against a metric. The second is memory and experience: the agent stores reflections or reusable skills and draws on them later. Both leave the base model untouched, which keeps them cheap and safe.

The third mechanism updates the weights themselves, fine-tuning the model on data the agent generates about its own mistakes. The fourth is architecture search, where a meta-agent proposes and tests entirely new agent designs in code. These two are more powerful and far riskier, and worth reaching for only after prompt-level gains plateau.

The table below maps the four mechanisms to what changes and when to reach for each. Keep it next to you as you read the nine frameworks. If you want the full picture of how these pieces fit, our walkthrough of the self-improving loop end to end traces one full cycle from feedback to update.

1. DSPy

DSPy (Khattab et al., Stanford NLP) reframes prompting as programming. Instead of hand-writing a prompt string, you declare the input and output signature, and an optimizer compiles the actual prompt for you against a metric you define. The base model never changes; what improves is the instructions and the examples DSPy selects, tuned on your own training set.

The MIPROv2 optimizer below searches instructions and few-shot examples to maximize your metric. Point it at a training set, give it a scoring function, and it returns a compiled program that scores higher than your hand-written baseline. This is the cheapest, most reliable form of self-improvement, and the right place to start.

import dspy

# assumes: dspy.configure(lm=dspy.LM("openai/gpt-4o-mini"))
def metric(example, pred, trace=None):
    return float(pred.answer.strip().lower() == example.answer.strip().lower())

program = dspy.ChainOfThought("question -> answer")
optimizer = dspy.MIPROv2(metric=metric, auto="medium")
optimized = optimizer.compile(program, trainset=trainset)  # trainset: list[dspy.Example]

DSPy is stable, pip-installable, MIT-licensed, and by a wide margin the most active repo on this list, with commits landing daily as of August 2026. It is the most production-ready entry here. It shines when your agent is a pipeline of prompted steps you can score end to end. For the wider view, our guide to automatic prompt optimization covers the optimizer families and their tradeoffs.

2. TextGrad

TextGrad (Yuksekgonul et al., published in Nature in March 2025) borrows the shape of backpropagation but runs it on text. Instead of numeric gradients, it uses natural-language feedback: an LLM critiques an output, that critique flows backward through the pipeline as a text gradient, and each variable, including your prompt, gets rewritten to reduce the loss you described in words.

The snippet below optimizes a system prompt against a plain-English loss. You declare the prompt a variable with requires_grad, define a text loss that penalizes wrong or verbose answers, call backward, and step. It suits feedback-driven refinement where your quality bar is easier to describe than to score numerically.

import textgrad as tg

tg.set_backward_engine("gpt-4o", override=True)
prompt = tg.Variable("Answer concisely.",
                     role_description="system prompt",
                     requires_grad=True)
model = tg.BlackboxLLM("gpt-4o", system_prompt=prompt)
answer = model(tg.Variable("What is 2+2?", role_description="query",
                           requires_grad=False))
loss = tg.TextLoss("Penalize wrong or verbose answers.")(answer)
loss.backward()
tg.TGD(parameters=[prompt]).step()

TextGrad is pip-installable and MIT-licensed, and it overlaps with DSPy on prompt tuning, with a different feel. Check its commit history before you depend on it: zou-group/textgrad has been quiet since mid-2025 at version 0.1.8, so treat it as stable-but-static rather than actively developed. DSPy wants a metric function; TextGrad wants a critique in words. Reach for TextGrad when your improvement signal is qualitative feedback rather than a clean numeric score you can already compute for every example.

3. Trace and OptoPrime

Trace (Cheng, Nie, and Swaminathan at Microsoft Research; pip install trace-opt) treats your whole agent as a computation graph, where nodes are the prompts, code, and tools that produced an output. Its OptoPrime optimizer reads execution feedback and updates those nodes together, so a single loop can rewrite a prompt and the Python glue around it in one coordinated pass.

This makes Trace a good fit when improvement is not just a prompt problem. If your agent’s quality depends on how prompts and code interact, optimizing them jointly beats tuning the prompt alone. It is pip-installable and MIT-licensed, aimed at heterogeneous agents where the logic and the language both need work.

The tradeoff is maturity. Trace is newer and less battle-tested than DSPy, with a smaller community and fewer worked examples. Treat it as the option to try when joint code-and-prompt optimization is genuinely your bottleneck, and budget time to learn its graph abstraction before you expect a clean production win.

4. Reflexion

Reflexion (Shinn et al.) adds a self-reflection step to the agent’s loop. After a failed attempt, the agent writes a short verbal critique of what went wrong, stores it in an episodic buffer, and reads it back on the next try. The memory of the mistake, in plain language, steers the retry toward a better answer.

One honest caveat: Reflexion ships as a research reference implementation, not a maintained pip package. Treat it as a pattern to implement rather than a library to install. The idea is small and portable, so folding a reflect-and-retry buffer into your own agent loop is usually a day of work, not a dependency.

Reflexion fits retry-heavy tasks where a second attempt is cheap and a lesson from the first genuinely helps, like coding or multi-step reasoning. It does nothing for one-shot calls with no retry. Pair it with a real eval so a reflection that sounds insightful but does not improve results gets caught.

5. Voyager

Voyager (Wang et al., NVIDIA and Caltech) came out of open-ended learning in Minecraft, and its idea travels well beyond the game. As the agent explores, it writes small programs that solve tasks and files them in a growing skill library. Later tasks reuse those skills, so the agent’s capability compounds instead of restarting from scratch each episode.

The pattern suits long-horizon agents in simulated or tool-rich worlds, where reusable skills accumulate real value over time. It is research code, MIT-licensed, and closely tied to its original environment, so expect to adapt the skill-library idea to your domain rather than install it as a drop-in library for a production agent.

The lesson to steal, even if you never touch Voyager’s code, is that memory can be executable. Storing working code as a skill, not just a text reflection, gives an agent something it can call again with confidence. That distinction matters when you design any experience-accumulating self improving agent of your own.

6. SEAL, Self-Adapting LLMs

SEAL (Zweiger et al., MIT) is where self-improvement stops touching only prompts and starts touching weights. The agent generates its own finetuning data, self-edits in natural language, and then actually updates the model on that data. The loop closes at the parameter level, so the improvement persists in the weights rather than in a prompt wrapper.

That power comes with real cost and risk: training compute, the chance of catastrophic forgetting, and a much harder rollback story than swapping a prompt. Reach for weight updates only once prompt-level gains have plateaued. Our comparison of when weight updates beat prompt tweaks covers exactly that line.

SEAL is research code, MIT-licensed, and best treated as a frontier to study rather than a library to deploy this quarter. If you do run it, gate every weight update behind a frozen eval set and keep the previous checkpoint, because a self-edit that hurts quality is easy to make and hard to notice.

7. ADAS, Automated Design of Agentic Systems

ADAS (Hu, Lu, and Clune) turns the agent itself into the thing being optimized. A meta-agent writes code that defines new agent designs, runs them, scores the results, and uses what it learns to propose the next design. Instead of tuning one agent, you search a space of possible agents for the architecture that performs best.

This is architecture search, and it is expensive: every candidate design is a full agent you have to run and evaluate. ADAS is research code under Apache-2.0, aimed at teams exploring genuinely novel workflows where no known design fits. For most products, prompt optimization gets you there for a fraction of the compute.

The reason to watch ADAS even if you never run it is direction. Architecture search hints at where the field goes once prompt and weight tuning saturate: agents that redesign their own scaffolding. Knowing that horizon exists helps you avoid over-investing in a hand-built design you will later want a search to replace.

8. Darwin Gödel Machine

The Darwin Gödel Machine (Zhang, Hu, Lu, Lange, and Clune) is a self-referential agent that rewrites its own code and proves each change earns its place. It proposes a modification to itself, runs against a benchmark, and keeps the change only if the score improves. An archive of past variants preserves diversity, so the search does not collapse to one line.

The empirical-validation part is the important lesson. Because every self-rewrite is accepted only against a benchmark, the loop cannot drift on vibes. It is research code under Apache-2.0, firmly in open-ended research territory, but the discipline it enforces, no change without a measured win, is exactly what any self improving agent needs.

Practically, you will not put the Darwin Gödel Machine in a product soon. What you can borrow today is its acceptance rule. Wrap any self-modifying step, however small, in the same gate: benchmark before, benchmark after, keep the change only on a real improvement, and archive what you replaced in case you need it back.

9. EvoAgentX

EvoAgentX (Wang, Liu, Fang, and Meng) brings evolutionary search to multi-agent workflows. Rather than optimize one agent, it mutates whole pipelines, how agents are wired, which roles exist, how they hand off, and selects the variants that score best. Over generations, the workflow itself evolves toward a shape you did not have to design by hand.

Evolution only works if selection is honest, which makes the scoring function the whole game. A weak metric evolves a workflow that games the metric, not one that helps users. Put a real eval in the loop; our note on a harness to score each variant shows how to make that selection pressure trustworthy.

EvoAgentX is MIT-licensed and ships as both a repo and a pip package. GitHub’s classifier tags it NOASSERTION because the license file appends third-party notices for vendored code, but the grant itself is standard MIT. It fits teams with genuine multi-agent complexity and the eval infrastructure to run many candidates, which is the part people underestimate.

How Do You Choose a Self-Improving Agent Framework?

With nine options, the choice comes down to three questions. What do you want to change, prompts, memory, weights, or architecture? How mature does the tooling need to be? And how will you prove the change helped? Answer those in order and most of the list falls away fast.

For production teams, install maturity is decisive. DSPy, TextGrad, and Trace are pip-installable and MIT-licensed, so they slot into a real codebase today. Reflexion, Voyager, SEAL, ADAS, and the Darwin Gödel Machine are research code you adapt, not dependencies you add, which is fine for exploration and risky for a shipping deadline.

The table below lines up all nine by mechanism, install maturity, and license so you can scan the tradeoffs at once. Confirm each license and install path at the moment you evaluate, since these repos move quickly. Then shortlist by mechanism first, and let maturity break the tie for anything production-bound.

Three active projects sit just outside this table. GEPA, a reflective prompt optimizer, is a close cousin of DSPy and TextGrad; it ships as a DSPy optimizer and as one of the six algorithms in Future AGI’s agent-opt, disclosed below.

AFlow generates agentic workflows like ADAS and EvoAgentX. AlphaEvolve, with its open replication OpenEvolve, pushes evolutionary search down to raw code. Track all three if your problem outgrows these nine.

How Do You Measure Whether Self-Improvement Is Real?

Every framework glosses over the same thing: without a frozen evaluation set, you cannot tell improvement from drift. A self-modifying loop will report that it got better while quietly getting worse on the cases you stopped checking. The optimizer’s own score is not evidence; an independent, fixed benchmark is.

If you want an open-source optimizer to sit alongside the frameworks above, agent-opt from Future AGI is Apache-2.0 and ships six algorithms behind one API: Random Search, Bayesian search over few-shot subsets and ordering, ProTeGi, Meta-Prompt, PromptWizard, and GEPA. It is disclosed plainly as our own tool rather than ranked as a tenth entry, and it sits in the same mechanism row as DSPy and TextGrad.

For the measurement layer, define a custom eval that encodes what a good answer means for your task.

Then run the optimization workflow to score every iteration against a fixed dataset, and freeze that set so every version is compared on identical ground.

If the gate needs to run in CI on every commit, the Apache-2.0 Agent Learning Kit (pip install ai-evaluation) gives you 72 metrics that score locally with no network call, so a frozen-benchmark check costs seconds instead of an API bill. Cheap gates are the ones that actually stay wired in.

That discipline is what separates a real self improving agent from one that just moves numbers around. Score every iteration, keep the frozen set honest, and roll back any version that regresses. Our guide to evaluate agent quality covers building the eval set that makes this measurement trustworthy.

Picking Your First Self-Improving Agent Framework

If you are starting today, start with prompt optimization. In practice a self improving agent means DSPy or TextGrad wrapped around a clear metric, because that is where the reliable, cheap gains live. You can ship it this week, and it rarely breaks anything the way weight edits can.

Escalate only when prompts plateau. If tuned prompts stop moving your metric, then consider weight-level adaptation with SEAL, or architecture search with ADAS, the Darwin Gödel Machine, or EvoAgentX. Each step up buys more headroom at a steep jump in compute, risk, and the amount of evaluation you need to stay safe.

Whatever you pick, keep the eval gate non-negotiable. Every framework here can improve an agent or quietly wreck it, and only a frozen benchmark tells you which happened. Choose by mechanism, adopt by maturity, and gate every self-modification behind our pre-deployment checklist for self-improving agents before it ships. That rule outlasts any single framework on this list.