.png)
Amazon announced custom reward functions for multi-turn reinforcement learning with Amazon Nova Forge. The release matters because the reward function is the part that actually defines the behavior you get from reinforcement fine-tuning, and in multi-turn agentic settings a bad reward can look “stable” right up until deployment.
The post is mostly about the reward design problem, not a new RL algorithm. The practical change is that Nova Forge runs your reward logic in your own environment through Bring Your Own Orchestration (BYOO) for multi-turn training, while Nova Forge coordinates rollouts, message passing, and conversation state across turns. AWS also points to a serverless multi-turn RL option, now generally available, for teams that do not want to manage the environment themselves.
Single-turn rewards are already easy to get wrong. Multi-turn rewards are harder because the model is not being judged on one answer; it is being optimized over a sequence of actions, tool calls, recoveries, and terminal outcomes.
That changes the failure modes in a few important ways. A reward that overweights local “good-looking” intermediate steps can teach the model to optimize for appearance instead of progress. A reward that only checks the final outcome can ignore bad behavior along the way, which matters when the agent is making external side effects, making tool calls, or wasting turns. A reward that is too sparse can leave the policy undertrained on the behaviors that separate useful agents from lucky ones.
Nova Forge’s multi-turn setup is aimed at that exact problem. Your reward function is not just scoring a single completion; it is scoring a trajectory, and that trajectory is what Group Relative Policy Optimization uses to update the policy. In practice, that means the reward definition has to encode not just “did the task finish,” but “did the model make the right decisions at the right time, across the whole conversation.”
The source post frames the core design question correctly: a multi-turn reward usually needs to be composite. That means combining several signals that reflect different properties of the rollout, rather than collapsing everything into one binary success metric.
For agentic tasks, the obvious components are task completion, correctness of intermediate tool use, recovery behavior after failures, and any constraints around safety or policy compliance. The hard part is weighting them so the model does not learn to game one signal at the expense of the rest. If intermediate-step reward is too strong, the agent can become verbose and overactive. If terminal success dominates everything, the model may learn to take risky shortcuts as long as it eventually lands the answer.
The post’s emphasis on custom reward logic in your own environment is important because these signals often depend on private tools, internal APIs, or environment-specific state that cannot be captured by a generic evaluator. BYOO makes the environment the source of truth for reward computation, which is the right place for it when the task definition depends on proprietary workflows or hidden state.
The engineering constraint is straightforward: the reward function becomes part of the training system, not just a post-hoc metric. It needs to be deterministic enough to debug, stable enough to compare runs, and expressive enough to distinguish between “technically solved” and “solved in the way you actually want.”
The choice AWS is drawing is operational, not conceptual.
BYOO gives you control over the reward environment. That is the better fit when reward depends on internal systems, custom instrumentation, or nonstandard task simulators. It also makes debugging easier when you need to inspect rollout state, reproduce a trajectory, or trace why a reward fired.
The serverless multi-turn RL option is the lower-ops path. It is the version you choose when the training loop should be managed for you and the environment is simple enough to fit the service boundaries. That is attractive for teams that want to experiment with multi-turn RL without building orchestration around it, but it naturally trades away some control over the reward runtime and environment integration.
For production teams, the choice comes down to where the complexity already lives. If your agent touches internal tools, custom business logic, or specialized evaluation harnesses, BYOO is the sensible default. If the task can be expressed cleanly inside the managed service, serverless reduces surface area and operational burden.
The bigger point is that AWS is treating reward evaluation as a first-class integration point rather than an afterthought. That is the right abstraction for multi-turn RL, because the reward is no longer a simple scalar attached to a text sample; it is an executable specification of desired behavior over time.
The blog post is useful because it calls out the real bottleneck in multi-turn RL: not rollout generation, not optimizer choice, but reward definition. That is where most custom agent training projects succeed or fail, and Nova Forge’s BYOO path is essentially an admission that the reward environment has to live close to the customer’s real task environment if the model is supposed to learn something operationally meaningful.
