Smart Mode: The Search Intelligence Layer for AI Agents

Since its inception, the Bigdata.com API has operated on a single, uncompromising philosophy: give the user absolute control.

We first built what is now Fast Mode. It is a precision instrument, a scalpel for financial data. It allows quantitative analysts and audit firms to filter by specific document subtypes, boost source authority, and construct complex Boolean logic, among many other things. For users building rigorous back-testing pipelines or tracing specific disclosures, this deterministic control is not just a feature; it is a requirement.

But there is a new challenge. The primary user of our API is no longer just a human expert; it is increasingly an AI Agent.

The Problem: powerful generalists, minimalist tool users

We didn't build Fast Mode just for our users; we built it for ourselves. It serves as the necessary backbone of our entire platform: a deterministic engine capable of executing highly specific instructions with zero ambiguity. We exposed this layer to our users because we believe sophisticated professionals deserve direct access to the core.

However, raw power creates a challenge, especially for a specific kind of user: the “generalist” AI Agent.

Frontier models (such as GPT-4 or Claude) are highly capable generalists, but they exhibit systemic under-utilization when presented with complex, deterministic tools. When interacting with an expert-grade API like Fast Mode, they lack the intrinsic financial domain expertise required to parameterize it optimally. Developers can pack system prompts with exhaustive schema definitions, API descriptions, and routing examples, yet generic LLMs consistently default to surface-level execution. They struggle to reliably translate implied financial intent into explicit database filters.

This creates a domain expertise gap that cannot be bridged by prompt engineering alone. Standard RAG architectures and ungrounded search tools are structurally inadequate for complex finance. When evaluated on real-world financial research tasks, agents relying on generic web search or under-parameterized APIs experience severe degradation in retrieval accuracy.

A taxonomy of retrieval failures in AI agents

When benchmarking generic AI agents against financial search APIs, there are some failures that tend to repeat. They stem from a fundamental inability to map human intent to complex database architectures. These structural failures typically fall into four categories:

• The Structural Gap: Generalist models do not inherently understand complex financial database schemas. When asked for an "earnings report," they fail to apply the exact Document Type and Subtype parameters (e.g., mapping to a specific RNS-SEC-6-K array), resulting in obvious precision drops. Smart search has been designed with a variety of specialized tools that facilitate this task.
• The Entity Gap: Agents do not inherently resolve entities to the canonical IDs that have been used to tag all our searchable content. They would rather use a simple keyword search, which causes them to miss mentions when omitting name versions, or add noise with detections of other unrelated entities or concepts. Smart mode resolves the mapping internally and executes targeted entity filters.
• The Recall Gap: Generic agents tend to execute singular, literal queries, or require multiple feedback loops to expand the search. If asked for "cash burn," they often search for exactly that phrase, completely missing highly relevant documents that discuss "negative free cash flow" or "capital expenditure”. Smart search has been trained to better explore different semantic paths and expand on related subtopics.
• The Date Logic Gap: Agents struggle to reliably convert relative temporal intent into the strict, explicit Boolean date bounding required by deterministic search engines. Neither they have implicitly any knowledge of fiscal reporting periods. Smart search takes better advantage of period detection to convert expressions into accurate reporting periods and temporal filters.

Introducing Smart Mode

To bridge these structural gaps, we developed Smart Mode: an intelligent, opinionated retrieval layer built on top of our deterministic backbone, engineered specifically to serve as middleware for AI Agents (and users who require abstracted search configurations).

Smart Mode functions as an automated translation engine. It accepts the unstructured natural language inputs generated by LLMs and systematically resolves the schemas, entities, and temporal logic required for high-precision retrieval. We adhere to a fundamental rule of search architecture: simplicity at the endpoint requires complexity in the backend. Smart Mode abstracts away the rigid parameterization of our database, eliminating the need for developers to build custom routing logic or exhaustive prompt engineering.

The architectural shift: explicit parameterization vs. automated inference

We are not deprecating Fast Mode. It remains the backbone for users and data pipelines that require reproducible, deterministic control, exposing the entire database schema to the developer. However, Smart Mode restricts manual filtering by design. Because it dynamically generates multi-query payloads based on semantic intent, it only allows users to define explicit bounds for Time and Source, fully automating the rest.

By disabling certain schema parameters in Smart Mode, we prevent "parameter collision" where an agent's explicit filter contradicts its semantic intent. The intelligence layer ensures that a raw request for "Apple's supply chain issues reported in the latest earnings call" is automatically routed to the correct Canonical Entity ID, bound to recent timestamps, and restricted to relevant content, without requiring a single line of explicit JSON routing logic from the developer.

Empirical benchmarks: quantifying the structural gap

To measure the real-world impact of schema literacy, we conducted an empirical evaluation comparing retrieval accuracy between the finance-focused bigdata.com search in manual Fast Mode (without any customized or targeted filters, as a naive user or agent would query), and fully automated structural inference in Smart Mode.

The results highlight exactly where the architectural breakdown occurs. Fast Mode relies on explicit instruction, meaning it fails to apply structural filters (Sources and Doc Types) when fed raw, unparameterized text by an Agent. Smart Mode systematically bridges this gap.

In a corpus of billions of financial documents, pre-retrieval filtering is a key driver of precision. By automatically translating unstructured semantic intent into deterministic structural parameters, Smart Mode ensures the retrieval engine isolates the correct sub-corpus before vector similarity search even initiates.

How it works: under the hood

Smart Mode isn't just a wrapper; it is an automated expert system with specialized tools for every content type: News, Filings, Transcripts, Expert Networks, Podcasts.

When you (or your Agent) type a query like "What's Doordash's cash burn rate according to their latest 10-K?", we trigger a multi-stage process to ensure the results are precise, fresh, and relevant:

Query enrichment

First, we run query enrichment that handles the essentials for good contextualization of the query, recognizing entities like "DoorDash" and detecting time periods. This step uses a sophisticated combination of NER models and our Knowledge Graph resolution, ensuring the more obscure entities are mapped to their canonical IDs. Then, we apply query intent and semantic understanding on top, answering crucial questions such as:

• Which detected entities are central to the question vs. just mentioned?
• What is the implicit document type? (e.g., "10-K" implies a specific filing subtype).
• Which sources should be prioritized?
• Is the query requesting for the fresher content or any specific relevant time periods?

Query expansion

To ensure we find the best answer, Smart Mode rewrites your intent into multiple variations to cast a wider net internally. For example, a request for "Netflix subscriber numbers" might trigger four parallel searches:

• "What are Netflix's latest subscriber numbers and growth trends?"
• "How many subscribers does Netflix have across different regions?"
• "Netflix subscriber additions and churn rates"

Each variation hits the engine with the same strict filters but different semantic vectors. This internal expansion increases recall, ensuring that the final top chunks returned to you are the most relevant.

The generated query (auditability)

Smart Mode converts that natural language into a highly structured API call. Trust in AI requires transparency, especially in finance. This is why we expose exactly what queries were executed, so you can verify the Agent's logic and trace every source.

Because Smart Mode compiles natural language down to our deterministic Fast Mode, it leaves a perfect audit trail. If an agent asks to "Find references to Samsung in Micron’s latest 10-K", you aren't left guessing how it found the data. We return the exact structured payload executed:

The impact on agent performance

By offloading the "thinking" from your Agent to our Search Engine, we have observed measurable improvements in retrieval quality during beta testing when comparing to naive Fast Mode:

• 20% higher quality score in the top results.
• 25% increase in the percentage of highly relevant results retrieved in the top-20.
• 54% reduction in the percentage of irrelevant noise (false positives) in the top-20.

Adding an intelligence layer requires processing time. Because Smart Mode acts as an automated expert system—performing real-time Query Enrichment and Query Expansion to cast a wider net internally—it naturally carries a higher latency footprint than a raw database query.

While Fast Mode remains our lightning-fast deterministic engine capable of executing highly specific instructions with zero ambiguity, Smart Mode prioritizes structural precision over raw speed.

Low latency search APIs shift the reasoning burden onto your LLM. When an agent receives unstructured, unparameterized results, it often triggers a multi-hop loop: it reads the poor results, realizes it missed the fiscal period, rewrites the query, and searches again. That multi-hop loop takes easily +30 seconds and can consume massive token context.

Smart Mode simplifies that reasoning loop into a single, highly optimized server-side execution. You are trading raw API latency for a lower 'Time-to-Answer' and reduced downstream LLM costs. It ensures the engine is looking in the right haystack before it even starts looking for the needle. While Smart Mode carries a higher per-call cost, it can dramatically reduce your overall AI expenditure. By delivering a 53% increase in highly relevant results and a 28% reduction in irrelevant noise, your LLMs spend less time (and incur fewer token costs) reading and discarding useless context windows. You are paying a marginal premium on the search layer to save thousands of dollars on complex, suboptimal prompt engineering and model fine-tuning downstream.

Benchmarking Smart Mode vs. external AI search providers

Having established how Smart Mode improves on Fast Mode for agentic workflows, the next question is how it stacks up against the broader market. Standard RAG architectures and general-purpose AI search APIs (such as Tavily, You.com, Exa.AI, Parallel AI or Perplexity) are not designed around the structural demands of financial research: strict entity disambiguation, document-type fidelity, and time-bound reporting constraints. When evaluated on real-world financial research tasks, agents relying on these providers show consistent and material degradation across all retrieval dimensions.

To quantify this, we benchmarked Smart Mode against some of the leading external AI search providers:

Top-20 precision: generic AI search vs. bigdata.com Smart Mode*

Note: Percentages represent precision within the top 20 results (the average percentage of returned chunks that perfectly satisfy the user's specific constraints).

Conclusion

Smart Mode allows generic LLMs to plug into deep financial intelligence without any fine-tuning on API documentation. By returning more relevant content and reducing noise, it maximises information density and slashes token spend - meaning smaller context windows and fewer LLM API calls.

If your architecture relies on strict, explicit database queries, Fast Mode remains your engine. But if you are deploying autonomous agents and want to stop burning tokens on unstructured web scrapes and multi-hop retrieval loops, Smart Mode is your intelligence layer. It shifts the reasoning burden for retrieval from your LLM's context window to our server, delivering the right answer the first time.

*The benchmarks referenced in this post were conducted using a dataset of approximately 200 complex, real-world queries, specifically selected because they are highly representative of the actual requests financial professionals and enterprise clients make. Examples from this dataset include: "What did Tesla's CEO say about FSD progress on the earnings call?", "What are Apple's key risk factors disclosed in their 10-K?”, "Find mentions of AMD in Nvidia's latest earnings call.". To ensure an "apples-to-apples" comparison, results were capped at 20, as many external services max out at this limit (though bigdata.com scales up to 1,000 results per query). We will be publishing a dedicated follow-up post detailing our complete evaluation framework and the full dataset in the near future.