NVIDIANVIDIA-Certified Professional: Agentic AI2026-105.3 Engineer planning strategies for sequential and multi-step decision-making.
Repair the affected plan before continuing
Completed by the knowledge check
Learning objective
Replan incrementally on failure or new observations instead of rigid one-shot plans.
Core idea
Replanning changes what the agent intends to do because an observation invalidated an assumption. A retry repeats an intended action; a replan changes the action, its inputs, its prerequisites, or the goal’s achievable scope. Repeating a failed call without changing a disproven assumption is activity without progress.
Incremental repair preserves results that remain valid and revises the affected unfinished work. It does not mean keeping every completed result: if the requested date changes, a completed date-specific calculation can become invalid too. The deciding question is whether the result’s inputs and assumptions still hold.
Plan representation and checks belong to 5.3.2. Here, those checks supply the observations that decide whether to continue, repair, or stop. Recovery after process interruption belongs to 5.4.2; this lesson concerns changing the plan during a task.
How it works
Turn an observation into a planning decision
Classify the observation against the intended step before invoking another planner. A transient transport failure with unchanged inputs might justify a bounded retry; see 2.4.2. A valid empty search result might instead disprove the planned source. A user correction might change the task even though no tool failed. An authorization refusal can constrain the achievable task rather than justify searching for another route to the same restricted data.
Store the observed condition, the affected step identifier, and the assumption it contradicts in the application’s plan record. Give the repair planner this structured failure context and the still-valid results. Passing only “something went wrong” forces it to reconstruct the problem and encourages a complete restart.
NeMo Agent Toolkit’s react_agent can use a tool failure as an observation through pass_tool_call_errors_to_agent. When that option is True, tool errors are passed to the agent; when False, they raise an exception. Choose deliberately whether the agent should adapt locally or the caller should decide the next path. An error visible to the model is useful input, not authorization to ignore the failed condition.
For rewoo_agent, NVIDIA documents a different boundary. The plan is created upfront, and limited adaptability to unexpected tool failures or information is a stated limitation. tool_call_max_retries controls retries; raise_tool_call_error controls whether failures raise immediately or enter tool responses. Neither setting should be treated as a guarantee that the agent regenerates a dependency-correct plan. If the application needs replanning, represent that control explicitly around execution.
Revise only what the observation invalidates
Define a repair node in a LangGraph StateGraph and use add_conditional_edges() after checking a step result. The routing function selects continued execution, repair, or a terminal incomplete result. The repair node returns updated state containing the revised unfinished work and retained valid artifacts. The Graph API provides routing and state updates; the application defines which artifacts remain valid.
Use the plan’s prerequisite relationships to identify affected consumers. If source selection changes, every unfinished consumer of that source must receive the replacement. If a calculation has already consumed the rejected source, invalidate that calculation too. A completed independent lookup can remain usable when its inputs, authorization scope, and freshness requirement are unchanged.
Validate the revised plan before dispatch: its prerequisites must resolve, its tools must remain allowed, and its success conditions must still match the user’s task. Do not let repair silently weaken “verified report” into “best-effort speculation.” If the original goal is no longer achievable, return the unmet requirement or ask for a scope decision through the application’s interaction path.
After a step result is checked, the routing function continues, repairs, or stops, and a repaired plan is validated before it is dispatched.
LangGraph’s evaluator-optimizer example illustrates feedback-driven conditional routing: a check accepts the output or returns feedback to generation. For planning, apply the same explicit control structure to the remaining work rather than blindly regenerating the entire answer. The repair itself is a team-defined policy, not a built-in promise of incremental invalidation.
Bound repair by remaining useful work
Track a team-defined repair count and remaining task deadline in graph state, and check them in the routing function. Stop when the success condition passes, the approved scope is impossible, or further repair cannot fit the remaining budget. Set a separate ceiling for tool calls when a local react_agent owns the next actions, using max_tool_calls.
LangGraph also accepts recursion_limit as a top-level invocation configuration key. It bounds graph supersteps and raises GraphRecursionError when exceeded. It is a backstop, not a count of failed plans or elapsed seconds: one repair can include several nodes, and parallel nodes can share a superstep. Import RemainingSteps from langgraph.managed and declare a state field such as remaining_steps: RemainingSteps. LangGraph populates it with the remaining steps before the recursion limit. Check it inside the graph to route proactively to the incomplete result while steps remain; catching GraphRecursionError outside the graph is the reactive alternative after the limit is exceeded.
A plan revision must also respect actions already taken. A successful external mutation does not disappear because the planner replaces its step. If an action’s result is uncertain, reconcile it before replay; see 2.4.4 for action recovery. Keep this separate from preserving a reusable read result, which has no external effect to undo.
To run the custom graph through NeMo Agent Toolkit, use workflow._type: langgraph_wrapper and point graph to the exported implementation, with nvidia-nat-langchain installed. The wrapper provides integration; your graph still owns repair eligibility and the stop decision.
Key distinctions and trade-offs
Use the smallest response that repairs the invalid assumption:
| Observation | Appropriate response | Preserved work | Main cost |
|---|---|---|---|
| Transient failure, assumptions unchanged | Bounded retry of the same action | Accepted independent results | Extra attempt latency |
| Source missing or result rejected | Replace affected steps and invalidate their consumers | Results whose inputs remain valid | Repair planning and repeated checks |
| User changes the task scope | Recompute scope-dependent work | Only results valid under the revised request | Broader invalidation and renewed acceptance |
| Scope impossible or budget exhausted | Return explicit incomplete outcome | Accepted partial results with their limits | Unfinished user objective |
Full replanning can be appropriate when the goal or most assumptions changed. Incremental repair is preferable when the change is local and retaining independent results saves meaningful time. The smallest textual edit is not necessarily the smallest correct execution repair.
Architecture / decision scenario
An industrial distributor’s employee assistant prepares supplier-risk summaries within 60 seconds. Its hypothetical task has spent 32 seconds and completed a supplier identity lookup, a certification check, and one sanctions-source lookup. A second source reports that its supplier identifier was replaced after a merger. Restarting the entire task takes an estimated 42 seconds; repairing the identifier-dependent source checks and synthesis takes 19 seconds.
The workflow engineer rejects a complete restart because 32 plus 42 exceeds the deadline. The check node routes to repair, supplies the replacement identifier and affected prerequisites, and retains the independent certification artifact only if it still names the same certified legal entity. The superseded sanctions result and its dependent draft are invalidated. With 28 seconds remaining, the 19-second repair is eligible for execution.
A rigid one-shot plan is also tempting because every planned tool was available. It fails the acceptance rule: source records must describe the same supplier entity. Successful transport cannot cure the identifier mismatch. The repair node must update the remaining plan, rather than let the solver combine inconsistent results.
The team allows one repair for this request class. If the replacement source then identifies another unresolved entity change, the routing function returns an incomplete summary with the unresolved requirement. The procurement data owner decides entity equivalence; the workflow engineer owns the repair budget. Neither an extra retry setting nor a larger graph recursion limit resolves that business ambiguity.
Common exam traps
- A retry is incremental replanning. Replanning changes the intended work in response to a changed assumption.
- Completed work is always reusable. A changed prerequisite can invalidate an already-computed result.
- Passing errors to the model guarantees recovery. It supplies an observation; repair still needs permitted actions and acceptance checks.
- A recursion limit is a business deadline. It counts supersteps, not seconds or plan revisions.
What to remember
Repair the assumptions and dependent work that the observation invalidates. Preserve independent valid results, check the revised plan before dispatch, and stop explicitly when the remaining goal cannot fit the scope or budget. Adaptive planning is controlled change, not unlimited regeneration.
Knowledge check
A research agent’s plan queries a regulatory database for a supplier’s jurisdiction. The query succeeds and returns a valid, empty result: the database does not cover that jurisdiction. An approved alternative source covers it, and the task requires this coverage. Two other completed lookups remain valid and do not use this source, and the deadline leaves no room to redo them. What should the agent do next?
Midway through a task, the user changes the requested reporting period from Q2 to Q3. Two results are complete: a Q2 revenue calculation, and a customer master-data lookup whose inputs do not depend on the period. The lookup still meets its freshness requirement, and the user’s authorization scope is unchanged. Which results should the repaired plan keep?
A LangGraph repair loop must stop after two repairs, or earlier when the remaining task deadline cannot fit another repair, and then return an explicit incomplete result. One repair can run several nodes, and some of them run in parallel. Which mechanism implements this stopping rule?
recursion_limit to the number of supersteps that two complete repairs takeGraphRecursionError outside the graph and return the partial resultmax_tool_calls on the local react_agent to the repair budgetrecursion_limit bounds graph supersteps, not plan revisions or seconds: one repair can span several nodes, and parallel nodes share a superstep. A team-defined repair count and remaining deadline in graph state, checked by the routing function, express the business rule directly. Catching GraphRecursionError only reacts once that same superstep limit is exceeded, and max_tool_calls bounds a local agent’s tool use, not repairs.A NeMo Agent Toolkit rewoo_agent runs a supplier-check workflow. When a source fails, the team needs a revised plan whose later steps still have their prerequisites satisfied. Which change puts that replanning under the application’s control?
tool_call_max_retries for each failing tool callStateGraphraise_tool_call_error: false in the workflow configurationadditional_planner_instructions describing how to replan after failurestool_call_max_retries repeats the call, raise_tool_call_error: false places the error in the tool response for the next tool, and planner instructions shape the initial plan. Replanning needs control the application represents explicitly around execution.An employee assistant’s step reads compensation records, and the HR tool refuses: the requesting user is not authorized for them. Another tool in the agent’s allowed set could export the same table. The user’s request requires those records. What should the repair path do?
References
- NVIDIA, Configure the ReAct Agent
- NVIDIA, Configure the ReWOO Agent
- NVIDIA, Running Existing LangGraph Agents in NVIDIA NeMo Agent Toolkit
- LangChain, Graph API overview
- LangChain, Workflows and agents