Runtime Reasoning for Robots
Runtime reasoning means the component that decides what to do next is still running while the task executes. It is the difference between a plan committed before execution and a decision that can respond to what the robot actually observes mid-task.
Why it is worth the cost
Reasoning at runtime is far more expensive per step than feed-forward inference. What it buys is the ability to act on evidence that only exists during execution: a grasp that did not hold, a drawer that did not open, an object that moved. An offline planner cannot see any of these, because it finished before they occurred.
The usual compromise
In practice the two are combined rather than chosen between. Deliberation is reserved for novelty, diagnosis and recovery, while mature behaviour runs on a cheap learned policy. TGL's report builds on exactly that split — a slow teacher for the frontier of knowledge, a fast student for what is already established — and the verified trajectories the system produces are what the fast student is trained from.
What has to be true for it to help
The reasoning component has to receive enough evidence to reason with. If the robot's interface reports only that a command was issued, runtime reasoning has nothing to work on; it will re-derive the same plan. This is why the interface — what a subgoal reports about its own effect — matters as much as the reasoning.
How TGL relates
TGL keeps the AI Agent running through the task and gives it something to reason over: each Skill Block has an outcome test, and its result is what the AI Agent reads. A passed effect advances the plan; a failed or inconclusive one prompts another observation, a different executor, or a revised route.