Multi-Agent Web Research System with Dynamic Task Generation

exa · Tech · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Autonomous web research

Exa needed to evolve from search and answer APIs into a production deep-research agent that can answer complex queries with structured, cited outputs while controlling latency and token cost.

Constraints:

Architecture

Exa built a LangGraph multi-agent deep-research system with a planner that dynamically creates tasks, independent task agents with Exa tools and required JSON schemas, and an observer that maintains full context across planning, reasoning, outputs, and citations.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  planner["Planner"]
  research-tasks["Research Tasks"]
  observer["Observer"]
  exa-api-tools["Exa API Tools"]
  planner --> research-tasks
  planner --> observer
  research-tasks --> planner
  research-tasks --> exa-api-tools
  research-tasks --> observer
  observer --> planner
  observer --> research-tasks
  exa-api-tools --> research-tasks
Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component Role Interacts with
Planner Analyzes research queries and dynamically generates parallel tasks. Research Tasks, Observer
Research Tasks Run independent web research with specialized Exa tools and required JSON outputs. Planner, Exa API Tools, Observer
Observer Maintains full context across planning, reasoning, outputs, and citations. Planner, Research Tasks
Exa API Tools Provide search snippets and full-content retrieval. Research Tasks

Data flow

A user query enters the planner, which generates parallel research tasks. Each task searches snippets first, requests full content when needed, returns structured JSON, and the observer maintains global context and citations across the workflow.

“The Planner component serves as the system's orchestration layer, analyzing incoming research queries and dynamically generating multiple parallel tasks based on query complexity.”summary, stated
“The Observer component maintains full context across all planning, reasoning, outputs, and citations, providing system-wide visibility and coordination.”summary, stated

Why this architecture

Exa selected LangGraph when the research product became complex enough to need explicit orchestration, dynamic task generation, observability, and stateful coordination across parallel investigations.

“their shift to a more complex deep-research architecture led them to reevaluate their tooling choices and ultimately select LangGraph as their framework of choice.”summary, stated
“This modular approach allows for parallel execution while maintaining consistency in output format, a critical requirement for API-based consumption.”summary, stated

Models used: LLM research agents · LangGraph

Scale

Alternatives considered (roads not taken)

Use no framework as in the original answers endpoint

Rejected because: Deep research added enough architectural complexity that Exa moved to LangGraph.

“While Exa's original answers endpoint operated without frameworks, their shift to a more complex deep-research architecture led them to reevaluate their tooling choices”summary, stated

Always crawl full page content

Rejected because: Snippet-first reasoning reduces token usage while preserving quality when snippets suffice.

“Rather than automatically crawling full page content, the system first attempts reasoning on search snippets, significantly reducing token usage while preserving research quality.”summary, stated

Patterns

multi-agent-orchestration (architecture)

Planner, task agents, and observer coordinate dynamic parallel research.

“their system employs a three-component architecture with a planner that dynamically generates parallel tasks, independent research units with specialized tools, and an observer maintaining full context”summary, stated

tool-use-orchestration (architecture)

Task agents use specialized Exa API tools for snippet and full-content retrieval.

“Each task receives specific instructions, a required output format (always JSON schema), and access to specialized Exa API tools.”summary, stated

context-engineering (context)

The observer sees full workflow context while individual tasks consume cleaned outputs to control tokens.

“individual tasks only receive the final cleaned outputs from other tasks, not intermediate reasoning states.”summary, stated

Tradeoffs

Use dynamic task generation

Chose Planner-created parallel tasks based on query complexity over Rigid fixed research workflow.

Rationale: Research queries vary in complexity and benefit from adaptive decomposition.

“This dynamic approach represents a significant departure from rigid workflow systems”summary, stated

Limit task context

Chose Cleaned outputs from other tasks over Full intermediate reasoning state.

Rationale: This balances information sharing with token efficiency and clarity.

“balancing information sharing with token efficiency and system clarity.”summary, stated

Gotchas (what bit them)

Research quality and token efficiency can conflict.

Root cause: Full page content is expensive, but snippets may be insufficient for some questions.

Resolution: Reason over snippets first and request full content only when needed.

“Only when snippet-level reasoning proves insufficient does the agent request full content.”summary, stated

Parallel task agents need global coherence.

Root cause: Independent research units can lose shared context without a coordinating view.

Resolution: Use an observer that maintains planning, reasoning, outputs, and citation context.

“ensuring that while individual tasks operate independently, the overall system maintains coherence and can provide comprehensive, well-cited research outputs.”summary, stated

Evaluation

The case reports production throughput and latency but does not give a formal offline evaluation design.

Metrics: daily query volume · latency · structured JSON output

“processes hundreds of research queries daily, delivering structured results in 15 seconds to 3 minutes.”summary, stated

Outcomes

Hundreds of daily queries with 15-second to 3-minute response times.

“ultimately providing structured JSON outputs specifically designed for API consumption.”summary, stated