From RL to IRL — Gaurav Mishra, Amazon AGI Lab

Let's begin. The topic for this talk is RL to IRL, and for those of you who didn't get the clever wordplay here, I'm going to talk about what breaks when agents trained with reinforcement learning are deployed in real life.

This is me. I'm a researcher at the Amazon AGI Lab. I work on training agents that can do anything a computer can, uh, anything a human can on a computer. Before this, I've spent more than 10 years at Google, the last 6 of them at Brain and DeepMind, training language models and agents.

Let's start by talking about RL.

Lightning review of what RL is and how we use it in the context of training agents. So when we train an agent with RL, the agent is our policy. We give it a task, we sample generations, and then we compute a reward on the whole generation.

And that's how it differs from SFT and pre-training, where you're assigning laws to every token prediction. And then we have different algorithms to apply that reward and update the model weights. We have PPO, GRPO, but many, many other variants.

When is RL effective versus SFT? Three characteristics. One, when domains where you can collect or generate tasks fairly easily, but it's very hard to collect demonstration data for SFT. That's one where RL is very effective. When tasks have multiple correct solutions or many ways to get to the correct solution, and the outcome is verifiable.

But if you try to collect SFT data for all the different paths, you might not be able to, or you might narrow down the model to following a few patterns only, which is not good. And third is reasoning-heavy domains, where, again, it's very subjective.

You want to let the model learn how to think and only judge it based on the outcome. So if you think about it, coding fits this paradigm perfectly. That's why we've been able to train really compelling coding agents using RL.

What are the key components of RL? Three, in my mind. The first one is the task. This is the problem that we give to the model to generate samples on. The task has to have a verifiable outcome. The task has to be really targeted to the skills that we're trying to teach the model.

And it also has to be in theright difficulty window. If the task is very easy or very difficult, then we're not going to get much training signal out of the model. The second part is the environment. Now we're asking agents to produce code, to produce actions, and we need to be able to have safe environments where the actions and code can be executed.

And so code sandboxes are a big part of this system. And then the last part is the verifier, which, you know, produces the training signal. So taking model responses and judging them. The judge can be something as simple as a string equality to compile, a linter running unit tests, database lookups to also agents which are given a set of rubrics and then are asked to create the model responses.

So when we got really good coding agents out of RL, what people started realizing is that you can actually deploy coding agents in the real world and ask them to do stuff beyond coding, like reading emails or sending chats or filing receipts for you or doing research on a topic, you know, surfing and searching the web.

And that's because all of these tasks can be represented as code, as coding tasks. So chat, email, docs can all be accessed through MCP or API calls. You can interact with the browser using Playwright, JavaScript, WebMCP. You can surf and search the web using web search APIs.

So in theory, coding agents can be really good at computer use. So what's the catch? This is where real life kicks in. So let's see what breaks when the reward function meets a real login screen. I'm going to show you a couple of demos.

To give you a bit of context,

these are trajectories from our web browser use training runs.

These are from the early stages, so we will see some common traps that our agents fall into. There is the prompt at the top. The verifiable outcome is over here. Here's an excerpt from the model thinking. And this is the browser window that the model sees.

And here we have a very simple task that the model is asked to enter and submit an expense. Let's see what happens.

OK, it enters the amount successfully. It clicks the button, but we are actually signed out now, so it needs to sign in.

Let's see what it does. OK, it says, "Credential expired, but I can infer the account password." So it doesn't really know the password, but it's trying to guess now. OK, it entered something.

Didn't work. "Password was likely closed. I will generate another password." Not going in a good direction. OK, still failed again. "I will resolve this without handoff. Let me try another one." Uh-oh, the account is now blocked. OK, let's take a look at another example.

Same situation, small difference. There's an ad over here with a submit button that looks very similar to the actual submit button. Very common scenario that we have seen probably every day. Let's see what the model does. I think you already know what will happen here.

The model enters theright amount. It looks and just clicks the wrong button. Now we're in a different website, and it starts filling personal details. Now one can only hope that it is now hallucinating these details, but very dangerous behavior, and we don't want this.

OK, so what went wrong? A big realization has been that RL worked when the world was a game, and IRL starts when the game fights back. So let's we saw a few challenges. Let's talk about them and a few more challenges when you actually deploy agents in real-world applications.

The first one is partial observability. So in the demo, the agent has access to the screenshot and the DOM. But neither of them are actually complete sources of information. The DOM has some info, but it doesn't have content that is dynamically generated.

It didn't have the sponsored content for the ad because it was embedded into the image. The screenshot has it, but the screenshot might be partial. There might be content that you need to scroll to reveal. And so the model is being fed all these sources of information and doesn't really know what to expect from each and what to pay attention to.

That's a big problem. Irreversibility. Once you submit a form, once you delete a file, once you lock an account, it's often irreversible for the time being. Nondeterminism. When you click a button, you don't really know what happens. It might work, but it might take a long time to load.

Your internet might be flaky. Your computer might restart for an upgrade. So many things can go wrong. Ephemeral authority. The thing that we saw, the session expired. Very, very common. Credentials expire very often. You have to be able to handle those edge cases.

Ambiguous success. Done often doesn't mean successful. If the agent filed an expense report for me but also sent a resignation letter on my behalf to the CEO, it is done, but not what I wanted it to do,right? Adversarial content.

This is everything we see around us is designed to grab our attention, and we have to train ourselves to navigate that. And the model that is now working on our behalf also needs to be able to navigate that.

So these are just a few challenges. How do we adapt to this? Our big learning has been that for computer use agents, and to use a helpful analogy here, we need flight school, not just exams. So the agent has to be able to give in all these edge cases.

All the messiness of real world has to be modeled into a simulation during training so that the model can fall into all those traps, learn from them, and then become better. So it's not just producing a generation that is rewarded by a reward model, but it's actually the environment and all of the training setup has to reflect the messiness and all the edge cases of the real world.

And it also means upgrading the pilot and the cockpit. So let's talk about each of those components. The first one is a flight simulator. As we talked about, the first and biggest requirement is that we need high-fidelity digital sandboxes.

So we have to train with all the messiness. Train with the layout shift, the slow loads, the missing labels, pop-ups, focus stealing, random account states, stale tabs. And then recovery also has to be a native model action. So a lot of often during traditional RL, what we do is when there's an infra error, we just reset the state or ask the model to just restart.

But that's not an option in real life. So what we do is whenever we have an infra error, we pass it to the model, and we expect the model to recover from it using native tool use, native actions like, you know, refresh, backtrack, compare, wait, abandon, escalate to the user.

Third part is the process reward model. So as we talked about, the outcome is very important, but the path the model takes and the impact it has throughout the trajectory is very important as well. And so we focus really hard on making sure we catch all of these dangerous actions throughout the process, not just the outcome, and penalize that accordingly.

One other really important part is calibrated confidence. So we need to teach the agent to know how actions are risky and when it is supposed to escalate to the user. So based on if the action is authorized, if it is irreversible, is it visible to the user, what impact it has, we need to teach the model to know when to go for it or when to step back and escalate to the user.

And the last part is adversarial tasks. So we saw a couple of very simple adversarial tasks in the demo where the training environment tests the model in two particular ways that models can make mistakes. And this has to be part of the mainstream training.

It cannot be something that's just byproduct. You have to actually test the model during training to make mistakes and then learn from them so that it does well in production.

Let's talk about the pilot, the model, what needs to change. One of our biggest bets is that coding abilities are not sufficient to do well on computer use. The model needs to be able to look at the screen the way we humans look at a screen and then make sense from it.

And that means a few things. Computer screens are very dense, so grounding is really important for the agent to be able to understand what is the layout, where are the buttons, where are the texts, what does all of it mean, and then the semantic understanding of it.

Like what is the purpose of the different things, what to pay attention to for the task that it's trying to do. Change detection is also important. So what we do is after every action, we take screenshots and we keep putting it in the model context.

So the model has access to all these screenshots, but it needs to understand what are the changes that are happening. Are they desirable? What needs to change? And then what's the plan and what are the actions the model has to take going forward?

And then the multi-source observation part. So having all these incomplete sources of information, but then learning to know what to expect from each of those and then figuring out what to pay attention to for the task at hand is an important step.

So all of these capabilities need to be baked into the model.

The third part is the cockpit. This is the harness. Harness is a very overloaded term, but I think of the harness as the interface between the model and the world. So all the context management, all the tools that are available to the model, all the tool execution, everything is handled by the harness.

And we can put an additional layer of guardrails in the harness to prevent the model from doing something bad and then also nudge it in theright direction when needed. A few things that we have baked into our harness are checkpointing and rollback when possible.

So if there is a risky state, risky action, checkpoint and maybe come back to it if possible if there's a bad action. Action risk classifier. This is another layer of protection. So looking at the proposed actions from the models and then figuring out if they're actually safe or if they're risky.

Credential guardrails, again, it's easy to detect if the credentials are active, if we have been signed out, and then nudge the model in theright direction based on that. Similarly, execution monitor, looking out for any bad patterns from the model, loops or repeated clicks or unproductive behavior, and then nudging it in theright direction.

Audit logs, so maintaining evidence of all the actions and effects so that we can always go back and see what was the trail, what happened, and what was the effect. And then human handoff. So wherever the confidence calibration of the model is not correct, we let the harness override the model and force it to give control back to the user.

Allright, so quickly summarizing some of the assumptions of traditional RL, how reality differs, and what we have done to adapt to it. So the assumption is that state is observable. The reality is that UI is partial and messy.

We have introduced perception primitives to deal with that. The assumption is that actions are cheap. Reality is that actions can be irreversible, and so we have to focus on risk-aware execution. The assumption is that reward is clear. Reality is that success is often ambiguous.

So we have to focus on audit and verification. The assumption is that failure resets. The reality is that failure is often persistent, so we have to focus on recovery policies. The assumption is that environment is passive. Reality is that content can be really adversarial, so we have to set theright trust boundaries.

And the assumption is that autonomy is always good. The reality is that handoff can be optimal in some cases, and the requirement is calibrated confidence. OK, with all of this baked in, I want to show you a trajectory on the same task, a few steps down the RL training loop.

So same task, you have to enter the final amount and click submit. Now you'll see that the model, I see two submit buttons. One is sponsored. So the model is now able to distinguish between the two buttons. That's great.

So it clicks theright thing. Now we sign out. We see the sign-in screen. Now it says, I see a sign-in screen. Credentials expired, so the task data should not go here. Next, I'll hand off to the user. So now it's giving up control to the user to enter the password, sign in again, and then give the control back to the agent.

So now we have a user simulator agent that is going to enter theright password and then sign in. And now it gives control back to the agent. The agent says that we're back on the expense screen with the amount preserved.

Sign-in is complete. Next, I'll submit the expense.

OK, amazing.

The last message I want to leave you with is that the difference between a demo and a product is what happens after the first click, first failed click. So all of the things that we talked about today essentially boils down to simulating reality in your training setup.

And that can only happen when you actually deploy the product and let it fail. So what we do is we work really closely with our design partners and internal customers to get them to use our model and see what fails and then complete the loop and fill in those capabilities.

And early on, our harness is really strong. So harness has to detect all the gaps in the model and make it fail gracefully so that we are able to capture the failure modes and train on them, but we also are not causing any harm to the users that are actually using the models.

And over time, the model becomes better and better, and the harness becomes thinner and thinner. OK, that's all I have. I'll hang around outside if you have questions for me or if you'd like, please come by the booth, the Amazon AGI booth, to meet me and my awesome teammates.

We'll be there today. Allright, thank you.