The Best Upgrade for a Data Agent Might Be Fewer Tools

A manager asks a fictional analytics assistant: “Which regions had more delayed shipments after the policy change, and what do the customer notes say?” The answer depends on a shipment table, a date boundary and a notes file. Giving an agent ten ways to open files does not solve the hard part: making sure the records join correctly.

The real work starts before the question

Data questions combine two kinds of reasoning. The agent must understand what the user means, then find the right fields and perform a valid operation. If tables are scattered across formats, every step can add uncertainty: which file is current, whether two identifiers refer to the same entity, how missing values are represented, and whether a date is local or universal time.

A dependable system can reduce that uncertainty before generation begins. Put related structured data behind a consistent interface, expose the schema, and let the agent inspect a bounded set of operations. This does not make data clean by magic. It makes the available structure legible enough to catch mistakes earlier and lets a reviewer reproduce the path.

NVIDIA’s KGMON team says it placed competition data into SQLite, used schema preflight, narrow tools, persistent intermediate state and inspectable traces, while reporting second place in the 2026 KDD Cup Data Agents competition. That is the team’s account of one competition system, not evidence that a small fixed model will outperform larger systems on all analytics work. NVIDIA’s KDD Cup account

The architecture lesson is worth testing independently of the placement. If every question starts from a reliable catalog of tables and a few well-defined actions, the model spends less effort improvising file access. The system can also log which tables it inspected and how it transformed them. Such traces turn a polished answer into something a colleague can audit.

A join can quietly change the answer

Imagine a fictional dataset with one shipment row per package and one customer-note row per customer. A customer with three packages has three shipment rows but one note. Joining those tables by customer ID creates three copies of that note. If the agent counts notes after the join, it may report three observations where there was only one.

The text can still sound precise. It might say that a recurring concern appears frequently in a region, because the duplicated note was attached to several shipments. The error is structural, not grammatical. A narrow analytics tool should make the join explicit, preserve row counts or aggregation levels, and expose enough intermediate state to catch the duplication.

Schema preflight is valuable because it can reveal whether a presumed key exists and whether a column name differs from the user’s terminology. A preflight does not tell us that customer_id is unique in a table; that requires checking the data and the contract. Good tools make both questions visible instead of blending schema discovery with a long generated query.

Why fewer tools can make behavior easier to trust

An agent with a broad shell, a file reader, a spreadsheet editor, several database connectors and a custom Python runner can potentially complete many tasks. It can also choose the wrong surface, issue inconsistent queries or leave intermediate calculations hidden in transient context. A smaller tool set makes the intended workflow easier to define and review.

For example, a system could offer “inspect available fields,” “run a read-only query,” and “save an intermediate result with its inputs.” Each action has a focused contract. A reviewer can ask whether the query operated on the expected date range and whether the saved result came from the right tables. The model remains responsible for framing the analysis, but it does not have to invent a data-management protocol on the fly.

Persistent intermediate state matters when a question has several stages. First, identify the shipment rows in the period. Next, aggregate delays by region. Then, connect a carefully defined set of notes to those records. If the intermediate tables have names and lineage, another person can inspect each transition. If the whole calculation lives only in a chat transcript, even a plausible answer may be hard to reproduce.

Tool restraint has a cost. A narrow interface may reject an unusual but legitimate request, and the team may need a human analyst to add a new operation. That is preferable only when the saved ambiguity and risk outweigh the lost flexibility. A well-designed system makes unsupported questions explicit and offers a safe path to extend the interface.

Build an agent around the data contract

Start by listing the questions the product is expected to answer and the tables needed for them. Document each table’s grain: one row per shipment, customer, invoice or event. Define keys, time zones, null semantics and any permitted joins. When a user question crosses grains, require the tool or agent to state the aggregation before attaching descriptive records.

Then make the agent show its work in operational terms. A trace need not expose hidden chain-of-thought. It should capture observable actions: tables inspected, schemas read, query parameters, row counts, intermediate artifact identifiers and validation outcomes. This information helps reproduce a computation without asking the model to narrate private internal reasoning.

Before returning a conclusion, apply checks suited to the question. Does the filtered period contain data? Did the join change the expected number of entities? Are totals consistent before and after aggregation? Are there missing values concentrated in one segment? These checks cannot certify every interpretation, but they catch common mechanical errors before prose turns them into confident claims.

When a larger toolset is the right choice

The strongest argument for broad tools is coverage: real analysts work across documents, databases, notebooks and proprietary systems. A tiny interface can force every novel request into a narrow template. The answer is not to minimize tools as a goal. It is to add capabilities behind explicit contracts, so new reach does not erase observability.

For a stable recurring workflow, a few reviewed operations may be enough. For exploratory research, a richer sandbox can be appropriate if it is isolated, permissioned and leaves reproducible artifacts. The design should be chosen against real questions, not a leaderboard slogan. Competition results can suggest what to investigate; a team’s own error cases decide what to ship.

Two adjacent contracts deserve equal care: decision models make classification outputs explicit, while source-aware verification asks whether evidence supports the specific claim and attribution. Narrow tools are most useful when their outputs remain inspectable.

The best upgrade may indeed be fewer tools—but only after the system knows what its data means. A compact, inspectable path can make an agent more reliable because the important choices become visible. When it is too restrictive, extend it deliberately, document the new contract and check that the added freedom solves an actual analytical need.