AI Engineer World's Fair 2026
User Signal Die at the Retrieval Boundary
Read the talk
Making Agent Retrieval Learn from Outcomes
An agent can reason, call tools, and finish a task without learning anything from the result. Outcome-aware retrieval connects reviewed runs to the context and skills used next time.
From a talk by Sonam Pankaj
Before you start: Basic familiarity with LLM tool calls, retrieval-augmented generation, and SQL queries will help you follow the examples.
What changes after an agent fails?
An agent finishes a task, and an evaluator marks the result wrong. What makes the next attempt any different? An LLM can have agency to reason, invoke tools, interact with the world, and retrieve memory without having a mechanism for learning from what worked or failed. That missing loop is the starting problem for Sonam Pankaj, who introduces herself as CEO and co-founder of Starlight Search.
Consider the ReAct execution pattern: a user supplies a prompt; the agent reasons, calls tools, retrieves information or searches, and repeats until the task is complete. The loop explains how an agent acts. It does not, by itself, explain how the outcome of one run changes the next run. Completing an execution loop is different from closing a learning loop.
Pankaj diagnoses repeated failures as partly a retrieval problem: the system keeps selecting context in the same way, even after that context has contributed to unsuccessful runs. She cites an 85% AI-project production failure rate, attributed to Gartner and a McKinsey 2025 report, and a 73% share of RAG pipeline failures attributed to retrieval rather than generation. Those figures lack verified study populations and measurement conditions here; they frame the motivation, rather than establish how often this mechanism causes failure. Context stuffing is the related problem: adding more retrieved material does not ensure that it helps the task.
The criticism echoes Ram Sriharsha’s post on broken agent memory: optimizing lookup speed and cost can make incorrect answers cheaper and faster without teaching retrieval which memories were useful. Retrieval needs a signal about outcomes, not only an efficient way to find similar text.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Getting evaluation signals out of the dashboard
The third problem is that agents are not outcome-informed. Observability can capture every tool call, LLM completion, and exception, yet those records need not influence subsequent execution. Together, static retrieval, context stuffing, and missing outcome feedback describe a system that can record its mistakes without adapting to them.
An evaluation suite adds a judgment—pass or fail—but that judgment may never reach the agent’s context, its SKILL.md files, or its next action. The missing layer consumes both traces and evaluations and converts them into retrieval guidance for future runs. Traces explain what happened; evaluations establish whether the result was acceptable; retrieval guidance makes that information available when a relevant task returns.
Without that connection, improvement becomes a manual engineering cycle: inspect the runs, rewrite prompts, redeploy, consider a more expensive model, restructure tools or the harness, or fine-tune a custom model. These interventions can change behavior, but an engineer must repeatedly translate observed failure into a system change.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Remembering preferences versus learning usefulness
Memory already sounds like the solution, but what the system remembers matters. User profiles, conversation history, extracted facts, and long-lived preferences support personalization. Remembering how someone likes to be addressed improves a chat experience; it does not necessarily teach an agent how to complete a production task. Pankaj names LangChain and Mem0 in this comparison, contrasting preference-oriented memory with the outcome-learning behavior she wants. This is a distinction between memory designs, rather than a complete assessment of those projects’ capabilities.
| Retrieval signal | What it helps select |
|---|---|
| Embedding similarity | Memories related to the current task |
| Similarity plus outcome utility | Related memories that have helped execution |
The proposed utility score reweights similarity according to how useful a memory has been for an agent’s task. Past traces and outcomes become part of selection, so two relevant memories need not receive equal priority if their execution histories differ.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Retrieve a lesson that changes the next action
Pankaj calls the proposed runtime layer Agent AgX, expanded as agents with runtime experience. Its intended role is to improve production agents through experience without pre-training, fine-tuning, or manual prompt engineering. She contrasts this with the compile-time approach she associates with DSPy: baking lessons into a prompt, versus adapting context while the agent executes tasks.
The retrieval decision combines semantic relevance to the current task with evidence that a memory historically helped or hurt execution. An evaluation outcome becomes a first-class reranking signal. It is no longer only feedback for someone reading a dashboard; it influences which guidance reaches the agent. The talk describes this weighting conceptually, without specifying an exact utility equation.
A refund request makes the distinction concrete. A fact-oriented memory might say that a user prefers a dark theme or a shorter name. A reasoning memory instead says to check settlement before issuing a refund, so the customer is not refunded twice. The useful memory carries a decision rule and its reason: inspect the relevant transaction state before taking the consequential action.
That lesson should enter context when the task calls for it. Reranking by usefulness and updating context according to the task are intended to avoid context stuffing: the goal is not to supply every remembered fact, but to supply the reasoning that can improve the current decision.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From individual memories to reusable skills
Pankaj introduces Reflect as the memory system evaluated on what she calls τ-bench, describing the task as following policy correctly. Pankaj reports τ-bench performance rising from 66% to 76% with Reflect without baked-in skills, and to 80% with skills. The recording does not establish the exact benchmark variant, scoring protocol, model configuration, or memory exposure, so the percentages are reported results rather than a reproducible comparison.
Skills provide a second destination for accumulated experience. After enough memories exist—Pankaj gives roughly ten as an example—the system can consolidate their reasoning into a skill that the agent consults. Instead of retrieving every individual lesson indefinitely, the agent can draw on a maintained piece of task guidance.
Consider a product SQL agent whose system prompt still mentions a column that is no longer available. That stale instruction can survive even as the agent repeatedly encounters the changed database. An updated skill can tell the agent not to use the obsolete column, and subsequent calls to the skill can expose the corrected guidance. This places some operational knowledge in an updateable artifact rather than leaving it fixed in the system prompt.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Reported gains and the limits of feedback
Pankaj says similar behavior appears with GPT-5.4, then broadens the discussion to agentic evaluation: reasoning, planning, and tool use over extended workflows, rather than only static question answering. She presents the following Humanity’s Last Exam comparison.
| Configuration | Speaker-reported score |
|---|---|
| Baseline | 35.7% |
| With RAG | 47.5% |
| With an unspecified memory system | 58.2% |
| With Reflect Memory System | 61.3% |
The model, tool access, evaluation subset, and memory protocol for these scores are not established in the recording. Pankaj also cites similar trends on BigCodeBench and a benchmark named LifeLongTV in the transcript, without giving numerical results for them.
Outcome-based retrieval introduces its own dependencies:
- Cold start: Retrieval begins as pure semantic search until enough reviews accumulate.
- Utility drift: Usefulness can drift, and similar memories can recur in retrieval.
- Review quality: Noisy outcome labels make the utility signal noisy.
- Reranking control: A hyperparameter, λ, is associated with credit and reranking.
Pankaj says Reflect reduces most of these problems, but gives no detailed mitigation procedure and identifies cold start as the remaining constraint. The system cannot use a history of reviewed outcomes before that history exists.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A product search with no memories
The live demonstration uses an agent that searches a product catalog stored in a SQL database. Pankaj asks it to find a gaming mouse. The run retrieves zero memories and responds that it cannot find one. She opens the dashboard to inspect what happened. This is the cold-start situation described earlier: there is no retrieved experience to guide a different response when the search fails.
During the dashboard transition, Pankaj briefly returns to evaluation, naming AgentBench and again describing reasoning and planning across tool-using workflows. The demonstration then returns to the unsuccessful catalog search, where the next step is to supply a review of the run.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A failed search becomes guidance to broaden the query
The feedback changes what counts as an acceptable result. A wireless mouse exists in the database, so Pankaj marks the run as failed and supplies the instruction “Give any relevant.” The review is attached to the input, response, trajectory, and tool call; the initial product-search result is empty. The lesson is therefore more specific than a negative rating: when an exact product search fails, a relevant alternative may satisfy the request.
A later run finds a Wireless Mouse. The displayed trace contains the task “find me a gaming mouse” and a product response, with review status still pending. In the narration, however, Pankaj describes the later input as “mouse.” The visible result shows a relevant product being returned after feedback, but the query discrepancy and broadened acceptance criterion prevent treating this as a controlled, identical-query comparison.
Pankaj emphasizes the tool trajectory: the earlier run made a product-search call and received an empty result; the later run still uses the product-search tool but obtains a relevant answer. The tool itself need not be replaced for retrieved guidance to change how the agent uses it.
For a catalog represented by a products table with a name column, the SQL distinction can be expressed as a specific search followed, if empty, by a broader one:
sql
SELECT name
FROM products
WHERE LOWER(name) LIKE '%gaming mouse%';
-- If the first search is empty and alternatives are acceptable:
SELECT name
FROM products
WHERE LOWER(name) LIKE '%mouse%';
This illustrates the search lesson, rather than reproducing the dashboard’s exact SQL. A name such as Wireless Mouse matches the broader query. Returning it as a related product preserves the distinction between finding an alternative and establishing that it meets the original gaming requirement.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep the lesson, then maintain the skill
The memory card makes the resulting guidance visible: it records the failed gaming-mouse search, identifies the mistake, describes a corrective action, associates the lesson with the search tool, and recommends broadening a query when no results appear. This is the reasoning-memory pattern from the refund example, now attached to a concrete tool failure. Memories are retrieved according to utility, and that utility is reranked as evidence of usefulness accumulates.
The final step is to consolidate reviewed experience into a skill. Pankaj describes memory scores changing with reviews, then gives about five reviews as an example of when findings could be baked into a skill. Earlier she used about ten memories; these are illustrative counts, not an established fixed threshold. The later Project Skill view still shows an unmet review threshold, so the demonstration explains the path to publication without showing a completed skill update.
The durable change is guidance the agent can consult without rewriting its system prompt. Individual reviewed runs produce memories; usefulness affects which memories reach future tasks; accumulated lessons can become maintained skills. That is how an outcome can cross the retrieval boundary and influence what the agent does next.
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
Ram Sriharsha's post argues that agent retrieval needs to learn, beyond improving lookup speed and cost.
The original paper introducing interleaved reasoning and actions for language-model agents.
The original benchmark paper; its arXiv record includes subsequent revisions.
Further reading
An installable coding-agent skill for adding Reflect memory to Python agents across several frameworks.
Updates since the talk
Current documentation explains how traces and reviews create memories, update utility, and influence retrieval, with a worked refund example.
Read the complete timestamped transcript
- 0:01
Hey, everyone. I'm Suyim. I'm the CEO and co-founder of Starlight Search, and today my talk is, user signals die at retrieval boundary. So we'll look into, uh, what are agents, essentially why agent fails, what is, uh, the cause of fails in retrieval particularly, and how to make actually signals cross the retrieval boundary, and how to make your
- 0:25
agent basically outcome fair. So, uh, let's get started. So what is an agent? An agent is an LLM that has agency to reason, invoke tools, uh, interact with the real world, retrieve, uh, the memory to complete the task.
- 0:43
One major loop here is missing is, uh, learning. It should also learn from what worked and what it didn't work. Suppose, uh, if I have to, uh,
- 0:54
explain what is agent, I can explain with ReAct agent. So if I have to explain, uh, what agent is, I'll explain it with ReAct agent. So basically, user prompt the agent, uh, uh, execute it in a loop, uh, call tool, retrieval, search, and then pause when the task is complete.
- 1:14
This is very basic ReAct architecture. One thing that is missing is how to make agent learn from the outcome.
- 1:24
So agent keeps failing at the same task. Gartner reports that eighty-five percent of AI projects fail in production, and so does McKinsey's twenty-twenty-five report. The problem came out to be most of the time is that retrieval is static.
- 1:40
Seventy-three percent of, uh, RAG pipeline fails because of retrieval, not generation, and context stuffing. So a recent, uh, uh, post from Ram Sriharsha, the ex-CTO of Pinecone said, uh, "We have been optimizing for the wrong thing.
- 1:59
You are paying a lot for your agent's memory. It is probably broken, and we have been optimizing for the wrong things. We made wrong answers appear faster and cheaper that we forgot to make retrieval learn."
- 2:12
So why this is-- does, does, does it matter?
- 2:16
Again, uh, the third problem is agents are not outcome-informed. So there's a missing layer between evals and action. Your observability has all the traces, uh, all the stack that capture-- eh-uh, observability is the stack that capture every tool call, every LLM completion, every exceptions.
- 2:37
Your eval suite judges whether the final output was correct or wrong, basically pass or fail. But these evals are not reflected in agent, uh, context, skills, MD files, or agent action in any ways.
- 2:57
Right? So the agent doesn't have any access to why yesterday's runs, uh, runs passed or failed. Eval signal dies in the dashboard. This is a missing layer, a system that consume traces, absorb eval, and convert both into retrieval guidance for future runs.
- 3:17
So there's a manual improvement tax. An engineer actually has to sit and see if the eval and observability perform well, rewrite the prompt, redeploy it, upgrade-- either upgrade to expensive model, restructure tool or hardness, or fine-tune the custom models.
- 3:36
Why are current memories failing? Why-- Memories was designed to actually address this, but, uh, uh, it's not.
- 3:47
So let's see, uh, eh, what we have in-- as a current system, uh, and current memory is that they basically store user preferences, profile, conversational history, or long-lived personal-- personalization.
- 4:05
So chat experience is not self-improving learning systems for production. If you see, uh, the already existing approach in the, uh, market, there's, uh, uh, LangChain, uh, there's Memzero, which does extracted fact, preferences.
- 4:21
A user's retrieval signal is, uh, embedding similarity. Does it learn from outcome? No. Uh, so we have come up with something called utility score, which is a similarity we-weighted by how useful it is for the agent to execute the task.
- 4:41
It has actually the history of past traces and past outcomes.
- 4:47
So we came up with Agent AgX, and that is agents with runtime experience. It's a runtime, uh, layer that let production agent improve from experiences without pre-training, fine-tuning, or manual prompt engineering.
- 5:01
Ha-- It's a bit different from compile time like DSPy because, uh, you bake in all the lessons in the prompt. Here, it's actually improving, uh, while it is executing the task.
- 5:14
So let's, uh, again introduce this, uh, utility score. So you do not retrieve by keyword, you retrieve by semantic similarity to the current task, weighted by whether those memories have historically helped or hurt the execution or the outcome.
- 5:32
The eval outcome becomes a first-class signal in the retrieval re-ranking and not just for feedback.
- 5:41
One of the key things is it treat memory as reasoning, not as facts, statics fact with no context and no history, but reasoning. Like suppose, uh, if, uh, if there's a-- if there is a customer support bot looking for refund, it will not only say, "Hey, user prefers," uh, uh, uh-
- 6:06
Dark theme or user prefers, uh, be-- to be called by a shorter name. It's actually reason about a query, like, uh, if some-someone asks for refund, you should check the settlement, uh, before refunding it so that the, the, the customer doesn't get paid, uh, refund twice.
- 6:26
So ReAct based on usefulness. Context is updated based on tasks. So this is a very big thing, uh, because most of the agents fail with context stuffing, and this has been brought up in the past and learned from history and reasoning, right?
- 6:42
Talking about benchmarks. So, uh, we have benchmarked, uh, our memory system Reflect with-- on τ-bench, which essentially measure if agents have followed a policy well or not. So we have seen, uh, the, uh, uh, the performance improve from sixty-six to seventy-six percent without baking in, uh, skills.
- 7:05
And with skills, uh, Reflect performs at eighty. So, uh, once there are, uh, enough memory, like ten, uh, memories, uh, what we do is we bake in the, uh, reasoning and the understanding into skills so that your o-agent always remains updated.
- 7:24
What happens most of the time, we have seen, suppose you have a product SQL agent, and there's a system-- there's a column in system prompt. Even though that column is no useful anymore, it remains as the system prompt.
- 7:36
So there's no system right now that can update that, "Hey, there's no column, uh, right now called this, so maybe probably you shouldn't entertain it in the future." And this is possible with skills that, uh, because agents always uses, uh, calls that skill, uh, updated skill all the time.
- 7:58
And the similar behavior has been s- uh, seen in GPT-5.4. Uh, we have also benchmarked it on agentic tasks, which essentially test a model's ability to reason, plan, and use tools over extended multi-step workflows rather than measuring a static Q&A.
- 8:16
So you can see here, uh, with the, suppose the HumanLast exam, uh, with RAG, you get forty-seven point five. If it is starting from the baseline thirty-five point seven, uh, with the, uh, the memory system, it gets to fifty-eight point two, but with the Reflected Memory System, uh, it gets to sixty-one point three percent.
- 8:38
So this k- uh, this kind of trend is shown in another, uh, agentic benchmarks, uh, as well, like, uh, BigCodeBench, LifeLongTV, et cetera. So of course, there are limitations to this, uh, uh, to this approach.
- 8:56
First of all, there's a cold start. So in the beginning, it's pure semantic search until, uh, enough reviews have been accumulated. Um, there's a utility l-drift. Maybe sometimes, uh, similar memories could come up.
- 9:12
There are a lot of problems that could come at scale with this experience, but we have combat most of them. Uh, there's a u-review quality, so noisy labels can make the utility noisy as well.
- 9:25
And there is a hyperparameter called lambda that is associated with credit and re-ranking. So we have bu-built Reflect in such a way that most of these problems and most of these, uh, limits are now reduced, uh, except for cold start, which we cannot do much about it.
- 9:44
Uh, let's now get into the demo. So let's check this demo.
- 9:57
Um, so it's a-- basically a product SQL demo. Uh, I'll give-- ask it to search some product in a SQL database, and let's see if it is able to find it out.
- 10:25
So I gave it, "Find me a gaming mouse."
- 10:30
Zero memories retrieved. I couldn't find a gaming mouse. Uh, okay. So maybe let's just go and see what's happening in the dashboard.
- 10:43
Okay, it came out that... So coming on another benchmark that with the agent bench, which ess-essentially measures if agent has actually done the right reasoning, planning, and, uh, have followed.
- 11:09
Which essentially test a model's ability to reason, plan, and use tools over extended multi-step workflows rather than measuring a static Q&A. So you can see here, uh, with the, suppose the HumanLast exam, uh, with RAG, you get forty-seven point five.
- 11:28
If it is starting from the baseline thirty-five point seven, uh, with the, uh, the memory system, it gets to fifty-eight point two, but with the Reflected Memory System, uh, it gets to sixty-one point three percent.
- 11:41
So this k- uh, this kind of trend is shown in another, uh, agentic benchmarks, uh, as well, like, uh, BigCodeBench, LifeLongTV, et cetera.
- 11:56
Wait, let's check. Uh, it couldn't find-- I couldn't find any gaming mouse in the product catalog. So suppose I want to mark it fail and s-tell it
- 12:07
Give any relevant. Because there is, uh, there is a wireless, uh, mouse in the database, and I have submitted the failure. Uh, this was the input, this was the response.
- 12:25
I couldn't find any, and this was a trajectory and tool call it took. So you can see the product is empty
- 12:33
with this product or with this query. Let's, uh, let's check again what happens now.
- 12:48
Let's see now, now what happens. ID, uh...
- 13:05
So it searched a wireless mouse. Uh, let's see what happens in the dashboard now.
- 13:16
Finally, I gave it mouse was the input. The response was, "I found a product related to mouse," as we asked it to find any kind of relevant. Let-- But the most important thing is how the tool call evolved.
- 13:30
You can see that previously, uh, the tool calls, uh, or the trajectory, uh, used to look just with one search, that is search products, uh, it called, uh, and the product was empty.
- 13:45
Now, the trajectory has changed in production, and, uh, it found something in the product, and it- it's still calling search product tool call, but it is getting some answer that we fed in as a feedback.
- 14:02
So, uh, that's the demo, and the most important thing that is happening over here is it's forming memories, which is retrieved based on the utility score. That is the score which basically keeps improving-- uh, keeps re-ranking itself on the basis of how useful that memory was.
- 14:26
So, um... You can see from these traces, past traces which memory. Uh, so this memory scores keep changing, and after a certain while, after suppose a five reviews need, you can take in these findings or these, uh, new
- 14:50
updates in a skill without, uh, so without changing any system prompt, you can actually update certain things that agent, uh, uh, draws, uh, a lot from.
- 15:05
So, uh, uh, you can update the skill, which is very cool. So, uh, I hope everything was...
- 15:15
I hope you get to try, uh, this new, uh, feature, this new, uh, runtime experience that we have built.
- 15:26
If you want more details, you can visit our website, and, uh, you can also contact me if at [REDACTED:email_address] or visit me. Thank you.