Long-horizon robot tasks combine many skills whose outcomes alter the world. Reliability therefore depends less on generating a long list once and more on verifying each postcondition, preserving valid partial progress and selecting a recovery from the current state.
A language context or plan transcript is not sufficient memory. Operations need structured facts, resources, side effects, evidence, timestamps and provenance so a restart can distinguish completed work from an uncertain command whose result was never observed.
Use this guide with the Nav2 recovery guide and failure-mining guide. Treat every external action as a state transition with an auditable receipt.
Represent the mission as a closed-loop state machine
Model goals, prerequisites, skills, expected effects, prohibited states and completion conditions. After each skill, observe the world and choose the next transition from current evidence instead of assuming the planned effect occurred.
Keep planning, execution, verification and recovery as explicit states. This makes timeout, interruption and human takeover behavior testable rather than hidden inside a conversation history.
Build a task graph with protected progress
A subgoal graph identifies dependencies and which completed effects must be preserved during replanning. Moving an object, opening a door or dispensing material can be costly or irreversible even when the overall task remains incomplete.
Mark compensation actions and non-repeatable transitions. A new plan must respect protected state unless an authorized recovery deliberately changes it.
| Record | Example | Lifetime | Failure if absent |
|---|---|---|---|
| Fact | Object is in bin B | Until contradicted | Wrong plan |
| Resource | Tool reserved | Until release | Conflict |
| Receipt | Command and result | Audit lifetime | Duplicate action |
| Checkpoint | Verified task state | Recovery lifetime | Restart loss |
| Decision | Why branch chosen | Audit lifetime | Untraceable behavior |
Separate skill return from observed postcondition
A controller can report success because its trajectory ended while the object slipped afterward. Define postconditions such as object pose, door state, inventory count or navigation arrival and verify them with an independent observation where practical.
Store evidence and freshness with the result. An unverified success should become an uncertain state, not a completed fact.
Write an execution receipt for every side effect
The receipt records command identifier, parameters, attempt, start and end time, controller result, observed effect, evidence, resources changed and recovery status. It connects high-level plans to physical consequences.
On restart, reconcile outstanding receipts with the world before issuing another command. This is especially important when communication failed after the robot acted but before acknowledgment arrived.
Make physical commands idempotent where possible
An idempotency key lets a downstream service recognize a repeated request and return the prior result instead of acting twice. Physical manipulation cannot always be made mathematically idempotent, so the executor must also check current state and action history.
Protect dispensing, payment, door operation, item transfer and other side effects with unique operation identities. Never infer that a timeout means nothing happened.
Preserve partial success as a new initial state
If three of five items are already sorted, restarting from the original plan may move them again or lose count. Commit verified subgoals and replan from the new state while preserving safety and task constraints.
Measure useful progress, not only binary mission success. Track completed protected subgoals, damaged resources and remaining feasible goals.
Classify failures before retrying
Distinguish perception, localization, planning, grasp, controller, environment, resource and communication failures. A retry should change a relevant parameter, viewpoint, grasp, path or skill rather than repeat the same conditions blindly.
Set per-class budgets, cooldown and escalation. Stop retrying when the state deteriorates, uncertainty grows or the next attempt would repeat an unsafe mechanism.
Replan with facts and constraints, not summaries alone
Natural-language summaries compress context but can omit provenance, timestamp and exceptions. Provide the planner with structured current facts, unresolved contradictions, available skills, protected progress and prohibited actions.
The SayCan project combines language-model skill usefulness with skill affordance values in its reported mobile-manipulation experiments. Its project page also notes limits of current-step environmental feedback, motivating explicit closed-loop state updates.
Use environment feedback after every skill
The Inner Monologue paper studies planning with environment feedback in its evaluated settings. The operational lesson is to make success detectors, scene descriptions and human feedback inputs to the next decision rather than appending only action names.
Feedback sources can disagree. Preserve raw evidence and apply confidence and conflict rules instead of letting the newest text overwrite a verified state silently.
Checkpoint for interruption and software restart
A checkpoint should contain task graph version, current state, verified facts, pending receipts, resource locks, protected progress, robot pose context, model versions and recovery authorization. Save after committed effects and before risky transitions.
Test cold restart with network loss, process crash and stale sensors. The system must reconcile physical reality before resuming from serialized state.
Evaluate completion, consistency and recovery cost
Report full and partial completion, verified postcondition rate, duplicate side effects, contradiction count, retries, recovery success, human interventions, time and resource cost. Per-skill success alone compounds poorly and hides state corruption.
Code as Policies demonstrates language-model-generated robot programs in its reported tasks. Any deployment still needs bounded tools, state verification, rollback and target-specific failure tests.
| Test | Fault | Expected behavior | Metric |
|---|---|---|---|
| Uncertain result | Lost acknowledgment | Reconcile before repeat | Duplicate rate |
| Partial success | Mid-task failure | Preserve valid progress | Retained subgoals |
| Perception drift | Contradictory fact | Request new evidence | Consistency |
| Process crash | Cold restart | Load and verify checkpoint | Resume success |
| Retry exhaustion | Repeated failure | Safe handoff | Escalation time |
Release a recoverable mission contract
Version task graph, skill schemas, postconditions, receipt store, retry rules, checkpoints, conflict resolution and human-handoff states. Preserve a complete event trace linking every plan change to observed evidence.
Close release review with the following checks.
- Represent prerequisites, effects and prohibited states.
- Verify postconditions from the world.
- Use receipts and duplicate protection for side effects.
- Preserve partial success and classify retries.
- Exercise interruption, checkpoint reconciliation and human handoff.
Frequently asked questions
Can a larger LLM context solve long-horizon robot tasks?
No. Context helps planning, but reliable execution still needs structured state, postcondition evidence and recovery semantics.
How do behavior trees relate to task memory?
A behavior tree organizes control flow; durable memory stores facts, receipts, checkpoints and evidence used across runs.
Is restarting from the beginning safest after failure?
Not when prior actions changed the world; reconcile and preserve valid progress before deciding.
How many retries should a skill receive?
Set a class-specific budget from risk, state change and information gained, then escalate when repetition is no longer useful.
How is partial success measured?
Track verified protected subgoals, remaining feasible goals, side effects and recovery cost separately from full completion.
Verified-State and Resume Boundary
Long-horizon robot reliability comes from verified state transitions, durable receipts and recoverable checkpoints. A longer plan or context window cannot substitute for evidence about the physical world.