DEV Community: Valyu AI

Building Multi-Agent Research Systems using Vercel AI SDK

Prosper Otemuyiwa — Fri, 13 Mar 2026 13:26:08 +0000

There are many ways to build apps and systems. In today’s AI-native world, the possibilities are endless.

Now imagine you’re tasked with building a multi-agent research system, with one key requirement: don’t over-engineer it.

KISS — Keep It Simple, Stupid.

This is the scenario given to you:

"A friend asked me to pull together everything on Eli Lilly's Q4 results, any ongoing GLP-1 trials they've filed recently, and how the financial press was covering it. Build a multi-agent research system that handles that so you can go accomplish 10 other things while the system gets you the result."

Now, let’s break this down:

Pull together everything on Eli Lilly’s Q4 results
Identify any GLP-1 trials they’ve filed recently
See how the financial press has been covering it

When broken down like this, it’s simply three queries across three completely different domains: SEC filings, clinical trials, and live news.

Three different tools, three different contexts and then stitching it all together manually at the end. It’s similar to the "15-tab" problem.

And it gets worse when you’re building an AI app. You often end up maintaining a research pipeline that’s just a collection of disconnected scripts, held together by copy-paste.

The Architecture

We have three different contexts, so three domains. We'll use the Vercel AI SDK to handle all three domains in parallel.

One query, three specialist agents running simultaneously, and a single synthesized response. With the @valyu/ai-sdk package, plugging in domain-specific data sources takes just one import—no manual tool definitions required.

This is the architecture: the Orchestrator–Worker pattern.

One orchestrator agent understands the query, dispatches the right specialists in parallel, and synthesizes the results. Each specialist has its own tool suite and domain expertise

The tools come from @valyu/ai-sdk, a package that provides ready-made Vercel AI SDK tools backed by Valyu's search API. No manual tool() definitions, no Zod schemas for parameters, no custom execute functions.

Import the tool, drop it into your tools object, done.

Why Parallel Dispatch Matters

Sequential agents are the wrong default for research workloads. Each specialist takes 4-6 seconds.

Three in sequence is 15+ seconds. Three specialists running simultaneously gets you results in the time it takes the slowest one to finish.

Data Flow: From Query to Report

For a query like "What's Eli Lilly's financial position and do their GLP-1 trials support the revenue projections?":

Setup

Install Nextjs and then add the following packages...

pnpm add ai @ai-sdk/anthropic @valyu/ai-sdk @ai-sdk/react zod valyu-js

Create .env.local:

ANTHROPIC_API_KEY=your_key_here
VALYU_API_KEY=your_key_here

Grab your Anthropic and Valyu API keys.

Both keys are read from environment automatically. @valyu/ai-sdk picks up VALYU_API_KEY without any explicit configuration.

Project structure:

research-nexus/
├── src/
│   ├── agents/
│   │   ├── financial-analyst.ts   # Financial analyst
│   │   ├── scientist.ts  # Scientist
│   │   ├── journalist.ts          # Journalist
│   │   └── orchestrator.ts        # Query router + synthesizer
│   └── app/
│       └── api/
│           └── chat/
│               └── route.ts       # Next.js API route
└── package.json

No lib/ or tools/ directories. The tools come pre-built.

The Specialist Agents

Each specialist is a ToolLoopAgent with domain-specific tools from @valyu/ai-sdk. The agent loop lets the model chain multiple tool calls before returning. Searching SEC filings, then cross-referencing earnings, then adding macro context, all within a single agent invocation.

Financial Analyst

import { ToolLoopAgent } from "ai";
import { anthropic } from "@ai-sdk/anthropic";
import { secSearch, financeSearch, economicsSearch } from "@valyu/ai-sdk";

export const financialAnalystAgent = new ToolLoopAgent({
  model: anthropic("claude-haiku-4-5-20251001"),
  instructions: `You are a senior financial analyst specializing in SEC filings, market data, and economic research.

Your capabilities:
- Search and analyze SEC filings (10-K, 10-Q, 8-K, proxy statements)
- Look up financial data including stock prices, earnings, income statements
- Research economic indicators and macro data

When responding:
- Always cite the specific filing type and date
- Present financial figures clearly with proper formatting
- Highlight key risks, trends, and material changes
- Compare metrics across periods when relevant
- Be precise about numbers — never approximate when exact data is available`,
  tools: {
    secSearch: secSearch({ maxNumResults: 3, responseLength: "short" }),
    financeSearch: financeSearch({ maxNumResults: 3, responseLength: "short" }),
    economicsSearch: economicsSearch({ maxNumResults: 3, responseLength: "short" }),
  },
});

financial-analyst.ts

Scientist

import { ToolLoopAgent } from "ai";
import { anthropic } from "@ai-sdk/anthropic";
import { bioSearch, paperSearch } from "@valyu/ai-sdk";

export const medicalResearcherAgent = new ToolLoopAgent({
  model: anthropic("claude-haiku-4-5-20251001"),
  instructions: `You are a medical and life sciences research specialist with expertise in clinical trials, drug discovery, and biomedical literature.

Your capabilities:
- Search clinical trial databases for trial status, results, and endpoints
- Look up FDA drug labels, approvals, and safety information
- Research biomedical literature from PubMed, bioRxiv, and medRxiv
- Analyze academic papers on drugs, therapies, and medical devices

When responding:
- Always cite trial IDs (NCT numbers), DOIs, or publication references
- Clearly distinguish between preliminary and peer-reviewed findings
- Note the phase of clinical trials and their primary endpoints
- Flag any safety concerns or adverse events mentioned in the data
- Use proper medical terminology but explain it when needed`,
  tools: {
    bioSearch: bioSearch({ maxNumResults: 3, responseLength: "short" }),
    paperSearch: paperSearch({ maxNumResults: 3, responseLength: "short" }),
  },
});

scientist.ts

Journalist

import { ToolLoopAgent } from "ai";
import { anthropic } from "@ai-sdk/anthropic";
import { webSearch } from "@valyu/ai-sdk";

export const journalistAgent = new ToolLoopAgent({
  model: anthropic("claude-haiku-4-5-20251001"),
  instructions: `You are an investigative journalist and news analyst with access to real-time web sources.

Your capabilities:
- Search the web for breaking news and current events
- Find and cross-reference multiple news sources on a topic
- Track developing stories and provide timeline context
- Research background on people, organizations, and events

When responding:
- Always attribute information to specific sources
- Present multiple perspectives when covering controversial topics
- Distinguish between confirmed facts and unverified reports
- Provide publication dates so readers know how current the information is
- Summarize key points clearly, then provide supporting details`,
  tools: {
    webSearch: webSearch({ maxNumResults: 5, responseLength: "short" }),
  },
});

journalist.ts

Three agents, three imports from @valyu/ai-sdk, zero custom tool definitions.

The Orchestrator

The orchestrator handles query classification, parallel dispatch, and synthesis.

import { ToolLoopAgent, tool, stepCountIs } from "ai";
import { anthropic } from "@ai-sdk/anthropic";
import { z } from "zod";
import { financialAnalystAgent } from "./financial-analyst";
import { scientistAgent } from "./scientist";
import { journalistAgent } from "./journalist";

const financialAnalystTool = tool({
  description:
    "Delegate to the Financial Analyst agent for SEC filings, stock data, earnings reports, economic indicators, and financial analysis.",
  inputSchema: z.object({
    task: z.string().describe("The financial research task to complete"),
  }),
  execute: async ({ task }, { abortSignal }) => {
    const result = await financialAnalystAgent.generate({
      prompt: task,
      abortSignal,
    });
    return result.text;
  },
});

const scientistTool = tool({
  description:
    "Delegate to the Scientist agent for clinical trials, drug information, FDA data, biomedical papers, and life sciences research.",
  inputSchema: z.object({
    task: z.string().describe("The medical/life sciences research task to complete"),
  }),
  execute: async ({ task }, { abortSignal }) => {
    const result = await scientistAgent.generate({
      prompt: task,
      abortSignal,
    });
    return result.text;
  },
});

const journalistTool = tool({
  description:
    "Delegate to the Journalist agent for real-time news, current events, breaking stories, and web-based research on any topic.",
  inputSchema: z.object({
    task: z.string().describe("The news/research task to complete"),
  }),
  execute: async ({ task }, { abortSignal }) => {
    const result = await journalistAgent.generate({
      prompt: task,
      abortSignal,
    });
    return result.text;
  },
});

export const orchestratorAgent = new ToolLoopAgent({
  model: anthropic("claude-haiku-4-5-20251001"),
  instructions: `You are a research orchestrator that routes queries to specialized agents.

You have three specialist agents available:
1. **Financial Analyst** — SEC filings, stock data, earnings, financial statements, economic data
2. **Scientist** — Clinical trials, drug discovery, FDA data, biomedical papers
3. **Journalist** — Real-time news, current events, web research

Your job:
- Analyze the user's query and delegate to the right specialist(s)
- For questions that span multiple domains, call multiple agents
- Synthesize results from multiple agents into a coherent response
- If a query doesn't fit any specialist, answer it yourself
- Always be clear about which sources informed your response`,
  tools: {
    financialAnalyst: financialAnalystTool,
    scientist: scientistTool,
    journalist: journalistTool,
  },
  stopWhen: stepCountIs(10),
});

The orchestrator agent acts as a smart router. It receives the user's query, analyzes what domains it touches, and delegates work to the right specialist(s).

It doesn't do the research itself. Instead, it calls one or more sub-agents as tools:

Financial Analyst for SEC/market data,
Scientist for clinical trials and biomedical literature,
Journalist for real-time news.

For cross-domain questions like "How does Eli Lilly's GLP-1 pipeline affect their stock outlook?", it calls multiple specialists in sequence.

Sub-Agents as Tools. Each specialist is a ToolLoopAgent wrapped in a tool() call, which makes it callable by the orchestrator just like any other function.

When invoked, the sub-agent runs its own independent loop, calling Valyu search tools (like secSearch or bioSearch), reading the results, and synthesizing a response.

The sub-agent's final text is returned to the orchestrator as the tool's output.

Loop Control. The stopWhen: stepCountIs(10) on the orchestrator caps it at 10 loop iterations to prevent runaway execution. The sub-agents use the default limit of 20 steps. Within those bounds, each agent is free to make multiple tool calls. For example, the Financial Analyst might search SEC filings first, then cross-reference with earnings data, all within a single invocation before returning its findings.

The API Route

// app/api/chat/route.ts
import { createAgentUIStreamResponse } from "ai";
import { orchestratorAgent } from "@/agents/orchestrator";

export async function POST(request: Request) {
  const { messages } = await request.json();

  return createAgentUIStreamResponse({
    agent: orchestratorAgent,
    uiMessages: messages,
  });
}

For the sake of keeping this post short, here’s the repo: multi-agent-research-sys.

You’ll find all the UI pages there. Clone the project and run it locally to explore the full setup.

Running it

pnpm dev

Output:

User entered query

Result shows up

What `@valyu/ai-sdk` Provides

The package ships ten tools that cover the major research verticals:

Tool	Data Sources
`secSearch()`	SEC 10-K, 10-Q, 8-K filings, EDGAR full-text
`financeSearch()`	Stocks, earnings, balance sheets, insider trades, dividends
`economicsSearch()`	FRED, BLS, World Bank, US government spending
`bioSearch()`	ClinicalTrials.gov, DrugBank, ChEMBL, FDA labels, Open Targets
`paperSearch()`	PubMed, arXiv, bioRxiv, medRxiv, academic publishers
`webSearch()`	Real-time web, news, general content
`patentSearch()`	USPTO, global patent databases
`companyResearch()`	Comprehensive company intelligence
`datasources()`	List available data sources
`datasourcesCategories()`	List available categories

Each tool accepts optional configuration: maxNumResults, relevanceThreshold, includedSources for source-level filtering. All read VALYU_API_KEY from the environment by default.

The difference from web only search matters most for the financial and biomedical agents.

A web search for "Eli Lilly 10-K 2024 risk factors" returns SEO articles about the filing. secSearch() returns the actual filing text.
A web search for "tirzepatide Phase 3 results" returns health news coverage. bioSearch() returns the ClinicalTrials.gov entries and DrugBank compound data.
That's primary source access vs secondary commentary. A meaningful difference for research quality.

Extending the System

Adding a fourth specialist (patents, legal, government) requires:

One agent file importing the relevant @valyu/ai-sdk tools
Adding the new agent to the orchestrator

Ten specialists in parallel takes the same wall-clock time as three.

The full code is on GitHub. Clone, run and explore!

Get a Valyu API key at platform.valyu.ai. $10 free credit, no credit card required.

Perplexity Sonar Alternatives for Developers (2026)

Prosper Otemuyiwa — Tue, 10 Mar 2026 12:13:15 +0000

Quick Answer: The best alternatives to Perplexity Sonar for developers are Valyu (for specialised data access + web search + benchmark-leading accuracy), Linkup (for simple web search with predictable pricing), and Tavily (for LangChain/LlamaIndex-integrated RAG).

For Sonar Deep Research specifically, Valyu's DeepResearch API is the only alternative that matches multi-step research with citations while also accessing full-text SEC filings, PubMed, and academic sources that Sonar cannot reach.

I've been building search-grounded AI apps long enough to have a mental list of the API switches that felt obvious in hindsight. Switching off Perplexity Sonar is near the top.

The Sonar API is a capable product. I'm not here to trash it. But if you've been running a production app on Sonar and you've hit the reliability ceiling, the throttling wall, or the "this thing only knows about public web pages" limit, you're not alone, and there are real alternatives now.

This article covers what Perplexity Sonar actually is (the full product family, not just the consumer chatbot), the documented reasons developers switch, and the concrete alternatives for each use case, including a dedicated section on Sonar Deep Research specifically.

What Perplexity Sonar Actually Is

First: Sonar is Perplexity's API product, not the consumer app.

"Perplexity" and "Sonar" are distinct things. Searching for Perplexity alternatives usually returns lists of consumer chatbots (ChatGPT, Claude, etc.). That's the wrong category if you're building as a developer.

The Sonar API family has five models:

Model	Primary Use	Pricing
sonar	Lightweight Q&A, high-volume	$5/1,000 requests
sonar-pro	Deeper content understanding	$8/1,000 requests + tokens
sonar-reasoning-pro	Enhanced multi-step reasoning	$2/M input, $8/M output
sonar-deep-research	Exhaustive multi-step research reports	$2/M input, $8/M output + $5/1,000 searches + $3/M reasoning tokens

sonar-deep-research runs autonomous multi-step research, searches the web multiple times, reasons over what it finds, produces a comprehensive report. Available via Perplexity API and OpenRouter.

The pricing for Deep Research compounds fast. A request that triggers 30 searches costs $0.15 in search fees alone, before tokens.

Why Developers Are Switching

These are documented complaints from /r/perplexity_ai, /r/AI_Agents, and developer comparisons, not personal opinions.

Reliability. One developer documented 20+ daily API outages with the Perplexity status page showing green the entire time. For a production app, that's not workable. The common workaround is building fallback logic, which defeats the point of paying for a managed API.

Intentional throttling. Linkup documented this in their own comparison: Sonar's API accuracy appears deliberately capped to avoid creating a competitive consumer product. Perplexity's primary business is a consumer chatbot. The API is secondary. The engineering priorities show.

The architecture problem. Sonar uses a /chat/completions endpoint, the same pattern as LLM chat APIs. Every API call forces a full text generation. If you only want source URLs for a RAG pipeline, you still pay for a generated answer. For developers who want to control the generation step themselves (use Claude or GPT-4 for generation, use search just for retrieval), this creates a wasteful and expensive architecture.

Linkup measured this...The unpredictability in output token length (ranging from 4 to 340,000 tokens) makes cost-per-query essentially impossible to forecast.

Web-only. This is the hard ceiling. Sonar searches the public web. That's it. No SEC filings, no PubMed, no academic journals, no ChEMBL compound databases, no FRED economic data. If you're building financial analysis tools, biomedical research assistants, or anything that requires authoritative data that lives behind institutional barriers, Sonar hits a wall.

The $5 Pro plan trap. Many developers sign up for Perplexity Pro at $20/month expecting meaningful API access. The Pro plan includes $5/month in API credits. That's roughly 1,000 standard queries at low search depth. A heavy testing session can burn through it in hours.

Alternatives for Standard Sonar Use Cases

Valyu DeepSearch API

The most differentiated option in this category, specifically because it goes beyond web search.

Valyu's DeepSearch API gives you a single endpoint that searches the public web AND 36+ specialised data sources; SEC 10-K, 10-Q, 13F, 13D, 13G filings with full-text search, PubMed and bioRxiv research papers, ChEMBL bioactive compounds, academic journals, FRED and BLS economic data, clinical trials, patent databases.

For developers building anything that needs financial data, biomedical research, academic content, or economic indicators, this is the alternative that actually solves the problem. Sonar doesn't provide reliable data in many of these areas.

On raw web search accuracy, Valyu benchmarks at 79% on FreshQA (600 time-sensitive queries) versus Sonar's architecture which relies on Perplexity's indexed web.

On finance-specific questions, Valyu scores 73% vs Google's 55%.

from valyu import Valyu

client = Valyu(api_key="your-api-key")

# Search web + SEC filings + economic data in one call
response = client.search(
    query="What risk factors did Apple disclose in their most recent 10-K?",
    search_type="all", # web + proprietary
    max_num_results=10
)

print(response)

The MCP server integration means it drops into Claude Desktop, Cursor, and other MCP-compatible tools with zero additional code. Native Vercel AI SDK and LangChain integrations exist.

Platform: platform.valyu.ai | Docs: docs.valyu.ai | Free $10 credit on signup.

Best for: Developers who need specialised data (financial, biomedical, academic, economic) or who want benchmark-leading accuracy on time-sensitive and domain-specific queries.

Linkup

Linkup's pitch is architectural clarity. They expose a dedicated /search endpoint with an outputType parameter, you specify whether you want search_results (clean JSON of sources), answer (generated text), or structured (custom JSON schema). This is fundamentally different from Sonar's chat completion approach.

Pricing is transparent and flat: standard search at €5/1,000 queries, deep search at €50/1,000 queries. No token variability. On SimpleQA benchmarks, Linkup hit 91% vs Sonar's 77.3%.

The one limitation: Linkup is web-only. No specialised data access.

Best for: Developers who want predictable pricing and architectural control over the search/generation split.

Tavily

They are one of the most commonly used search APIs in the LangChain/LlamaIndex ecosystem. Tavily's biggest advantage is installation friction: if you're building a LangChain agent, Tavily is a one-liner. The free tier (1,000 credits/month) is generous enough for development.

Performance is solid. Pricing: $0.008/credit pay-as-you-go, Monthly plans start around $30/month for ~4,000 credits.

Best for: RAG pipelines built on LangChain or LlamaIndex where developer experience and quick integration matter more than maximum accuracy.

Alternatives for Sonar Deep Research Specifically

sonar-deep-research occupies a specific niche: multi-step autonomous research that produces comprehensive reports, not just answers. The use case is different from standard search. You're asking it to do what a human researcher would do over an hour, not just answer a question.

The key question is what you actually need from a deep research API:

Multi-step search execution (runs multiple queries, synthesizes results)
Citations and source references in the output
Access to authoritative data sources, not just indexed web pages
Structured output or webhook support for long-running tasks

On criteria 1, 2, and 3, Valyu's DeepResearch API is the only alternative that matches sonar-deep-research functionally while expanding what it can do.

# Valyu DeepResearch - multi-step autonomous research
# with access to SEC filings, PubMed, academic journals

from valyu import Valyu

client = Valyu(api_key="YOUR_API_KEY")

# Create an async DeepResearch task
task = client.deepresearch.create(
    query="Analyze the financial health of Tesla based on recent SEC filings and analyst sentiment",
    mode="standard",  # also supports: "fast", "heavy", "max"
    output_formats=["markdown"],
    search={
        "search_type": "proprietary",
        "included_sources": ["finance", "academic"]
    }
)

if task.success:
    print(f"Task created: {task.deepresearch_id}")

    # Wait for completion with progress updates
    result = client.deepresearch.wait(
        task.deepresearch_id,
        on_progress=lambda s: print(f"Status: {s.status}")
    )

    if result.status == "completed":
        print(result.output) # markdown report
        print(result.sources)  # cited sources with URLs
        print(result.cost) # fixed task cost

The difference that matters for serious use cases: when Sonar Deep Research researches "clinical trial outcomes for GLP-1 receptor agonists," it's searching whatever's publicly indexed on the web. When Valyu DeepResearch does the same query, it's searching PubMed, ClinicalTrials.gov, FDA drug labels, ChEMBL, and Open Target where the actual source databases where this research lives.

For financial research: Valyu reads the actual 10-K filings, earnings transcripts, and insider trading data. Sonar reads articles about those filings.

Pricing comparison for deep research:

Product	Per Request Cost	Data Sources	Output
Sonar Deep Research	$2/M input + $8/M output + $5/1,000 searches + $3/M reasoning tokens	Public web only	Markdown report
Valyu DeepResearch (fast)	$0.10	Web + 36+ specialised sources	Markdown, PDF, JSON
Valyu DeepResearch (standard)	~$1-3	Web + 36+ specialised sources	Markdown, PDF, JSON
Valyu DeepResearch (max)	$15.00	Web + 36+ specialised sources	Markdown, PDF, JSON, Excel

Valyu also supports webhooks (for async long-running tasks), file analysis, and follow-up instructions, features the Sonar Deep Research endpoint doesn't offer.

Head-to-Head Comparison Table

	Perplexity Sonar	Valyu DeepSearch	Linkup	Tavily
Web search	Yes	Yes	Yes	Yes
Proprietary data	No	36+ sources	No	No
FreshQA accuracy	Not published	79%	Not published	Not published
SimpleQA accuracy	77–86%	94%	91%	Not published
Dedicated search endpoint	No (/chat only)	Yes	Yes	Yes
MCP integration	No	Yes	No	No
LangChain integration	Limited	Yes	Yes	Yes (native)
Webhooks	No	Yes (DeepResearch)	No	No
Predictable pricing	No (token-variable)	Yes	Yes	Yes
Deep research mode	Yes (sonar-deep-research)	Yes (DeepResearch API)	Yes (deep search)	No
Entry price (web search)	$5/1,000 requests	Free $10 credit	€5/1,000 queries	Free 1k credits/mo

Which Alternative for Which Use Case

Building a RAG pipeline on LangChain/LlamaIndex?
Start with Tavily. It's the path of least resistance and performs well. If you hit accuracy issues or need data beyond the public web, move to Valyu.

Building anything that touches financial data?
Valyu. SEC filings, earnings data, stock prices, FRED economic data, balance sheets, insider trading, all in one API call. No other search API comes close for this use case.

Building biomedical or clinical research tools?
Valyu. PubMed, bioRxiv, ClinicalTrials.gov, ChEMBL, DrugBank, Open Targets, FDA drug labels. The Bio app (310 GitHub stars) is a live demo of what's possible.

Need multi-step autonomous research (replacing sonar-deep-research)?
Valyu DeepResearch API. It's the only deep research API that combines multi-step synthesis with access to authoritative specialised databases, plus structured output formats and webhook support.

Pure web search with transparent pricing, no specialised data needed?
Linkup for pricing predictability.

A Note on What Sonar Does Well

Sonar has strong developer documentation, an OpenAI-compatible API format that makes migration easy, and solid performance for general web Q&A tasks. The sonar-reasoning-pro model is genuinely useful for chain-of-thought web-grounded reasoning.

The limitations documented here are real, but they're architectural constraints that come from being a secondary product of a consumer AI company, most likely not signs of bad engineering. If your use case is pure web Q&A at scale and you're happy with the public web as your data universe, Sonar is a viable choice.

The alternatives above exist for when those constraints become blockers.

FAQ

What is the best alternative to Perplexity Sonar API?
Valyu DeepSearch for developers who need specialised data access (finance, biomedical, academic) or benchmark-leading accuracy. Linkup for predictable pricing and architectural control. Tavily for the fastest LangChain/LlamaIndex integration.

What is the best alternative to Perplexity Sonar Deep Research?
Valyu's DeepResearch API is the only alternative that matches sonar-deep-research on multi-step research synthesis while also accessing SEC filings, PubMed, academic journals, and clinical trial data that Sonar cannot reach.

Is Perplexity Sonar web-only?
Yes. All Sonar models (Sonar, Sonar Pro, Sonar Reasoning, Sonar Reasoning Pro, Sonar Deep Research) search only the public web and Perplexity's index. They have no access to SEC filings, academic databases, clinical trials, or other specialised data sources.

Why is Sonar API unreliable?
Perplexity's primary product is a consumer chatbot. The API is a secondary product. Developer forums document 20+ daily outages with no reflection on the official status page. The API capacity and reliability engineering reflects these priorities.

Does Perplexity Sonar have an MCP integration?
Yes. Sonar offers a Model Context Protocol server. Valyu also does. It can be added to Claude Desktop, Cursor, and other MCP-compatible environments with one command: npx skills add valyuAI/skills.

How does sonar-deep-research pricing work?
Sonar Deep Research charges $2/million input tokens, $8/million output tokens, $5 per 1,000 searches (a single request might trigger 30 searches = $0.15 in search fees alone), and $3/million reasoning tokens. The total cost per request is hard to predict and can range significantly based on query complexity.

What is AI Search?

Prosper Otemuyiwa — Wed, 04 Mar 2026 12:10:07 +0000

A developer's guide to understanding AI-native search, how it works, what separates the good from the bad, and what to actually check before picking a provider.

Quick answer: AI search is the ability for an AI system to query external information sources at runtime and retrieve actual content. Not just links, not summaries of summaries, but real data. Without it, an LLM is limited to whatever it saw during training. With it, an LLM can answer questions about earnings calls filed yesterday, drug interactions from the latest clinical trial, or stock prices from three hours ago.
AI search is to an LLM what the internet is to a knowledge worker. It's not optional infrastructure.

Why AI Agents Need Search
AI-Native Search vs Traditional Keyword Search
The Five Things That Need to Be First-Class
- Breadth: Web + Proprietary Sources
- Depth: Content, Not Links
- Freshness: Real-Time, Not Stale Caches
- AI-Native Query Understanding
- LLM Integration: First-Class, Not Bolted On
The Evaluation Checklist
The Good, and the Bad
Benchmark Reality Check
FAQ

Why AI Agents Need Search

Think about what makes a human researcher effective. It is not just memory, it is the ability to go look things up.

A doctor does not rely purely on what they memorized in medical school. They check UpToDate, PubMed, current prescribing guidelines.

A financial analyst does not rely on their training data. They pull the latest 10-K, check earnings transcripts, cross-reference FRED data, check stocks daily.

LLMs face the same constraint. GPT-4o was trained on data with a cutoff. Same with Claude and Gemini. Every model's knowledge stops somewhere. This creates three categories of failure:

Staleness: Asking about anything that changed after the training cutoff returns either a wrong answer or a hedge ("I don't have information beyond...").
Hallucination at the edges: When a model is uncertain, it sometimes fills the gap with plausible-sounding fiction. Real-time retrieval with citations is the structural fix for this.
Coverage gaps: Training data is biased toward publicly crawlable content. SEC filings, paywalled research papers, proprietary financial data, clinical trial databases, most of the professional information infrastructure does not end up in training data at useful fidelity.

Search solves all three. Not by making the model smarter in the abstract, but by giving it access to ground truth at query time.

The pattern that works: LLM receives a question, determines it needs external data, calls a search tool, retrieves real content, reasons over that content, returns a grounded answer with citations. This is the architecture that drives production AI applications in finance, healthcare, legal, transportation and research today.

AI-Native Search vs Traditional Keyword Search

This distinction matters more than most developers realize when they first start building.

Traditional search: The kind behind every enterprise search box built in the past decade and more. It operates on keyword matching. You construct a query like cancer AND (immunotherapy OR checkpoint inhibitor) NOT pediatric and get documents that contain those terms. This works for humans who have time to iterate on queries, scan results, and synthesize across ten browser tabs.

If you have spent any time doing serious research on Google, you know the tricks that have accumulated over the years: site:gov filetype:pdf to find government PDFs, intitle:"annual report" "2024" to find exact-title matches, "exact phrase" -exclusion to filter noise, after:2024-01-01 to constrain by date, or related:competitor.com to find similar sites. Power users have entire mental libraries of these operators. I became an expert at these tricks. Some queries end up looking like:

"PFAS contamination" site:epa.gov OR site:atsdr.cdc.gov filetype:pdf after:2023-01-01 -"press release"

This is not a quirk. It is part of the fundamental design. Google was built for humans who can iteratively refine, scan results, and make judgment calls about relevance. The operator syntax is the escape hatch that power users reach for when natural language search fails them.

AI agents do not work like that. They work like this:

"Get me the stock price of Tesla over the last 30 days"

"What did Pfizer's CFO say about margins in their most recent earnings call?"

"Which clinical trials are currently recruiting for NASH treatment in the US?"

"Get me the rulings and judgements about insider trading that happened in the past 20 days"

These are natural language questions. They imply intent. They require the search layer to understand that "last 30 days" means a dynamic date range, that "earnings call" means looking at SEC filings or earnings transcripts, that "currently recruiting" means filtering on trial status.

An LLM generating a Google query has to translate intent into operator syntax before it can search and then translate SERP results back into content before it can reason. Every translation step introduces error.

An LLM that generates NASH clinical trials recruiting site:clinicaltrials.gov might get results, or it might not, depending on how clinicaltrials.gov structures its content for Google's crawler. The search layer is working against the LLM, not with it.

An AI-native search system handles this natively. You pass natural language, the kind of query an LLM would generate, and the search layer handles the translation to underlying sources, retrieves actual content (not a list of URLs), and returns that content in a format the LLM can reason over directly.

The shift from keyword search to AI-native search is roughly similar to the shift from SQL to natural language database queries. The interface changes, the underlying capability requirements change, and the failure modes change completely.

The Five Things That Need to Be First-Class

When evaluating an AI search provider, five things matter enough that weakness in any one of them might be a dealbreaker for serious use cases.

1. Breadth: Web + Proprietary Sources

Most AI search APIs search the web. That is the table stakes. What separates research-grade search from ordinary search is proprietary source coverage.

The information that actually matters in professional contexts is mostly not just sitting on the open web:

Financial research: SEC filings (10-Ks, 10-Qs, 8-Ks), earnings transcripts, balance sheets, insider trading disclosures - these are on EDGAR but require structured access to be useful for AI
Biomedical research: PubMed, bioRxiv, medRxiv, clinical trial registries, ChEMBL's 2.5 million bioactive compounds, DrugBank, FDA drug labels
Academic research: Full-text multimodal search over ArXiv, PubMed, BioRxiv, MedRxiv, and more. The actual papers, not just the abstracts
Economic data: FRED (Federal Reserve Economic Data), BLS statistics, World Bank indicators
Legal and regulatory: Patent databases, SEC enforcement actions, legislation

But public databases are only part of the picture. The other category of proprietary data is internal, and it is often where the highest-value information lives.

A mid-size law firm's decades of case notes, client briefs, and research memos.
A pharmaceutical company's internal compound testing database that has never been published.
A logistics company's shipment history and carrier performance data. An enterprise sales team's CRM notes and deal history. None of this is on the open web. None of it is in any public database.

But all of it is the kind of context that makes AI responses actually useful for the people inside those organizations.

The right AI search architecture can be plugged into these internal sources too: vector databases, document stores, internal wikis, SQL databases, proprietary APIs.

The more sources a search layer can reach, the more complete its picture of the world. An AI assistant that can simultaneously search PubMed, a biotech company's internal research database, and the latest FDA filings delivers fundamentally different answers than one that is web-only.

This is the compounding advantage of breadth: each additional source does not just add coverage, it adds the ability to cross-reference. "Find mentions of compound X across our internal trial data, published literature, and competitor patent filings" requires all three sources to be reachable in one query. Web-only search makes that impossible by design.

When evaluating breadth, ask specific questions:

Which proprietary sources are integrated, and what is the specific dataset (not just "financial data" but "SEC 10-K filings with full text including MD&A sections")?
Are academic papers full-text or abstract-only?
How many data sources are covered, and can you filter by source type in a single API call?
Does the provider support connecting to custom internal sources, and through what mechanism?

Web-only providers and most of the market is web-only will fail any use case that requires professional-grade data, internal knowledge, or cross-source synthesis.

2. Depth: Content, Not Links

This is the difference between a search API and a web search API wrapper.

A web search wrapper returns a list of URLs with snippets. The LLM then has to decide which links are worth following, potentially trigger additional API calls to retrieve content, and synthesize across multiple round trips. This is slow, expensive, and introduces noise.

AI-native search returns content directly. When you query for "Moderna's RNA platform approach in their 2024 10-K," you should get the actual text from that document, the specific section about their RNA platform, not just a URL to EDGAR where you could theoretically find that document.

Depth also means content quality. The raw HTML of most financial documents is a mess. PDFs are worse. A good search provider handles extraction, normalization, and structuring as part of the retrieval pipeline. You get clean, LLM-ready text, not a soup of HTML tags and formatting artifacts.

Depth indicators to check:

Does the API return full document content or snippets?
What is the content extraction quality on complex document types (PDFs, tables, structured financial data)?
What is the maximum content length per result?
Is there a content extraction endpoint that works separately from search?

3. Freshness: Real-Time, Not Stale Caches

This is where the difference between providers becomes visible in production.

Heavy crawl caching was a reasonable approach for search engines built for human consumption. If a document was crawled three weeks ago, that is probably fine for general-purpose search. For AI agents operating in time-sensitive contexts, it is a critical failure mode.

A recruiter using an AI research tool should not discover that the candidate's current employer is wrong because the AI's search layer cached their LinkedIn profile three months ago. A financial analyst querying recent news should not get results from last month because the search provider's crawl queue is backed up.

The worst pattern is a search provider that advertises "live search" but performs live crawls only as a fallback when the cached version is stale by their internal definition. The result is non-deterministic freshness: sometimes you get today's data, sometimes you get data from three weeks ago, and you cannot tell which you are getting without manual verification.

Real freshness requirements:

News and market data: Minutes, not hours
SEC filings: EDGAR indexes within 5-10 minutes of filing; your search should reflect this
Clinical trial registries: Updates happen continuously. Staleness of more than 24 hours affects research validity
Web content: Varies by use case, but the provider should give you visibility into crawl timestamps

When evaluating a provider's freshness claims, ask for documentation of their crawl frequency and caching policy. Ask whether their "live crawl" option is reliable or an unreliable fallback. Run the same query twice on the same day with different time stamps in the query, and check whether results change.

4. AI-Native Query Understanding

The query interface is the developer experience.

Legacy search APIs require you to construct the query in a format the search engine understands: keyword boolean syntax, specific field names, structured filters. You have to translate the user's intent into the search system's dialect before you can use it.

AI-native search inverts this. You pass natural language, and the search layer handles the translation to underlying sources. This matters across every vertical:

Finance: "What did Tesla's management say about gross margin pressure in the last two earnings calls?" should route to earnings transcripts and SEC filings, not a news summary blog.

Biomedical: "Recent studies on CRISPR off-target effects in vivo" should pull from PubMed and bioRxiv, ranked by recency and citation weight.

Legal: "UK court precedents on contractor misclassification in the gig economy since 2020" should pull from case law databases with correct jurisdictional filtering, not general web results that might cite the wrong legal system or be two years out of date.

Shipping and logistics: "Current Suez Canal transit delays for container ships" should route to live maritime tracking data, port authority feeds, and recent news, not a Wikipedia article about the 2023 blockage.

Prediction markets: "Current odds on the next Federal Reserve rate decision across Polymarket and Kalshi" should pull from those specific markets with live contract prices, not a news article from last week speculating about what the Fed might do.

Each of these queries contains implicit routing logic: which sources are relevant, what time frame applies, what the user actually means by vague terms like "recent" or "current." AI-native search handles this inference layer so the LLM does not have to.

Semantic understanding also matters for result ranking. A keyword search for "risk factors" returns documents containing the phrase "risk factors."

A semantically-aware search returns documents that discuss risk even if the exact phrase does not appear because the model understands that "material uncertainty," "contingent liabilities," and "regulatory exposure" are semantically proximate to the concept of risk.

Test this concretely: Give a provider three natural language queries you would realistically generate from an LLM tool call. Evaluate whether the results are actually what those queries mean, not just documents that contain the keywords.

5. LLM Integration: First-Class, Not Bolted On

How the search API integrates into your AI stack determines the actual developer experience.

First-class integration means:

Tool/function calling format: The API should work as a native tool in OpenAI, Anthropic, and other LLM tool-use patterns. You define the tool once and the LLM decides when to call it and what to pass.
Framework support: LangChain, LlamaIndex, Vercel AI SDK, CrewAI - Your search provider should be a first-class citizen in whichever orchestration layer you use. Not a custom wrapper you have to maintain.
MCP support: Model Context Protocol is now the standard for LLM-to-tool communication. A provider without MCP support adds friction for Claude and Cursor users.
Streaming: For real-time interfaces, the ability to stream results as they arrive matters for perceived performance.
Structured outputs: The LLM often needs search results in a specific schema. Can the search provider return structured JSON directly, or do you have to parse raw text in your application layer?

Bolted-on integration looks like this in practice:

A REST API that returns a single blob of text with no schema, so you have to write custom parsing logic in your application to extract titles, URLs, content, and timestamps separately.
No official SDK or not enough SDKs. You are writing raw HTTP requests or maintaining your own wrapper library that breaks every time the provider changes their response format.
Documentation that shows Python examples only, nothing for TypeScript or Go, and the Python examples use requests instead of an official client.
MCP support that is "in beta" with no ETA, forcing you to write a custom MCP server adapter.
No streaming support, so your UI freezes for 3-5 seconds on every search call while waiting for the full response.
LangChain integration that exists as a third-party community package maintained by one person, not the search provider.
No tool-use JSON schema provided, meaning you have to write your own OpenAI function definition and hope it matches what the API actually accepts.
Rate limit errors that return HTTP 200 with an error field in the body instead of HTTP 429, breaking standard retry logic.
Pagination that requires stateful session tokens the LLM cannot manage across tool calls.

The cumulative effect of bolted-on integration is that you spend engineering time maintaining glue code rather than building your product. This is the quiet cost that does not show up in a pricing comparison but adds up to weeks of engineering time at scale.

The Evaluation Checklist

Use this when running a structured evaluation of AI search providers:

Data Coverage

[ ] Web search included (table stakes)
[ ] Which proprietary sources are included, listed specifically, not categorically
[ ] Full-text access to academic papers (not just abstracts)
[ ] Financial data: SEC filings, earnings, market data
[ ] Biomedical: PubMed, clinical trials, compound databases
[ ] Can you filter by source type in a single API call?
[ ] Does the provider support connecting to internal/custom data sources?

Content Quality

[ ] Returns full document content, not just URLs or snippets
[ ] Clean extraction from PDFs and structured documents
[ ] Table and structured data handling
[ ] Configurable result length

Freshness

[ ] Documented crawl frequency per source type
[ ] Time-to-index for SEC filings (should be under 30 minutes)
[ ] News freshness (should be under 5 minutes for major events)
[ ] No silent caching that makes freshness non-deterministic

Query Interface

[ ] Natural language queries work without manual keyword construction
[ ] Semantic ranking, not just keyword matching
[ ] Handles multi-part queries correctly

Integration

[ ] Official SDK for your language
[ ] LangChain / LlamaIndex integration
[ ] Vercel AI SDK tool integration
[ ] MCP server support
[ ] Streaming support

Reliability and Pricing

[ ] SLA with documented uptime
[ ] Pricing is per-result, not per-request (so you pay for what you get)
[ ] Rate limits are documented and sufficient for your use case
[ ] Transparent pricing for proprietary vs web content

The Good, and the Bad

The Good

Unified search across heterogeneous sources. The right architecture gives you a single API call that can query the web, SEC filings, PubMed, and FRED economic data simultaneously. Your LLM does not need to know which source to use for which question. The search layer figures that out. This is transformative for building research agents: instead of wiring together five different data source integrations, you have one.

Grounded answers that cite sources. When search results are the context for LLM reasoning, the LLM can cite its sources. This changes the trust model completely. A financial analyst can see not just the answer but the specific 10-K paragraph that supports it. A doctor can see which PubMed study the recommendation came from. Grounded answers are auditable; pure LLM answers are not.

Real-time awareness. An LLM with search access is always current. It does not need to be retrained to know about yesterday's earnings call or last week's FDA ruling. This decouples knowledge currency from model versioning, which is a significant architectural win.

Reduced hallucination on factual claims. Hallucinations happen most often when the model is uncertain. It generates confident rubbish. Real-time retrieval gives the model ground truth to reason over rather than forcing it to infer from training data. Benchmark data consistently shows that retrieval-augmented generation outperforms pure LLM generation on factual tasks: 79% accuracy on FreshQA for top-tier AI search vs 39% for Google's standard search.

The Bad

Latency. Search adds round-trip time to every query that requires it. A tool call to retrieve content and return it to the LLM typically adds 1-5 seconds depending on source and query complexity. For real-time interfaces, this is noticeable. Deep research workflows that chain multiple search calls can take 30+ seconds. You need to architect around this with streaming, async patterns, and user feedback mechanisms.

Cost accumulation. At scale, search costs add up quickly. Pricing models vary significantly across providers: some charge per request, some per result, some per character of content returned. A single complex research query that touches multiple sources can cost more than you expect if you have not modeled your usage carefully. Price per 1,000 web searches ranges from $1.50 to $15+ depending on the provider and mode.

Result noise. No search system has perfect precision. At high recall settings, you get relevant results but also irrelevant ones. The LLM then has to distinguish signal from noise in its context window and a bloated context with irrelevant content can actually degrade answer quality. Good search configurations tune precision and recall for the specific use case.

Over-reliance on search. Building an AI system that calls search for every query is not always the right architecture. Some queries are better answered from a fine-tuned model or a curated knowledge base. The skill is knowing when to retrieve and when to rely on the model's parametric knowledge. Indiscriminate search adds latency and cost without improving quality for questions the model already knows well.

Benchmark Reality Check

Here is how top AI search providers perform on standardized benchmarks as of early 2026:

Benchmark	Valyu	Parallel	Exa	Google
FreshQA (600 time-sensitive queries)	79%	52%	24%	39%
SimpleQA (4,326 factual questions)	94%	93%	91%	38%
Finance (120 finance questions)	73%	67%	63%	55%
Economics (100 economics questions)	73%	52%	45%	43%
MedAgent (562 complex medical queries)	48%	42%	44%	45%

A few things worth noting here:

The FreshQA gap between Exa (24%) and top-performing providers (79%) is not a minor implementation difference. It is a fundamental architectural difference in how freshness is handled. Exa's neural search model is built on a large cached index, which delivers excellent semantic relevance on older content but fails on time-sensitive queries. This is a known tradeoff they have publicly acknowledged.

The SimpleQA results show that most providers cluster between 91-94% on factual retrieval tasks. The floor drops significantly for Google (38%) because standard Google search is optimizing for human page-browsing behavior, not LLM-ready content delivery.

Finance and economics benchmarks show the clearest differentiation, because these domains require proprietary source access that web-only providers do not have. A provider that scores 55% on finance questions versus 73% is not just slower, it is genuinely missing data that lives in structured financial databases rather than on the open web.

FAQ

What is the difference between AI search and RAG?

RAG (Retrieval-Augmented Generation) is the broader pattern: retrieve relevant content, add it to the LLM's context, generate an answer. AI search is one implementation of the retrieval component. You can do RAG with a vector database of your own documents, with a search API, or with both. AI search APIs are the external retrieval component, they give your LLM access to content beyond whatever you have locally indexed.

Can AI search replace fine-tuning?

For knowledge tasks, often yes. Fine-tuning embeds knowledge into model weights, which makes it fast to retrieve but expensive to update. Search retrieves knowledge at query time, which is slower but always current. For a financial assistant that needs to know about last week's earnings call, search is the right tool. For a coding assistant that needs to know your internal coding conventions, fine-tuning or RAG on your codebase is better. Most production systems use both.

Why not just use Google Search via the API?

Google's Search API returns links and snippets optimized for human web browsing. It does not return full content. It does not cover proprietary databases. It scores 39% on FreshQA despite being the most-crawled index on earth, because its content format and coverage gaps make it poorly suited to LLM context injection. Google is excellent at finding web pages that humans then read. It is not designed for the LLM use case of retrieving ground-truth content for reasoning.

What does AI-native search actually mean?

It means the search system is designed from the ground up for the query patterns and consumption patterns of AI systems (AI agents, apps, etc) not human users.

Key differences: Natural language queries without keyword syntax, content returned directly rather than URLs to browse, results formatted for LLM context windows, source diversity beyond the open web, and integration patterns (tool calling, MCP, SDK) that fit AI agent architectures.

How do I handle freshness requirements in production?

First, check timestamp metadata on every search result and log it. This gives you visibility into actual freshness rather than relying on provider claims.
Second, separate your use cases by freshness requirement: some queries can tolerate cached results (what is the history of X?), others cannot (what is the current price of X?).

What is the right number of search results to pass to an LLM?

For most use cases: 3-5 results for single-shot Q&A, 10-15 for research tasks that need broad coverage, 1-2 for fact lookup where precision matters more than recall. The tradeoff is context window cost (more results = more tokens = more cost and potentially degraded coherence) vs recall (fewer results = risk of missing the relevant content). Test empirically on your domain rather than using defaults.

Should I build my own search infrastructure or use an API?

For domain-specific corpora you own (internal documents, proprietary databases), build or buy a specialized solution.
For external information access: Web, SEC filings, academic papers, market data, building your own infrastructure means managing crawl infrastructure, database partnerships, content licensing, and extraction pipelines. This is a multi-year engineering effort. Use an API unless search is literally your core product.

What questions should I ask a search provider before signing a contract?

What is your exact crawl frequency for [specific source category relevant to my use case]?
Do you have direct database integrations with [specific databases] or do you scrape the web versions?
What is the maximum content length I can retrieve per result?
What is your SLA and what are the remedies if you miss it?
How are proprietary source costs priced? Per retrieval, per query, or per subscription?

Deep Research API for AI Agents: The Complete Guide (2026)

Prosper Otemuyiwa — Mon, 02 Mar 2026 18:24:14 +0000

I spent three days testing every deep research API I could find. OpenAI's. Perplexity's. Exa's. Parallel's. Gemini's.

They all have the same blind spot: they only search the web.

If your AI agent needs to cross-reference a drug trial with a bioRxiv preprint, or analyze a company's 10-K risk factors alongside FRED economic data, or map a patent landscape against recent academic research, web-only search might not get you there. The data you need most likely isn't indexable by Google or crawlable by search bots.

This guide covers what a deep research API actually is, how the major options compare, and how to build AI agents that can reach proprietary data sources: SEC filings, PubMed, clinical trials, patents in a single API call.

Note: All examples are shown in both Python and TypeScript. Non-developers stay tuned, there's also something for you! 😉

What Is a Deep Research API?

A deep research API is a programmatic interface that performs multi-step, autonomous research on behalf of an AI agent. Unlike a standard search API that returns a list of results, a deep research API:

Plans a research strategy from a query
Executes multiple searches across sources
Reads, synthesizes, and cross-references retrieved content
Returns a structured report with citations

The term entered mainstream usage after OpenAI launched their "deep research" feature in February 2025. Since then, every major AI company has shipped a version. For developers building AI agents, the question isn't whether to use one, it's which one reaches the data you actually need.

Key factors when evaluating a deep research API:

Data source coverage (web-only vs. proprietary databases)
Output formats (markdown, PDF, structured JSON)
The ability to handle deliverables
Async handling (how long tasks run, webhook support)
Pricing model (per task vs. per retrieval)
Benchmark accuracy on domain-specific queries

The Deep Research API Landscape in 2026

Here's what's actually ranking when you search "deep research API" and what each tool can and can't reach:

API	Data Sources	Output Formats	Best For	Pricing
OpenAI Deep Research	Web (Bing)	Text	General research, broad questions	o3: ~$10-30/call ($10/M in, $40/M out); o4-mini: ~$1-3/call ($2/M in, $8/M out)
Perplexity Deep Research	Web	Text	Quick cited answers	Free tier + Pro $20/mo
Parallel.ai	Web	Markdown, JSON	Developer agentic workflows	Per task, usage-based
Gemini Deep Research	Web + Google Search	Text, structured	Google ecosystem integration	Gemini Advanced $20/mo
Valyu DeepResearch	Web + 36+ proprietary (SEC, PubMed, patents, clinical trials, financial data)	Markdown, PDF, structured JSON	AI agents needing authoritative/paywalled data	$0.10-$15.00 per task

On pricing transparency

OpenAI's deep research costs are token-based and can spike quickly. One independent analysis ran 10 test queries and spent $100 on o3-deep-research, $9.18 on o4-mini-deep-research. Both are usage-variable, a research task that cites 50 sources will cost substantially more than one that cites 5.

Valyu's pricing is flat per task regardless of how many internal searches and retrievals the agent performs. For production workloads where cost predictability matters, that's a meaningful difference.

The critical column: Data Sources

Four of the five options above are web-only. That means:

No SEC 10-K/10-Q filings (EDGAR isn't fully indexable by web crawlers)
No paywalled academic papers (Elsevier, Springer, Wiley)
No real-time financial data (stock prices, earnings, balance sheets)
No clinical trial data (ClinicalTrials.gov full text)
No patent claims (USPTO full text)

If your use case lives entirely in open web content, the OpenAI or Perplexity options are fine. If it doesn't, you need an API with proprietary source access.

When Web Search Is Not Enough

Three use cases where web-only deep research fails:

1. Financial research agents

You ask: "What are the key risk factors disclosed by Nvidia in their latest 10-K, and how do they compare to AMD's?"

A web-only API returns news articles about these filings, not the filings themselves. The actual MD&A sections, risk disclosures, and financial statements are in EDGAR. Some might return details about the filings, but simply surface details.

2. Biomedical research agents

You ask: "What bioactive compounds in ChEMBL target the KRAS G12C mutation, and how do they relate to current clinical trials?"

ChEMBL has 2.5 million bioactive molecule records. ClinicalTrials.gov is partially indexed but the structured data (phase, endpoints, eligibility criteria) isn't extractable via web search.

3. Patent landscape analysis

You ask: "Which companies hold patents in transformer-based neural architecture search filed after 2022?"

USPTO full-text patent search isn't something a lot of Search APIs return well. Some return some data but let you know that it might not be complete or recent.

Deep Research API for Researchers & Non-Developers

Valyu has a "Deep Research" UI mode simply for non-developers, researchers and folks from all walks of life to have access to the full power of the Deep Research API simply by prompting what you need.

DeepResearch dashboard for the non-coders

You can see the Deliverables feature there as well. Deliverables allow you to extract structured data or create formatted documents (CSV, Excel, PowerPoint, Word, PDF) from the research alongside the report.

Building with Valyu's Deep Research API (for Developers)

Valyu's DeepResearch is an async API. You submit a task, it runs in the background, you poll for completion or use webhooks. This is the right architecture for research that takes 30 seconds to 15 minutes depending on complexity.

Installation

Python

pip install valyu
export VALYU_API_KEY=your_key_here

TypeScript

pnpm add @valyu/valyu-js
export VALYU_API_KEY=your_key_here

Quick Start

Python

from valyu import Valyu

valyu = Valyu()

# Create a research task
task = valyu.deepresearch.create(
    query="What are the key risk factors disclosed by Nvidia in their 2024 10-K?",
    mode="standard",
    search={
        "search_type": "proprietary",
        "included_sources": ["finance"]  # SEC filings, earnings, market data
    }
)

print(f"Task ID: {task.deepresearch_id}")
print(f"Status: {task.status}")  # 'running' or 'queued'

TypeScript

import { Valyu } from "@valyu/valyu-js";

const valyu = new Valyu(process.env.VALYU_API_KEY!);

// Create a research task
const task = await valyu.deepresearch.create({
  query: "What are the key risk factors disclosed by Nvidia in their 2024 10-K?",
  mode: "standard",
  search: {
    search_type: "proprietary",
    included_sources: ["finance"]  // SEC filings, earnings, market data
  }
});

console.log(`Task ID: ${task.deepresearch_id}`);
console.log(`Status: ${task.status}`);  // 'running' or 'queued'

Waiting for Results

Python

# Wait for completion with progress tracking
def on_progress(status):
    if status.progress:
        print(f"Step {status.progress.current_step}/{status.progress.total_steps}")

result = valyu.deepresearch.wait(
    task.deepresearch_id,
    poll_interval=5,
    max_wait_time=1800,
    on_progress=on_progress
)

if result.status == "completed":
    print(result.output)      # Full markdown report
    print(f"Cost: ${result.cost}")

    for source in result.sources:
        print(f"- {source.title}: {source.url}")

TypeScript

const result = await valyu.deepresearch.wait(task.deepresearch_id, {
  pollInterval: 5000,
  maxWaitTime: 1800000,
  onProgress: (status) => {
    if (status.progress) {
      console.log(`Step ${status.progress.currentStep}/${status.progress.totalSteps}`);
    }
  }
});

if (result.status === "completed") {
  console.log(result.output);      // Full markdown report
  console.log(`Cost: $${result.cost}`);

  result.sources.forEach(source => {
    console.log(`- ${source.title}: ${source.url}`);
  });
}

Research Modes

Valyu has four modes, optimized for different depth/cost tradeoffs:

Mode	Price	Max Steps	Best For
`fast`	$0.10	10	Quick lookups, batch processing
`standard`	$0.50	15	Balanced research
`heavy`	$2.50	15	Complex topics, fact verification
`max`	$15.00	25	Exhaustive multi-source analysis

For most agentic workflows, standard mode hits the right tradeoff. Use fast for high-volume batch tasks. Use heavy or max when you need the agent to cross-verify claims across sources.

Proprietary Source Selection

The search parameter controls which data sources the agent searches.

Python

# Academic + biomedical research
task = valyu.deepresearch.create(
    query="Recent advances in CRISPR base editing for sickle cell disease",
    mode="heavy",
    search={
        "search_type": "proprietary",
        "included_sources": ["academic"]  # PubMed, arXiv, bioRxiv, medRxiv, clinical trials
    }
)

# Financial + economic analysis
task = valyu.deepresearch.create(
    query="How do current FRED interest rate indicators compare to 2008 pre-crisis levels?",
    mode="standard",
    search={
        "search_type": "proprietary",
        "included_sources": ["finance"]  # SEC filings, FRED, BLS, stocks, earnings
    }
)

# Patent landscape
task = valyu.deepresearch.create(
    query="Which companies have filed transformer architecture patents since 2022?",
    mode="heavy",
    search={
        "search_type": "proprietary",
        "included_sources": ["patents"]  # USPTO patent database
    }
)

# Cross-domain: web + proprietary combined
task = valyu.deepresearch.create(
    query="Analyze competitor drug pipeline for NASH treatment",
    mode="max",
    search={
        "search_type": "all",
        "included_sources": ["academic", "finance"]
    }
)

TypeScript

// Academic + biomedical research
const academicTask = await valyu.deepresearch.create({
  query: "Recent advances in CRISPR base editing for sickle cell disease",
  mode: "heavy",
  search: {
    search_type: "proprietary",
    included_sources: ["academic"]  // PubMed, arXiv, bioRxiv, medRxiv, clinical trials
  }
});

// Financial + economic analysis
const financeTask = await valyu.deepresearch.create({
  query: "How do current FRED interest rate indicators compare to 2008 pre-crisis levels?",
  mode: "standard",
  search: {
    search_type: "proprietary",
    included_sources: ["finance"]  // SEC filings, FRED, BLS, stocks, earnings
  }
});

// Patent landscape
const patentTask = await valyu.deepresearch.create({
  query: "Which companies have filed transformer architecture patents since 2022?",
  mode: "heavy",
  search: {
    search_type: "proprietary",
    included_sources: ["patents"]  // USPTO patent database
  }
});

// Cross-domain: web + proprietary combined
const crossTask = await valyu.deepresearch.create({
  query: "Analyze competitor drug pipeline for NASH treatment",
  mode: "max",
  search: {
    search_type: "all",
    included_sources: ["academic", "finance"]
  }
});

Available proprietary source categories: academic, finance, patent, legal, transportation, politics.

Structured JSON Output

Instead of markdown, you can define a schema for structured output, useful when your agent needs to pipe results into a database or downstream process.

Python

competitor_schema = {
    "type": "object",
    "properties": {
        "companies": {
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "name": {"type": "string"},
                    "ticker": {"type": "string"},
                    "key_risk_factors": {
                        "type": "array",
                        "items": {"type": "string"}
                    },
                    "revenue_guidance": {"type": "string"}
                },
                "required": ["name", "key_risk_factors"]
            }
        },
        "summary": {"type": "string"}
    },
    "required": ["companies", "summary"]
}

task = valyu.deepresearch.create(
    query="Extract risk factors and revenue guidance from Q4 2024 10-Ks for major cloud providers",
    mode="heavy",
    output_formats=[competitor_schema],
    search={
        "search_type": "proprietary",
        "included_sources": ["finance"]
    }
)

TypeScript

const competitorSchema = {
  type: "object",
  properties: {
    companies: {
      type: "array",
      items: {
        type: "object",
        properties: {
          name: { type: "string" },
          ticker: { type: "string" },
          key_risk_factors: {
            type: "array",
            items: { type: "string" }
          },
          revenue_guidance: { type: "string" }
        },
        required: ["name", "key_risk_factors"]
      }
    },
    summary: { type: "string" }
  },
  required: ["companies", "summary"]
} as const;

const task = await valyu.deepresearch.create({
  query: "Extract risk factors and revenue guidance from Q4 2024 10-Ks for major cloud providers",
  mode: "heavy",
  output_formats: [competitorSchema],
  search: {
    search_type: "proprietary",
    included_sources: ["finance"]
  }
});

The API returns JSON that conforms to your schema, ready to deserialize directly.

Webhooks for Production

Don't poll in production. Use webhooks.

Python

import hmac
import hashlib
from flask import Flask, request, jsonify

app = Flask(__name__)
WEBHOOK_SECRET = "your-stored-secret"  # returned on task creation, store it

@app.route("/webhooks/deepresearch", methods=["POST"])
def handle_research_complete():
    signature = request.headers.get("X-Webhook-Signature")
    timestamp = request.headers.get("X-Webhook-Timestamp")
    payload = request.get_data(as_text=True)

    signed = f"{timestamp}.{payload}"
    expected = "sha256=" + hmac.new(
        WEBHOOK_SECRET.encode(),
        signed.encode(),
        hashlib.sha256
    ).hexdigest()

    if not hmac.compare_digest(expected, signature):
        return jsonify({"error": "Invalid signature"}), 401

    data = request.json
    if data["status"] == "completed":
        process_research_result(data["deepresearch_id"], data["output"])

    return jsonify({"received": True}), 200


# Task creation with webhook
task = valyu.deepresearch.create(
    query="Comprehensive competitive analysis: SEC filings + market data",
    mode="max",
    webhook_url="https://your-app.com/webhooks/deepresearch"
)
# CRITICAL: store task.webhook_secret immediately - only returned once
store_secret(task.deepresearch_id, task.webhook_secret)

TypeScript

import crypto from "crypto";
import express, { Request, Response } from "express";

const app = express();
app.use(express.raw({ type: "application/json" }));

const WEBHOOK_SECRET = process.env.WEBHOOK_SECRET!;

app.post("/webhooks/deepresearch", (req: Request, res: Response) => {
  const signature = req.headers["x-webhook-signature"] as string;
  const timestamp = req.headers["x-webhook-timestamp"] as string;
  const payload = req.body.toString();

  const signed = `${timestamp}.${payload}`;
  const expected = "sha256=" + crypto
    .createHmac("sha256", WEBHOOK_SECRET)
    .update(signed)
    .digest("hex");

  if (!crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(signature))) {
    return res.status(401).json({ error: "Invalid signature" });
  }

  const data = JSON.parse(payload);
  if (data.status === "completed") {
    processResearchResult(data.deepresearch_id, data.output);
  }

  res.json({ received: true });
});


// Task creation with webhook
const task = await valyu.deepresearch.create({
  query: "Comprehensive competitive analysis: SEC filings + market data",
  mode: "max",
  webhook_url: "https://your-app.com/webhooks/deepresearch"
});
// CRITICAL: store task.webhookSecret immediately - only returned once
await storeSecret(task.deepresearch_id, task.webhook_secret);

Date Filtering

For time-sensitive research tasks, you can pin the search window.

Python

task = valyu.deepresearch.create(
    query="Clinical trial results for GLP-1 receptor agonists in NASH",
    mode="standard",
    search={
        "search_type": "proprietary",
        "included_sources": ["academic"],
        "start_date": "2023-01-01",
        "end_date": "2025-12-31"
    }
)

TypeScript

const task = await valyu.deepresearch.create({
  query: "Clinical trial results for GLP-1 receptor agonists in NASH",
  mode: "standard",
  search: {
    search_type: "proprietary",
    included_sources: ["academic"],
    start_date: "2023-01-01",
    end_date: "2025-12-31"
  }
});

This prevents the agent from pulling in outdated studies. This is very important for medical or financial research where recency matters.

Attach Documents for Analysis & Inclusion

Feed existing documents of all types into the research task. This is useful for combining internal documents with external research.

Python

import base64

with open("internal_q4_report.pdf", "rb") as f:
    pdf_b64 = base64.b64encode(f.read()).decode()

task = valyu.deepresearch.create(
    query="Compare the Q4 projections in this internal report against actual SEC filing data for our competitors",
    mode="heavy",
    files=[{
        "data": f"data:application/pdf;base64,{pdf_b64}",
        "filename": "q4_report.pdf",
        "mediaType": "application/pdf",
        "context": "Internal Q4 2024 financial projections"
    }],
    search={
        "search_type": "proprietary",
        "included_sources": ["finance"]
    }
)

TypeScript

import fs from "fs";

const pdfBuffer = fs.readFileSync("internal_q4_report.pdf");
const pdfB64 = pdfBuffer.toString("base64");

const task = await valyu.deepresearch.create({
  query: "Compare the Q4 projections in this internal report against actual SEC filing data for our competitors",
  mode: "heavy",
  files: [{
    data: `data:application/pdf;base64,${pdfB64}`,
    filename: "q4_report.pdf",
    mediaType: "application/pdf",
    context: "Internal Q4 2024 financial projections"
  }],
  search: {
    search_type: "proprietary",
    included_sources: ["finance"]
  }
});

Deep Research API in Production

"Talk is cheap, show me the code, and show it to me in production" - Odogwu Machalla

Consult Ralph is an AI-powered Deep Research app for consultants. It's in production, currently used by hundreds of consultants daily. The app is heavily powered by Valyu DeepResearch API.

// Detect dark theme var iframe = document.getElementById('tweet-2020959881935962295-93'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2020959881935962295&theme=dark" }

It's also open-source. You can fork, clone, star it and check out the code for good references on how to use the Valyu Deep Research API in your codebase.

Benchmarks

Valyu's DeepResearch scores 53.1 on DeepResearch-Bench. The best published score for any commercial deep research API.

On domain-specific benchmarks where proprietary data access matters:

Benchmark	Valyu	Parallel	Exa	Google
Finance (120 questions)	73%	67%	63%	55%
Economics (100 questions)	73%	52%	45%	43%
MedAgent (562 medical queries)	48%	42%	44%	45%
FreshQA (600 time-sensitive)	79%	52%	24%	39%

The finance and economics gaps are almost entirely explained by proprietary data access. Valyu queries FRED, BLS, and SEC directly. Web-only APIs rely on articles that reference this data, which is noisier and often outdated.

Frequently Asked Questions

What is a deep research API?

A deep research API is a programmatic interface that performs multi-step autonomous research. It accepts a query, plans a research strategy, searches multiple sources, synthesizes results, and returns a structured report with citations. Unlike a standard search API, deep research APIs run asynchronously - tasks can take seconds to minutes depending on depth.

How does Valyu's DeepResearch API differ from OpenAI's?

OpenAI's deep research (o3-deep-research, o4-mini-deep-research) only searches the web via Bing. Valyu's DeepResearch searches both the web and 36+ proprietary data sources including SEC filings, PubMed, arXiv, clinical trials, USPTO patents, FRED economic data, and ChEMBL bioactive compounds. For AI agents that need authoritative domain data rather than general web content, this is the meaningful difference.

What does the Valyu DeepResearch API cost?

Four modes: fast ($0.10/task), standard ($0.50/task), heavy ($2.50/task), max ($15.00/task). Pricing is per task regardless of the number of searches or retrievals the agent performs internally. Signup gets $10 in free credits, no card required.

Does Valyu's deep research API support webhooks?

Yes. Pass a webhook_url on task creation. The API returns a webhook_secret for signature verification. Webhooks fire on task completion or failure with the full output payload. Retries use exponential backoff (up to 5 attempts) on server errors.

Can I get structured JSON output from a deep research API?

Valyu supports custom JSON Schema for structured output. Pass a schema object in output_formats. The API returns output that conforms to your schema, ready to deserialize directly into your application's data structures.

How long does a deep research task take?

Fast mode typically completes in under 60 seconds. Standard mode takes 2-5 minutes. Heavy and max modes can take up to 15-30 minutes for complex multi-source analysis. Use the wait() method with progress callbacks for synchronous use cases, or webhooks for production event-driven workflows.

Can I attach documents to a deep research task?

Yes. Pass files as base64-encoded data with a media type. The API supports PDFs, images (PNG, JPEG, WebP), and other documents. Useful for combining internal documents with external research - for example, analyzing your internal financial projections against publicly filed SEC data.

Is there a TypeScript / JavaScript SDK?

Yes. pnpm add @valyu/valyu-js. The API surface is identical to the Python SDK - all examples in this guide are shown in both languages.

Summary

If you're building AI agents that only research general web content, OpenAI or Perplexity deep research are solid choices, including Valyu. If your agents need to touch SEC filings, academic papers behind paywalls, clinical trial databases, USPTO patents, or real financial data, you need an API with proprietary source access.

Valyu's DeepResearch API:

Four modes from $0.10 (fast) to $15.00 (max)
36+ proprietary data sources across finance, biomedical, academic, patent, and legal domains
Markdown, PDF, and structured JSON output
Webhook and polling support
53.1 on DeepResearch-Bench (best published commercial score)

Docs at docs.valyu.ai/guides/deepresearch.

$10 free credits on signup at platform.valyu.ai.

Why your AI agent keeps hallucinating financial data (and how to fix it)

Prosper Otemuyiwa — Fri, 27 Feb 2026 12:02:18 +0000

You asked your financial agent for NVIDIA's current P/E ratio. It answered: 40.2.

The actual number was 45.65.

You asked it to summarize the key risks from a company's latest 10-K. It cited concerns that were quietly removed two annual reports ago.

You asked for Apple's most recent quarterly revenue. Off by $3 billion.

This is not a hallucination problem in the sense you might think. The LLM isn't randomly generating numbers. It's retrieving the most statistically likely answer from its training data, and doing it confidently. The problem is that financial data has a shelf life measured in hours, sometimes minutes and LLM training data has a shelf life measured in years or months.

This is a data access problem, not an intelligence problem. And it has a clean fix.

Why the training cutoff ruins financial agents

GPT-5.2's training data cuts off is August 31, 2025. Claude 4.6 Sonnet's is August 2025.

Stock prices move by the second. Earnings drop quarterly. The Fed makes a rate decision and markets reprice overnight. A company files an 8-K about a material event and that changes everything. LLMs have none of this.

What makes it worse is that the model doesn't know it's wrong. When you ask for Microsoft's current P/E ratio, it has an answer. That answer was accurate at some point during training. It delivers it with the same confidence as if it just pulled the number off a live exchange. No hedging, no "as of my knowledge cutoff" qualifier, unless you've explicitly prompted for it, and even then it often still gives you a number.

The result: An agent that sounds authoritative while being factually wrong on every time-sensitive financial data point.

For general Q&A this is acceptable. For anything financial, it's a liability.

The two approaches that don't actually work

Approach 1: Prompt the model harder

const result = await generateText({
  model: openai('gpt-5.2'),
  prompt: `You are a financial expert. Always provide accurate,
  up-to-date financial data. Today's date is ${new Date().toISOString()}.
  What is Apple's current stock price?`,
});

This does nothing useful. Telling the model today's date doesn't give it access to today's data. It still answers from training data. Worse, the explicit date sometimes triggers more confident wrong answers because the model pattern-matches "I know this domain" and generates a plausible-sounding number.

Approach 2: RAG with financial documents

Some teams build a RAG pipeline: scrape financial reports, chunk them, embed them, retrieve on query. This is better than nothing but it creates a new set of problems:

You're now responsible for keeping the document store current
Scraped financial documents lose structure (tables, footnotes, cross-references)
Your retrieval quality determines your answer quality
SEC filings alone average 40,000 words. Chunking strategies matter enormously
You're essentially rebuilding a financial data API, badly

The root problem isn’t your retrieval strategy. It’s that you’re trying to solve a live data problem with a static data architecture.

Let’s be honest. It’s 2026. Why are you still building and maintaining your own RAG pipeline from scratch?

Vector DB tuning. Chunking debates. Re-indexing jobs. Infra bills creeping up every month. Edge cases multiplying. It gets expensive fast. And the maintenance burden compounds even faster.

The actual fix: live data as tools

The correct mental model is this: An LLM should reason over financial data, not store it.

The LLM is good at understanding context, synthesizing information, drawing conclusions, and communicating clearly. It's bad at being a database. Stop asking it to be one.

The fix is to give your agent tools that query live financial data at inference time. When the agent needs a stock price, it calls a tool and gets the current price. When it needs SEC filings, it searches them in real time. The LLM never touches a stale number.

Here's what this looks like with the Vercel AI SDK and TypeScript:

Basic setup

pnpm add @valyu/ai-sdk ai @ai-sdk/openai

import { generateText, stepCountIs } from "ai";
import { financeSearch } from "@valyu/ai-sdk";
import { openai } from "@ai-sdk/openai";

const { text } = await generateText({
  model: openai('gpt-5.2'),
  prompt: 'What is the current P/E ratio for NVIDIA and how does it compare to AMD?',
  tools: {
    financeSearch: financeSearch(),
  },
  stopWhen: stepCountIs(5),
});

console.log(text);

When the agent runs this, it doesn't guess. It calls financeSearch with a query, gets back current market data, and reasons over it. The number it tells you is the number that was retrieved from a live source at the moment you asked.

Building a financial research agent

Here's a more complete example, a streaming financial agent you can drop into a Next.js API route:

// app/api/finance/route.ts
import { openai } from '@ai-sdk/openai';
import { financeSearch } from '@valyu/ai-sdk';
import { streamText } from 'ai';

export async function POST(req: Request) {
  const { messages } = await req.json();

  const result = streamText({
    model: openai('gpt-5.2'),
    messages,
    system: `You are a financial analyst with access to real-time market data and SEC filings. When asked about any financial metric, stock price, earnings figure, or company filing, always use your search tool to retrieve current data. Never rely on prior knowledge for financial figures. Cite your sources.`,
    tools: {
      searchFinance: financeSearch(),
    },
  });

  return result.toDataStreamResponse();
}

The critical part is the system prompt instruction: "Always use your search tool to retrieve current data. Never rely on prior knowledge for financial figures."

This forces the agent to go live on every financial query instead of falling back to training data.

Going deeper: SEC filings and Earnings data

Stock prices are the obvious case. But the same problem applies to everything structural: balance sheets, income statements, risk factors, insider transactions, earnings guidance.

Here's how to search SEC filings specifically:

import { Valyu } from "valyu-js";

const valyu = new Valyu();

// Search for specific disclosure language across recent 10-K filings
const response = await valyu.search(
  "material risk factors related to AI compute supply chain 2024",
  {
    searchType: "proprietary",
    includedSources: ["valyu/valyu-sec-filings"],
    maxNumResults: 10,
    responseLength: "large",
  }
);

response.results.forEach((result) => {
  console.log(`Filing: ${result.title}`);
  console.log(`Source: ${result.url}`);
  console.log(`Excerpt: ${result.content.slice(0, 400)}`);
});

This returns actual filing content. Not summaries, not news articles about filings, the actual text from 10-Ks.

Natural language queries work. You don't need ticker symbols or accession numbers.

For combining market data with fundamentals in one agent:

import { generateText, stepCountIs } from "ai";
import { financeSearch } from "@valyu/ai-sdk";
import { openai } from "@ai-sdk/openai";

const { text } = await generateText({
  model: openai('gpt-5.2'),
  prompt: `Analyze Microsoft's financial position: current valuation
  multiples, most recent quarterly earnings vs expectations, and any
  material risk disclosures from their latest 10-K.`,
  tools: {
    finance: financeSearch(),
  },
  stopWhen: stepCountIs(10),
});

The agent will make multiple tool calls. One for market data, one for earnings, one for SEC filings and synthesize the results into a coherent analysis. All from live sources.

Combining multiple financial data sources

The most useful financial agents cross-reference data types. An earnings miss is more meaningful when you can see it alongside the stock reaction, the analyst revision history, and what management said in the 8-K. Here's a multi-source pattern:

import { Valyu } from "valyu-js";

const valyu = new Valyu();

async function analyzeCompany(ticker: string) {
  // Parallel queries across data types
  const [marketData, fundamentals, filings] = await Promise.all([
    valyu.search(`${ticker} stock price market cap volume`, {
      searchType: "proprietary",
      includedSources: ["valyu/valyu-stocks"],
      maxNumResults: 3,
    }),
    valyu.search(`${ticker} earnings revenue EPS most recent quarter`, {
      searchType: "proprietary",
      includedSources: [
        "valyu/valyu-earnings-US",
        "valyu/valyu-income-statement-US",
      ],
      maxNumResults: 5,
    }),
    valyu.search(`${ticker} 10-K risk factors material disclosures`, {
      searchType: "proprietary",
      includedSources: ["valyu/valyu-sec-filings"],
      maxNumResults: 5,
      responseLength: "large",
    }),
  ]);

  return {
    market: marketData.results,
    fundamentals: fundamentals.results,
    filings: filings.results,
  };
}

This is the pattern that makes financial agents actually useful. You're not asking the LLM to recall financial data, you're giving it three live data streams to reason over.

Handling the response in a streaming UI

If you want this in a chat interface, the Vercel AI SDK handles the streaming side cleanly:

// app/page.tsx
'use client';

import { useChat } from 'ai/react';

export default function FinanceAgent() {
  const { messages, input, handleInputChange, handleSubmit, isLoading } = useChat({
    api: '/api/finance',
  });

  return (
    <div className="flex flex-col h-screen max-w-3xl mx-auto p-4">
      <div className="flex-1 overflow-y-auto space-y-4 mb-4">
        {messages.map((message) => (
          <div
            key={message.id}
            className={`flex ${
              message.role === 'user' ? 'justify-end' : 'justify-start'
            }`}
          >
            <div
              className={`rounded-lg px-4 py-2 max-w-2xl ${
                message.role === 'user'
                  ? 'bg-blue-500 text-white'
                  : 'bg-gray-100 text-gray-900'
              }`}
            >
              {message.content}
            </div>
          </div>
        ))}
        {isLoading && (
          <div className="text-gray-400 text-sm">Searching live data...</div>
        )}
      </div>

      <form onSubmit={handleSubmit} className="flex gap-2">
        <input
          value={input}
          onChange={handleInputChange}
          placeholder="Ask about any company or market..."
          className="flex-1 px-4 py-2 border rounded-lg"
          disabled={isLoading}
        />
        <button
          type="submit"
          disabled={isLoading}
          className="px-6 py-2 bg-blue-500 text-white rounded-lg disabled:bg-gray-300"
        >
          {isLoading ? 'Searching...' : 'Ask'}
        </button>
      </form>
    </div>
  );
}

What changes once you do this

The quantitative difference is real. On a benchmark of 120 finance-specific questions, agents using live proprietary data access score 73% accuracy. Agents using GPT with no tool access score significantly lower, and every miss is a confident, plausible-sounding wrong answer.

A more practical scenario: When a user asks your agent about a company's debt-to-equity ratio, they're probably making a decision. The cost of a confidently wrong answer is not a user complaint, it's a user making a bad decision because your tool told them something false with authority.

The architecture shift here is small. You're adding a tool definition and changing a system prompt instruction. The result is an agent that reasons accurately over live financial data instead of pattern-matching from stale training.

FAQ

Q: Does this work with Claude and other models, not just OpenAI?

Yes. The Vercel AI SDK supports any model through their provider system. Swap openai('gpt-5.2') for anthropic('claude-sonnet-4-6') and the tool calling works identically. Financial data tools are model-agnostic.

Q: What financial data sources does this actually cover?

The financeSearch tool routes across stocks (200K+), crypto (200+ coins), forex (180+ pairs), ETFs (25K+), plus company fundamentals, earnings, balance sheets, income statements, cash flows, dividends, insider transactions. And SEC filings (3M+ documents: 10-K, 10-Q, 8-K, Form 4s). All queryable via natural language.

Q: What about FRED economic data and macro indicators?

You can include valyu/valyu-fred and valyu/valyu-bls as sources in the search. Same pattern. Just pass them in includedSources and query in natural language. Useful for macro context alongside company-level data.

Q: How do I avoid the agent making too many tool calls and running up costs?

stopWhen: stepCountIs(N) from the Vercel AI SDK controls the maximum number of tool call steps. For simple queries, stepCountIs(3) is usually enough. For deep research queries, stepCountIs(10) gives more room. You can also set maxPrice on the search tool itself to cap per-result retrieval costs.

Q: Should I still use RAG for financial data?

RAG makes sense for private documents you own. Internal research reports, your own financial models, proprietary analysis. For public financial data (market prices, SEC filings, earnings) that changes continuously, live API access is more appropriate. Don't use static RAG for data that has a freshness requirement.

Q: Does this work for real-time stock prices or just historical data?

Both. Market data has a 1-5 minute delay on real-time prices. Historical data is available going back years. For most analytical use cases, the 1-5 minute delay is irrelevant. If you're building a trading system that requires millisecond precision, you need a dedicated market data feed. For financial research agents, this is more than sufficient.

The code in this article is runnable as-is with a VALYU_API_KEY and OPENAI_API_KEY in your environment.

Full working examples are in the Valyu cookbook on GitHub.

Here's a real-world Finance AI agent - https://finance.valyu.ai. The repo is open-source

If you're building something with this, drop it in the comments. I'm curious what use cases people are working on.

How I Built a Live Stock Market AI Agent in ~40 Lines of TypeScript

Prosper Otemuyiwa — Tue, 24 Feb 2026 11:48:37 +0000

I got tired of jumping between Yahoo Finance, a broker dashboard, and a Google News tab every time I wanted a quick read on a stock. What I actually wanted: type a question, get a grounded answer that pulls live prices, recent earnings, and current news in one shot.

Turns out you can wire this up in an afternoon with Vercel AI SDK and Valyu's financeSearch + webSearch tools. Here's how.

What we're building

A Node.js CLI agent you run like this:

npx tsx agent.ts "What's happening with NVDA? Give me price, recent earnings, and any news I should know about."

It streams back a real answer, not a hallucinated one, pulled from live financial data and current web sources.

Setup

You need two things:

A Valyu API key - free $10 credit when you sign up at platform.valyu.ai
An Anthropic API key (or swap in OpenAI/any other AI SDK provider)

pnpm add ai @ai-sdk/anthropic @valyu/ai-sdk

Create a .env file:

VALYU_API_KEY=your-valyu-key
ANTHROPIC_API_KEY=your-anthropic-key

The agent

// agent.ts
import { streamText, stepCountIs } from "ai";
import { anthropic } from "@ai-sdk/anthropic";
import { financeSearch, webSearch } from "@valyu/ai-sdk";

const query = process.argv[2] ?? "What's the current price and outlook for AAPL?";

const result = streamText({
  model: anthropic("claude-3-5-sonnet-20241022"),
  messages: [
    {
      role: "system",
      content: `You are a stock market analyst with access to live financial data and web search.
- Use financeSearch for stock prices, earnings, dividends, balance sheets, and insider transactions
- Use webSearch for recent news, analyst sentiment, and market context
- Always cite sources
- Be specific: include actual numbers, dates, and figures from your search results`,
    },
    {
      role: "user",
      content: query,
    },
  ],
  tools: {
    financeSearch: financeSearch(),
    webSearch: webSearch(),
  },
  stopWhen: stepCountIs(5),
});

for await (const chunk of result.textStream) {
  process.stdout.write(chunk);
}

console.log("\n");

That's the whole thing. The agent loop is handled by stepCountIs(5), the model keeps calling tools until it has enough data to answer, up to 5 steps.

How it works

When you run it, the agent:

Receives your question
Decides which tools to call (financeSearch, webSearch, or both)
Gets results back. Real prices, actual earnings figures, live news
Synthesizes an answer with citations
Streams it back token by token

The financeSearch tool pulls from stock prices, earnings reports, income statements, balance sheets, dividend history, and insider transaction data. webSearch covers current news, analyst coverage, and anything else on the open web.

For a query like "What's happening with NVDA?" you'd typically see it call financeSearch for price and recent earnings, then webSearch for news about data center demand or any recent analyst upgrades, then combine them into a coherent analysis.

Extending it

A few directions from here:

Add more tools for deeper research:

import { secSearch, economicsSearch } from "@valyu/ai-sdk";

tools: {
  financeSearch: financeSearch(),
  webSearch: webSearch(),
  sec: secSearch(),          // 10-K, 10-Q, 8-K filings
  economics: economicsSearch(), // FRED, BLS macro data
},

Compare multiple tickers:

content: "Compare MSFT and GOOGL on trailing P/E, revenue growth, and recent earnings beats"

The agent will run parallel searches and give you a side-by-side.

Control costs with config options:

financeSearch({
  maxNumResults: 5,        // fewer results = lower cost
  relevanceThreshold: 0.8, // only high-quality matches
})

What the data actually covers

financeSearch isn't just price tickers. It pulls from:

Historical and real-time stock, crypto, and forex prices
Earnings per share, revenue, and guidance
Balance sheets, income statements, cash flow
Insider buy/sell transactions (Form 4 data)
Dividend history

So queries like "How have TSLA insiders been trading over the last 6 months?" or "What's Apple's free cash flow trend since 2021?" work out of the box.

Running it

npx tsx agent.ts "Is AMD a buy right now? Give me current price, latest earnings, and analyst sentiment."

Sample output (abridged):

AMD is currently trading at $X.XX, down X% today...

Recent Earnings (Q4 2024):
- Revenue: $X.XB (beat estimates by X%)
- EPS: $X.XX vs $X.XX expected
- Data center segment grew XX% YoY...

Analyst Sentiment:
According to recent coverage from [source], consensus is...

The numbers are real. The sources are cited. No hallucination.

The Underlying API

Under the hood, @valyu/ai-sdk is a thin wrapper around Valyu's DeepSearch API. If you want to build a custom tool, one that only searches specific financial sources, you can drop down to the raw tool() from the AI SDK:

import { tool } from "ai";
import { z } from "zod";

const cryptoSearch = tool({
  description: "Search cryptocurrency price and market data",
  inputSchema: z.object({
    query: z.string(),
  }),
  execute: async ({ query }) => {
    const response = await fetch("https://api.valyu.ai/v1/search", {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "x-api-key": process.env.VALYU_API_KEY,
      },
      body: JSON.stringify({
        query,
        search_type: "proprietary",
        included_sources: ["valyu/valyu-crypto"],
        max_num_results: 5,
      }),
    });
    return response.json();
  },
});

Full list of available sources and parameters at docs.valyu.ai.

Code

Full example is a single file, agent.ts , above is all you need. If you build something on top of this, the main things to think about are:

System prompt quality matters a lot for financial queries. Be explicit about what each tool is for
stepCountIs(5) is usually enough for single-stock analysis; bump to 8-10 for comparative research
Stream the output for better UX - streamText over generateText

The Valyu finance data covers benchmarks like 73% accuracy on 120 finance questions vs 55% for Google search, which matters when you're asking specific questions about earnings or insider activity where precision is the point.

DEV Community: Valyu AI

Building Multi-Agent Research Systems using Vercel AI SDK

The Architecture

Why Parallel Dispatch Matters

Data Flow: From Query to Report

Setup

The Specialist Agents

Financial Analyst

Scientist

Journalist

The Orchestrator

The API Route

Running it

What @valyu/ai-sdk Provides

Extending the System

Perplexity Sonar Alternatives for Developers (2026)

What Perplexity Sonar Actually Is

Why Developers Are Switching

Alternatives for Standard Sonar Use Cases

Valyu DeepSearch API

Linkup

Tavily

Alternatives for Sonar Deep Research Specifically

Head-to-Head Comparison Table

Which Alternative for Which Use Case

A Note on What Sonar Does Well

FAQ

What is AI Search?

Table of Contents

Why AI Agents Need Search

AI-Native Search vs Traditional Keyword Search

The Five Things That Need to Be First-Class

1. Breadth: Web + Proprietary Sources

2. Depth: Content, Not Links

3. Freshness: Real-Time, Not Stale Caches

4. AI-Native Query Understanding

5. LLM Integration: First-Class, Not Bolted On

The Evaluation Checklist

The Good, and the Bad

The Good

The Bad

Benchmark Reality Check

FAQ

Deep Research API for AI Agents: The Complete Guide (2026)

What Is a Deep Research API?

The Deep Research API Landscape in 2026

On pricing transparency

The critical column: Data Sources

When Web Search Is Not Enough

Deep Research API for Researchers & Non-Developers

Building with Valyu's Deep Research API (for Developers)

Installation

Quick Start

Waiting for Results

Research Modes

Proprietary Source Selection

Structured JSON Output

Webhooks for Production

Date Filtering

Attach Documents for Analysis & Inclusion

Deep Research API in Production

Benchmarks

Frequently Asked Questions

Summary

Why your AI agent keeps hallucinating financial data (and how to fix it)

Why the training cutoff ruins financial agents

The two approaches that don't actually work

Approach 1: Prompt the model harder

Approach 2: RAG with financial documents

The actual fix: live data as tools

Basic setup

Building a financial research agent

Going deeper: SEC filings and Earnings data

Combining multiple financial data sources

Handling the response in a streaming UI

What changes once you do this

FAQ

How I Built a Live Stock Market AI Agent in ~40 Lines of TypeScript

What we're building

Setup

What `@valyu/ai-sdk` Provides