Perplexity is experimenting with a different way to improve its Computer agent: instead of learning only from sessions that end successfully, it is training on the moments inside real user sessions where people correct the agent and where its tools fail. The goal is to preserve useful behavior without teaching the model to imitate every intermediate action merely because the final result happened to be acceptable.
The method is described in Perplexity Research’s official September 21 report, “Learning from Real-World Mistakes.” This is a research and post-training result rather than a newly announced consumer rollout. Perplexity says it applies the technique after reinforcement learning in synthetic environments to close some of the gap between controlled training tasks and the messy conditions agents encounter in real use.
The central insight is simple but important for search and computer-use agents: a successful final answer does not prove that every action taken along the way was good. An agent can issue a bad tool call, misunderstand a data structure or miss a user requirement, then recover later and still complete the task. Training indiscriminately on that successful trajectory risks reinforcing the mistake along with the recovery.
A successful task can contain bad behavior
One common way to learn from real-world agent sessions is rejection-sampling fine-tuning. The system judges the final outcome, keeps successful sessions and trains the model to imitate them.
That works when success is a reliable proxy for the quality of every step, but long-running agents violate that assumption. A task can contain dozens of searches, tool calls, code executions and intermediate decisions. Some may be unnecessary or wrong even if the final delivery satisfies the user.
Perplexity argues that blindly imitating the entire successful trajectory can therefore preserve avoidable errors. The inverse problem also exists: throwing away unsuccessful sessions discards evidence about precisely the situations where the model needs improvement.
The company’s method attempts to extract useful supervision from both kinds of sessions rather than reducing each interaction to a single success-or-failure label.
User corrections reveal what the agent misunderstood
Real users naturally generate a signal that synthetic benchmarks struggle to reproduce: they tell the agent when it got something wrong.
A follow-up such as a correction, clarification or expression of dissatisfaction can identify a requirement the model missed earlier in the task. Perplexity says these high-intent follow-ups are particularly valuable because the user is actively trying to complete the assignment and the correction can pinpoint the mismatch between the requested result and the agent’s behavior.
The training pipeline includes a user-feedback group containing sessions with a genuine user follow-up or a medium-to-high dissatisfaction flag. Rather than simply using the eventual outcome, Perplexity examines these signals to locate potentially avoidable mistakes within the trajectory.
This turns user correction from a conversational repair mechanism into a possible training signal. The ambition is not merely to make the agent better at recovering after someone complains, but to reduce the probability that the same correction will be necessary in the future.
Tool errors provide a second source of supervision
The other signal comes from tools themselves. Agents operating browsers, code environments, APIs and connected applications regularly receive structured failures that reveal exactly where an attempted action broke down.
Perplexity’s tool-error sampling group contains sessions with failed calls identified by rule-based checks. The pipeline excludes recognized infrastructure failures and situations where authorization was declined, focusing instead on errors that may reflect something the model could reasonably have avoided.
The research paper gives an illustrative coding example. The model first performs a valid search, then incorrectly treats a returned list as if it were a dictionary. The code tool responds with a type error. Because the tool’s return structure was already documented in context, Perplexity treats the mistake as potentially correctable rather than as an unpredictable environmental failure.
This distinction matters. An agent should not be penalized for an external service outage it could not anticipate, but it can learn from a malformed call when the information needed to make the correct call was already available.
Perplexity generates grounded hints for the mistake
Once a potentially avoidable error has been identified, Perplexity creates a short corrective hint. The hint must be grounded in information the model already had at the moment the mistake occurred.
That constraint is important because training should not teach the agent to rely on hindsight that was unavailable during the original decision. A correction based on information discovered only later would create an unrealistic target.
The hint instead makes explicit the relevant evidence already present in context. A teacher model then produces token probabilities conditioned on that corrective guidance, while the student is trained toward the improved behavior through a KL-divergence objective.
Perplexity calls the approach hint-guided self-distillation. It combines that correction mechanism with conventional cross-entropy imitation of useful behavior from sessions whose final outcomes were judged successful.
The model learns what to preserve and what to change
The resulting training signal is more granular than treating an entire session as good or bad. Useful recorded actions from successful sessions can remain imitation targets, while specific mistakes can become correction targets.
An unsuccessful session can still be valuable if it contains a clearly identifiable mistake with a grounded correction. Conversely, a successful session does not receive a blanket endorsement for every step it contains.
This is particularly well suited to agents because agent trajectories are heterogeneous. One session can contain good searches, a bad code call, a successful recovery and a correct final report. A single outcome label loses that internal structure.
Perplexity’s method attempts to preserve it.
The data comes from real Perplexity Computer sessions
Perplexity says its sampling pipeline draws from a training-eligible subset of real-world Computer sessions served by GLM 5.2. Before selecting examples for this workflow, the company applies users’ training choices and PII-related exclusions.
The research states that sessions containing personally identifiable information are excluded and that sessions from users who opted out of having their data used for training are also excluded. This is an important qualification because the method depends specifically on real product interactions rather than purely synthetic trajectories.
The initial screening also selects sessions that an LLM judge rates four or five on a five-point task-difficulty scale. Perplexity then separates candidates into user-feedback and tool-error groups before additional outcome evaluation.
Two LLM judges independently assess the final delivery against the user’s request, and both must return a positive verdict before the session is labeled successful. Sessions judged incomplete, such as tasks still waiting for the user, are excluded.
Real-world sessions contain failures synthetic environments miss
Synthetic training environments remain useful because developers can create controlled tasks with outcomes that are relatively easy to verify. The limitation is coverage: designers have to anticipate the scenario they want the model to practice.
Real users do not respect that boundary. They combine unusual instructions, files, tools, constraints and follow-up requests in ways benchmark designers may never have written down. Sessions can also unfold over multiple turns rather than ending after a single prompt.
That makes production interactions valuable not merely because there are many of them, but because their distribution is different. User corrections expose requirements the model failed to infer, while tool errors expose mismatches between what the agent attempted and what the real environment actually accepts.
Perplexity positions this post-training stage as a complement to synthetic reinforcement learning rather than a replacement for it.
The research is especially relevant to search agents
Search agents perform long chains of actions whose quality is difficult to judge from the final answer alone. An agent can search the wrong phrase, inspect a weak source, recover with a better query and ultimately cite the right evidence.
If training rewards only the successful outcome, the initial bad search can survive as part of the behavior being imitated. If the system can identify that intermediate decision as avoidable, it has a chance to improve the research process rather than only the final prose.
The same principle applies to source retrieval, browser actions and data extraction. A final answer can look correct while hiding unnecessary retries or fragile tool behavior underneath.
For AI search products, improving those intermediate steps can matter for latency, cost and reliability even when the visible answer would otherwise appear unchanged.
Perplexity reports a 21.2% reduction in tool-call failures
Perplexity says a later trained checkpoint reduced tool-call failures by 21.2% relative to an earlier trained checkpoint in live use. This is the strongest production result reported in the research.
The figure should be interpreted carefully. It is a relative comparison between Perplexity’s checkpoints under its own online testing, not an independent benchmark against competing agents. The company also explicitly says its online tests did not establish a reduction in user dissatisfaction.
That limitation is useful because it separates a measurable mechanical improvement from a broader claim about user experience. Fewer failed tool calls can make an agent more reliable without automatically proving that users perceive the final work as better.
Perplexity itself frames the goal as building an agent that needs correction less often, not simply one that can recover gracefully after a mistake.
Tool reliability and research quality are related but not identical
A search agent that calls tools more reliably has fewer opportunities to derail a workflow, but reliable execution does not guarantee good research judgment.
An agent can execute a perfectly valid search query that is strategically poor. It can retrieve a page successfully but choose a weak source. It can operate a browser without errors and still draw an unsupported conclusion.
The training signals described by Perplexity are therefore strongest when the mistake is identifiable from feedback or tool behavior. They do not solve every problem associated with source quality, reasoning or citation accuracy.
The broader value is that they add another layer of supervision to agent training: not only whether the task ended successfully, but where the trajectory showed evidence of a correctable failure.
User feedback becomes part of the model-development loop
The research also illustrates how the relationship between users and AI products is changing. A correction that once disappeared after fixing one conversation can potentially become evidence used to improve later checkpoints, subject to the company’s eligibility and privacy filters.
This creates a development loop grounded in real usage. Users expose edge cases, the system identifies avoidable mistakes, training turns those mistakes into corrective targets and a later model can be evaluated on whether the same class of failure occurs less often.
The value of that loop depends heavily on filtering. Not every user complaint means the model was wrong, and not every tool error was avoidable. Perplexity acknowledges that its judges can make mistakes and that fixing one turn does not guarantee successful completion of the entire task.
Real-world feedback is therefore noisy supervision, not ground truth.
Outcome-only benchmarks can hide fragile agent behavior
Perplexity’s work points to a larger evaluation problem in agentic AI. Benchmarks often score whether a task was completed, but two agents can reach the same successful outcome through very different trajectories.
One may solve the task cleanly with a small number of correct actions. Another may make several avoidable errors, consume more tokens, retry tools repeatedly and eventually recover. A binary success score can treat them as equivalent.
For production systems, they are not equivalent. The second agent costs more, takes longer and creates more opportunities for a failure from which it cannot recover.
Training and evaluating the trajectory itself can therefore expose reliability differences that final-answer scoring misses.
Privacy choices are part of the training architecture
Because this method depends on real sessions, data governance is not peripheral to the research design. Perplexity says training opt-outs and PII-related exclusions are applied before examples are selected for the workflow.
That means the usable training distribution is intentionally narrower than the complete set of Computer interactions. The company is trying to learn from real mistakes while respecting users who have declined training use and excluding sessions that trigger its personal-information filters.
No filtering system should be assumed perfect merely because it is documented, but the exclusion criteria are material to understanding what Perplexity says it trained on. The research does not claim unrestricted ingestion of every Computer conversation.
For enterprises evaluating agent products, this kind of documentation is increasingly relevant because post-training pipelines can matter as much as inference-time privacy controls.
The agent is learning from the path, not just the destination
The most interesting idea in Perplexity’s September 21 research is that agent training should not reduce a complex workflow to whether the final answer looked right.
A user correction identifies a moment when the system misunderstood the task. A failed tool call can identify a moment when the system misunderstood its environment. A successful action inside an otherwise failed session can still demonstrate behavior worth preserving.
Perplexity’s method attempts to separate those signals and use each appropriately: imitation for useful behavior, grounded corrective distillation for avoidable mistakes and final-outcome judgments for determining which completed trajectories deserve broader imitation.
The reported 21.2% reduction in tool-call failures suggests that this finer-grained supervision can improve at least one dimension of live agent reliability, while Perplexity’s own caveat about user dissatisfaction shows that the evidence does not yet justify broader claims.
For search agents, the direction is significant. The training target is moving beyond producing the right answer toward executing a cleaner research process. The moments when users say “that is not what I meant” and when a tool says “that call failed” are becoming part of the curriculum.