Skip to lesson

NVIDIANVIDIA-Certified Professional: Agentic AI2026-105.5 Adapt reasoning strategies based on prior experiences and feedback.

Reuse trajectories without copying their mistakes

Completed by the knowledge check

Learning objective

Reflect on past trajectories and reuse successful examples in context.

Core idea

A useful past trajectory shows which action worked under which conditions. Reusing its final answer alone loses the decision that made it useful. Replaying its entire transcript can carry obsolete observations, irrelevant tool output, and unsupported conclusions into another task.

For adaptation in context, extract a reviewed example or a scoped instruction from the experience, then supply it when a subsequent task needs that strategy. Model weights stay unchanged. LangChain describes episodic memory as past experiences commonly implemented through few-shot examples, and reflection as refining instructions using conversations or explicit feedback. The engineering decision is what deserves to influence the next inference.

See 5.1.2 for reconciling facts before memory writes and 5.1.3 for recall and retirement. Here, the stored object teaches an approach to a task, rather than another fact about a user. See 5.2.3 for bounding critique within a reasoning run; this lesson concerns carrying reviewed experience across runs.

How it works

Separate the trajectory from its lesson

Retain the observed input, consequential actions, tool results, and verified outcome as the source record. Write a separate lesson that names the condition, the attempted approach, the observed failure or success, and the proposed change. For example: when a catalog response marks a component as discontinued, check an approved replacement before estimating availability. That is a conditional strategy; “always replace the requested component” is an unsupported generalization.

In NeMo Agent Toolkit, evaluation’s workflow_output.json contains per-sample question, expected answer, generated_answer, and intermediate_steps. These give a reviewer a starting point for inspecting a run. Use the recorded steps to check the proposed lesson against what happened, and resolve task success against the business system’s result where the answer text alone cannot establish it.

Treat a generated reflection as a candidate change. A fluent explanation can describe a plausible cause without establishing it. If a tool returned an obsolete catalog entry, changing the planner prompt is a different intervention from correcting the catalog. The owner of the workflow should approve the intervention that addresses the observed cause.

Choose an example or an instruction

A few-shot example preserves a concrete input and a successful response or action sequence. It helps when the agent needs to see the intended structure, tool order, or stopping decision. Select examples by the incoming task’s relevant conditions, rather than by their success score alone. A successful routine lookup may offer little guidance for an ambiguous replacement request.

Reflection can instead revise a reusable instruction. LangChain’s memory overview illustrates an update_instructions node that consumes prior instructions and conversation feedback, then saves revised instructions with store.put. Its call_model node loads instructions with store.get and places them in the model prompt. These are application-defined nodes in the example, not universal framework node types. The change affects later prompts; it does not train the model.

To run such a graph through NeMo Agent Toolkit, NVIDIA documents workflow._type: langgraph_wrapper with graph identifying the exported graph, and requires the nvidia-nat-langchain integration package. The graph owns the instruction-update logic.

Prefer an example when the decision is hard to express without a demonstration. Prefer a scoped instruction when the feedback identifies a general rule with clear applicability. Keep the source trajectory available for review in either case so that a proposed rule can be challenged against its origin.

Implement deliberate admission and retrieval

NVIDIA documents MemoryEditor.add_items, search, and remove_items as the low-level memory interface. MemoryItem includes conversation, tags, metadata, user_id, and optional textual memory. An application can use metadata for its own source-run identifier, tool-schema version, review outcome, and applicability labels. Those labels are application conventions, not predefined toolkit fields.

Use add_items after the example has passed review, then search to retrieve candidates for the next task. Check application metadata before injecting an example into the prompt. A stored sequence that depends on a retired tool schema is unsuitable even when its wording resembles the request. Use remove_items through the chosen backend’s supported deletion criteria when a discovered defect invalidates an example.

A stored example passes review before add_items and a metadata check before it enters the prompt.

A stored example passes review before add_items and a metadata check before it enters the promptAfter the example has passed review, the application adds it with add_items. For the next task it calls search and receives candidates. After it checks application metadata, it injects the example into the prompt, unless the example depends on a retired tool schema, which makes it unsuitable. When a discovered defect invalidates an example, the application calls remove_items.PromptMemoryEditorApplicationexample passed reviewunsuitablealt[check application metadata][depends on retired tool schema]opt[defect invalidates anexample]add_itemssearch for the next taskcandidatesinject exampleremove_items

NVIDIA also defines MemoryManager as an abstract interface for higher-level operations such as reflection. That is an extension point, not a ready-made reviewer that establishes correctness. You own the transformation from trajectory to lesson, the admission decision, and how retrieved examples enter the workflow prompt.

Key distinctions and trade-offs

Choose the reusable artifact according to the decision it must teach:

ArtifactDeciding conditionMechanismCost or failure risk
Reviewed few-shot trajectoryTool sequence or response structure is easier to demonstrateSelect past examples and insert them into the promptRepeated input tokens; irrelevant examples can steer the wrong strategy
Reflected instructionFeedback supports a rule with explicit conditionsApplication-defined instruction update, such as store.put, followed by prompt loadingAn overgeneralized rule affects many later tasks
Raw transcriptDetailed investigation is still necessaryInspect intermediate_steps in workflow_output.jsonNoise, sensitive content, and unsuccessful actions require review before reuse

In-context reuse spends retrieval time and input tokens on each affected request. Moving reflection into background processing removes that work from the response path, but a completed interaction cannot benefit from a lesson that has not yet been prepared. LangChain documents this hot-path versus background trade-off. Choose the timing according to whether immediate reuse is worth delaying the response.

Architecture / decision scenario

An industrial parts distributor runs an employee assistant that identifies approved replacements for discontinued components. The team has 120 reviewed trajectories. Its proposed prompt contains all 120 examples, averaging 700 tokens each: 84,000 example tokens before the live request and tool output. The service’s chosen example budget is 2,000 tokens per request.

The workflow owner rejects loading the complete archive. The application retrieves candidates through MemoryEditor.search, checks their application-defined catalog and tool-schema metadata, and admits at most two 700-token examples. Two consume 1,400 tokens and leave 600 for short applicability notes. These are design budgets, not toolkit limits.

One successful trajectory obtains a replacement only after checking the discontinued flag. Another ends with a confident availability estimate despite a failed catalog call. The first becomes a reviewed demonstration; the second remains a failure record. A reflection from that failure proposes checking catalog-call success before making an availability claim. The owner evaluates that instruction on separate cases before admitting it.

A third stored success used an approval tool that the warehouse team has retired. Its similarity score is high, but the schema metadata excludes it. This prevents a good outcome under a previous interface from teaching an unusable action sequence. The team then checks adaptation quality as described in 5.5.3 rather than equating successful retrieval with successful reasoning.

Common exam traps

  • Treating remembered examples as a model-weight update.
  • Reusing only the final answer when the useful information is the action sequence.
  • Accepting an agent’s retrospective explanation as proof of the failure’s cause.
  • Selecting examples solely by similarity while ignoring tool and policy applicability.
  • Assuming MemoryManager supplies an automatic correctness review.
  • Giving every successful transcript permanent authority over future prompts.

What to remember

Convert observed experience into a reviewed demonstration or a conditional instruction. Keep the source outcome separate from the agent’s explanation, admit only applicable examples, and budget their repeated prompt cost. Memory supplies the material; your workflow decides whether it deserves to teach the next run.

Knowledge check

References