Teaching Agents to Search with NVIDIA Data Designer — Dhruv Nathawani, NVIDIA

An agent that can answer a question from memory has little reason to search. Teaching search therefore starts before training: create questions that make searching useful, capture how a model solves them with tools, and select the resulting examples carefully. In this workshop, NVIDIA research scientist Dhruv Nathawani develops that approach through three notebooks using NeMo Data Designer. Search is the worked example of a more general task: turn a desired agent behavior into training data.

Internet text supplies raw material, but it does not automatically supply examples of the behavior a model should learn. Data Designer can generate synthetic examples from scratch or transform a seed dataset, such as Wikipedia material, into a different training format. The seed gives generation a connection to real information; the generation recipe determines what the model is asked to do with it.

A repeated prompt is a weak recipe. Ask for a product, review and customer profile over and over, and the outputs can become repetitive while failing to preserve useful relationships among those fields. More calls do not themselves provide control over diversity, validation or reproducibility. Nathawani’s emphasis is emphatic: “diversity, diversity, diversity.”

Data Designer expresses a dataset as columns connected in a directed acyclic graph, or DAG. Different column types perform different jobs:

• Seed columns bring in optional existing data from CSV, JSONL or Parquet files.
• Sampler columns choose attributes such as easy, medium or difficult. Conditional sub-samplers can associate each difficulty with suitable problem types.
• Generation columns produce text, structured data, code or images using the preceding inputs.
• Validation checks generated outputs before they become useful dataset records.

The graph makes those dependencies explicit, so executing the recipe creates the dataset column by column.

The first notebook uses local inference through vLLM on an NVIDIA GPU cluster, with gpt-oss-120b as the generating model. Model providers are configurable: the pipeline is not tied to that teacher. Nathawani also flags model licensing as a practical constraint when generated outputs will be used to train another model.

The seed is deliberately simple: a CSV containing Wikipedia topics. A difficulty sampler adds easy, medium or hard, with configurable weights so the dataset can contain more medium questions, for example. Question types can depend on difficulty: an easy question might ask for a definition or direct fact, while a hard question asks about something obscure or more detailed. This controls the mix before the LLM starts writing.

How do those choices reach the model? A question column, added with add_column, uses a Jinja prompt template that inserts the topic, difficulty and question type at runtime. The model receives varying combinations of inputs rather than the same request repeated indefinitely. A structured column can then request a format such as JSON; records that fail the requested structure are dropped in the described workflow. Input variation encourages diversity, while format filtering handles a separate failure: an answer that cannot be consumed in the required form.

Preview mode tries to generate three records for inspection. One example asks which W3C recommendation shares a three-letter abbreviation with an airport code for a Norwegian city. The combination of web standards and geography makes the question obscure, but this first notebook still only generates a question and an answer. Difficulty alone has not yet added search behavior.

Another model can judge question quality, adding a score to the generated record. The notebook also exposes dataset views, statistics and an export to Hugging Face. Three preview rows are useful for spotting problems, but too few for meaningful aggregate statistics. Once the recipe looks suitable, batch creation scales the requested record count: questions are generated first, then answers, followed by the judge’s assessments.

The second notebook keeps the topics, samplers and question generation, then changes how the answer is produced. Model Context Protocol, or MCP, connects the model to Tavily search. Adding the tool alias to the answer-generation configuration lets the model issue a search request and use the returned information in its response.

This changes the training material from an isolated answer into an inspectable attempt. The preview is still the place to examine a few records, revise prompts or the workflow, and only then launch a batch. A plausible final answer is no longer the only thing worth looking at: the route taken to obtain it matters too.

What information passes through one search attempt? The example asks which German city Telefunken moved its headquarters to in 1949. The narrated first query retains Telefunken and the year, although it asks “to which company” rather than which city. Tavily returns URLs, a title for each result and associated content; the model then produces a response. The trace exposes the query and retrieved material separately, making it possible to inspect the model’s search formulation rather than judge only its final prose.

Search solves a basic limitation of stored model knowledge. Training uses a finite collection of data assembled before the training run; today’s weather cannot be recovered from that old collection alone. NVIDIA’s motivation was to teach Nemotron models to retrieve information when their internal knowledge was insufficient.

BrowseComp supplies a harder test than a direct weather lookup. The example in the workshop asks for a football match between 1990 and 1994 using clues about a Brazilian referee and yellow cards. Nathawani gives the answer as Ireland versus Romania. The important operation is decomposition: decide which clue to search, collect information, compare it with the original constraints, and decide what to search next.

To generate similar training challenges, the seed changes from a list of topics to walks through Wikidata’s entity graph. The example connects NVIDIA to Jensen, Jensen to Oregon State University, the university to Benton County, and the county to its namesake, Thomas Hart Benton. What makes those entities useful together is the relationship between each pair. The diagram preserves those relationships so the eventual riddle can be read backward from its clue to its answer.

The resulting riddle asks: “Which company was founded by the person who went to college where the county was named after Thomas Hart Benton?” It conceals the company behind linked facts. The intended behavior is to resolve intermediate entities through search rather than supply a familiar answer immediately. This construction makes memory shortcuts less attractive; it does not guarantee that a model cannot already know or infer the answer.

Walk length is a heuristic, not a difficulty guarantee. Nathawani initially describes five to eight hops, then settles on roughly four to eight as what worked for him. Longer walks can drift into unhelpfully generic facts: a person connects to “human being,” which is true but contributes little to a distinctive riddle. The goal is a connected question whose answer requires assembling information, rather than merely a long question. His later clarification is useful: pasting the whole question into search should not readily yield the answer.

The third notebook joins the pieces. Collected Wikidata paths enter a prompt that asks a model to create a question using any or all of their entities. A separate search-agent instruction tells the answering model to use web search and return valid JSON containing the final answer, supporting URLs and a short justification. Seed collection grounds the question; tool execution supplies the attempt to solve it.

The tool instructions also address cost and usage. An agent should not keep calling search far beyond what a question merits. Nathawani’s extravagant examples of a hundred calls and a thousand-dollar bill illustrate the concern rather than establish configured limits. An example call in the prompt demonstrates how to use the search tool through in-context learning: the generating model receives a pattern it can follow while producing the trajectory.

How does a path become more than a generated question? In the preview, Nathawani describes a seed involving the Indian Council of Medical Research and Bhubaneswar, then expands the agent-solution field to inspect multiple tool calls and the attempt to find an answer online. The location relationship is presented tentatively and should not be treated as a verified geographic fact. The useful distinction is visible in the record structure: the seed path, generated question and executed solution are separate objects.

The questions distinguish two operations that are easy to conflate. The seed collector is a programmed graph-walking algorithm, described by Nathawani as deterministic; the agentic behavior happens later, when a model searches to solve a generated question. A random-walk seed recipe is therefore not itself an agent trajectory. Other seed-generation methods could replace it without changing the need to capture tool use.

This search project uses supervised fine-tuning, or SFT, during post-training. The chosen teacher model generates the target responses through Data Designer. That is a form of distillation, although the surrounding samplers, non-LLM operations and filtering also shape what the student sees. Tavily is a practical choice rather than a requirement of the method; Nathawani names Exa or a custom search tool as alternatives.

Two other results help define the scope of that claim:

• Text to SQL: Nathawani reports BIRD performance moving from 26% to 41% for Nemotron Nano. When asked about higher scores elsewhere, he distinguishes this non-agentic SQL setup from agentic systems and emphasizes model size. Those scores are not interchangeable comparisons.
• Structured outputs: He reports a Nemotron student exceeding its GPT-OSS teacher on StructEval after distillation. That supports the possibility of a student surpassing a teacher on a targeted capability; the workshop does not quantify this example or isolate which pipeline choices caused the gain.

Reinforcement learning changes where solutions are produced. Instead of executing every riddle in advance to create a target trajectory, stop with a dataset of prompts. During RL training, the model attempts those prompts with tools in real time, and a reward function implemented through NeMo Gym evaluates the attempts. The reusable output from Data Designer is then the task distribution, while the training run supplies the trajectories.

Generating a general reward function is a separate unsolved problem in this discussion. Asked whether that part could also be supplied, Nathawani says the team is considering it and identifies generality across use cases as the challenge. Likewise, his answer about ETL reliability is explicitly an expectation rather than a use case he has personally tested.

The production funnel is much narrower than the generation step suggests. Nathawani started with 50,000 seeds and retained 7,000 high-quality end-to-end SFT records after generation and filtering. Training on the selected data moved the reported BrowseComp result from 0% to 30%. This is the workshop’s reported training outcome, rather than an isolated measurement of any one sampler, prompt or filter.

What does the evaluation view help inspect? Its function brings together LLM-judge scores for trajectories, word counts for questions or search queries, and a keep percentage. Nathawani cites 66% in that displayed example; it is a separate evaluation view, not the retention rate of the full 50,000-seed run. These diagnostics describe selection and dataset characteristics. They still leave the central question: is the answer correct?

The U.S. Steel example exposes a failure shared by the generator and verifier. A riddle asks which country owns U.S. Steel. The agent answers the United States, and the verifier accepts it. A later web search leads Nathawani to question that answer after finding information about a Japanese acquisition. His recollection of the transaction is tentative, so the anecdote establishes a verification problem rather than a precise account of ownership: a seed can become stale, and agreement with that seed can certify an outdated answer.

A simple deterministic matching function creates a different risk: treating its own limitations as evidence that the data is bad. Nathawani describes a roughly 24% result from such a check, then questions the quality of his matching function. A low agreement rate needs interpretation. It may reveal bad answers, an unsuitable reference or a check that fails to recognize acceptable responses; the scalar alone cannot distinguish them.

Evaluation therefore combines evidence from several directions:

• Model judgments assess generated questions or trajectories at scale.
• Human review of judgments checks whether the LLM judge is applying the intended standard, rather than assuming its scores are reliable.
• Current information helps check search answers whose underlying facts may have changed.

Passing a collection of checks only rules out the failures those checks detect. It does not prove that no other failures remain.

The same framework extends beyond the single user prompt and final response used in the search example. That single turn can contain several internal search calls; multi-turn datasets add further conversational exchanges, while multi-tool datasets can combine search with tools such as weather or coding. Other projects target structured output, SQL, scientific reasoning and STEM pretraining data. Structured output matters because application code needs agents to return usable JSON, YAML or other required formats reliably.

The practical advice follows from the earlier examples:

• Diversity before volume: vary the ways examples are constructed before increasing their count.
• The cheapest correct column type: use a Python sampler for sampling; reserve an LLM for work such as generating text.
• Overproduce, then filter: plan for discarded records rather than assuming every generation belongs in training.
• Inspect the preview: look directly at a few examples and revise the recipe before paying for a large batch.

The shareable artifact is “code that can create data.” A versioned recipe records the seed choices, sampling logic and generation process, so another team can modify the search workflow rather than receive only a frozen dataset. Existing tools for code review and version control can then carry changes to the data-creation process itself.

The closing example changes what the seed is meant to preserve. For a synthetic healthcare dataset in San Francisco, plausible individual records are insufficient: the collection should also reflect relevant demographic distributions. Nemotron Personas USA, created with Data Designer and reusable as a seed, supplies synthetic people intended to carry that population context into downstream generation.

What does a persona contribute beyond a name? The example describes a fifty-year-old pharmacist and combines a personal narrative with a professional persona and fields such as first, middle and last name, gender and age. Nathawani describes a million such personas available as seeds. The intended benefit is to learn from aggregate information without using a particular person’s healthcare record directly; this description does not establish a formal privacy guarantee.

Tax forms make the distribution problem concrete. A synthetic W-2 or 1040 should not contain arbitrary income values attached to arbitrary ages. Age and income can have meaningful relationships, including uncommon combinations that a plausible-looking average would erase. Nathawani compares unsteered generation to asking a model for jokes and getting the same familiar material back: repeated plausibility does not reproduce a population. Persona-grounded generation is intended to preserve useful distributions while creating new records.

Synthetic generation sits alongside other data work. NeMo Curator prepares existing real-world data through curation and post-processing. Data Designer creates synthetic examples. NeMo Anonymizer addresses sensitive material in existing data, including agent logs that may accidentally contain API keys or personal information. NeMo Safe Synthesizer is presented as a tool for generating synthetic versions of sensitive datasets. These address different starting materials and needs; synthetic data is not the preferred answer for every task.

The final technical detail explains how the U.S. personas get their demographic grounding: census information is processed using a probabilistic graphical model, or PGM, to represent connections among demographic attributes and generate a dataset from them. This gives the persona recipe a statistical starting point beyond asking an LLM to invent people. Nathawani also names persona datasets for Japan, India, Singapore and Brazil as starting points for country-specific AI applications.