DEV Community: Valyu AI

25+ GPT-6 Astra Creations Every Developer Should See And How to Enrich them with Real World Datasets

Prosper Otemuyiwa — Mon, 07 Sep 2026 11:27:50 +0000

TL;DR: The best GPT-6 Astra examples so far are not simple chatbots. They are playable games, 3D worlds, CAD workflows, Blender experiments, computer-use demos, model-routing tools, and agent orchestration projects. The next step is grounding those creations with real data. That is where Valyu fits: Astra can build the interface or agent loop, while Valyu supplies cited search, research, web content, academic, financial, medical, geospatial, and other datasets.

What is GPT-6 Astra?

GPT-6 Astra is OpenAI’s frontier model for difficult end-to-end work, including coding, tool use, browsing, computer-use workflows, long-context tasks, and professional automation.

The public model ID used in examples is gpt-6-astra.

Useful starting points:

This article focuses on public creations and showcases connected to GPT-6 Astra. It intentionally excludes unrelated Astra results such as Astra DB, AstraZeneca, WordPress Astra themes, and Google Project Astra.

Selection Criteria

I don't want AI-slop, so these were the things I considered:

public demo, repo, creator post, or credible discussion
concrete artifact, not just a vague claim
technically or visually interesting
runnable where possible
no empty repos
no SEO repost farms
no unrelated “Astra” projects

Added Confidence labels to differentiate:

High: public repo and/or live demo with a matching creator/project trail.
Medium: credible public demo, creator post, or repo, but not fully reproducible from the article alone.
Low: thin signal only. I excluded those from the main list.

Best GPT-6 Astra Creations and Showcases

#	Project	Type	Repo	Demo / Evidence	Confidence
1	GPT-6 Astra One-Shot Games	Browser games	GitHub	Melon game, Mosswing	High
2	Red Alert 2 Browser Recreation	Browser RTS	GitHub	Live demo	High
3	Astra Plays GTA Vice City	Computer-use / game agent	GitHub	Creator post	High
4	NULLSPACE	Game project	GitHub	Live site	High
5	Holographic 3D Cards	Blender / Three.js tooling	GitHub	Gallery	High
6	GPTBlender Floor Plan to 3D Model	3D workflow	GitHub	Walkthrough	High
7	Universe Duel	Browser game	—	Live demo, creator post	Medium
8	Elderwood Realms	Multiplayer browser world	—	Live demo, creator post	Medium
9	Rogue Arena Prototype	Game prototype	—	Live demo, creator post	Medium
10	Verdant Forest	3D web scene	—	Live demo, creator post	Medium
11	Seoul 3D Atlas	3D city atlas	—	Live demo, creator post	Medium
12	Walk Through Van Gogh	Interactive 3D world	—	Live demo, creator post	Medium
13	3D Anatomy Site	Educational 3D UI	—	Showcase post	Medium
14	3D Game From Scratch	Game demo	—	Showcase post	Medium
15	Runtime-Generated Trains in Three.js	Procedural 3D	—	Showcase post	Medium
16	Zillow Listing to 3D Promo Video	Real-estate / video workflow	—	Showcase post	Medium
17	Drawing a Portrait in Canva	Computer-use design demo	—	Showcase post	Medium
18	House Photo to Full 3D Model	3D reconstruction	—	Showcase post	Medium
19	Steam Train Blender Build	Blender asset creation	—	Showcase post	Medium
20	KiCad PCB Layout	Electronics / CAD	—	Showcase post	Medium
21	Interactive V8 Engine	Technical visualization	—	Showcase post	Medium
22	Hangzhou in Three.js	3D city scene	—	Showcase post	Medium
23	Robot Arm Control	Robotics / control	—	Showcase post	Medium
24	Agentic CAD Workflow	CAD agent workflow	—	Showcase post	Medium
25	Video Generation Showcase	Creative video workflow	—	Showcase post	Medium

Why These Examples Stand Out

The strongest Astra examples are interesting because they require coordination across multiple layers:

Games need physics, controls, state, rendering, rules, and feel.
3D worlds need spatial reasoning, visual hierarchy, performance, and interaction.
CAD and PCB examples need precision and domain constraints.
Blender workflows need stateful tool use, not just code output.
Computer-use demos require the model to operate real interfaces.
Agent orchestration projects test planning, delegation, routing, and verification.

A static landing page no longer proves much. A playable RTS, a 3D city, a PCB layout, or an agent controlling a game is a more meaningful test.

Useful GPT-6 Astra Tooling and Infrastructure

These are not all “wow” demos, but they are useful if you want to build with Astra.

Project	Repo / Link	Why it matters	Confidence
awesome-gpt-6-astra	https://github.com/Anil-matcha/awesome-gpt-6-astra	Curated index of Astra use cases, prompts, integrations, evaluations, and safety notes	High
MagicCreator Astra Gallery	https://magiccreator.ai/astra	Visual gallery of Astra demos and live links; verify individual entries before citing them separately	Medium
OpenAI Relay for Cursor	https://github.com/coreprocess/openai-relay-for-cursor	Practical relay for Cursor-style workflows	Medium
Astra Advisor	https://github.com/DannyMac180/astra-advisor	Advisor/orchestration-style project	Medium
Task Model Router	https://github.com/LunarXuan/task-model-router	Model-routing experiment for choosing when to use Astra	Medium
Dual Model MCP	https://github.com/Firnschnee/dual-model-mcp	Side-by-side model query harness using MCP	Medium
GPT-6 Astra 100 HTML Files	https://github.com/MiaAI-Lab/GPT-6-Astra-100-HTML-Files	Collection of generated HTML artifacts	Medium

The Missing Piece: Better Data

Many Astra demos prove that the model can create the shell:

a game
a dashboard
a 3D city
a 3D anatomy app
a real-estate promo
an agent workflow
a creative coding tool

But a shell is not a product. To become useful, these creations need grounded data: current facts, citations, structured datasets, research sources, financial filings, academic literature, geospatial data, medical references, patents, life sciences, news, and more.

That is where Valyu fits.

Relevant Valyu APIs:

Valyu API	What it does	Best use case
Search API	`POST /v1/search`	Finds information across web, academic, financial, news, and proprietary sources
Contents API	`POST /v1/contents`	Extracts clean LLM-ready content from URLs
Answer API	`POST /v1/answer`	Produces grounded answers with citations
DeepResearch API	`POST /v1/deepresearch/tasks`	Runs deeper multi-step research tasks
Datasources API	`GET /v1/datasources`, `GET /v1/datasources/categories`, `GET /v1/datasources/search`	Discovers available datasets

Valyu sources span academic, finance/company data, healthcare, Env & Geo, compliance, and web. Examples listed by Valyu include arXiv, bioRxiv, ChemRxiv, PubMed, SEC filings, earnings, stocks, ETFs, ClinicalTrials, DailyMed, PubChem, Open Targets, weather, air quality, disaster sources, sanctions lists, and public web content. Exact availability can change, so agents should confirm source IDs through the Datasources API before hard-coding them.

How Valyu Can Enrich Astra Creations

1. 3D Anatomy Apps

An Astra-generated anatomy app can use Valyu to pull from medical and scientific sources such as PubMed, ClinicalTrials.gov, DailyMed, ICD, PubChem, and Open Targets.

Instead of placeholder labels, the app can show sourced explanations, drug references, condition summaries, and citations.

2. Financial Dashboards

Astra can build the dashboard. Valyu can provide SEC filings, earnings data, stock data, ETF data, commodities, macroeconomic sources, and company research.

That turns a generated finance UI into something closer to a real research product.

3. 3D City Atlases

For demos like Seoul 3D Atlas or Hangzhou in Three.js, Valyu can add weather, air quality, disaster feeds, geocoding, local web context, environmental overlays, and news signals.

The result is not just a pretty map. It becomes a live information interface.

4. Real-Estate Demos

For a Zillow-style 3D promo workflow, Valyu can enrich the output with neighborhood information, weather, air quality, local amenities, risk signals, public web context, and market context.

Astra builds the experience. Valyu grounds the content.

5. Game Worlds

For games and interactive worlds, Valyu can help generate historically grounded settings, climate-informed environments, cultural references, local myths, geography, and current events.

This is how generated game worlds stop feeling generic.

6. Research Assistants

For agentic workflows, Valyu’s DeepResearch API can produce cited reports instead of shallow summaries.

This is useful for scientific research, market research, competitive research, policy analysis, technical literature reviews, and diligence workflows.

Agent Pattern: Astra Builds, Valyu Grounds

The pattern is simple:

Astra creates the app, simulation, game, workflow, or agent.
The agent decides what data it needs.
The agent calls Valyu Search, Contents, Answer, or DeepResearch.
Astra uses the cited results to update the creation.
The app preserves sources instead of hallucinating facts.

Here is a simplified TypeScript-style sketch. It is illustrative, not copy-paste SDK code: it omits x-api-key headers, uses a generic post() helper, and uses a placeholder astra.generate() function.

const valyuTools = {
  search: async (query: string) => {
    return post("https://api.valyu.ai/v1/search", {
      query,
      search_type: "all",
      max_num_results: 10
    });
  },

  contents: async (urls: string[]) => {
    return post("https://api.valyu.ai/v1/contents", {
      urls,
      response_length: "medium",
      extract_effort: "high"
    });
  },

  answer: async (query: string) => {
    return post("https://api.valyu.ai/v1/answer", {
      query
    });
  },

  deepResearch: async (query: string) => {
    return post("https://api.valyu.ai/v1/deepresearch/tasks", {
      query,
      mode: "standard",
      output_formats: ["markdown"]
    });
  }
};

async function enrichAstraCreation(goal: string) {
  const researchPlan = await astra.generate({
    model: "gpt-6-astra",
    input: `
      We are enriching this generated app or demo:

      ${goal}

      Decide whether you need quick search, URL extraction,
      cited answer synthesis, or deep research.

      Return:
      - the best Valyu tool to call
      - the query
      - why that data is needed
    `
  });

  const data = await valyuTools.answer(researchPlan.query);

  return astra.generate({
    model: "gpt-6-astra",
    input: `
      Improve the creation using this cited Valyu data.

      Rules:
      - preserve citations
      - do not invent facts
      - separate sourced facts from generated content
      - keep the UI/game/world coherent

      Goal:
      ${goal}

      Valyu data:
      ${JSON.stringify(data)}
    `
  });
}

Example Prompt: Build a Real World Data Enriched 3D City Atlas

Build a 3D city atlas of Seoul.

Use Valyu to gather:
- current weather
- air quality
- district-level context
- local transport information
- recent public events
- relevant environmental signals

Then create a layered 3D interface where users can toggle:
- weather
- transit
- air quality
- local events
- neighborhood summaries

Every factual panel must include sources.

Example Prompt: Build a Real World Data Enriched Anatomy Explorer

Build a 3D anatomy explorer for the cardiovascular system.

Use Valyu to retrieve:
- PubMed references
- clinical trial context
- drug information from DailyMed
- ICD condition mappings
- plain-English medical explanations

The app should include:
- 3D organ visualization
- sourced condition explanations
- drug references
- citations
- a disclaimer that it is educational, not medical advice

Example Prompt: Build a Real World Data Enriched Real-Estate Experience

Turn this property listing into a 3D interactive promo.

Use Valyu to enrich it with:
- neighborhood context
- weather
- air quality
- local amenities
- disaster or climate risk signals
- local market context

Create:
- a 3D property tour
- a neighborhood summary
- sourced local context cards
- a buyer-facing PDF summary

Best Astra + Valyu App Ideas

If I were building from this trend, I would skip generic chatbots and build one of these:

A cited 3D anatomy explorer
A filing-aware investor dashboard
A live city intelligence atlas
A property research agent
A scientific literature visualizer
A patent landscape explorer
A game world builder grounded in geography and history
A robotics/CAD research assistant
A climate-aware real-estate explorer
A medical education simulator with citations

The common pattern: Astra handles the interface and orchestration; Valyu handles the grounded data layer.

FAQ

What are the best GPT-6 Astra demos?

The strongest public examples I found are GPT-6 Astra One-Shot Games, Red Alert 2 Browser Recreation, Astra Plays GTA Vice City, NULLSPACE, Holographic 3D Cards, GPTBlender floor-plan modeling, Universe Duel, Walk Through Van Gogh, Seoul 3D Atlas, and the KiCad PCB layout showcase.

Are all GPT-6 Astra demos open source?

No. Some of the best examples are live demos or creator posts without GitHub repos. Where a repo exists, I included it. Where it does not, I labeled the item as a demo or social showcase rather than a runnable project.

Why not list 100 GPT-6 Astra creations?

Because I could not verify 100 high-quality examples without including weak or unrelated results. A smaller, cleaner list is more useful than a padded roundup.

How can developers use Valyu with GPT-6 Astra?

Developers can expose Valyu APIs as tools to an Astra-powered agent. The agent can call Valyu Search for source discovery, Contents for URL extraction, Answer for cited synthesis, DeepResearch for longer reports, and Datasources to discover available datasets.

What kinds of Astra apps benefit most from Valyu?

The best fits are apps that need grounded data: 3D atlases, financial dashboards, medical/anatomy explorers, real-estate tools, research assistants, patent explorers, and world building systems.

Final Takeaway

The best GPT-6 Astra examples are not chatbots. They are playable browser games, 3D worlds, CAD workflows, Blender experiments, computer-use demos, model-routing tools, and agent orchestration projects.

But the next wave should be more grounded.

Astra can create the interface. Valyu can provide the real-world data.

That is how impressive demos become useful products.

Investment Research APIs in 2026: 7 DeepResearch Workflows for Deal Teams

Prosper Otemuyiwa — Wed, 26 Aug 2026 17:25:27 +0000

An investment research API gives you the same access to financial information that an analyst gets from a terminal, a filings database, and a browser, except it returns structured, cited output that another program can consume. Many stop at retrieval: you ask for a ticker's fundamentals, you get fundamentals. The harder problem is the work that happens after retrieval, when someone has to read forty sources, reconcile them, and produce a document a director or CIO will put in front of a client or use to make a multi-million pound decision.

The second half is what deep research APIs automate. This article covers seven workflows that run in production today on the Valyu Search and DeepResearch APIs. All of them are built for investment research and banking deal teams, all invocable with a single call and a company name, with every result traced back to the primary source.

TL;DR: the seven workflows

#	Workflow	`workflow_id`	What it answers
1	Company Profile	`ib-company-profile`	What does this company do, how does it make money, what happened recently?
2	Comparable Companies	`ib-comps-analysis`	Who are the real peers, what are they trading at, why does each belong?
3	Precedent Transactions	`ib-precedent-transactions`	What has been paid for assets like this, and under what circumstances?
4	DCF Valuation Reference	`ib-dcf-reference`	What assumptions should a DCF use, and what does the market imply?
5	LBO Screening Analysis	`ib-lbo-screen`	Could a sponsor buy this, and would the returns work?
6	Buyer & Investor List	`ib-buyer-list`	Who would buy this, and why would each one care?
7	Strategic Alternatives Review	`ib-strategic-alternatives`	What paths are available, and what does each one cost?

What is an investment research API?

Teams use investment research APIs to build equity research tools, power AI agents, run screening pipelines, and replace manual data collection.

They fall into three categories, and the distinction matters more than any vendor comparison:

A market data API answers "what is NVDA's EV/EBITDA."
A web data API answers "what does this specific 10-K say."
A research API answers "build me a defensible peer set for NVDA and explain why each comp belongs in it," a question with no single endpoint behind it.

Many production stacks use all three.

The gap between those question types is measurable. Across 4.2 million queries logged through the Valyu DeepResearch API, a single user-facing research question expands, on average, into 11 to 19 sub-queries. An investment thesis request expands into 14 to 22. A market data API serves one of those sub-queries in milliseconds. A research API is the thing that decides which nineteen to ask, runs them, and reconciles the answers.

The seven workflows below sit in the third layer and assume you already have the first two.

The 7 investment research workflows (DeepResearch)

These are ordered the way a deal team actually builds a pitch. Profile first, valuation next, then the strategic layer on top.

1. Company Profile

The question it answers: What does this company actually do, how does it make money, and what has happened to it recently?

Every deal document starts here, which makes it one of the most repeated tasks on any deal team. Someone needs a clean business overview, segment breakdown, revenue composition, management summary, and recent developments assembled from filings, transcripts, and news, with sources attached.

task = valyu.deepresearch.create(
    workflow_id="ib-company-profile",
    workflow_params={"company": "NVIDIA (NVDA)"},
    output_formats=["markdown", "pdf"],
    deliverables=["docx"],
)

result = valyu.deepresearch.wait(task.deepresearch_id)

What comes back: A structured pitch book profile covering business description, segment and geographic revenue split, financial summary, competitive positioning, and a recent-developments timeline. Every claim cites its source.

When to use it: Pitch prep, first-call decks, target screening, onboarding a new coverage name. It is the entry point most teams run first, and the input to most of the others.

2. Comparable Companies

The question it answers: Who are the real peers, what are they trading at, and why does each one belong in the set?

Comps are where analyst judgment and grunt work collide. Pulling multiples is trivial. Defending the peer set is not, and that is the part that gets challenged in a client meeting.

task = valyu.deepresearch.create(
    workflow_id="ib-comps-analysis",
    workflow_params={"company": "Datadog (DDOG)"},
    deliverables=["xlsx"],
    tools={"code_execution": {"enabled": True, "max_calls": 5}},
)

Enabling code_execution matters here. The agent computes the multiples and statistics rather than reproducing numbers it read somewhere, which removes a whole class of transcription error.

What comes back: A peer set with trading multiples (EV/Revenue, EV/EBITDA, P/E), the selection rationale for each name, and summary statistics across the set. The xlsx deliverable drops straight into a model.

When to use it: Valuation sections, fairness work, any time you need a peer set you can defend line by line.

3. Precedent Transactions

The question it answers: What has been paid for assets like this, and what were the circumstances?

Precedent transaction analysis is unusually painful to automate with conventional tools, because deal terms are scattered across press releases, merger proxies, and trade press. Multiples paid are frequently not stated and have to be derived.

task = valyu.deepresearch.create(
    workflow_id="ib-precedent-transactions",
    workflow_params={"sector": "Enterprise search and observability software"},
    search={"start_date": "2019-01-01"},
    deliverables=["xlsx"],
)

The input here is a sub-sector, not a ticker: "Vertical SaaS for healthcare", "Defense electronics", "Specialty insurance brokers". Narrow enough to define a deal set, broad enough that a deal set exists.

The search.start_date parameter is doing real work. Precedents from a different rate environment are actively misleading, and constraining the window is usually the right call. Read it as a bound on which documents get retrieved rather than on which deal dates reach the output: a 2019 floor will still surface a 2015 transaction if a recent source discusses it.

What comes back: A transaction table with acquirer, target, date, deal value, multiples paid, and the strategic context of each deal.

When to use it: Sell-side positioning, board valuation discussions, establishing a defensible premium range.

4. DCF Valuation Reference

The question it answers: What assumptions should a DCF on this company actually use, and what does the market imply?

This workflow does not replace your model. It builds the reference layer underneath it, the assumption set you would otherwise spend a day sourcing and defending.

task = valyu.deepresearch.create(
    workflow_id="ib-dcf-reference",
    workflow_params={"company": "Airbnb (ABNB)"},
    tools={"code_execution": True, "charts": True},
    deliverables=["xlsx"],
)

What comes back: Revenue growth and margin assumptions with sourcing, a WACC build with component inputs, terminal value approaches, and sensitivity ranges. Charts if you enable them.

When to use it: Before you build the model, and again when someone challenges an assumption and you need the provenance.

5. LBO Screening Analysis

The question it answers: Could a sponsor actually buy this, and would the returns work?

A fast structural read on whether a target is financeable. Debt capacity against cash flow, likely structure, sponsor fit, and whether the returns clear a hurdle without heroic assumptions.

task = valyu.deepresearch.create(
    workflow_id="ib-lbo-screen",
    workflow_params={"company": "Ziff Davis (ZD)"},
    tools={"code_execution": {"enabled": True, "max_calls": 8}},
    deliverables=["xlsx"],
)

What comes back: Debt capacity analysis, indicative capital structure, cash flow coverage, sponsor fit assessment, and a returns feasibility view.

When to use it: Sponsor coverage, take-private screening, deciding whether a name is worth full diligence.

6. Buyer & Investor List

The question it answers: Who would buy this, and what is the specific reason each one would care?

Buyer lists are where generic AI output fails most visibly. "Large technology companies" is not a buyer list. A useful one names specific acquirers and articulates the strategic logic per name: adjacency, gap being filled, precedent for similar deals, and capacity to pay.

Its target is free text rather than a ticker, which matches how a sell-side mandate usually arrives. The client is private, so you describe the asset (profitability, scale, category) and the buyer universe follows from that profile rather than from a name.

task = valyu.deepresearch.create(
    workflow_id="ib-buyer-list",
    workflow_params={"target": "A profitable $200M ARR HR-tech SaaS"},
    deliverables=["xlsx", "pptx"],
)

What comes back: Segmented strategic and financial buyer universe with per-buyer rationale, acquisition history, and capacity assessment. The pptx deliverable is built for the sell-side kickoff deck.

When to use it: Sell-side mandates, pitch materials, board discussions about who the natural acquirers are.

7. Strategic Alternatives Review

The question it answers: What are all the paths available to this company, and what does each one cost?

The only heavy mode workflow in the set, running close to 40 minutes at $2.60 against $0.50 for a standard run. The extra depth goes into evaluating sale, IPO, recapitalisation, and standalone paths, then comparing them against each other rather than assessing any one in isolation.

Mode is defined by the workflow itself, so you do not pass it. ib-strategic-alternatives runs heavy by default.

task = valyu.deepresearch.create(
    workflow_id="ib-strategic-alternatives",
    workflow_params={"company": "Peloton (PTON)"},
    previous_reports=[profile_task_id, comps_task_id],
    deliverables=["docx", "pptx"],
)

The parameter worth noting is previous_reports. It chains earlier workflow output into this one, so the strategic review reasons from the profile and comps you already ran instead of rediscovering them. It accepts up to three prior task IDs.

What comes back: Each alternative assessed with valuation implications, execution risk, timing, and stakeholder considerations, plus a comparative recommendation.

When to use it: Board advisory, activist defence, any mandate that begins with "what are our options."

Checking a run before you pay for it

This is the workflow where it pays to look before you spend. At close to forty minutes it is the longest run in the set, and the failure mode you care about is not a bad answer. It is a good answer to a question you did not ask.

workflows.preview() resolves a workflow against your parameters and returns exactly what would run, without starting a task and without spending anything.

preview = valyu.workflows.preview(
    "ib-strategic-alternatives",
    workflow_params={"company": "Peloton (PTON)"},
)

print(preview.resolved.mode)              # "heavy" - budget accordingly
print(preview.resolved.input)             # the fully substituted prompt
print(preview.resolved.research_strategy) # sources and methodology
print(preview.resolved.report_format)     # structure of the output
print(preview.resolved.deliverables)      # files that will be produced

resolved is a ResolvedWorkflowTemplate with six fields: input, research_strategy, report_format, deliverables, mode, and tools. For the strategic alternatives review that surfaces mode: "heavy" and a docx plus xlsx pair, which is what determines the cost in time and money.

Preview also validates. Pass a parameter the workflow does not define and it fails immediately, rather than at task creation:

valyu.workflows.preview("ib-buyer-list", workflow_params={"company": "Confluent (CFLT)"})
# success: False | error: 2 validation errors    <- key is "target", not "company"

valyu.workflows.preview("ib-buyer-list", workflow_params={"target": "Confluent (CFLT)"})
# success: True

Because preview costs nothing and returns instantly, it is the one control that composes with a parallel batch, which is where the next section picks it up.

Production patterns

Constrain sources deliberately. search.search_type accepts all, web, or proprietary. For workflows that must not cite blog speculation, restrict to proprietary. source_biases lets you weight sources from -5 to +5 rather than excluding them outright, which is usually the better instrument.

Pin versions in production, float in staging. Workflows are in beta and templates improve. Pin workflow_version anywhere a parser depends on the shape of the output.

Preview before you spend. workflows.preview() is free, instant, and catches a malformed parameter set before it becomes a billed run. Make it the default pre-flight in any pipeline. It is the cheapest control you have over a process that otherwise runs for half an hour before telling you anything.

Inspect the template, do not guess at it. workflows.get(slug) returns the typed variables, so you can check the parameter name and whether it is required before wiring anything up. preview() goes further and shows the resolved mode, which is what tells you whether to budget twelve minutes or forty.

detail = valyu.workflows.get("ib-strategic-alternatives")
for variable in detail.workflow.variables:
    print(variable.key, variable.required)

check = valyu.workflows.preview(
    "ib-strategic-alternatives",
    workflow_params={"company": "Peloton (PTON)"},
)
print(check.resolved.mode)           # heavy - budget accordingly
print(check.resolved.deliverables)

Track long runs by status, not by blocking. deepresearch.status(task_id) returns a DeepResearchStatus: queued, running, completed, failed, and cancelled, plus paused and awaiting_input if you have enabled a checkpoint, alongside the cost and the generated deliverables. Tag each task with metadata at creation and you can reconcile a whole batch afterwards without holding six threads open.

Structured output for pipelines. Pass a JSON Schema object in output_formats when the consumer is a database or dashboard rather than a person. Use deliverables when the consumer is a banker who wants an XLSX.

Chaining them: the full pitch-book pass

The workflows are individually useful and considerably more useful composed. A complete first-pass pitch book on a single target:

import concurrent.futures

COMPANY = "Snowflake (SNOW)"

# Each workflow declares its own variable key - comps and buyer list take
# "target", precedent transactions takes "sector".
FOUNDATION = [
    ("ib-company-profile",        {"company": COMPANY}),
    ("ib-comps-analysis",         {"target":  COMPANY}),
    ("ib-precedent-transactions", {"sector":  "Cloud data warehousing and analytics"}),
    ("ib-dcf-reference",          {"company": COMPANY}),
    ("ib-lbo-screen",             {"company": COMPANY}),
    ("ib-buyer-list",             {"target":  COMPANY}),
]

def run(item):
    slug, params = item
    task = valyu.deepresearch.create(
        workflow_id=slug,
        workflow_params=params,
        workflow_version=1,
        deliverables=["xlsx"],
        metadata={"deal": "project-frost", "slug": slug},
    )
    return valyu.deepresearch.wait(task.deepresearch_id)

# Free pre-flight: validate every parameter set before anything is billed
for slug, params in FOUNDATION:
    check = valyu.workflows.preview(slug, workflow_params=params)
    if not check.success:
        raise ValueError(f"{slug}: {check.error}")

results, failed = [], {}
with concurrent.futures.ThreadPoolExecutor(max_workers=6) as pool:
    pending = {pool.submit(run, item): item[0] for item in FOUNDATION}
    for future in concurrent.futures.as_completed(pending):
        try:
            results.append(future.result())
        except Exception as exc:   # keep the five that worked
            failed[pending[future]] = exc

# Strategic review reasons over everything above
strategic = valyu.deepresearch.create(
    workflow_id="ib-strategic-alternatives",
    workflow_params={"company": COMPANY},
    previous_reports=[r.deepresearch_id for r in results][:3],
    deliverables=["docx", "pptx"],
)

On a recent full pass against Snowflake, the six parallel standard runs completed in 26 minutes, the fastest at 12, the slowest two at 25 and 26, since the batch only finishes when its slowest member does. The heavy strategic review added a further 39. Total wall clock was a little over an hour, total cost $5.80, and the output was seven cited documents in formats a deal team already works in.

Budget by the slowest workflow rather than the average. If you need a faster first look, run the foundation six and start reading those while the strategic review finishes. Nothing downstream blocks on it except the review itself.

Note workflow_version=1 pinned explicitly, and metadata tagging every task with a deal code. Both are small habits that pay for themselves the first time you need to audit what produced a number.

Collect results with as_completed rather than pool.map. map re-raises the first exception when you iterate it, so a single failed run discards the five that succeeded, after you have already paid for them and waited 26 minutes. Gathering failures into a dict instead lets you retry the one that broke.

What changes for deal teams

The honest framing is not that these workflows replace analysts. They collapse the retrieval and first-draft phase of work that currently occupies the first days of every mandate.

We have the numbers on what that phase costs. Looking at six months of financial query traffic across 4.2 million API queries, a single investment thesis run resolves in about 75 minutes of agent time at roughly $50, against 14 to 18 analyst hours for the equivalent output, work a junior analyst would take three to five days to produce.

The seven workflows in this article are the productised version of that same pattern, scoped tighter. The same dataset shows where this is already concentrated. Traditional research (investment theses, filings, and transcripts) accounts for 57% of query volume, and 74% of sell-side queries fall into that bucket. These are not speculative use cases. They are the majority of what financial research traffic already looks like.

The analyst's job moves to where it should have been: challenging the peer set, pressure-testing assumptions, and forming the view. The workflows handle the part that was never judgment in the first place.

Frequently asked questions

What are the three types of investment research API?

Market data APIs return structured numeric series. Web data APIs return raw page content. Research APIs return synthesised, cited analysis built from many sources. Most production stacks use all three, because each answers a question the other two cannot.

How is a deep research API different from a market data API?

A market data API answers questions with a schema behind them, like a ticker's EV/EBITDA, in milliseconds. A deep research API answers questions with no single endpoint behind them, like building a defensible peer set with rationale, by running multi-step research across many sources over several minutes.

What are the 7 investment banking workflows in Valyu?

Company Profile, Comparable Companies, Precedent Transactions, DCF Valuation Reference, LBO Screening Analysis, Buyer & Investor List, and Strategic Alternatives Review.

Can I create my own workflows?

Yes. Custom workflows are defined with a slug, title, and version containing a prompt, research strategy, report format, and typed variables with key, label, and required fields. They appear in workflows.list() alongside the Valyu-published catalogue.

How do I discover available workflows programmatically?

Call valyu.workflows.list(scope="valyu", vertical="investment-banking"). The scope filter selects between Valyu-published and your organisation's own workflows; vertical filters by industry category.

What output formats are supported?

output_formats accepts markdown, pdf, or a JSON Schema object for structured output. deliverables generates files in csv, xlsx, pptx, docx, or pdf. Structured output suits pipelines; deliverables suit humans.

Are the outputs cited?

Yes. Every claim carries citations to source documents, which is what makes the output usable in regulated and client-facing contexts rather than only for internal exploration.

Can workflows build on each other?

Yes. previous_reports accepts up to three prior task IDs, so a downstream workflow reasons from earlier output rather than rediscovering it. Chaining the profile and comps into the strategic alternatives review is the common pattern.

How do I keep output stable as workflows improve?

Pin workflow_version in production. Version 1 continues returning the same structure after the template is revised, so downstream parsers do not break when a prompt improves.

Literature-in-the-Loop: Citation-Grounded Triage for AI Protein Design

Prosper Otemuyiwa — Wed, 26 Aug 2026 11:31:00 +0000

Quick answer: Lab-in-the-loop protein and antibody design generates tens of thousands of candidates per cycle but tests a few hundred. What lab-in-the-loop needs is literature-in-the-loop: a citation-grounded evidence-ranking step between generation and assay selection that retrieves published structures, affinities, homologous sequences, and negative results to rerank candidates, while reserving explicit capacity for novel designs.

The gap between what gets generated and what gets tested

The scale of the mismatch is documented. In Genentech/Prescient Design's lab-in-the-loop antibody design system, the generative methods "may produce up to 30,000 designs per lead molecule" in a single round. Across four rounds, four clinically relevant targets (EGFR, IL-6, HER2, and OSM), and ten lead molecules, more than 1,800 unique antibody variants were actually designed, synthesised, and tested.

Averaged out, that is roughly 45 variants assayed per lead molecule per round against a generation ceiling of 30,000. That gap is closer to three orders of magnitude than two. Every candidate that occupies an assay slot displaces another. Which means the ranking function that fills the queue is one of the highest-leverage components in the entire pipeline, and it is usually built from model-internal signals alone.

Published lab-in-the-loop systems do not describe a literature-based evidence-ranking step between generation and assay selection. Candidates are ranked on model confidence, predicted structure quality, and predicted binding. These three signals answer fundamentally different questions. When they are treated as interchangeable, candidates with strong prior literature support can be deprioritised relative to novel designs that happen to score well under a model's internal metric.

Lab-in-the-loop needs literature-in-the-loop: a triage layer that retrieves published structural, sequence, and affinity data to rerank candidates before wet-lab slots are allocated. Not as a veto gate that eliminates novel binders, but as a layer that enriches the assay queue with evidence-supported candidates while reserving explicit capacity for genuinely novel architectures.

Why ranking breaks when signals are treated as interchangeable

The standard design-to-assay loop works like this: a generative model proposes a batch of sequences, each annotated with predicted properties, and a ranking system selects which candidates to synthesise and test.

The Prescient/Genentech system annotates generated designs with predicted expression, binding affinity, and non-specificity. Worth being precise about how those labels are constructed, because it is the crux of the problem. From the paper:

All properties have associated binary labels (e.g., 1:1 binding to target antigen is or is not detected by SPR at a fixed concentration) modeled by binary classifiers, and expression yield and binding affinity are modeled as scalars.

So binding ground truth is a binary readout from SPR at a single fixed concentration, alongside scalar regressors for yield and affinity. That is a perfectly reasonable experimental design. The problem arises downstream, when teams treat these heterogeneous predictions as interchangeable proxies for "this candidate will work."

pLDDT measures structural self-consistency, not binding

pLDDT (predicted Local Distance Difference Test) is AlphaFold2's per-residue confidence score, ranging from 0 to 100, estimating agreement between predicted Cα positions and the unknown true structure. Scores above 90 indicate accuracy comparable to experimentally determined structures; 70 to 90 is generally sufficient for backbone prediction; below 70 requires careful interpretation. AlphaFold's own guidance is that long regions below 50 "should not be interpreted" as structure at all, but read as a prediction of disorder.

A model can place every residue with high pLDDT and still produce a loop conformation at the paratope, or an interface geometry, that is incompatible with binding. High pLDDT means the model agrees with itself.

Predicted binding is a weak classifier, and there is a number for it

Predicted binding, whether from docking, interface energy calculations, or specialised classifiers, attempts to estimate the likelihood or strength of an interaction. This is a separate question from structural confidence, and current metrics are not good at it.

The Adaptyv EGFR binder design competition analysis (Cotet et al., 2025) evaluated structure-prediction confidence scores against experimental outcomes across the competition's characterised designs. ipTM (interface predicted TM-score) achieved an AUROC of 0.64 for binding classification. The authors concluded these metrics were "insufficiently predictive of true experimental binding probability or affinity."

An AUROC of 0.64 sits modestly above the random baseline of 0.5. It carries real signal. It is not a defensible sole selection criterion for a resource as expensive as an assay slot.

Model confidence measures the model, not reality

Log-likelihood, pLDDT of the designed structure, or a classifier output on a held-out validation set measures the model's internal consistency and its agreement with its training distribution, not its agreement with physical reality.

Treating these three as interchangeable creates two failure modes:

High-confidence-but-physically-wrong candidates consume assay slots.
Candidates with lower model confidence but strong prior literature support get deprioritised in favour of novel designs that score well on a model-internal metric.

The second failure mode is the expensive one, because it is invisible. Nobody logs the binder you never tested.

Where literature-in-the-loop triage sits

The triage step belongs between candidate generation and assay queue assembly: after the generative model has produced a batch, before wet-lab slots are allocated.

It is not a replacement for the model's own ranking. It is a re-ranking layer that supplements model outputs with external evidence the model did not see at training time or could not fully encode.

For each candidate, the triage step should produce an evidence packet containing:

Target biology context: published mechanism, expression pattern, and known functional domains of the target antigen, with source citations.
Epitope and accessibility evidence: known linear or conformational epitopes, structural surface accessibility from experimental or predicted structures, and published epitope mapping data.
Homologous sequence evidence: closest known antibody or protein sequences by CDR similarity, framework identity, or full-chain alignment, with sequence identity percentages and source references.
Known structures: PDB entries for the target, for antibodies against the same target, and for the candidate's predicted fold, with resolution and method noted.
Measured affinities: published KD, IC50, Ki, or EC50 values for antibodies or proteins against the same target or epitope, with assay type and conditions recorded.
Negative and conflicting results: published reports of non-binding, cross-reactivity, aggregation, or failed expression for related sequences, flagged separately from positive evidence.
Source quality and uncertainty: per evidence item, peer-reviewed vs. preprint, assay type (SPR, BLI, ELISA, cell-based), measurement reproducibility, and whether the result has been independently confirmed.

The packet should be machine-readable for automated reranking and human-readable for review of ambiguous cases.

Here is a concrete retrieval step for one candidate, using the Valyu TypeScript SDK:

import { Valyu } from "valyu-js";

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

// search(query, options): query is positional, options are camelCase.
const literatureResponse = await valyu.search(
  "anti-HER2 antibody CDR-H3 binding affinity epitope SPR",
  {
    searchType: "proprietary",
    includedSources: ["valyu/valyu-pubmed", "valyu/valyu-biorxiv"],
    maxNumResults: 15,
    startDate: "2015-01-01", // plain hyphens; YYYY-MM-DD is validated
  },
);

// Each result carries a primary source URL, a source identifier, and a
// relevance score. The triage layer joins these items with sequence and
// structural evidence before reranking the candidate.
const evidencePacket = literatureResponse.results.map((r) => ({
  title: r.title,
  url: r.url,
  source: r.source,
  relevance: r.relevance_score,
  excerpt: r.content,
}));

Which evidence should influence ranking, and how to represent uncertainty

Not all evidence carries equal weight. A high-affinity SPR measurement for a homologous antibody against the same epitope is a fundamentally different kind of claim than a qualitative ELISA binding report for a distantly related sequence. The ranking system must encode this hierarchy explicitly.

Target biology establishes functional context: whether the target is a receptor with a known active site, a shed antigen, or a membrane protein with restricted epitope accessibility. This constrains which epitopes are plausible and which design strategies have precedent.

Epitope accessibility determines whether a binder can physically reach its target. A structurally buried epitope on the native conformation may not be accessible in vivo. Published epitope mapping (alanine scanning, hydrogen–deuterium exchange, cryo-EM reconstructions) provides direct evidence of which surface patches are exposed.

Homologous sequences offer the strongest signal for novel candidates. If a generated CDR-H3 shares significant similarity with a known binder against the same target, that is a positive signal; similarity to a known non-binder, or to a binder against an unrelated target, is a cautionary one. Similarity is most informative at the CDR level, where variation most directly relates to binding, rather than at the framework level where germline similarity is common and uninformative.

Known structures provide geometric constraints. If a PDB structure of an antibody–target complex exists, the paratope–epitope interface geometry is known, and a candidate predicted to occupy a similar geometry has structural precedent. Resolution matters: higher-resolution structures provide stronger geometric evidence.

Measured affinities provide quantitative anchors. ChEMBL 37 (prepared 1 May 2026) contains 2,921,148 distinct compounds, 24,527,044 activities across 1,970,438 assays, and 18,552 targets. Critically, ChEMBL classifies assay data into Binding (B), Functional (F), ADME (A), Toxicity (T), and Physicochemical (P) types, plus Unclassified (U), so a KD from a binding assay is machine-distinguishable from a functional cell-based readout.

That distinction is the whole point. A retrieval step for measured affinities must keep the source identifier and assay type attached to every measurement, so the ranking function never treats a ChEMBL KD and a qualitative PubMed observation as the same kind of evidence:

const affinityResponse = await valyu.search(
  "HER2 antibody KD IC50 Ki binding affinity assay",
  {
    searchType: "proprietary",
    includedSources: ["valyu/valyu-chembl", "valyu/valyu-pubmed"],
    maxNumResults: 25,
  },
);

// Literature writes affinities in two orders. Matching only one of them
// silently drops most of the corpus. "KD = 5 nM" is far more common in
// prose than "5 nM (KD)".
const LABEL = String.raw`K[Dd]|IC50|EC50|K[Ii]`;
const VALUE = String.raw`(\d+(?:\.\d+)?)\s*(pM|nM|µM|uM|mM)`;

const labelFirst = new RegExp(`(${LABEL})\\s*(?:=|≈|~|:|of)?\\s*${VALUE}`, "g");
const valueFirst = new RegExp(`${VALUE}\\s*\\(?(${LABEL})\\)?`, "g");

const measurements = affinityResponse.results.flatMap((r) => {
  // content is `string | object | any[]`. Structured records (data_type
  // === "structured") arrive as objects and should be read as fields;
  // regex is only for the unstructured prose path.
  if (typeof r.content !== "string") return [];

  const fromLabelFirst = [...r.content.matchAll(labelFirst)].map((m) => ({
    assayType: m[1].toUpperCase(),
    value: parseFloat(m[2]),
    unit: m[3],
  }));

  const fromValueFirst = [...r.content.matchAll(valueFirst)].map((m) => ({
    assayType: m[3].toUpperCase(),
    value: parseFloat(m[1]),
    unit: m[2],
  }));

  return [...fromLabelFirst, ...fromValueFirst].map((m) => ({
    ...m,
    sourceUrl: r.url,
    sourceId: r.source,      // log this once to confirm the exact string
    relevance: r.relevance_score,
  }));
});

const chemblMeasurements = measurements.filter(
  (m) => m.sourceId === "valyu/valyu-chembl",
);
const literatureMeasurements = measurements.filter(
  (m) => m.sourceId === "valyu/valyu-pubmed",
);

ChEMBL returns structured bioactivity records; PubMed hits are frequently qualitative. Keeping the source identifier explicit is part of representing uncertainty. If a query returns no measurements at all, that coverage gap is itself a first-class output, not something to bury inside an averaged confidence score.

How evidence reranks without becoming a hard gate

The central risk of literature-in-the-loop triage is that it degenerates into a novelty penalty: candidates with no prior literature support get systematically deprioritised, and the assay queue fills with minor variants of known binders. This is the exploration-versus-exploitation problem in active learning, applied to wet-lab selection.

Three mechanisms prevent the collapse.

1. An explicit exploration budget. Reserve a meaningful fraction of assay slots for candidates the evidence step scores as low-evidence but the generative model scores as high-confidence or high-novelty. Label them as exploration candidates and track them separately. The budget structurally prevents the ranking system from optimising purely for prior support.

2. A novelty-conditional scoring function. Rather than ranking all candidates on a single evidence score, compute a conditional one: for candidates with close literature analogues, weight evidence heavily; for candidates in sparsely populated regions of sequence or structure space, weight evidence lightly and lean on model confidence and structural plausibility. The function should be transparent and auditable, not a black-box reranker.

3. Human review for ambiguous cases. Flag candidates where evidence conflicts, where the closest homolog is a known non-binder, or where the epitope is disputed in the literature. A computational biologist or antibody engineer with the full evidence packet can make a judgment that automated ranking cannot. This is not a failure of automation. It is an acknowledgment that some decisions require domain expertise no ranking function fully encodes.

The output is a reranked queue with three tiers: evidence-supported, exploration, and flagged for human review. Assay slots are allocated across tiers according to the exploration budget, not purely by score.

A transparent retrospective protocol

The value of literature-in-the-loop triage can be assessed retrospectively using a public antibody lineage with a documented history of measured affinities and validation outcomes.

The anti-HER2 lineage suits this well. The murine monoclonal 4D5 was described in Hudziak et al., 1989 (Mol Cell Biol) and humanized onto a consensus human IgG1 framework to produce trastuzumab in Carter et al., 1992. The lineage continues through trastuzumab-based antibody–drug conjugates (ado-trastuzumab emtansine and trastuzumab deruxtecan), which retain the 4D5-derived variable domains.

One clarification that matters for this protocol: pertuzumab is not in the 4D5 lineage. It is rhuMAb 2C4, derived from a separate murine parent antibody and binding a distinct epitope on HER2 domain II (the dimerization arm), where trastuzumab binds domain IV. It is a same-target, different-lineage antibody. In a protocol whose ranking turns on CDR-level sequence homology, conflating the two would produce meaningless results. Treat it as a useful negative control for homology-based ranking instead: a clinically successful anti-HER2 antibody that CDR similarity to 4D5 should not, and does not, predict.

The protocol:

Define the candidate set. Assemble a panel representing the known lineage (the parent antibody, intermediate variants described in the literature, clinical candidates) plus computationally generated decoys or variants absent from the historical record.
Set a historical evidence cutoff. Choose a date preceding the clinical disclosure of later-generation antibodies in the lineage, and retrieve only literature and bioactivity data published before it. This simulates what the triage system would have known at that point.
Run blinded ranking. Apply the evidence-ranking pipeline to the full panel using only pre-cutoff evidence. The system does not know which candidates are the clinically successful antibodies and which are decoys.
Compare against measured-affinity labels. Using post-cutoff literature, retrieve measured affinities and validation outcomes for each candidate, and compare the evidence-based ranking to experimental outcomes.
Report three metrics. Candidates deprioritised: how many known binders the system would have placed below the assay cutoff. Enrichment among survivors: whether the evidence-supported tier contains a higher fraction of true binders than the full panel. False rejection of a real binder: whether any clinically validated antibody would have been deprioritised, and why.

The historical cutoff maps directly onto the endDate parameter:

const evidenceBeforeCutoff = await valyu.search(
  "HER2 antibody trastuzumab 4D5 affinity structure PDB",
  {
    searchType: "proprietary",
    includedSources: ["valyu/valyu-pubmed", "valyu/valyu-chembl"],
    maxNumResults: 20,
    endDate: "2010-12-31", // simulate pre-disclosure state
  },
);

One caveat worth stating plainly: date filtering operates on the publication date attached to the indexed document. For literature that maps cleanly. For curated database records, the deposit date and the date of the underlying experiment can differ, so a strict cutoff is an approximation of historical knowledge, not a perfect reconstruction of it.

This protocol is a proposal, not a completed experiment. I have not run it, and no candidate counts, enrichment rates, or false-negative rates should be read as findings. Its value is in being specifiable and auditable in advance, and in surfacing its own coverage gaps. A retrospective built only on PubMed and ChEMBL would systematically underestimate negative evidence, because failed binders are underpublished. That biases the analysis toward overestimating support for candidates whose failures never made it into print.

The infrastructure this requires

The triage step needs something most lab-in-the-loop systems were not designed around: on-demand retrieval of structured, auditable literature and bioactivity data, callable at candidate-selection time, with every result traceable to a primary source.

Three capabilities.

Semantic search over biomedical literature. PubMed comprises more than 40 million citations of biomedical literature, updated daily by the NLM. Note that not every citation carries an abstract (coverage is uneven, especially for older records), and PubMed does not host full text, though it links out where available. A query for "anti-HER2 antibody CDR-H3 affinity" should return relevant studies with metadata and links. Valyu's PubMed index covers 37M+ papers and supports natural-language queries structured around candidate features such as target name, epitope description, or CDR sequence motif, rather than requiring hand-built Boolean strings. Its index refreshes monthly, which is fine for a design-cycle cadence and worth knowing if you need same-week publications.

Structured bioactivity retrieval. ChEMBL's 24.5M activities across 18,552 targets cover IC50, Ki, KD, EC50, functional potencies, and ADMET properties. That is the upstream database's full scale, and any given retrieval layer indexes some subset of it, so check the coverage figures for whichever provider you use rather than assuming parity. The retrieval system has to query across multiple dimensions and return structured records rather than free text. Valyu's search results carry a data_type of "structured" or "unstructured", so a caller can branch on it rather than regexing everything and hoping.

Provenance and auditability. Every evidence item must carry a traceable link to its primary source: the PubMed PMID, the ChEMBL assay ID, the PDB entry, the UniProt accession. When a candidate is reranked because a homologous antibody has a published KD, the ranking record must include the assay type, source identifiers, and measurement conditions. This audit trail is what lets a human reviewer verify evidence during ambiguous-case review, and what makes retrospective analysis of ranking decisions possible at all.

Valyu is one implementation of this shape: ChEMBL bioactivity data and 37M+ PubMed papers behind a natural-language semantic search API. The critical requirement is not a specific vendor. It is the ability to retrieve structured, cited evidence programmatically, at the speed of candidate selection, with enough coverage of both positive and negative published results to be worth trusting.

And the infrastructure has to be honest about its limits. PubMed abstracts and ChEMBL records do not capture every experimental detail, and they capture almost no unpublished data. The evidence-ranking system should represent coverage uncertainty as a first-class output rather than burying it inside a single confidence score.

FAQ

Why is a design-to-assay loop incomplete when model confidence, predicted structure quality, and predicted binding are treated as interchangeable?

Model confidence measures the internal consistency of the generative model. pLDDT measures per-residue structural prediction confidence. Predicted binding estimates the likelihood of an interaction, and does it weakly: ipTM scored an AUROC of 0.64 in the Adaptyv EGFR competition analysis. Each answers a different question. Treating them as one signal lets a candidate with high pLDDT and poor predicted binding rank above one with moderate structural confidence and strong published precedent against the same epitope.

Where should literature-in-the-loop triage sit, and what should it produce?

Between generative candidate production and assay queue assembly. For each candidate it produces an evidence packet: target biology context with citations, epitope and accessibility data, homologous sequence alignments with identity percentages, known PDB structures with resolution and method, measured affinities with assay type and conditions, negative and conflicting results, and per-item source quality metadata.

How should source quality and uncertainty be represented?

Per evidence item, not per candidate: peer-reviewed vs. preprint, assay type (SPR, BLI, ELISA, cell-based), measurement reproducibility, and whether conditions match the intended assay. Per-candidate uncertainty should then capture the ratio of supportive to cautionary evidence, the spread of measured affinities for related binders, and the degree of novelty relative to the closest known sequence or structure. Zero retrieved evidence is a distinct state from conflicting evidence, and the two should never collapse into the same score.

How does evidence rerank candidates without becoming a hard gate that removes novel binders?

An explicit exploration budget reserving assay slots for low-evidence, high-novelty candidates; a novelty-conditional scoring function that weights evidence heavily only where close analogues exist; and human review for conflicting or disputed cases. The output is a three-tier queue (evidence-supported, exploration, flagged), with slots allocated across tiers rather than purely by score.

What retrospective protocol could validate this on a public lineage?

Assemble a panel of known lineage sequences and generated decoys, set a historical evidence cutoff preceding later-generation disclosures, run blinded evidence-based ranking on pre-cutoff data only, compare against post-cutoff measured-affinity labels, and report candidates deprioritised, enrichment among evidence-supported survivors, and any false rejection of a real binder. This is a proposed protocol. It has not been run, and nothing here should be read as a result.

Can literature-in-the-loop triage replace wet-lab validation?

No. Literature evidence informs prioritisation. It cannot confirm that a specific generated candidate binds its target, expresses at usable levels, or meets developability criteria. Wet-lab validation remains the only source of ground truth for a novel candidate. Triage changes which candidates are tested first, not whether they are tested.

AI Agents in Finance: From Cited Reports to Finished Deliverables

Prosper Otemuyiwa — Mon, 24 Aug 2026 14:40:22 +0000

Most AI research agents are graded on their prose. Analysts are graded on what lands in the model, the memo and the deck.

This post covers a large update driven entirely by watching how people actually used it on our Finance open source app.

Finance is open source.

TL;DR

23 curated deep research workflows across investment banking, private equity, hedge funds and GTM — each with a depth chip, a runtime estimate, and deliverable badges stated before you spend a credit.
The app now reads your freeform query and pre-fills the deliverables picker with the format it implies. Conservative, visible, editable, and it never blocks your run.
Generated files moved to the top of the report, above the body.
Every claim resolves to a clickable primary source.
It's open source on github and live at finance.valyu.ai

The Missing Deliverable

Ask a junior analyst for "a peer comps table for Alphabet vs Microsoft and Meta as an Excel spreadsheet" and you get a spreadsheet.

Ask most AI research tools the same thing and you get a beautifully written essay — sometimes with formatted tables — about peer comparables, followed by silence on where the downloadable file should be.

That silence is the missing mile. Every leaderboard measures retrieval accuracy, citation quality and reasoning depth. Very few measure whether the thing you asked for arrived in a form you could open.

Which workflows ship today

Workflows are organised by vertical, because a hedge fund analyst and a GTM lead are not looking for the same artifact. The catalogue currently holds 23 templates across four domains:

Investment banking — company profiles, IC memos, comparables
Private equity — commercial due diligence, market maps
Hedge funds — thesis work, screening
GTM — account intelligence briefings

A fifth lens, Popular, sits first and cuts across all four, surfacing the most-used templates.

Each card carries three signals before you commit a credit:

Signal	What it tells you
Depth chip	Fast, Standard or Heavy. A depth knob, not a speed knob — even Fast runs for minutes.
Runtime estimate	4–8 min for an Account Intelligence Briefing; 7–12 for a Company Profile; 10–25 for an IC Memo, Market Map or Commercial Due Diligence.
Deliverable badges	`DOC` · `XLS` · `PPT` — what you get at the end, stated up front.

Pick one and you get an auto-generated form. The variables come from the workflow definition itself, so a template that needs a company gets a company field with real ticker examples, and a template that needs a thesis gets a textarea instead of a single-line input.

The agent now reads your query

Alongside the templated workflows there's a freeform research box. Type anything, pick a depth, hit enter, get a cited report.

A deliverables picker sat under that box: pick a format, describe the contents, get a file. It worked perfectly. It also required you to know it was there.

So what happens when someone doesn't know which format is right, or simply forgets to open it? Finance now runs a small model over your settled query and pre-fills the picker with a format and description drawn from the query itself.

Type the peer comps request, pause for a moment, and the panel opens on its own with an Excel row already filled in:

What it infers, and when it stays quiet

The design constraint was that inference must never make things worse than the old manual flow.

It suggests, it does not decide. Suggestions appear in an open panel, badged, before launch. Every one is editable and deletable. Nothing is attached without being shown to you first.
It fails open. No API key, a timeout, or a malformed response all resolve to "no suggestions" — your research launches exactly as it did before, with nothing visible going wrong.
It is schema-bound. The response is strictly validated; a bare-array answer is rejected rather than guessed at.
It caps out at five deliverables per run across .xlsx, .pptx, .docx, .csv and .pdf.

Deliverables now lead the report

Small in the diff, large in practice.

Generated files used to render last — below the full report body and the chart gallery. On a report running to several thousand words, the spreadsheet you asked for sat several screens down, past every table and footnote.

They now sit directly under the title, above the collapsed activity feed and the body.

The reasoning is straightforward: the file is often why a finished report gets opened at all. Charts stayed where they were, because they illustrate the analysis and read alongside it.

Why every claim carries its source

Templated workflow or freeform query, the output is cited inline. Claims resolve to favicon pills you can click through to sec.gov, finance.yahoo.com, nvidianews.nvidia.com, and whatever else the research actually touched.

The reasoning isn't hidden either. Every run keeps an activity feed — the model's plan, the searches it ran, the sources it found, the code it executed — live while it runs, collapsed by default once it finishes.

For financial research this isn't a nice-to-have. A number you cannot trace is a number you cannot put in a memo.

Three lessons for anyone building finance agents

The deliverables picker was fully functional the entire time. It produced excellent spreadsheets. Its problem was that reaching them required a user to know it existed, open it, choose a format, and write a good description — four steps of friction guarding a capability they had already described, in plain English, one input box above.

1. Grade your agent on the artifact, not the prose. If an analyst has to retype your output into Excel, the run finished at 80%.

2. Inference belongs where users already speak. If people describe a control in natural language before failing to find it, that control is a candidate for inference. Show what you inferred, let them change it, never let it block the run.

3. Provenance is the product. Depth of reasoning is worth nothing if the number cannot be traced to a filing with a date on it.

The query already contained the answer. All that was missing was something small, cheap and conservative to read it.

Try it

Open finance.valyu.ai and run a workflow on a name your team already knows well. Compare it against what you would have produced manually.

Check the citations. Do they resolve to the actual filing, or to an article about it?

Then type a query that names a file, like peer comps for GOOGL, MSFT and META as an Excel spreadsheet, and watch the panel open before you hit enter.

Finance runs on the same Search and DeepResearch APIs your own agents can call. Grab a key at platform.valyu.ai — $10 in free credits, $20 with a work email, no card — and see the full coverage at docs.valyu.ai.

FAQ

What is an AI agent in finance?
One that plans and executes a multi-step research task — deciding which sub-questions to ask, fanning out across filings, market data and news, cross-checking what it finds, and returning a synthesised, cited output. It differs from a single search call, which answers one question against one index, and from a chatbot, which has no persistent task or artifact.

What is a deep research workflow?
A versioned, parameterised research template that runs as an async task and returns a cited report plus downloadable files. The methodology, source strategy and section structure are fixed; the inputs — company, thesis, category — are variables anyone on the team can fill in.

Does the app decide what files to generate on its own?
No, it suggests. Suggestions appear in an open panel, badged, before you launch, and you can edit or delete every one. Nothing is attached without being shown to you first.

What happens if the suggestion model is unavailable?
Nothing visible. The feature fails open — no key, a timeout, or a bad response all resolve to "no suggestions," and your research launches exactly as before.

Which model does the deliverable extraction?
gpt-5.6-luna by default, overridable with the DELIVERABLE_SUGGEST_MODEL environment variable. Whatever you pick must support strict structured outputs, since the response is schema-validated and a bare-array answer is rejected. Without an OPENAI_API_KEY the extractor stays off.

How long does a deep research run take?
Depth is the knob, not speed. Estimates range from 4–8 minutes for an Account Intelligence Briefing to 10–25 for a Market Map, IC Memo or Commercial Due Diligence. Runs continue server-side if you navigate away — pick them up again from Reports.

What file formats can it produce?
Excel (.xlsx), PowerPoint (.pptx), Word (.docx), CSV and PDF, up to five per run. Office formats are produced through code execution, which the app enables automatically when you request one. Every run produces a PDF regardless.

Can I run this without a Valyu account?
Not on finance.valyu.ai — that needs a signup. But it's open source, so you can deploy it yourself by switching the mode to self-hosted in the env variables.

Can I build my own workflow?
You can build workflows on the Valyu platform, and the app links you there. Note that the in-app browser currently requests the curated catalogue only (scope=valyu), so custom templates won't appear in the domain lenses yet.

Give Your AI Agent a Scientist's Library. a Science MCP Server

Prosper Otemuyiwa — Mon, 24 Aug 2026 13:29:29 +0000

Most "research agent" demos are searching abstracts and calling it literature review. The abstract tells you a Phase 3 melanoma immunotherapy trial hit its endpoint. It does not tell you the imaging protocol used to assess tumour response that lives in the methods section, or a supplementary table, or a figure caption.

This walks through wiring a hosted science MCP server into your AI agent, scoping it to actual scientific collections, and running a controlled before-and-after test where exactly one variable changes.

Valyu is a search API built for AI agents: one endpoint over biomedical literature, clinical trial registries, patents, financial filings and the open web, returning full text and structured metadata with resolvable identifiers rather than a list of links to go click.

TL;DR

The hosted MCP server is a plain HTTP endpoint. No local process, no Node, no mcp-remote.
The MCP tools take query and max_num_results and nothing else. No source filtering. If you need scoped retrieval, you need the REST API or an SDK — not the MCP client.
Scope with included_sources in the API, then check result.source on every hit.
include_abstracts=True widens PubMed to the whole abstract corpus; the default restricts to papers with available full text.
Every claim gets a resolvable identifier. The API returns result.doi — read it, don't prompt for it.

What you need

A Valyu API key from platform.valyu.ai — $10 in free credits, $20 if you sign up with a work email, no card
Claude Desktop, Cursor, or any MCP client
Python 3 and pip install valyu for the API examples

No Node.js. The hosted server is remote HTTP.

Connecting the MCP server

The endpoint is:

https://mcp.valyu.ai/mcp?valyuApiKey=YOUR_API_KEY

Auth rides in the query string. You can cap spend per session by appending &maxPrice=50.

Claude Desktop / claude.ai — go to claude.ai/settings/connectors → Add custom connector → paste the URL.

Open in Cursor

What the server exposes

Eleven tools, not one :

Tool	Arguments	Use
`valyu_search`	`query`, `max_num_results`, `fast_mode`	Web search returning full page content
`valyu_academic_search`	`query`, `max_num_results`	Full text across arXiv, PubMed, bioRxiv, medRxiv
`valyu_bio_search`	`query`, `max_num_results`	PubMed, clinical trials, FDA labels, bioRxiv, medRxiv, ChEMBL, PubChem, DrugBank, Open Targets, NPI Registry, WHO ICD
`valyu_patents`	`query`, `max_num_results`	Patent documents — claims, abstracts, inventors, filings
`valyu_contents`	`urls`	Extract content from up to 10 URLs
`valyu_datasources`	`category`	Enumerate the 36+ datasets at runtime

Plus valyu_financial_search, valyu_sec_search (adds response_length), valyu_company_research (company, sections), valyu_economics_search and valyu_datasources_categories.

Scoping your sources

(API and SDK only — see the constraint above.)

Sources are addressed two ways through included_sources: presets (curated bundles) and dataset IDs (individual collections).

Presets: academic, finance, patent, health, genomics, chemistry, physics, legal, politics, transportation, pulse, cybersecurity, environment, automotive, compliance, medical.

Watch the preset boundaries — this bites people. academic covers literature and preprints only:

Dataset ID	Preset	Coverage
`valyu/valyu-pubmed`	academic	37M+ open-access biomedical papers, monthly
`valyu/valyu-arxiv`	academic	Physics, CS, maths, quant finance, economics
`valyu/valyu-biorxiv`	academic	250K+ life-sciences preprints
`valyu/valyu-medrxiv`	academic	80K+ clinical/health preprints
`valyu/valyu-chemrxiv`	academic	30K+ chemistry preprints
`valyu/valyu-clinical-trials`	health	500K+ ClinicalTrials.gov studies, real-time
`valyu/valyu-drug-labels`	health	150K+ FDA labels via DailyMed
`valyu/valyu-patents`	patent	8M+ USPTO filings, full text and figures
`valyu/valyu-patents-epo`	patent	4M+ European filings from 1978
`valyu/valyu-chembl`	chemistry	2.5M+ bioactive compounds
`valyu/valyu-pubchem`	chemistry	100M+ compounds
`valyu/valyu-open-targets`	chemistry	60K+ drug targets

valyu_bio_search additionally reaches DrugBank, the NPI Registry and WHO ICD codes, which aren't broken out as dataset IDs in the datasources guide.

Clinical trials are not in academic. If you scope a trial question to the academic preset you will get papers about trials, not registry records. Use health, or name valyu/valyu-clinical-trials directly.

from valyu import Valyu

valyu = Valyu(api_key="YOUR_API_KEY")  # or set VALYU_API_KEY

response = valyu.search(
    "Phase 3 melanoma immunotherapy trials",
    search_type="proprietary",          # all | web | proprietary | news
    included_sources=["valyu/valyu-pubmed"],
    max_num_results=10,
)

for result in response.results:
    print(result.title)
    print(result.source)          # check this
    print(result.doi)
    print(result.content)

Then check the results. Every SearchResult carries a source field. After each search, confirm each result came from a collection you declared. If something arrives from elsewhere, treat the output as unscoped and rerun tighter. Filtering narrows the search; it is not a guarantee of exclusion.

Note excluded_sources accepts dataset IDs and domains but not presets.

The before-and-after test

Here's the part worth running, with one honest caveat up front.

By default (include_abstracts=False), PubMed search is restricted to papers that have available full text. Setting include_abstracts=True expands the search to PubMed's complete abstract corpus and returns document-level abstracts.

So this is not a clean single-variable A/B. Two things change at once: the corpus gets bigger, and the returned granularity drops to abstract level. It's still the sharpest comparison the API gives you, but describe it accurately — you are comparing full-text-only retrieval against broad abstract-level retrieval, not "the same search with and without full text."

1. Pick a question the abstract can't answer

You want a detail that lives in the methods, a figure caption, or a supplement:

What imaging protocol did the trial use for tumour response assessment?

2. Run it abstract-only

abstract_run = valyu.search(
    "Phase 3 melanoma immunotherapy tumour response assessment imaging protocol",
    search_type="proprietary",
    included_sources=["valyu/valyu-pubmed"],
    include_abstracts=True,      # widen to the full PubMed abstract corpus
    max_num_results=10,
)

This has to run in Python, not through the MCP client. No MCP tool accepts include_abstracts — see the section above. Save the output verbatim. This is your baseline.

3. Run it with full text

fulltext_run = valyu.search(
    "Phase 3 melanoma immunotherapy tumour response assessment imaging protocol",
    search_type="proprietary",
    included_sources=["valyu/valyu-pubmed"],
    include_abstracts=False,     # default — papers with available full text only
    max_num_results=10,
)

Identical query, identical source, identical result count. Save that too.

4. Compare

Put them side by side. Does the abstract-only answer contain the imaging protocol? Does the full-text one?

If full text surfaces evidence abstract-only missed, you have a controlled result — for this query, this index, and this date.

Things not to do with it:

Don't generalise to "abstract-only retrieval is unreliable." You tested one query against one index.
One run is a demonstration, not a benchmark.
PubMed full text is open access only. If your topic is dominated by paywalled journals, the full-text run has less to work with and the comparison says more about OA coverage than about retrieval depth.
Don't publish until you've independently opened the paper and confirmed the detail is where you say it is.

Recording the run

Four things, or nobody can reproduce it: the exact call parameters, the full verbatim output, the source list, and the correction.

{
  "query": "<identical query string used in both runs>",
  "shared_params": {
    "search_type": "proprietary",
    "included_sources": ["valyu/valyu-pubmed"],
    "max_num_results": 10
  },
  "run_abstract_only": {
    "include_abstracts": true,
    "output": "<full output, verbatim>",
    "sources_returned": ["<result.source values>"]
  },
  "run_full_text": {
    "include_abstracts": false,
    "output": "<full output, verbatim>",
    "sources_returned": ["<result.source values>"]
  },
  "run_date": "<YYYY-MM-DD>",
  "correction": {
    "missed_by_abstract": "<what was missing>",
    "found_in_full_text": "<what full-text surfaced>",
    "source_doi": "<result.doi>",
    "location": "<methods / figure caption / supplement>"
  }
}

Record the date — PubMed syncs monthly and trials update in real time, so the same call will drift.

Citation rules that scientists actually use

Every claim links to a resolvable identifier. This is the line between a science agent and a chatbot with a search tool.

Source type	Identifier	Resolves at
Journal articles	DOI	`https://doi.org/<doi>`
Preprints (bioRxiv, medRxiv, ChemRxiv)	DOI	`https://doi.org/<doi>`
Clinical trials	NCT number	`https://clinicaltrials.gov/study/<nct>`
US patents	USPTO patent number	USPTO patent search portal

You don't have to parse these out of prose — SearchResult exposes doi, citation, authors, publication_date, citation_count and source as structured fields. Read them directly rather than asking the model to extract them.

Do not demand a DOI for everything. Trials and patents have their own registries, and a prompt that insists on DOIs produces fabricated ones.

For every factual claim, cite a resolvable identifier: a DOI for journal
articles, an NCT number for clinical trials, or a patent number for patents.
If the result has no identifier, give the URL and state that the claim is
unverified. Never construct an identifier that was not returned.

Combining literature, trials and patents

Three scoped searches, correct preset for each:

from valyu import Valyu

valyu = Valyu(api_key="YOUR_API_KEY")

# Literature — academic preset
lit = valyu.search(
    "PD-1 inhibitor combination therapy melanoma",
    search_type="proprietary",
    included_sources=["academic"],
)

# Clinical trials — registry records live in health, NOT academic
trials = valyu.search(
    "PD-1 inhibitor melanoma Phase 3",
    search_type="proprietary",
    included_sources=["valyu/valyu-clinical-trials"],
)

# Patents — USPTO full text and figures
patents = valyu.search(
    "PD-1 antibody immunotherapy",
    search_type="proprietary",
    included_sources=["valyu/valyu-patents"],
)

DOIs for the literature, NCT numbers for the trials, patent numbers for the patents.

Valyu's DeepResearch (POST /v1/deepresearch/tasks) spans the same catalogue asynchronously. It can reach across domains in one task, but verify the returned sources match your intended scope before treating the output as complete.

Six checks to keep the agent honest

Source provenance — read result.source on every result. If it isn't a collection you declared, the run is unscoped.

Identifier resolution — verify the cited identifier actually resolves before presenting the claim. DOI at doi.org, NCT at clinicaltrials.gov, patent through USPTO. Doesn't resolve → unverified.

Full-text availability — PubMed full text is open access only, and include_abstracts=True means you got abstracts instead of full text. Have the agent state which mode it ran in. An agent reasoning over an abstract as though it read the paper is the failure this whole post is about.

Preprint status — bioRxiv, medRxiv and ChemRxiv are not peer-reviewed. Label them as preprints, with server name and DOI, so the reader can judge evidence level.

Citation entailment — when the agent says a source supports a statement, confirm the passage is actually in the returned content. If it cites a figure, confirm the figure came back.

Missing assets — figures, tables and supplements are not retrievable from every source. valyu/valyu-patents is the one dataset documented as carrying full text and figures; don't assume that generalises to the preprint servers. If an asset isn't there, the agent says so rather than substituting.

Access and copyright limits

Retrieval is not a redistribution licence. The Valyu Acceptable Use Policy applies across all APIs, datasets, models and indexes. You must not:

Reproduce or redistribute copyrighted content
Access content behind paywalls or access controls
Store or display publisher content in ways licensing doesn't allow
Extract, store or manipulate full-text articles from licensed sources
Rebuild, replicate or simulate any Valyu corpus, dataset, index or scoring
Join outputs to reassemble source materials
Scrape or bulk download via high-volume search queries

The contents endpoint is your responsibility. Per the AUP: "You — not Valyu — are the party responsible for ensuring that your use of the Contents endpoint in connection with any given URL is lawful and authorised." Before submitting a URL, review the target's terms and acceptable use policy, and confirm automated extraction isn't prohibited by robots.txt, X-Robots-Tag headers or <meta name="robots"> directives.

In practice: the agent reads and reasons over retrieved content in-session and does not store it for redistribution. And retrieved research is not a substitute for professional medical advice, or for a human reading the primary source.

Checklist

[ ] MCP endpoint connected and tools listed in the client
[ ] Reproducibility runs done via API/SDK, not the MCP client
[ ] included_sources set, with the right preset for the source type
[ ] Both runs use identical query, sources and max_num_results
[ ] Only include_abstracts differs between the two runs, and the writeup says the corpus widened too
[ ] Full output saved verbatim, plus run date
[ ] result.source checked on every result
[ ] Every claim linked to a returned doi, NCT number or patent number
[ ] Preprints labelled as preprints
[ ] Conclusion scoped to this query and index only
[ ] No stored or redistributed licensed full text
[ ] No URL sent to /v1/contents without checking terms and robots directives
[ ] Retrieved research not presented as medical advice

FAQ

How do I run the same question through both abstract-only and full-content workflows?
In Python, not through MCP — no MCP tool exposes include_abstracts. Issue the identical query twice against valyu/valyu-pubmed, once with include_abstracts=True and once with the default False, keeping search_type, included_sources and max_num_results fixed. Save both outputs verbatim.

Can I restrict my Claude Desktop agent to just PubMed?
No. MCP search tools accept only query and max_num_results. Your scope control is which tool the agent picks. For real source pinning, call the API directly.

What makes a good test question?
One where the decisive detail sits outside the abstract — imaging protocols, assay conditions, eligibility subtleties. "What imaging protocol did the Phase 3 melanoma immunotherapy trial use for tumour response assessment?" works because that lives in methods or a supplement.

Why did my clinical trial search return papers instead of registry records?
You almost certainly scoped to the academic preset. Clinical trials live in health — use included_sources=["valyu/valyu-clinical-trials"].

How should the agent cite results without DOIs?
NCT number for trials, patent number for patents. If none exists, the URL plus an explicit note that the claim is unverified. Read result.doi rather than having the model extract it.

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. Valyu's. OpenAI's. Perplexity's. Exa's. Parallel's. Gemini's.

Many 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-195'); 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.