← All AI Engineer talks

AI Engineer Code 2025

Agent Reinforcement Fine Tuning

Read the talk

Agent Reinforcement Fine-Tuning: Learning Better Tool Use

Agent RFT trains the decisions between tool calls, using task rewards to improve repository research, code changes and GPU kernels while reducing wasted work.

From a talk by Will Hang and Cathy Zhou

Before you start: Familiarity with model tool calls, training and evaluation datasets, and basic Python will help with the examples.

What makes a coding agent better?

How do you improve a coding agent that can already use a terminal but still struggles to complete your tasks? Start with what the agent actually does. A standalone model produces an answer; an agent interacts with an environment to get work done. For coding, that environment might expose a terminal, a code interpreter or an entire repository. Will Hang and Cathy Zhou, from OpenAI’s fine-tuning team, describe an architecture in which reasoning, tool calls and tool outputs share the same context window. Each tool result becomes information the agent can use to decide what to do next.

Agents slide showing a GPT-5 trajectory from input prompt through reasoning, tool calls and tool output to a final answer, with connections to a Tools box.
An agent trajectory interleaves reasoning with tool calls and outputs before reaching a final answer.

Codex illustrates the pattern: it can inspect a codebase, write unit tests and produce substantial code changes. Some capabilities appear as terminal commands; others are custom functions, such as a function that invokes a planning workflow. Improving this agent means improving the sequence of decisions that connects the initial task to a useful result, including which tools it calls and how it interprets their outputs.

0:220:26
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:22 · section reference included

From better prompts to learned tool use

There are several places to intervene before changing model weights.

InterventionWhat changes
Prompt optimizationInstructions that steer behavior
Task optimizationTask scope, guardrails and available tools
Fine-tuningThe model’s weights

Task optimization includes simplifying the job, adding guardrails, adding or removing tools, and changing tool behavior to make the environment easier to use. Fine-tuning comes after these improvements, when the task still has performance headroom.

Agent reinforcement fine-tuning, or Agent RFT, changes model weights according to a learning signal supplied by the developer. During training, the agent explores different ways of using tools to solve the task. In the customer-facing RFT beta described here, training can call tools through publicly hosted endpoints and invoke a custom reward endpoint after each completed rollout. A rollout is one attempted trajectory through the task, ending in an answer that can be graded. The consequential addition is that training can learn from interaction with the customer’s environment.

The target is a reasoning model that must act over multiple steps, not simply produce a better standalone response. Will reports successful training with as few as ten examples in unspecified cases. That illustrates possible sample efficiency, rather than establishing a minimum dataset size. He also describes improved task performance and lower latency as benefits of learning better tool use.

1:441:58
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

1:44 · section reference included

Adapt to the environment and penalize wasted calls

A business environment can differ substantially from the environments used to train a general model. This domain shift can show up as repeated tool calls or invalid tool inputs. Agent RFT lets the model explore the actual environment and learn both how to invoke its tools and how to reason over their outputs. Reward guides that exploration toward more successful trajectories.

The reward can also encode a tool-call budget. Penalizing trajectories that exceed the budget gives the model a reason to finish with fewer interactions. Will describes models learning to stay within that limit while preserving or exceeding their original task performance. The slide makes the rule concrete: a cutoff at ten tool calls gives trajectories reaching an eleventh call a reward of −1, while a trajectory that reaches a final answer receives 0.7. These are example reward assignments, not measured latency results.

Latency slide with three example trajectories above a dashed cutoff at 10 tool calls; two show tool call 11 and reward −1, while the third ends with a final answer and reward 0.7.
A ten-tool-call cutoff contrasts trajectories rewarded −1 with a final answer rewarded 0.7.
3:544:05
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

3:54 · section reference included

Grade the complete trajectory, then establish a baseline

Trajectory-level grading requires a way to connect external actions to the answer they produced. Each rollout receives a unique UUID, associated with every tool call made into the customer’s system. Customer infrastructure can use that identifier to maintain the trajectory’s state as it evolves. When the final answer arrives, the same association lets the grader evaluate it together with the accumulated context. The grading unit can therefore include what the agent did, rather than only what it said at the end.

Before starting training, establish whether the setup can support a meaningful improvement:

  1. Build training and evaluation datasets that closely match production traffic.
  2. Run the base model on those datasets to establish a baseline.
  3. Improve prompts and task design against that baseline.
  4. Use Agent RFT when those changes leave worthwhile performance gains to pursue.

This sequence also makes the customer examples easier to interpret: each selects a particular agent behavior and supplies an environment and reward suited to that behavior.

5:115:27
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

5:11 · section reference included

Cognition: select the right files, then search in parallel

Cognition applied Agent RFT to Devin’s code-edit planning phase. Before making edits, the agent inspects the repository with shell tools such as grep and file reads, then selects the files it intends to change. Cognition paired user queries with the files users actually modified and rewarded the agent using file-selection F1. Precision discourages selecting irrelevant files; recall discourages missing necessary ones. F1 balances the two.

A small Python grader captures this set-based reward. In this example, selecting src/auth.py and README.md when the reference files are src/auth.py and tests/test_auth.py gives one correct selection, one unnecessary selection and one omission.

python

def file_selection_f1(selected: set[str], expected: set[str]) -> float:
    if not selected and not expected:
        return 1.0
    return 2 * len(selected & expected) / (len(selected) + len(expected))

selected = {"src/auth.py", "README.md"}
expected = {"src/auth.py", "tests/test_auth.py"}
score = file_selection_f1(selected, expected)  # 0.5

The empty-set convention is explicit here; the central mechanism is that both extra files and missing files lower the reward.

Cognition also built a separate VM for each trajectory. That VM held the codebase, executed tool calls and graded the final answer. Isolation kept shell activity in one rollout from affecting another rollout’s environment.

Cathy reports a five-point improvement with approximately 100 training examples and a ten-point improvement with 1,000 examples. The reward was file-selection F1, but she does not explicitly identify the metric behind those reported improvement points. The practical lesson is that a small dataset can provide a useful start while additional high-quality examples can still materially improve behavior.

Cathy reports that planning fell from eight to ten steps before RFT to four steps afterward. Initially, the model alternated reasoning and tool calls. After training, it launched many tool calls in parallel at the first step, reducing sequential work before it could begin editing. For Devin, that shorter planning phase mattered because users wanted code changes to start appearing quickly.

6:527:08
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

6:52 · section reference included

Qodo: improve research and remove the long tail

Qodo’s code review system includes a deep research agent that answers developer questions about large repositories. Qodo trained GPT-5 to use repository search and retrieval tools, using approximately 1,000 authentic question-answer pairs from eight repositories. Its reward measured the recall of relevant facts the agent retrieved.

Cathy describes the quality improvement as 6%; the displayed results specify facts recall increasing from 0.68 to 0.74. That is a gain of 0.06 on the displayed recall scale. The slide also reports 10–15% fewer tool-call steps and 50% fewer output tokens to tools. These results describe Qodo’s repository-question setup; the token reduction is specifically for output sent to tools.

The distribution reveals a further benefit. Base GPT-5 occasionally exceeded 15 tool calls per sample; after RFT, Cathy reports that the long tail disappeared and the distribution centered around two to four calls. Those unusually long runs were slow and could produce inconsistent behavior. Cathy describes their removal as eliminating P95 long-tail cases, although no numerical P95 latency measurement is given. The production benefit is more predictable work per request alongside better fact retrieval.

Qodo slide listing facts recall increasing from 0.68 to 0.74, 10–15% fewer tool-call steps and 50% fewer output tokens to tools, alongside overlapping base and RFT histograms.
Qodo results pair improved facts recall and reduced tool use with a histogram comparing base and RFT tool-call counts.
8:559:07
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

8:55 · section reference included

Cosine: make correctness the gate

Cosine trained coding agents for large enterprise codebases with 30 tools, including file reads, keyword search, terminal sessions and browser sessions. Its early grading approach gave partial credit for attempts, but the model began optimizing style and tone instead of reliably producing working code. Cosine changed the reward so that final code had to pass tests before it could receive credit. Correctness became a prerequisite for reward.

A strict gate creates sparse rewards: many attempted solutions may receive zero. GPT-5 helped because it could already produce some successful samples. Cosine then increased batch size and compute to obtain more positive-reward samples and reduce the risk of batches containing nothing but failures. The training setup needed successful trajectories to learn from, not merely a precise definition of failure.

Once code was correct, a custom LLM judged style and tone, penalizing verbosity, emojis and unprofessional presentation. The grader also rewarded agents that validated their own work by running tests, inspecting terminal outputs and checking lint results before reporting success. These secondary signals refined a successful coding workflow without replacing the test-passing requirement.

Cathy reports state-of-the-art results across multiple benchmarks and a much faster agent, without naming the benchmarks or scores in the spoken explanation. Before training, some Cosine trajectories exceeded 100 messages; afterward, Cathy describes a tighter sequence without giving a final message count. As in the Qodo example, reducing extremely long trajectories was part of the improvement.

10:2610:51
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

10:26 · section reference included

Mako: reward fast kernels, not shortcuts

Mako’s task was to write highly performant GPU kernels. Training examples are scarce in this domain, especially for new hardware such as NVIDIA B200s. Cathy reports that Mako trained GPT-5 using approximately 100 PyTorch prompts. The attraction of RFT was that a useful reward could support learning without a large collection of example kernel solutions.

The reward itself needed repair. By inspecting early rollouts, Mako identified seven categories of reward hacking. The examples Cathy names are returning the reference code, returning no-op kernels and returning identity kernels. A judge LLM detected those categories and assigned zero reward. Static analysis using an abstract syntax tree supplied another check: generated kernels had to exist and actually be launched.

Only after these protections did the grader score correctness and real speedup against the PyTorch baseline. That order matters: a fast result is useful only if the agent performs the intended computation through the generated kernel. The slide groups the safeguards under a judge LLM and Kernel Reachability Analysis, alongside correctness and speed rewards.

MAKO GPU kernel building agent slide listing 100 PyTorch examples, correctness and speed rewards, a judge LLM evaluating seven hack categories, and Kernel Reachability Analysis.
MAKO combines 100 PyTorch examples with correctness and speed rewards and checks against reward hacking.

With the safeguards in place, Cathy reports that the trained agent substantially outperformed base GPT-5. Mako then generated three samples and selected the best. Cathy reports that selecting the best of three samples beat the state of the art by 72%. The talk does not name the benchmark, comparator or aggregation behind that percentage, so it remains an attributed result for this historical experiment.

12:4613:09
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

12:46 · section reference included

Make exploration produce a learnable signal

Will closes with four conditions for productive training. First, define a constrained task with an unambiguous meaning of success. Grading should not depend on subjective taste. Second, make training and evaluation data mirror production traffic, so the deployment environment does not reintroduce domain shift.

Third, check whether additional sampling exposes better solutions. For the same input, some rollouts should perform better than others, and the best observed performance should improve as more samples are drawn. That variation gives training something to learn: a distinction between good and bad ways of completing the same task. If exploration never finds a better result, the proposed setup offers little evidence of a useful learning signal.

Fourth, close reward-hacking loopholes and prefer continuous rewards where they faithfully measure progress. Will compares this to giving a student partial credit: intermediate scores can guide incremental improvement. Cosine’s experience supplies the necessary qualification. Partial credit is helpful when it rewards progress toward the actual objective; it is harmful when style or apparent effort can substitute for working code. A strict correctness gate and richer rewards for valid solutions can serve different parts of the same grading design.

At the time of the recording, the instruction for obtaining Agent RFT access was to contact an account director. That is historical access guidance: the current fine-tuning documentation now says the platform is winding down and is unavailable to new users.

14:4514:54
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

14:45 · section reference included

Resources

Updates since the talk

Read the complete timestamped transcript
  1. 0:00

    [on-hold music]

  2. 0:21

    Hey, everyone, I'm Will.

  3. 0:22

    And I'm Cathy, and we're on the fine-tuning team at OpenAI.

  4. 0:26

    And we're super excited to talk to you today about Agent RFT, the most powerful way to enhance the performance of your agents. So you're probably joining us today because you're building an agent for your business and you'd like to improve its performance.

  5. 0:39

    So let's first start by talking about what an agent actually is. What makes an agent different from a regular model is its ability to interact with the outside world to complete a task, to get things done on its own without having to go through you all the time.

  6. 0:52

    So this agent needs to have access to tools. For example, if you're building a coding agent, it's gotta have access to a terminal, a code interpreter, or maybe even an entire code base.

  7. 1:01

    But these agents aren't just blindly calling tools. They're reasoning at the same time. The way that we think about these agents is that their interactions with the outside world, such as tool calls, are interleaved with their reasoning traces in the same context window.

  8. 1:16

    So an example of an agent that we've built in-house using this paradigm is Codex. Codex is our flagship coding agent. It has access to a wide range of tools to complete coding tasks end to end, like writing unit tests or submitting large diffs to your code base that are hopefully correct.

  9. 1:33

    Um, some tools are exposed as terminal commands, and other tools are custom functions the model can call to invoke, say, a planning workflow. So now how do we make our agents better?

  10. 1:44

    We're all probably pretty familiar with, uh, frontline techniques to improve the performance of agents. For example, for starters, prompt engineering or prompt optimization. Prompting, you can steer model or agent behavior to align more with your preferences.

  11. 1:58

    But let's say you still wanna squeeze more juice out of your task, well, you can then turn to task optimization. You can simplify the task. You can add better guardrails around the task.

  12. 2:08

    You can add and subtract tools, or you can change tool behavior to work better for the agent. But let's say you still wanna squeeze even more juice out of that task.

  13. 2:18

    You've tried all these approaches, and you still want better performance. So that's where you would turn to fine-tuning. Fine-tuning is a way to train the a- agent end to end on your task to achieve even better performance by changing the weights of the model.

  14. 2:33

    And Agent Reinforcement Fine-Tuning, or Agent RFT, is the way to do this, or it's the way that we would like you all to do this. Um, Agent RFT changes the weights of the model according to a learning signal that you specify to teach the model what good behavior and what bad behavior looks like.

  15. 2:47

    And during training, the agent will explore many different ways of calling your tools to solve your task. So we've introduced several major new additions to the RFT product. Um, first off, the model can now call your tools via your endpoints that are hosted in the public internet, um, and after each rollout will also invoke your custom reward

  16. 3:07

    signal that's hosted via an endpoint. So these two additions actually mark the first time that we, we at OpenAI have allowed models to interact with the outside world during the training process.

  17. 3:18

    So I think this is pretty cool. To summarize the benefits of Agent RFT, it helps you improve the performance of your reasoning models, but more specifically, the reasoning models that have to call tools and interact with the outside world to get things done in a multi-step fashion.

  18. 3:35

    Agent RFT is also quite sample efficient. We've seen people get success from literally only using, like, ten examples, which is pretty amazing. We'll go over specific examples of this when we deep dive into some of our customer spotlights.

  19. 3:46

    And it results in a model that has lower latency and just works better for your tasks. So now let's dive a little bit deeper into how all this works.

  20. 3:54

    Uh, one of the challenges with making agents work with your specific business context is that your environment, your world, might just be different from how we train our models in-house.

  21. 4:05

    So this phenomenon in ML is called domain shift, and it can result in an agent that doesn't quite call your tools that, that well. Might call a tool too many times, or it might just straight up shove wrong inputs into your tools.

  22. 4:18

    Agent RFT can readapt the model to your domain through this weight changing training process that results in an agent that actually understands your environment, and this has some really nice properties, obviously, better ML performance.

  23. 4:32

    It trains the model to use tools better, and it trains the model to reason over the outputs of those tools better. All this is learned organically by the model while it explores the search space, all the possible ways of interacting with your environment and hill climbing on your reward.

  24. 4:48

    Another really nice property that results from this is the ability to achieve much lower latencies by making sure that the model stays within a given tool called budget and doesn't go over that limit.

  25. 4:58

    So we can actually impose this penalty that, you know, penalizes the model for going over that budget. What actually happens is the model learns to stay within that budget while preserving or exceeding the original ML performance.

  26. 5:11

    So to dive a little bit deeper into what happens at a systems level, uh, for each agent rollout, we'll produce this unique identifier that specifies that that's that particular rollout, and we will associate all the tool calls that we make into your system with that UUID.

  27. 5:27

    And so we do this for every tool call so that you can keep track of a trajectory as it evolves, so that when we emit that final answer at the very end, you can then associate that final answer with all the context that you've maintained so far, and you can just pass this whole thing as a holistic

  28. 5:42

    grading context into your grader. Now, we don't recommend everyone or anyone just use Agent RFT right off the bat. Uh, there's a process that we'd like you all to follow.

  29. 5:52

    You first wanna make sure that your training data set and your eval data set closely match your production traffic. You do not want any drift whatsoever. Then you want to ground yourself in a baseline.

  30. 6:02

    You wanna run your base model against these data sets so that you kind of understand what to expect performance-wise, so that you can then hill climb From there. And then you want to optimize performance using some of the techniques that we talked about prior, like prompt or task optimization, and only then, when you still feel like you've

  31. 6:21

    squeezed all the juice out of the task, but you still want more, more juice, you would turn to Agent RFT to push the frontier for your task. So now I'm gonna turn it over to Cathy to talk about how some of our partners have really pushed that frontier.

  32. 6:36

    Yeah, so now that we learned how Agent RFT works and how, when you should use it, I'll show you some coding-related examples of how our customers were able to use Agent RFT to make their agents better, and also highlight some key takeaways that you can apply when optimizing your own agents.

  33. 6:52

    So a few months ago, we partnered with Cognition, who use Agent RFT on their code-edit planning phase. This is the part where Devin inspects a repo and run sh- runs shell tools like rep and file reads to decide which exact files to edit.

  34. 7:08

    To train this behavior, they built a data set of user queries paired with actual files that s- that users has modified, and they used the F1 score of the selected files as the reward.

  35. 7:18

    This F1 score is really great because it balances between the pr- precision and the recall. So this ensures that the agent doesn't return too many inaccurate files or misses the critical ones.

  36. 7:31

    They also build extremely robust in- r- infrastructure to support this training. So in this case, for each individual trajectory, they spun up a, a VM to manage the code base, to execute the tool calls, and grade the final answer.

  37. 7:45

    These VMs make sure that the environment is isolated so that the shell tools will not affect each other in different rollouts. We saw two important takeaways from Cognition's use case.

  38. 7:57

    First, data quality and the volume really matters. So at first, they fine-tuned on a data set of around 100 examples and were able to get a five-point improvement. But when they scaled to 1,000 examples, the improvement jumped to 10 points.

  39. 8:12

    So the number of high-quality examples you provide can very directly translate to a better agent behavior. Second, we also learned that RFT is really good for learning to call tools in parallel.

  40. 8:26

    So in this case, the model would i- initially take eight to 10 steps, alternating between generating tokens in its reasoning to actually calling the tools. After RFT, the agent launches many tool calls in parallel at the very first step, so this was able to reduce that number down to four.

  41. 8:46

    And in this use case, the speed-up was especially important because they wanted Devin to start producing edits quickly.

  42. 8:55

    And now I wanna highlight a different use case. Kodo is building a code review agent, and a key piece of that is a deep research agent that answers developer questions on large code bases.

  43. 9:07

    To improve this deep research agent, they trained GPT-5 to answer coding questions by calling tools like search and retrieve over the repository. They assembled around 1,000 authentic question and answer pairs from eight different, uh, repositories and rewarded the model using the recall of how many relevant facts the agent were able to retrieve.

  44. 9:33

    With RFT, the agent improved by 6%, and it was using fewer tool calls and output tokens. And what we found most interesting is this graph, where it shows how RFT shifted the distribution of the number of tool calls.

  45. 9:49

    So with base GPT-5, the agent will occasionally fall into these bad runs, where there were more than 15 tool calls in a single sample. This is very slow and also can lead to some inconsistent behaviors.

  46. 10:02

    So after RFT, these tool calls that are very long tail, um, disappeared, and the, the sh- the distribution centered to just around two to four tool calls. In this setup, RFT didn't just improve, uh, accuracy, it also stabilized the agent's behavior in elimi- eliminating these P95 long-tail cases, and this is very important for production use cases where

  47. 10:26

    your latency will matter. Next, I wanna share how Cosine build coding agents for large and complex enterprise co- uh, enterprise cod- code bases with Agent RFT. To make this work, they trained the agent on a very comprehensive set of 30 tools, such as file read, keyword search, session terminal, browser sessions, et cetera.

  48. 10:51

    And they've also built a very strict grader. So they observed that the model, um, originally, when they were providing mo- the model with partial credits and ch- uh, points for just trying out things, um, it didn't get really good results because the model would start to optimize things on coding style and tone.

  49. 11:10

    Um, so at first, they want to really make sure the agent ships working code. And so based on that, they give the model the reward only when the final code passes the test.

  50. 11:22

    And because the grader is very strict, it can sometimes give sparse rewards. In that case, um, GPT-5 is also, like, is actually very great because it can give us some samples that work.

  51. 11:34

    So, um, Cosine also boosted the batch size, and they increased the amount of compute so that there is even more samples that can give us positive rewards. So it's not like every single sample in the batch would give us zero reward.

  52. 11:48

    Once the code is correct, um, they also have a custom LLM that would judge by the score and tone, so it will penalize verbosity, emojis, or anything that feels unprofessional.

  53. 11:59

    Finally, the grader will reward the agents that validate their own work, so this means running tests, inspecting terminal outputs, and also checking linting before calling out a success.

  54. 12:12

    And after training with this very thoughtful set of tools and graders, Cosine was able to reach the state of the art on a lot of different benchmarks over here, and they also got a match much faster agent.

  55. 12:27

    So like in earlier examples, RFT shifted this, this distribution of tool calls, and the agent stopped taking these extremely long trajectories. In this case, there was sometimes more than 100 messages in a single trajectory, and it converged to a much tighter and more efficient sequence of steps.

  56. 12:46

    Lastly, Maco is a very interesting use case. They're building agents that write high- highly performant GPU kernels, which is traditionally very hard for LLMs because in normal use cases there's a lot more examples, but in this case, there's not a lot of example for kernels, especially if you're using new hardware platforms like NVIDIA B200s.

  57. 13:09

    With Agent RFT, Maco trained GPT-5 to write fast kernels using only about 100 PyTorch prompts, and this was a major unlock. So we don't actually need that many samples and kernel data set in order to train a good model that produces kernels, and we just have to specify a good reward function.

  58. 13:31

    In this case, specifying a good reward function is also very hard. Early in training, they observed that the model was reward hacking. So what they did was that they inspected the rollouts, and they found seven different cases where the model was hacking, and this include things like just, uh, returning the reference code or returning no-op kernels or

  59. 13:53

    identity kernels. And they built a, a judge LLM to catch all of these seven cases and reward them with a zero. They also added a static analysis tool with a ab- abstract syntax tree to verify that the generated kernels actually exist, and they're actually being launched.

  60. 14:12

    So after the-- they made sure that there was no reward hacking, they also scored on correctness and real speed-up compared to the PyTorch baseline.

  61. 14:22

    Once all of these protections were in place, the agent got significantly better than GPT-5. And c- uh, Maco also used a really smart technique here to improve the performance even more.

  62. 14:33

    They ran three different samples, and they took the best one out of the three. This allowed them to beat the state of the art by 72%. And yeah, I'll hand it back to Will.

  63. 14:45

    Thanks a lot, Cathy. So, uh, now we want all of you, all of you in this room and beyond, to be as successful as the partners that Cathy just mentioned with Agent RFT.

  64. 14:54

    So here are four key principles to ensure your success. First of all, you wanna make sure that your task is well-defined, well-constrained. There should be a clear, unambiguous definition of success.

  65. 15:05

    You should have removed all subjectivity out of your task. Taste should not be a requirement to grade your task properly. Next, you do not want the model to feel surprised in production.

  66. 15:15

    You wanna make sure that your train and eval data sets mirror your production traffic. So no, none of that domain shift that we talked about. You do not wanna introduce that domain shift on your own.

  67. 15:24

    Um, next, and this is a really important part, you wanna make sure that through exploration, the model actually achieves better performance on a given data point if it samples more, so that it can learn from itself.

  68. 15:37

    So what this means is if you take the maximum performance on a given data set, that should improve as you sample more from the model. So because of this, you should be able to see the, these variances from a given data point, so the model can learn from itself, learn what the difference between a good and a

  69. 15:52

    bad rollout is for a given data point. And, uh, lastly, you wanna make sure that your reward function is not hackable. Hopefully, you've plugged up all the corner cases, all the edge cases, um, but also, hopefully, you've framed your task so that the reward is more continuous than binary.

  70. 16:09

    The continuous reward actually allows the model to kind of inch up closer and closer to optimal performance, sort of like giving, giving a student partial credit, um, rather than, you know, slapping them all in the face or giving it a cookie, uh, if it gets stuff wrong or gets stuff right.

  71. 16:24

    So now in order to get started with Agent RFT, please contact your friendly neighborhood account director, and we're really excited to see what you all build with us. Thank you so much. [audience applauding] [upbeat music]