Choose Isaac Lab’s Direct workflow when the task needs tightly connected custom logic in one environment class. Choose the Manager-Based workflow when observations, actions, rewards and events need to be exchanged independently. Both describe a robot-learning environment; the difference is where its behavior is assembled and which parts can be reused.
The choice becomes concrete when a reaching task grows into a small research project. One experiment changes the reward, another replaces joint commands with a task-space controller, and a third adds a camera. The architecture should make those intended changes easy to locate while keeping the rest of the experiment stable.
A reward change exposes the difference
The official workflow comparison presents the same Cartpole reward in two forms. Manager-Based configuration names reward terms and associates each with a function, a weight and parameters. The environment coordinates the managers. In a Direct task, the environment’s _get_rewards() method calls the reward computation directly.
Neither arrangement determines what the reward ought to mean. A distance penalty can reward the wrong physical point in either implementation. What changes is the route from a proposed experiment to the code that implements it.
For a team trying several reward definitions with a common robot and observation pipeline, separate terms provide a useful comparison surface. For a task whose reward depends on a custom state machine, with several calculations sharing intermediate tensors, a Direct implementation may make the dependency easier to follow. These are design choices to assess against the actual task, rather than labels for simple and advanced users.
| Expected change | What to examine in Direct | What to examine in Manager-Based |
|---|---|---|
| Add an observation | Environment observation method and tensor assembly | Observation terms and their grouping |
| Replace action interpretation | Action handling and application methods | Action term configuration and implementation |
| Tune an existing reward | Reward function and configured coefficients | Named term weights and parameters |
| Coordinate unusual task state | Shared environment state and reset logic | Whether the state can be expressed clearly across terms |
The useful comparison is the amount of task-specific code that must change. Count the interfaces and dependencies affected by the experiment, not just the number of files in the project.
Direct still has a configuration and a lifecycle
The Direct RL tutorial uses an environment class alongside a configuration class. Direct does not mean putting all constants into an unstructured simulation loop. Configuration still supplies quantities such as episode duration and action scaling, while methods handle observations, rewards, termination and reset behavior.
That separation matters when debugging a reaching task. If a target becomes reachable after increasing the action scale, the change may have altered the command range rather than improved the learner. Keep that configuration with the checkpoint so the result can be interpreted later.
Direct also leaves room to optimize groups of tensor operations together. The workflow documentation shows a compiled reward function as an example. Whether that improves a particular training run depends on where the time is spent; rendering, physics and optimization may dominate instead. No timing comparison was run for this article.
Manager-Based design pays off when terms are reused
The Manager-Based RL tutorial builds the task from configured components. This makes it possible to retain the observation and action definitions while changing reward or termination terms, provided the replacements use the same physical assumptions.
Imagine two robot arms sharing a reaching benchmark. Reusing a reward term is useful only if its referenced body, target frame and distance units still describe the same task. A configuration that names the wrong link can be structurally valid and reward a different motion. Review the resolved entities alongside the reusable function.
Manager-Based design therefore moves some debugging effort toward configuration resolution. Direct design puts more of it into the environment methods. Pick the location that makes the expected experiments understandable to the people maintaining them.
Compare one task before migrating the project
Start with a small representative task and write down its observation order, action meaning, reward components, termination conditions and reset distribution. Follow one action from the policy to the simulated robot, then follow the next observation back. That trace is also the focus of the camera-observation guide when images are involved.
If converting between workflows, compare those definitions before comparing learning curves. A different reset distribution or action scaling changes the task, even if both versions use the same robot model and algorithm.
This article follows the Isaac Lab main workflow documentation checked October 16, 2026. That documentation track is separate from release-specific backend instructions; use the Isaac Lab version and backend guide to identify the stack first. Then choose the workflow around the changes the task will need, and retain the resolved task configuration with each result.