AI Engineer World's Fair 2026
Beating RL With Reflection: GEPA and Optimize Anything — Lakshya A. Agrawal, GEPA
Slide chapters
9 slide and demo groups · Timestamps are approximate. 24 additional groups were omitted from this pass.
Read the talk
Beating RL With Reflection: GEPA and Optimize Anything
Lakshya A. Agrawal explains how full execution traces can teach an optimizer more than a reward alone—and how the same search can improve prompts, agent programs, repository skills and evaluators.
From a talk by Lakshya Agrawal
At a glance
Ideas worth remembering
Reflection uses the diagnostic content of an attempt—intermediate outputs, tool responses and errors—to propose a behavioral change in text.
GEPA’s Pareto pool preserves candidates with strengths on individual examples, allowing search to continue along alternatives when the highest-scoring prompt stops improving.
Optimize Anything can search over prompts, programs and policies when they can be represented as text and scored. The evaluator should return actionable feedback alongside its score.
Learned repository skills can carry practical knowledge between attempts and models, reducing repeated exploration as well as improving task completion.
For subjective tasks, detailed human annotations can first train an LLM judge prompt; that judge can then guide agent optimization in a continuing production feedback cycle.
When each attempt takes hours, learning from a score gets expensive
Teaching an AI system a new task usually means updating its weights: during pretraining, supervised fine-tuning or reinforcement learning. Lakshya A. Agrawal opens with the practical obstacle to that approach. Most teams do not have the data and compute needed for large training runs, especially when the task involves unfamiliar domain knowledge or an agent that works for hours.
Two costs make sample efficiency—the amount learned from each example—central:
- Scarce domain examples. A specialized task may have too little existing knowledge or labeled data for supervised fine-tuning.
- Expensive attempts. Running the agent, waiting for its tools and measuring the result can all take substantial time. Repeating that process hundreds of thousands of times becomes impractical.
In the reinforcement-learning setup described here, a model produces several rollouts, an evaluator assigns rewards, and an algorithm such as GRPO converts those rewards into weight updates. The learning signal compresses a rich attempt into a scalar score. Yet the attempt also contains intermediate reasoning, tool calls, environment responses and error messages. A failure score tells the optimizer that something went wrong; an error message may tell it what went wrong.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Use the trace to change the instructions
Reflective optimization gives a language model the rollout itself. The model examines what worked and what failed, then proposes a change to the prompt. Reflection can use intermediate outputs and, potentially, retrieve supporting information from a company knowledge base or a guide. The update happens in text, where a short instruction can express a large behavioral change.
A summarizer makes the idea easy to see. Change its instruction from producing a one-line summary to producing a ten-line summary, and the requested output changes substantially through a tiny edit. The example illustrates the size of an update available in prompt space: reflection can identify a desired behavior and state it directly, rather than trying to obtain it through a sequence of small weight updates.
GEPA combines this reflection with an evolutionary search over candidate prompts. Each attempt supplies a score and textual feedback, including domain-specific information. In Agrawal’s presented comparison, one reflection round using three examples produced twice the performance gains that GRPO achieved after 25,000 rollouts. Further reflection increased the gap, and the model performed its own reflection without an external expert teacher. These and the later benchmark results are task-specific reported outcomes; the recording does not establish complete evaluation protocols or dataset splits, so they do not establish a universal advantage over reinforcement learning.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A better prompt can be a better problem specification
The useful output of reflection is often a clearer specification of the task: how to interpret the input, what a pipeline stage is supposed to accomplish, and which lessons the examples reveal. In a multihop question-answering system, the optimized second-hop prompt captured a division of work. First-hop documents often cover one entity or aspect of the question; the next retrieval should find documents related to that information. The prompt teaches the stage how to contribute to the whole pipeline.
This automates part of the work teams otherwise do by repeatedly editing prompts and discovering the task specification themselves. Agrawal gives a run-time estimate of half an hour to one hour, depending on the pipeline. The approach also works through proprietary model interfaces: an optimized GPT-4.1 mini prompt outperformed GPT-4.1 on the math task presented.
The AMD example shows what a concrete learned correction can do. A coding agent had to program a new NPU through an unfamiliar API with very little information available online. Its initial performance was roughly 4%. GEPA changed the prompt, leaving the rest of the agent unchanged, and the reported result rose to roughly 30%. One discovered instruction told the agent to avoid an AMD library header that existed for NPU programming but did not work with the hardware generation being tested.
The causal change is specific: an apparently relevant library was unsuitable for this target, reflection discovered that restriction, and the prompt carried the restriction into subsequent attempts. GEPA found it in one step. The overall gain belongs to the optimized prompt as a whole; the example does not isolate how much of that gain came from this single instruction.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep useful specialists so search can take another route
GEPA’s basic loop runs the current pipeline on a few examples, collects feedback and asks a model or agent to propose a better prompt. The important search decision comes afterward: which candidates remain available for future improvement? The Pareto pool keeps candidates that win on even one training example, rather than retaining only the highest overall scorer.
Why preserve a candidate that is not the best overall? In the search example, a simple improvement loop reached a better prompt, then repeatedly generated changes that failed to improve it. Each rejected change returned the search to the same incumbent until the budget ran out. A pool preserves other starting points with useful strengths on particular examples. Those alternatives let the search develop several branches instead of spending everything around one local optimum.
What information travels through this search, and where does diversity survive? The diagram separates the diagnostic feedback used to write a candidate from the example-level results used to retain candidates. Reflection supplies the edit; the pool determines which lines of improvement remain available.
Across four benchmarks, Agrawal attributes more than half of GEPA’s gains to this candidate-selection strategy and reports almost twice the gains of a model-in-a-loop approach. He then shows results spanning question answering, instruction following, claim verification and math. The lesson from the search comparison is narrower and useful: improving prompts requires both informative edits and a way to avoid repeatedly editing the same dead end.
Reflection proposes changes; the Pareto pool preserves alternatives
Read the diagram as text
- Candidate pool. Retain candidates that win on individual training examples.
- Run a candidate. Execute the pipeline on a few examples.
- Collect feedback. Observe domain information and results from the environment.
- Reflect and propose. A model or agent reads feedback and writes a better prompt.
- Candidate pool → Run a candidate: Continue search from retained candidates.
- Run a candidate → Collect feedback: Execution results.
- Collect feedback → Reflect and propose: Diagnostic information.
- Reflect and propose → Candidate pool: Retain useful proposed candidates.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Optimize Anything makes the editable object larger
A prompt is one text artifact that controls behavior. An agent’s Python or JavaScript program is another. Optimize Anything extends the same search to an object that can be represented as text and evaluated with a score. Instead of editing only instructions inside an agent, the optimizer can edit the program that determines its tools and control flow.
The evaluator has two jobs: measure the candidate and return information that can help improve it. The examples make that distinction concrete:
- CUDA kernels. Compilation and profiling can produce both a score and diagnostics about the code.
- Numeric parameters. Numbers can be serialized as text, making them editable candidates too.
- Cloud scheduling policies. A policy or heuristic can be scored on cost or efficiency, while job traces and service-level agreement violations explain where it failed.
The API accepts the problems to solve and a fitness function that returns a score plus an open-ended dictionary of side information. Expert feedback, compiler errors, profiler messages, tool errors and documentation can all go into that dictionary. This is the integration work that makes reflection useful: expose what the environment knows about the candidate, rather than reducing everything to whether it passed.
A playful example optimizes a Python script that renders a 3D unicorn to a PNG. It demonstrates that the candidate can be an image-producing program, rather than a prompt that returns text. The recording compares the resulting renderings, but does not explain the visual fitness function; the example illustrates the range of editable artifacts rather than a reproducible measure of visual quality.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From a single model call to an agent—and from trajectories to skills
Agent development usually involves choosing tools, writing their descriptions and arranging control flow. In the ARC-AGI example, the starting point was a four-line Python program that called a model to reason through the problem. After 16 reflection rounds, Optimize Anything produced a six-step agent, raising the reported Gemini Flash accuracy from 32.5% to 89.5%. The editable object was the agent file itself, so search could introduce new steps.
The generated agent induced rule hypotheses, synthesized code, executed and traced that code, debugged it and proposed revisions. It then ran the resulting code on the test inputs and returned the output. This changes how an answer is produced: the system can inspect the consequences of an executable hypothesis and revise it before returning a result. A second harness example on MATH-500 produced a two-step agent and a reported accuracy improvement of 20% for GPT-4.1 nano; the recording does not specify whether that figure means a relative increase or percentage points.
Repository skills offer a different place to store what reflection learns. The objective is to learn a skill from an agent trajectory that will help when a similar problem appears. In the Go repository issue-resolution example, learned skills raised a budget-constrained GPT-5 mini coding agent from 24% to 93%. The skills contained practical repository knowledge: where features live, how the repository is organized, how to invoke tests and which build system it uses.
Those skills also transferred to Claude Sonnet, where Agrawal reports 100% issue resolution on the tested tasks and almost a 50% reduction in resolution time. The proposed explanation is practical: carrying repository knowledge into the next attempt reduces repeated discovery and token use. The skills learned with a cheaper model could therefore help a different model work more efficiently. The open-source skill-learning feature is available through the GEPA repository.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Choose whether to solve this instance or learn for future ones
Optimize Anything distinguishes three optimization modes by what the result must serve:
- Single problem. Improve one artifact, such as a particular matrix-multiplication kernel.
- Multitask search. Work on related problems, such as matrix-multiplication and dot-product kernels, where information may transfer between them.
- Generalization. Optimize using a set of examples, then deploy the prompt, skill or agent architecture on new problems.
The production examples span different objectives. Agrawal reports almost 40% lower cloud scheduling costs compared with expert heuristics and almost 35% lower OCR error rates for leading models. He also describes Databricks tuning an open model to outperform Claude Opus on its agent task at 90 times lower cost. These examples put accuracy, error rate and operating cost on the same agenda: a successful optimization need not mean buying a larger model.
Does a better model make prompt optimization less useful? Agrawal’s answer is the opposite: stronger instruction following can increase the value of precise task instructions. In the presented comparison, Claude Opus gained more from optimization than the open model did. That supports his view that model capability and task specification can reinforce each other, although it does not establish how every future model will respond.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Learn the evaluator, then use it to improve the agent
Subjective tasks complicate the requirement to score a candidate. The proposed starting point is production experience: collect agent trajectories and ask a human to annotate about 50 of them with detailed feedback. Comments can describe response length, quality, terminology or other task-specific preferences. GEPA then optimizes an LLM judge prompt using those annotations, and that judge evaluates candidates while the agent is optimized.
How does human feedback reach the next deployed agent? The cycle below makes the intermediate evaluator visible. Human annotations first shape the judge; the judge then guides agent optimization; deployment produces the next set of trajectories. The judge’s usefulness depends on how well the annotations capture the intended quality standard—this procedure makes that standard learnable, without making subjective evaluation objective.
The ending returns to weight training. In work called “Learning Fast and Slow,” Agrawal describes co-optimizing model weights and prompt harnesses for continual learning. He does not develop the update procedure in this recording. The proposal nevertheless changes the relationship established at the start: reflection in text can accompany weight updates, with both becoming parts of a learning system.
Agrawal closes with reports of production adoption and an integration claim: GEPA can work with different frameworks and models without hard dependencies. His practical advice is to expose as much actionable domain information as possible. A score selects the desired result; traces, errors, documentation and expert feedback give reflection something useful to change. That is the starting point for trying the approach through the open-source implementation.
Human feedback trains the judge that guides the agent
Read the diagram as text
- Production trajectories. Collect attempts from the deployed agent.
- Detailed human feedback. Annotate about 50 trajectories with task-specific judgments.
- Optimized LLM judge. Use annotations to optimize the judge prompt.
- Optimize and deploy the agent. Use the learned judge to guide agent improvement.
- Production trajectories → Detailed human feedback: Human review.
- Detailed human feedback → Optimized LLM judge: Optimize the evaluation prompt.
- Optimized LLM judge → Optimize and deploy the agent: Evaluate agent candidates.
- Optimize and deploy the agent → Production trajectories: New production experience.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Explore the implementation behind reflective optimization and the repository skill-learning feature discussed in the talk.
Read the complete timestamped transcript
9 slide groups. Extracted from the recording; expand builds to follow changes. Timestamps are approximate. 24 additional groups were omitted from this pass.
- 0:12
Hi everyone, my name is Lakshia Agraal
- 0:15
and today I'll be presenting on behalf
- 0:17
of a very large effort uh the problem of
Reflective Optimization
Lakshya A. Agrawal introduces reflective optimization: self-improving prompts, agents, and models using textual feedback.
Text in image
Reflective Optimization Self-improving prompts, agents, and models from text feedback Lakshya A Agrawal, Donghyun Lee (Luke), Shangyin Tan, Rishabh Tiwari, Dilara Soylu, Kusha Sareen, Noah Ziems, Wenjie Ma, Rishi Khare, Karim Elmaaroufi, Krista Opsahl-Ong, Arnav Singhvi, Rohit Sandadi, Herumb Shandilya, Michael J Ryan, Christopher Potts, Kurt Keutzer, Inderjit S Dhillon, Meng Jiang, Sanjit A. Seshia, Rishabh Agarwal, Devvrit Khatri, Koushik Sen, Dan Klein, Joseph E. Gonzalez, Ion Stoica, Omar Khattab, Alexandros G. Dimakis, Matei Zaharia github.com/gepa-ai/gepa Logo text: The University of California Berkeley, 1868; sky
- 0:21
reflective optimization or how can we
- 0:24
self-improve prompts agents and models
- 0:27
from textual feedback. The question we
- 0:29
start with is how can we teach AI to
- 0:32
perform new tasks. The standard way has
- 0:35
been to perform weight updates with
- 0:37
gradient descent either during
- 0:38
pre-training, supervised fine-tuning or
- 0:41
reinforcement learning. This has proven
- 0:43
to be extremely effective, but it
- 0:45
requires a huge number of examples.
- 0:48
trillions of tokens for pre-training,
- 0:50
tens of thousands of labeled examples
- 0:52
for supervised fine-tuning or hundreds
How can we teach AI new tasks?
Pretraining, SFT, and RL teach tasks through gradient descent, but require vast numbers of tokens, labeled examples, or trial rollouts. Most teams lack that much data or compute.
Text in image
How can we teach AI new tasks? Standard way: weight updates with gradient descent: pretraining, supervised fine tuning (SFT), reinforcement learning (RL) Very effective, but requires huge numbers of examples! - Trillions of tokens for pretraining - 10,000s of labeled examples for SFT - 100,000s of rollouts (trials) for RL (math, coding, etc) Most teams do not have that much data or compute. Interface text: CC
- 0:54
of thousands of rollouts for
- 0:56
reinforcement learning in domains like
- 0:58
math, coding, etc.
- 1:02
However, most teams do not actually have
- 1:05
that much data or compute and in fact
- 1:08
the problems are that we are trying to
- 1:10
tackle with AI now are bottlenecked by
- 1:13
sample efficiency. What do we mean by
- 1:15
that? Two things. First of all, there is
- 1:18
low availability of domain specific
- 1:21
knowledge resources which means there is
- 1:23
not enough data to perform offline
- 1:25
algorithms like SFT. Second, the domains
Why this is hard in practice
Domain-specific data can be too scarce for supervised fine-tuning, while rollouts can be costly when the LLM workflow or task metric is slow or expensive to execute.
Text in image
Why this is hard in practice Low availability of domain specific knowledge resources Expensive rollouts: either the LLM workflow for the task or the task metric is slow/expensive to execute Illustrations: AI Engine-ML Kernel and Graph Programming Guide [illegible] AMD TASK
- 1:28
that we are trying to apply AI
- 1:30
increasingly are having expensive
- 1:32
rollouts where either the LLM workflow
- 1:34
pipeline or agentic rollouts are itself
- 1:37
uh very slow or expensive to do or the
- 1:40
task metric is very slow or expensive to
- 1:42
execute. We are seeing that agents can
- 1:44
now work for hours on end and if you
- 1:47
were to apply an online learning
- 1:49
algorithm to this uh it would require
- 1:52
hundreds of thousands of rollouts and it
- 1:53
would not be feasible. So we are seeing
Increasing use of agents for real-world applications
Agents connect models to tools and retrieval, with guardrails. Long-running tool calls can make repeated rollouts costly, worsening sample inefficiency.
Text in image
Increasing use of Agents for real-world applications Monolithic LLM Agent Tool Invocation Retrieval Guardrails Interface text: CC
- 1:56
increasing use of agents for real world
- 1:58
product uh applications where uh these
- 2:01
invoke tools which can also be long
- 2:03
running further exacerbating the sample
- 2:05
inefficiency issue.
- 2:08
The current dominant paradigm is
- 2:10
reinforcement learning with verified
- 2:11
rewards where given a model and a task,
- 2:14
we perform any number of parallel
- 2:16
rollouts and get rewards at the end.
- 2:20
Finally, an algorithm like GRPO takes
- 2:22
these rewards and converts it into
- 2:24
gradients that are applied back to the
- 2:26
model. However, as we can see, there was
The current dominant paradigm
The model generates multiple rollouts, but RL uses their 0/1 rewards to update the model. The speaker asks whether the intermediate traces—including tool calls, responses, and error messages—could also inform learning.
Text in image
The current dominant paradigm RL with verified rewards: Model Rollout 1 → 1 Rollout 2 → 0 Rollout 3 → 1 Rewards There was a lot of information in each rollout, but we only took a 0/1 score and propagated that via gradient descent. Can we use the other info? Interface text: CC
- 2:29
a lot of information in each of these
- 2:32
rollouts, but we only learned an O of
- 2:35
one score and propagated that via
- 2:38
gradient descent. We can see that there
- 2:40
is chains of thought, the tool calls
- 2:42
made to the environment, the envir
- 2:44
environment's responses to those tool
- 2:46
calls, which could potentially contain
- 2:48
error messages which also provide
- 2:50
diagnostic value and we learned almost
- 2:53
nothing from all of that. So the
- 2:55
question we ask is can we make use of
- 2:58
this other extremely rich information.
Idea: Reflective Optimization in Text Space
A language model examines rollout traces and intermediate outputs to identify what worked, potentially using retrieval. It then updates a prompt, where one natural-language change can substantially alter behavior.
Text in image
Idea: Reflective Optimization in Text Space Instead of only using the 0/1 reward signal, have a LM look at the traces of all the rollouts and reflect on what worked in them (using all intermediate outputs, and potentially even other tools, such as retrieval!) Agent Tool Invocation Retrieval Guardrails Interface text: CC
Show 2 builds
- 3:00
An agent diagram accompanies a proposal for a language model to reflect on rollout traces and intermediate outputs.
Text in image
Idea: Reflective Optimization in Text Space Instead of only using the 0/1 reward signal, have a LM look at the traces of all the rollouts and reflect on what worked in them (using all intermediate outputs, and potentially even other tools, such as retrieval!) Agent Tool Invocation Retrieval Guardrails Interface text: CC
- 3:34
An agent diagram accompanies explanations of reflecting on rollout traces and updating prompts.
Text in image
Idea: Reflective Optimization in Text Space Instead of only using the 0/1 reward signal, have a LM look at the traces of all the rollouts and reflect on what worked in them (using all intermediate outputs, and potentially even other tools, such as retrieval!) Instead of only updating weights with small deltas, update a prompt: a single natural language update can give a large behavior change Agent Tool Invocation Retrieval Guardrails Interface text: CC
- 3:00
- 3:02
Our idea is to perform reflective
- 3:04
optimization in text space where instead
- 3:07
of only using the zero or one reward
- 3:10
signal, we can have a language model or
- 3:12
an agent look at the trace of the entire
- 3:16
rollout and reflect on what worked in
- 3:18
them, what did not work in them. And
- 3:20
this reflection could potentially use
- 3:22
all intermediate outputs and potentially
- 3:25
even make other tool calls such as
- 3:27
retrieval from your company's knowledge
- 3:29
base or some guide textbook and so on.
- 3:33
So that's the first key idea and the
- 3:35
second is that instead of only updating
- 3:38
weights with small deltas, we can
- 3:40
instead update a prompt where a single
- 3:43
natural language update can give a very
- 3:45
large behavior change. Let's take a
- 3:47
simple example. Let's say you're tasked
- 3:48
with writing a text summarization system
- 3:51
and the prompt of that system says
- 3:53
generate a oneline summary. If I just go
- 3:56
and tweak that prompt to say generate a
- 3:58
10-line summary, we can all agree that
- 4:01
the behavior of the system would change
- 4:03
quite significantly with that just one
- 4:05
word change. And making that one word
- 4:07
change is quite quick and we can reflect
- 4:09
on our own behavior and identify what
- 4:12
needs to change. If we were to achieve a
- 4:15
similar kind of behavior update from our
- 4:17
AI system, we would have to have
- 4:19
thousands of gradient very tiny gradient
- 4:21
updates sequentially.
GEPA: Reflective Prompt Optimization for Agents
GEPA uses text feedback to evolve prompts and Pareto-based selection to find test-case-specific solutions before aggregating them.
Text in image
GEPA: Reflective Prompt Optimization for Agents RL in text space: Instead of just receiving a reward score, we obtain <score, text feedback> Genetic Leverage text feedback to create good prompts from genetic pool Pareto (Multi Objective) Discovers test case specific solutions first and aggregate later Interface text: CC
- 4:23
So with that key idea, we proposed JPEA
- 4:26
which is a reflective prompt
- 4:27
optimization technique for agents. It
- 4:30
uses an evolutionary loop along with a
- 4:32
novel parto-based candidate selection
- 4:34
which I will come to later. It is akin
- 4:37
to doing reinforcement learning in text
- 4:39
space where instead of just rewarding
- 4:41
receiving a reward score we are actually
- 4:44
obtaining score along with textual
- 4:46
feedback which can be very domain
- 4:47
specific and learn all about the domain
- 4:50
from it.
- 4:52
Let's compare Japa with gRPO which is
- 4:54
one of the leading RL techniques. On the
- 4:56
x-axis we have the number of training
- 5:00
steps uh also proportional to number of
- 5:02
data samples seen and on the y-axis we
- 5:05
have the performance on our domain that
- 5:07
we are training for. And what we can see
- 5:09
is that Japa in just one round of
- 5:12
reflection using just three data points
- 5:14
is already able to get twice the
- 5:16
performance gains that gpo got after
- 5:19
25,000 rollouts. Continuing to run Japa
- 5:22
for a few more steps further increases
- 5:25
that gap itself by another 2x. I want to
- 5:29
note here that the model Quen 38B is
- 5:33
optimizing itself here. There is no
- 5:35
external expert teacher involved
- 5:37
whatsoever.
GEPA Generates a System Specification
GEPA expands a one-line seed into a second-hop retrieval specification. It directs the query toward missing, related information rather than repeating facts already found in the first hop.
Text in image
Seed Prompt for Second-Hop of Multi-Hop QA System Given the fields question, summary_1, produce the fields query. GEPA Prompt Optimizer GEPA generates a complete system specification GEPA’s Optimized Prompt for Second-Hop of Multi-Hop QA System, GPT-4.1 Mini You will be given two input fields: question and summary_1. Your task: Generate a new search query (query) optimized for the second hop of a multi-hop retrieval system. • The original user question is typically complex and requires information from multiple documents to answer. • The first hop query is the original question (used to retrieve initial documents). • Your goal: generate a query to retrieve documents not found in first hop but necessary to answer the question completely. Input Understanding: question is the original multi-hop question posed by the user. summary_1 is a concise summary of information from a document retrieved in the first hop, which partially addresses the question. Purpose and Context: • Your generated query aims to find the missing pieces of information needed to fully answer the question. … • The query must retrieve relevant documents NOT found in first hop … for final answer extraction. Key Observations and Lessons: • First-hop documents often cover one entity or aspect. • Remaining relevant documents often involve connected or higher-level concepts mentioned in summary_1 but not explicitly asked in the original question. The query should target these missing, but logically linked, documents. • Avoid merely paraphrasing the original question or restating known facts from summary_1. • Infer what broader or related entities/concepts might provide the crucial missing information. • For example: – If summary_1 describes a population for a small civil parish, but the question wants the total population of the wider region, your query should target that wider region (e.g., “Madeira archipelago population in 2011”). – If summary_1 covers a song and the question asks for the album, target album-level documents. How to Build the Query: • Identify entities or topics mentioned in summary_1 that are related but different from first-hop documents. • Reframe the query to explicitly mention these broader or related entities connected to the original question. • Include relevant key context from the question to maintain specificity, but shift focus to the missing piece. • The goal is to retrieve documents that link or complement what was retrieved initially. Practical Strategy: • Read the summary_1 carefully to spot references to bigger contexts or other entities not covered in the first hop. • Ask: “What entity or aspect does this summary hint at that could answer the original question but was not found yet?” • Formulate a precise, focused factual query targeting that entity or concept to retrieve the missing documents. Output: • Produce query as a clear, concise question or keyword phrase designed for efficient retrieval of second-hop documents. • Ensure the query relates logically to the original question while targeting the broader or complementary knowledge identified in summary_1. … Do not include the original question or simply rephrase it. Do not duplicate information already well-covered by the first hop retrieval … Interface text: CC
- 5:39
And what does Japa learn? Unlike prior
- 5:42
prompt optimizers somewhat which would
- 5:44
uh uh use model idiosyncrasies like my
- 5:48
grandmother will be really angry if you
- 5:50
don't generate a good prompt. Here Jpa
- 5:53
is actually giving a very detailed
- 5:55
problem specification which includes how
- 5:57
to make sense of the input. What is the
- 6:00
purpose and context of this particular
- 6:02
pip part of the pipeline? What are some
- 6:04
key observations and lessons from the
- 6:06
data? So the prompt we are seeing here
- 6:08
is for the second hop of a multihop
- 6:11
question answering system where given a
- 6:13
question we need to retrieve some
- 6:15
documents that could potentially answer
- 6:16
that question. Look at those documents
- 6:18
summarize it and then finally answer the
- 6:20
question. And here what we see is Japa
- 6:22
has found out that first hop documents
- 6:24
that often cover one entity or aspect
- 6:28
and the second hop should actually be uh
- 6:31
recovering documents that are related to
- 6:32
it. We have seen that human engineering
- 6:35
teams whenever a new model comes out
- 6:37
spend weeks of their time manually
- 6:40
tweaking one word here and there trying
- 6:43
to discover the problem specification.
- 6:45
This entire process is fully automated
- 6:48
now with Japa which takes about half an
- 6:50
hour to 1 hour to run depending on your
- 6:53
uh pipelines.
GEPA on GPT-4.1-mini: Math
On LiveBench Math, GEPA-optimized GPT-4.1-mini outperforms GPT-4.1. The accompanying prompt spells out answer formats and guidance for exact values, geometry and notation.
Text in image
GEPA on GPT-4.1-mini: Math LiveBench Math Y-axis ticks: 55%, 56%, 57%, 58%, 59%, 60%, 61%, 62%, 63%, 64%, 65% Legend: GPT-4.1-mini; GPT-4.1-mini GEPA; GPT-4.1 You will be given a mathematical problem to solve. Your task is to provide a detailed, step-by-step solution that clearly explains your reasoning, including any substitutions, assumptions, known results, or algebraic manipulations. This reasoning should be thorough enough to validate correctness and allow easy parsing. Important domain-specific details and formatting rules you must strictly follow: 1. Final Answer Formatting - If the question presents multiple-choice options labeled by letters (e.g., (A), (B), (C), etc.), and explicitly asks you to pick an answer letter, then after determining the correct choice, respond by writing that letter repeated exactly five times consecutively in a single string (e.g., "AAAAA" if the answer is A). - If the question asks for a numeric or symbolic expression to be enclosed in a box, present your exact final numeric or symbolic answer within LaTeX \(\boxed{}\) notation without decimal approximations. For example, write \(\boxed{42}\) or \(\boxed{\frac{1674}{7}}\). 2. Exact Values and Fractions Whenever computing numeric quantities such as means, variances, or simplifying expressions, avoid decimal approximations. Use exact or fractional forms to maintain precision and ease of parsing. 3. Geometry Problems Involving Tangent Circles - When the problem involves circles tangent to each other or to lines (such as Apollonius circle problems or Soddy circle problems), apply relevant theorems like the Descartes Circle Theorem (Soddy's formula) carefully, paying close attention to sign conventions and curvatures. 4. Polynomial and Trigonometric Identities - Be prepared to recall or derive polynomial expansions or trigonometric identities, for example expansions of \(\tan(nx)\), binomial expansions involving complex numbers, or identities involving coefficients depending on parity to extract particular terms. 5. Expression and Variable Consistency - Use consistent and clear notation, especially when dealing with coordinates (often homogenized coordinates for points in projective geometry), roots, factorization, or parametric forms. 6. Solution Style - Do not enclose your solution reasoning inside any special tags; instead, present your reasoning plainly followed immediately by your final answer. - If unsure of the final numeric value, make a best-educated guess consistent with problem context, clearly marking the final answer according to formatting rules. Interface text: CC- 6:56
We can also apply Japa to leading
- 6:58
proprietary models. Just for an example
- 7:01
here we were able to optimize GPT 4.1
- 7:04
minis performance to outperform GPT 4.1
- 7:08
on a math task and we can see the kind
- 7:10
of information distillation JPA has done
- 7:13
in the prompt space itself. Coming back
- 7:16
to the problem of sample efficiency, AMD
- 7:19
developed a new hardware accelerator
- 7:21
called NPU XDNA2 which had used a
- 7:24
completely new API to program which had
- 7:27
almost zero available information over
- 7:29
on the internet and because of this uh
- 7:32
the leading models at the time which was
- 7:34
GPT4 was failing miserably to perform
- 7:37
this task. We are able to take an
- 7:39
existing agent which was getting 4.25%
- 7:41
25% on this task and apply Japa without
- 7:45
any other change to the agent itself and
- 7:47
we got this prompt and pushed this
- 7:49
performance 7x to 30.52%.
- 7:53
So what this is uh what this goes to say
- 7:55
is there can be lots of domain specific
- 7:57
information which if you include in your
- 8:00
AI systems prompts the models could
- 8:02
actually perform much better and JPA can
- 8:04
help you fully automatically discover
- 8:07
that. I want to highlight the sentence
- 8:09
saying avoid including ADF.h H. Now the
- 8:11
interesting thing is AMD actually ships
- 8:13
a library called ADF.h for programming
- 8:15
NPUs but that did not work with this
- 8:18
latest uh generation of hardware that we
- 8:21
were working with and Jeppo was able to
- 8:22
discover that in just one step. So how
- 8:26
does it work? It's an extremely simple
- 8:28
algorithm which simply takes your AI
- 8:30
pipeline written in any agentic
- 8:32
framework or even raw LLM calls that you
- 8:34
may have. It simply runs your systems on
- 8:37
a few examples and collects domain
- 8:39
specific feedback. whatever information
- 8:41
your environment contains is observed.
- 8:44
Second, it runs reflection with an LLM
- 8:46
or agent that reads the feedback and
- 8:49
proposes a better prompt. Finally, and
- 8:51
most importantly, it keeps a parto pool
- 8:54
where it keeps every single candidate
- 8:56
that wins on even one training example
- 8:59
and not just the top scorer. The
- 9:01
question is, but why keep a parto pool?
- 9:04
And we kept getting asked this question
- 9:06
a lot that is Jepper really better than
- 9:09
running the model in a loop. So we went
- 9:11
and tested it out and what happens is a
- 9:13
loop keeps only the best and gets stuck
- 9:16
in a local optima. So on the left hand
- 9:18
side you see a search tree that was
- 9:20
generated by using an LLM in a loop
- 9:23
starting from a seed prompt at the top
- 9:25
left where um we asked the LLM to
- 9:28
improve the prompt. It improved the
- 9:30
prompt and it generated a prompt that
- 9:32
gave us the middle node. However, this
- 9:34
prompt got stuck in a local optima and
- 9:36
once again when we asked the LLM to try
- 9:39
and improve it, it proposed something
- 9:40
but that was not actually better. So, it
- 9:42
went back and it again tried to improve
- 9:44
it and it kept doing this and it
- 9:46
exhausted all of the search budget. On
- 9:48
the other hand, with Japa's parto based
- 9:50
candidate selection strategy on the
- 9:51
right, we can see that it maintains a
- 9:53
much more balanced search process
- 9:56
eventually converging to a much higher
- 9:58
score. Across four benchmarks, we saw
- 10:00
that more than half of the gains seen
- 10:03
with Japa actually account for this and
- 10:05
it gets almost twice the performance
- 10:07
gains that you would get with just
- 10:09
applying the model in a loop.
- 10:11
Japa can perform really well across
- 10:13
diverse benchmarks. Here we see results
- 10:15
on question answering, instruction
- 10:17
following, claim verification as well as
- 10:19
math which all the leading frontier
- 10:21
model companies are already optimizing
- 10:23
their models a lot for and we are still
- 10:25
able to get plus 10% just by optimizing
- 10:28
the prompt on it. So we have so far seen
- 10:32
Japa only optimizing the prompts but
- 10:34
Japa goes far beyond prompts. And
- 10:36
because prompts are just text artifacts
- 10:38
that determine AI system behavior, the
- 10:41
same algorithm can improve anything that
- 10:43
you can express as a piece of text and
- 10:46
you can score. For example, your entire
- 10:49
agent harness is eventually just a
- 10:50
Python or a JavaScript file and we can
- 10:53
apply the same kind of reflective
- 10:55
optimization process to that entire file
- 10:57
and we can work with it. So if you can
- 11:00
write it as text and score it, JPA can
- 11:02
optimize it. So with that insight in
- 11:05
mind, we propose optimize anything which
- 11:07
is a universal API for optimizing any
- 11:10
text parameter given any domain like
- 11:14
code optimization where let's say you
- 11:15
want to optimize the CUDA kernel code.
- 11:17
The input is just that CUDA kernel code
- 11:20
where an evaluator looks at this piece
- 11:22
of code, maybe compiles it, profiles it,
- 11:25
generates a bunch of related information
- 11:27
that we call as actionable side
- 11:28
information which is then provided to an
- 11:31
LLM which proposes an better candidate
- 11:34
maintaining this parto and it keeps the
- 11:36
uh repeating this process um till we get
- 11:39
convergence. The same thing can be
- 11:41
applied to numeric optimization where
- 11:42
your numbers can actually be serialized
- 11:44
as text or harness optimization where an
- 11:46
entire harness can be serialized as text
- 11:49
or even cloud scheduling policy
- 11:51
optimization where the scheduling policy
- 11:53
or heristic algorithm can be expressed
- 11:55
as a piece of text and the evaluator can
- 11:58
be something like the negative of cost
- 11:59
or some function measuring accuracy uh
- 12:02
efficiency and the actionable side
- 12:04
information can be something like job
- 12:05
traces SLA violations and so on.
- 12:09
The API is dead simple to use. All it
- 12:12
requires is you give us the set of
- 12:14
problems that you care to be solved
- 12:16
along with an evaluator function or a
- 12:18
fitness function that returns a score
- 12:20
along with any available domain specific
- 12:23
side information. If your domain
- 12:25
produces expert feedback, return that.
- 12:27
If your domain produces compiler error
- 12:29
messages, profiler messages, tool call
- 12:31
error messages, return that. If you have
- 12:33
maybe a written up documentation, return
- 12:36
that. any kind of it's a very open-ended
- 12:38
dictionary. You can return literally
- 12:40
anything and all you do is you call
- 12:42
optimize anything with this fitness
- 12:44
function and the set of problems that
- 12:46
you have and optimize anything will sort
- 12:48
of take care of it um and give you a
- 12:51
optimized solution. Let's see some
- 12:52
applications. Let's say you were tasked
- 12:55
with generating a 3D unicorn. This is
- 12:58
all the code that you would write or
- 13:00
your agent can now write it because we
- 13:02
have seen that optimize anything is a
- 13:04
very easy to use API for leading agents
- 13:06
like plot code. So all you do is write
- 13:09
this code which says optimize a Python
- 13:11
program to generate a 3D unicorn. Um and
- 13:14
the candidate is a Python script that
- 13:15
produces a PNG rendering whatever and
- 13:19
here is the result. On the left hand
- 13:20
side we can see claude opus 4.6. If you
- 13:23
gave it this task, this is what it
- 13:25
generated. And on the right hand side,
- 13:27
what what we the unicorn that we get
- 13:29
with optimize anything. This just for
- 13:32
fun. But let's say you were tasked with
- 13:35
writing an agent to solve a specific
- 13:38
task. Typically teams spend lots and
- 13:41
lots of time tweaking their agents,
- 13:42
building tools for it, writing tool
- 13:44
descriptions, uh carefully orchestrating
- 13:47
the control flow and so on. Here we
- 13:49
started with a simple four-line Python
- 13:51
program that was simply calling a
- 13:53
model's uh chain of thought to solve an
- 13:56
RKGI problem. Within just 16 rounds of
- 13:59
reflection, JEPA within optimize
- 14:01
anything was able to find this
- 14:04
sophisticated sixstep agent that took
- 14:07
RKGI accuracy on RKGI uh that took RKGI
- 14:10
accuracy of Gemini flash from 32.5% to
- 14:15
89.5%. And we can see that this agent is
- 14:18
automatic like by itself doing rule
- 14:20
hypothesis induction code synthesis. It
- 14:22
executes and traces the code
- 14:24
automatically debugs this code goes back
- 14:26
and proposes new versions of that code.
- 14:28
And finally it runs it on the actual
- 14:31
test inputs and returns the output. This
- 14:33
is a runnable example. You can go to
- 14:35
this QR code and you can run this
- 14:36
example right now.
- 14:40
So um applying the same uh uh like
- 14:43
approach of discovering agent harnesses
- 14:46
to math 500 we are able to push its
- 14:48
accuracy of GPT 4.1 nano by 20% by
- 14:52
simply creating a two-step agent and
- 14:54
again I want to emphasize that all we
- 14:56
did is we asked optimize anything to
- 14:59
optimize an agent file and it was
- 15:01
automatically discovering the
- 15:03
sophisticated agent architecture and we
- 15:04
did not have to do anything other than
- 15:06
specifying the objective and the task.
- 15:10
Finally, every single one of us is using
- 15:12
uh some coding agent like cloud code or
- 15:15
codex or maybe your favorite agent and
- 15:18
agent skills has become a very leading
- 15:20
part of the ecosystem where almost all
- 15:22
coding agents understand skills. Let's
- 15:24
say you want to optimize skills for your
- 15:27
specific repository. This is the code
- 15:29
that you write which says learn a skill
- 15:31
from the trajectory. When the coding
- 15:33
agent is presented with similar problem,
- 15:35
the skill should be helpful. We just
- 15:37
gave it this natural language behavior.
- 15:39
And what we see is we started with
- 15:41
minisu agent with GPT5 mini because we
- 15:44
were very budget constrainted and we
- 15:46
were able to take its performance from
- 15:48
24% to 93%. An almost 3x jump on go
- 15:53
repository issue resolution but more
- 15:56
importantly the skills that were
- 15:57
optimized very cheaply on a GPT5 mini
- 16:00
agent we are able to take that and apply
- 16:02
to the latest claude sonnet. This was
- 16:04
done of uh about a few months back but
- 16:06
we applied it to clots onet 4.5 pushing
- 16:09
its accuracy to 100% issue resolution
- 16:12
while more importantly cutting down the
- 16:14
execution time or issue resolution time
- 16:17
by almost 50%. We cut it down into half
- 16:20
which also means it spent less tokens
- 16:22
because skills contain information about
- 16:25
how the repository is organized, how to
- 16:27
invoke the test cases, where a
- 16:29
particular feature is implemented, um
- 16:32
what are the build system used by this
- 16:33
repository and so on. This is a a
- 16:37
feature called GSkill. You can find it
- 16:39
in the JPA repository and it's fully
- 16:40
open source as well. So, optimize
- 16:43
anything is a single uh interface that
- 16:45
provides three optimization modes. If
- 16:47
you have just a single problem like
- 16:48
there is a single matrix multiplication
- 16:50
kernel that you want to optimize you can
- 16:52
use it that way. If you have any number
- 16:54
of related problems like you want to
- 16:55
optimize a matrix multiplication kernel
- 16:57
along with a dot product kernel and you
- 16:59
know there might be some information
- 17:00
transfer between these two you can use
- 17:02
what we call as the multitask search
- 17:04
mode and finally build a skill which is
- 17:07
if you want to optimize on a set number
- 17:09
of problems but your uh deployment can
- 17:12
actually come up with many new problems.
- 17:14
So like uh in case of math op like in
- 17:16
case of math prompt optimization we are
- 17:19
training on some examples but when we
- 17:21
deploy it we can receive a completely
- 17:22
new kind of query. So we care about
- 17:24
generalization mode. So there you can do
- 17:26
prompt optimization agent architecture
- 17:28
optimization and so on.
- 17:30
So optimize anything is can be used for
- 17:34
a broad set of domains including cloud
- 17:36
scheduling policy optimization where we
- 17:38
were able to cut costs by almost 40%
- 17:41
compared to expert huristics write
- 17:44
custom solvers to match and exceed
- 17:45
Optina even in blackbox mathematical
- 17:47
optimization create agent skills prompt
- 17:50
optimization and so on. It is so easy to
- 17:53
use that within just 20 hours of
- 17:55
releasing it, people at Snorkel had
- 17:58
already improved some of their internal
- 17:59
benchmarks with it and were tweeting
- 18:01
about it. So, and Japa also improves
- 18:04
multimodel VLM models performance. Here
- 18:06
we are able to cut OCR error rates for
- 18:09
leading models by almost 35%. And this
- 18:12
is an externally validated report. Um,
- 18:14
similar similarly, data bricks actually
- 18:17
achieved 90x cost reduction in their
- 18:20
deployed agents performance. uh uh
- 18:22
performance and here they were able to
- 18:24
tune GPT OSS 120B to outperform Claude
- 18:28
Opus while being 90x cheaper. More
- 18:31
importantly, the performance delta
- 18:32
improvement that you see on top of
- 18:34
Claude Opus is actually bigger than the
- 18:36
one you see on open source models. Some
- 18:39
people have asked me that oh as models
- 18:41
get better the importance of prompt
- 18:42
optimization will go down. I argue the
- 18:45
opposite which is as models get better
- 18:48
they will get better at instruction
- 18:49
following and the more precise
- 18:51
instruction about your task that you
- 18:53
have to give to a very smart model the
- 18:55
better that model will be at a uh
- 18:58
solving your task and this is exactly
- 18:59
what we see happening here the better
- 19:01
the instruction was claopus actually
- 19:03
jumped much uh higher
- 19:07
some people have this question of uh
- 19:09
what if we have subjective tasks which
- 19:11
are very hard to evaluate jpa can
- 19:13
actually learn evals for your task from
- 19:15
production traces. The way to do that is
- 19:18
you collect a bunch of production traces
- 19:20
from your agent. Get a human to annotate
- 19:22
just about 50 of those trajectories
- 19:25
giving very detailed feedback. This is a
- 19:26
long response. This is a short response.
- 19:28
This is a good response. This uses this
- 19:30
terminology, whatever. And once you get
- 19:33
those human annotations, you can use JPA
- 19:35
to optimize an LLM as a judge prompt.
- 19:37
And you can use that LLM as a judge
- 19:39
prompt then to go back and optimize your
- 19:41
agent and deploy that agent. And this
- 19:43
becomes a data flywheel where you can
- 19:45
keep improving it. And this is a
- 19:47
successful paradigm that uh some leading
- 19:49
teams in production are already using.
- 19:51
Then the question we get asked is like
- 19:53
can we actually use this uh reflective
- 19:56
optimization to train models and we
- 19:58
recently had this paper called learning
- 20:00
fast and slow where we propose fast slow
- 20:03
learning where we can co-optimize model
- 20:05
weights and prompt harnesses and this
- 20:07
shows some very strong properties that
- 20:09
one would want in a continual learning
- 20:11
algorithm. Um I don't have much time to
- 20:13
go over details but please uh look at
- 20:15
the uh papers and
- 20:19
uh since uh since release Japa has been
- 20:22
used in production by these companies as
- 20:24
well as the main methodology in these
- 20:26
papers and here the CEO of Dropbox and
- 20:29
Shopify are talking about their use of
- 20:31
Japa and OpenAI also wrote a blog post
- 20:33
about how you can build self-improving
- 20:36
AI systems with Japa. Um so it's very
- 20:39
simple to get started. It can plug into
- 20:41
any framework, any model and it has
- 20:44
absolutely zero hard dependencies. So
- 20:46
you can deploy it any in any kind of
- 20:48
setting. So um don't be afraid to
- 20:51
optimize in the tech space and many
- 20:54
problems can be framed as optimization.
- 20:55
So bring actionable side information and
- 20:58
surface as much domain specific
- 21:00
information as you can to optimizers and
- 21:02
the optimizers of future will be able to
- 21:04
work with them. So please go and check
- 21:07
it out. Thank you very much.