---
title: 'Prompt Optimization for AI Agents: GEPA and DSPy (2026)'
description: Prompt engineering for AI agents is going automatic. GEPA, an ICLR 2026 Oral, rewrites agent prompts from their traces and beats RL with up to 35x fewer runs.
url: https://nerdleveltech.com/prompt-optimization-ai-agents-gepa
language: en
date: '2026-07-22'
category: ai-ml
tags:
  - prompt optimization
  - GEPA
  - DSPy
  - prompt engineering
  - AI agents
  - reflective prompt evolution
  - MAS-PromptBench
  - agentic ai
markdown_url: https://nerdleveltech.com/prompt-optimization-ai-agents-gepa.md
attribution: 'Source: NerdLevelTech — https://nerdleveltech.com/prompt-optimization-ai-agents-gepa'
terms: https://nerdleveltech.com/llms.txt
---

# Prompt Optimization for AI Agents: GEPA and DSPy (2026)

**In one line:** Prompt optimization for AI agents is becoming automatic. GEPA — a Genetic-Pareto optimizer accepted as an ICLR 2026 Oral — rewrites an agent's prompts by reflecting on its own reasoning and tool-call traces, beating reinforcement learning across six tasks with up to 35x fewer runs.[^1]

**TL;DR:** For two years the advice for making an agent reliable was "write a better system prompt." In 2026 that job is being handed to an optimizer. GEPA (Genetic-Pareto) reads an agent's own execution traces — the reasoning, the tool calls, the tool outputs — diagnoses what went wrong in plain English, and evolves the prompt from there. It landed as an Oral at ICLR 2026, ships as a first-class DSPy optimizer (`dspy.GEPA`) and a standalone library with several thousand GitHub stars, and reports beating the reinforcement-learning method GRPO by up to 20% while using up to 35x fewer rollouts.[^1][^2][^3] The catch, published in June, is that the same technique gets unpredictable the moment you point it at a multi-agent system.[^4]

## What you'll learn

- What GEPA is and how "reflective prompt evolution" differs from hand-tuning a prompt
- The benchmark numbers that got it an ICLR 2026 Oral — and what they do and don't claim
- Why reading tool-call traces makes this specifically an *agent* technique, not just an LLM trick
- Where it already lives in your stack: `dspy.GEPA`, the standalone library, and the big-lab prompt tools
- The catch: what MAS-PromptBench found when the same optimizer met multi-agent systems
- What to actually do about it if you build agents

## What GEPA actually is

GEPA — short for **Genetic-Pareto** — is a prompt optimizer that "thoroughly incorporates natural language reflection to learn high-level rules from trial and error."[^1] That definition, from the paper's own abstract, is the whole idea in one sentence. Instead of adjusting model weights or nudging a numeric reward, GEPA works in the medium the model already understands best: language.

Here is the loop. You give GEPA an AI system that contains one or more prompts, plus a way to score its output. GEPA runs the system on a handful of training tasks and records the full trajectory — the model's reasoning, the tool calls it made, and the outputs those tools returned. A reflection step then reads those traces in natural language, diagnoses what failed, and writes a revised prompt. Crucially, it keeps a *Pareto frontier* of its best attempts rather than a single "current best," so it can combine complementary lessons from prompts that each won on different examples.[^1] The result is a rewritten instruction that a human never typed.

The reason this matters is the medium. The paper's core argument is that "the interpretable nature of language often provides a much richer learning medium for LLMs, compared to policy gradients derived from sparse, scalar rewards."[^1] A reinforcement-learning signal tells the model *that* it scored 0.3; a reflection tells it *why* — "you called the search tool before you had the user's account ID." One of those is far more actionable, and it is the one GEPA uses.

## The numbers that got it an ICLR 2026 Oral

GEPA was accepted to ICLR 2026 as an Oral — the top tier of acceptance — after a v2 revision posted in February 2026.[^1] The author list is not a group of unknowns: it includes DSPy's creator Omar Khattab, Databricks co-founders Matei Zaharia and Ion Stoica, Stanford's Christopher Potts, and Berkeley's Dan Klein, among a dozen others.[^1] That pedigree is part of why the results traveled.

The headline comparison is against reinforcement learning. Across six tasks, GEPA "outperforms GRPO by 6% on average and by up to 20%, while using up to 35x fewer rollouts."[^1] GRPO — Group Relative Policy Optimization — is a mainstream RL method that, per the same paper, "often require[s] thousands of rollouts to learn new tasks."[^1] Read the claim carefully, because the framing matters: the *average* edge over GRPO is 6%, and 20% is the *best-case* gap, not the typical one. The efficiency number is the genuinely striking part. Turning "thousands of rollouts" into a job that can run with dramatically fewer is what makes prompt optimization cheap enough to reach for by default.

GEPA also went after the prior state of the art in *prompt* optimization. It "outperforms the leading prompt optimizer, MIPROv2, by over 10% (e.g., +12% accuracy on AIME-2025)."[^1] MIPROv2 is the optimizer GEPA effectively supersedes inside DSPy, so this is the more direct apples-to-apples result for anyone already doing automated prompt search.

| Comparison | GEPA's reported result | What the baseline is |
|---|---|---|
| vs. GRPO (reinforcement learning) | +6% average, up to +20%, with up to 35x fewer rollouts | An RL method needing thousands of rollouts[^1] |
| vs. MIPROv2 (prior prompt optimizer) | Over 10% better; +12% on AIME-2025 | The previous "leading prompt optimizer"[^1] |

## Why this is an agent technique, not just an LLM trick

Plenty of tools rewrite a prompt. What makes GEPA land squarely in agent territory is *what it reflects on*. The trajectories it samples explicitly include "reasoning, tool calls, and tool outputs."[^1] That is the anatomy of an agent run, not a single completion. When an agent fails, the failure usually is not "the wording was slightly off" — it is that the agent called the wrong tool, called the right tool in the wrong order, or misread a tool's output and kept going. Those are exactly the events sitting in a trace, and they are exactly what a reflection step can name and correct.

This reframes what "prompt engineering for agents" even means. The old craft was a human staring at a system prompt, guessing at phrasings, and re-running a few examples by hand. The new shape is an optimization loop: define a metric, capture real traces, and let a reflector propose changes it can defend against those traces. Prompt engineering starts to look less like copywriting and more like the evaluation-and-iteration discipline this site has covered around [testing LLM prompts in CI](https://nerdleveltech.com/promptfoo-test-llm-prompts-ci-tutorial) — with the human moving from author to reviewer.

It also connects to a problem agents are already drowning in: tool sprawl. We have written before about [how many tools an agent can handle before accuracy drops](https://nerdleveltech.com/how-many-tools-can-an-ai-agent-handle), and a big part of the answer is how well the agent's instructions steer it through a crowded tool surface. A prompt that has been optimized against real tool-call traces is directly attacking that failure mode, rather than hoping a longer hand-written instruction happens to help.

## It is already in your toolchain

None of this is a research artifact you have to reimplement. GEPA ships two ways.

Inside DSPy it is a built-in optimizer, documented as "`dspy.GEPA`: Reflective Prompt Optimizer."[^3] You hand it a `GEPAFeedbackMetric` that returns both a score and a text `feedback` string — that textual feedback is the optimization signal, which is the whole point — and you pick a budget with an `auto` parameter set to `light`, `medium`, or `heavy`.[^3] The feedback-carrying metric is the part worth internalizing: GEPA is at its best when your metric can *say something*, not just emit a number.

It also exists as a standalone library, `gepa-ai/gepa`, that bills itself as a way to "optimize prompts, code, and more" through AI-powered reflective optimization.[^2] As of this writing the repository has several thousand stars and hundreds of forks — fast traction for an optimizer whose paper is a year old.[^2]

And GEPA is not alone in mainstreaming this idea. The major labs now ship their own prompt-refinement tooling: Anthropic's Prompt Improver rewrites an existing prompt using prompt-engineering best practices,[^5] and OpenAI offers a dashboard Prompt Optimizer that does the same against current guidance.[^6] Those are lighter-weight refiners rather than trace-driven evolutionary loops, but the direction is unmistakable — hand-authored prompts are becoming a starting point, not a deliverable.

## The catch: multi-agent systems break the clean story

Here is the part most write-ups skip. GEPA's numbers are single-agent numbers. What happens when you extend the same reflective optimization to a *team* of agents was measured directly in **MAS-PromptBench**, a June 2026 benchmark whose title asks the operative question: "When Does Prompt Optimization Improve Multi-Agent LLM Systems?"[^4]

The answer is: sometimes, and sometimes it makes things much worse. The benchmark's own Figure 1 puts it plainly: "While GEPA consistently improves single-agent performance across all five diverse tasks, its natural multi-agent extension yields highly variable effects across tasks and workflow topologies, ranging from large gains to severe performance drops."[^4] Quantified, "improvements reach up to 24.0 percentage points," but "performance can drop by as much as 16.0 percentage points for certain configurations."[^4]

| Setting | What the optimizer does | Reported outcome |
|---|---|---|
| Single agent | Reflect on one agent's traces, rewrite its prompt | Consistent gains across all five tasks[^4] |
| Multi-agent (natural extension) | Apply the same reflection across the team | Anywhere from +24.0 to −16.0 percentage points[^4] |

The benchmark also points at *why*. Optimization worked best when an agent's local behavior was "explicit, controllable, and verifiable," and when the team's communication protocol had explicit shared structure; larger teams introduced coordination overhead that made optimization harder.[^4] In other words, the more of your system lives in the murky space *between* agents — handoffs, implicit conventions, who-does-what — the less a single-agent-style prompt optimizer can help, and the more it can accidentally hurt. Automated prompt optimization is a real tool, not a magic wand, and the multi-agent case is where the difference shows.

## What this means if you build agents

A few practical takeaways fall out of the research.

First, treat prompt engineering as an optimization problem with a metric, not a wording exercise. GEPA and every tool like it needs a way to score outputs; the quality of your optimized prompt is bounded by the quality of that metric. If you cannot measure it, you cannot optimize it.

Second, make your metric *talk*. The single biggest lever in GEPA's design is that its feedback is natural language, not a scalar.[^1][^3] A metric that returns "failed: called `refund` before verifying the order status" will produce a better prompt than one that returns `0.0`. Spend your effort there.

Third, optimize against real traces, including tool calls. The whole reason this beats generic prompt-rewriting for agents is that it reflects on what the agent actually did. Feed it representative runs, not toy examples.

Fourth, do not assume single-agent wins transfer to your multi-agent setup. If you run an orchestrator with sub-agents, MAS-PromptBench is the caution to keep pinned to your monitor: measure before and after per topology, and be ready for the optimizer to make a configuration worse.[^4] This is one more reason the [production infrastructure being built around agent runtimes](https://nerdleveltech.com/managed-agent-runtimes-aws-google-alibaba) increasingly bundles evaluation and tracing — you need both to know whether an "optimized" prompt actually helped.

## FAQ

**What is GEPA?**
GEPA (Genetic-Pareto) is a prompt optimizer that reflects on an AI system's own execution traces in natural language to diagnose failures and evolve better prompts, keeping a Pareto frontier of its best attempts rather than a single best prompt.[^1]

**Is prompt engineering being automated?**
Increasingly, yes. Optimizers like GEPA turn prompt tuning into a metric-driven loop, and the major platforms now ship built-in prompt refiners.[^1][^5][^6] Human judgment shifts toward defining good metrics and reviewing results rather than hand-wording every instruction.

**Does GEPA really beat reinforcement learning?**
On the paper's six tasks it beats the RL method GRPO by 6% on average and up to 20%, using up to 35x fewer rollouts.[^1] That is a strong, specific result — not a universal law that reflection always beats RL everywhere.

**How is GEPA different from MIPROv2?**
Both are automated prompt optimizers in the DSPy lineage. GEPA reports beating MIPROv2 by over 10% (for example, +12% on AIME-2025), largely by using rich natural-language feedback instead of numeric search signals.[^1][^3]

**Can I use GEPA today?**
Yes. It is available as the `dspy.GEPA` optimizer inside DSPy and as the standalone `gepa-ai/gepa` library.[^2][^3]

**Does it work for multi-agent systems?**
Unreliably. MAS-PromptBench found that extending GEPA to multi-agent systems produced anywhere from +24.0 to −16.0 percentage points depending on the task and topology, with structured, verifiable setups faring best.[^4]

## The bottom line

Prompt optimization for AI agents crossed a line in 2026: the reflective, trace-driven approach that GEPA represents is now peer-reviewed, packaged, and sitting one import away in DSPy. For single agents, the case is strong — it beats reinforcement learning on the paper's tasks while spending a fraction of the compute, and it does it by reading the exact tool-call traces where agents actually fail.[^1] The honest asterisk is multi-agent systems, where the same idea swings from big wins to real regressions.[^4] The takeaway is not "stop writing prompts." It is that the highest-leverage work is moving up a level — from wording instructions to defining the metrics, feedback, and traces that let an optimizer write them for you.

## Related reads

- [Microsoft Project Perception: AI Security Agents 2026](https://nerdleveltech.com/microsoft-project-perception-mai-cyber-1-flash)
- [AI Agents in Go: Microsoft Joins Google's Bet in 2026](https://nerdleveltech.com/microsoft-agent-framework-go-google-adk)

[^1]: Agrawal et al., "GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning," arXiv:2507.19457 (v1 25 Jul 2025; v2 14 Feb 2026; accepted to ICLR 2026, Oral). https://arxiv.org/abs/2507.19457
[^2]: gepa-ai/gepa — the standalone GEPA optimizer library, GitHub (tagline and star/fork counts as of 22 Jul 2026). https://github.com/gepa-ai/gepa
[^3]: "dspy.GEPA: Reflective Prompt Optimizer," DSPy documentation (accessed 22 Jul 2026). https://dspy.ai/api/optimizers/GEPA/overview/
[^4]: "MAS-PromptBench: When Does Prompt Optimization Improve Multi-Agent LLM Systems?" arXiv:2606.23664 (June 2026). https://arxiv.org/abs/2606.23664
[^5]: "Console prompting tools" (Prompt improver), Claude Platform documentation (accessed 22 Jul 2026). https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-tools
[^6]: "Prompt optimizer," OpenAI API documentation (accessed 22 Jul 2026). https://developers.openai.com/api/docs/guides/prompt-optimizer