Oracle says catalog-side search cut total AI token use 71% in test

Oracle says an AI agent used far fewer tokens when its data catalog handled the search for relevant tables. In an October 26 experiment write-up, the company reported a 94.7% reduction in Codex token use. Counting the catalog’s own AI work, the reduction was 71%—a smaller but still substantial saving in the tested configuration.

Two different measures of the saving

The experiment covered 5,000 tables and approximately 50,000 annotations—descriptions that give data business meaning. Oracle compared standard catalog list APIs, the interfaces used to retrieve metadata, with those same interfaces plus its Agentic Search feature. It used Codex with what it described as the latest OpenAI models available when the experiment ran.

Codex consumption dropped from 1.14 million tokens to 60,000. But the combined Codex-plus-catalog total was 329,000 tokens. That distinction matters: the client’s reduction does not measure the entire system’s reduction. Oracle also reported 78% lower normalized client latency, meaning the client took 0.22 times as long as the baseline.

These are company-reported results for that configuration, not a general performance guarantee. Oracle identifies the model selection only in relative terms, without naming exact versions. Its results table measures metadata volume, token consumption and client latency; it does not provide an answer-accuracy score alongside those efficiency gains.

Search inside the catalog, not across the client’s context

Agentic Search runs within AI-Cat, the AI Data Catalog in Oracle AI Lakehouse. Instead of handing a consuming agent broad sets of metadata to explore, it uses the user’s question to narrow catalogs and schemas. It then inspects selected table and column descriptions, returning a focused set of candidates for tasks such as generating SQL, the language used to query databases.

The search agent plans which schemas and tables need inspection, then fetches selected descriptions and properties in parallel batches. Annotations help it recognize useful tables even when their technical names reveal little. This puts the exploration inside the catalog rather than making the downstream agent repeatedly retrieve and process broad lists.

Permissions remain part of retrieval. Both standard catalog APIs and Agentic Search enforce access rules; the difference is not that only the latter checks authorization. AI-Cat’s tools apply the user’s metadata permissions throughout discovery, so the same question can produce different candidates for different users. Applications reuse that authorization rather than creating a separate metadata-access policy for each agent.

A shortlist still needs business meaning

In a separate healthcare example, Oracle shows the catalog answering which hospital procedures cost the most and which physicians are associated with them. Across Oracle and Iceberg catalogs, discovery narrows 83 schemas to two and 736 tables to four candidates. Inspecting 17 columns leads to three Iceberg tables: Procedure, Undergoes and Physician. This illustrates the retrieval path, rather than the 5,000-table benchmark.

Finding the right table is only part of interpreting a business question. Oracle’s year-to-date sales example shows how a plausible answer can use the wrong months or totals. Treating fiscal Q2 as calendar Q2, or filtering to the quarter before calculating the year-to-date total, changes the result. An Analytic View supplies the fiscal calendar and calculation rules.

AI-Cat combines annotations, relationships and shared definitions to supply that business context. Oracle also describes using data values and query history: values can identify how a concept is stored, while past queries expose established joins, filters and expressions. The approach therefore depends on more than shrinking the material an agent receives; it also supplies meaning that bare table and column names may leave out.