Idea Atlas

Executive Summary

Idea Atlas is a multi-agent research pipeline built on LangGraph that turns an unstructured product idea into a structured, evidence-backed evaluation report. A checkpointed state graph runs an adaptive interview, discovers and filters competing/adjacent products from the web, fans research out in parallel across the surviving candidates, and synthesizes a report that goes through a critique-and-revise loop before being returned.

The Problem

A single LLM call asked to "research my idea" tends to produce a plausible-sounding but shallow answer, with no way to trace which claim came from where, and no mechanism to notice when its own coverage is thin. Running every step through the biggest available model is also unnecessary and slow: a one-line greeting does not need the same model as a multi-turn interview, and a routine relevance check does not need the same model as final report synthesis.

The Solution

Idea Atlas decomposes the problem into a 15-node LangGraph state machine across four phases: intake, discovery, research, and report. Every LLM call in the graph is routed through a role-based model router with a per-role provider fallback chain, so a role only pays for as much model as the task actually needs, and a failed provider degrades to the next one instead of failing the run. Research is fanned out in parallel per candidate via LangGraph''s Send API, and the final report is checked and revised through an automated critique loop before being handed back.

System Architecture

1. Intake Phase
   A heuristic classifier (word-count and keyword based, zero API cost) makes a first routing pass into light / medium / deep conversational complexity before ever spending a real model call. Deep ideas move into a multi-turn adaptive interview, capped at 8 turns, which converges on a structured idea profile the user then confirms.

2. Discovery Phase
   The confirmed idea is embedded (gemini-embedding-2) and used to drive a Tavily-backed search (advanced depth, 15 results per query) that discovers up to 40 raw candidate products. An LLM relevance-check role — deliberately the cheapest, fastest chain in the whole config, since it runs once per candidate before anything expensive — filters that set down to the 15 most relevant candidates.

3. Parallel Research Phase
   Each of the 15 surviving candidates is fanned out into 3 parallel research task types (general info, reviews, gap analysis) via LangGraph''s Send API — up to 45 concurrent LLM-backed research calls per report — then reduced back into a single joined state through a dedicated join node.

4. Report Phase
   A synthesis node drafts the structured report; a critique node scores it and either sends it back for another synthesis pass or lets it through, capped at 3 iterations.

Model Router

Every role above (11 in total: classification, three chat tiers, query planning, relevance check, three research task types, report synthesis, report critique) is configured in config.yaml with an ordered provider fallback chain across 4 providers — Groq, Ollama Cloud, Google AI Studio, and OpenRouter — with per-provider concurrency semaphores (Ollama 2, OpenRouter 3, Groq 5, Google 5) so the graph never exceeds what a given provider''s tier can actually sustain.

Engineering Decisions

Why route through a zero-cost heuristic before any model call?
Most conversational turns do not need a model decision at all — a short greeting or an unambiguous idea statement can be classified by word count and keyword matching alone, so the heuristic only escalates to a real LLM call when it genuinely cannot decide.

Why is the interview role Groq-first instead of the largest available model?
An interview turn blocks a live chat response, so it needs to feel fast. An earlier version put the largest 550B-class OpenRouter model first here, which meant every single conversational turn waited on both the heaviest model in the whole roster and OpenRouter''s free-tier queue latency. Groq''s LPU inference with a 70B model turned out to be more than sufficient for a single clarifying question, and dramatically faster.

Why filter relevance before the expensive research fan-out, and with the cheapest possible chain?
The relevance check runs once per discovered candidate — up to 40 times per report — right before the 3x-per-candidate research stage. Keeping it on the fastest, cheapest chain available bounds the cost of the expensive stage that follows it.

Why is the highest-volume research role deliberately not provider-first on OpenRouter, unlike the other research roles?
Gap analysis fires once per candidate (up to 15 times per report) and is the single highest-volume role in the graph. OpenRouter''s free tier caps at 50 requests/day per account, so putting a high-volume role first there would burn through it in a single run. It is kept as a last-resort fallback instead, preserving that budget for the genuinely low-volume roles.

Why checkpoint the graph state with AsyncSqliteSaver?
The interview and research phases can span multiple separate HTTP calls. Checkpointing on a thread ID lets a session resume exactly where it left off after a server restart or a dropped connection, instead of requiring the entire multi-phase flow to complete inside one request.

Pipeline & Throughput

Graph size: 15 nodes across 4 phases (intake, discovery, research, report).
LLM roles routed: 11 distinct roles, each with a 2-3 provider fallback chain across 4 providers.
Candidate discovery ceiling: up to 40 raw candidates per run (Tavily, advanced depth, 15 results/query).
Relevance-filtered research set: top 15 candidates.
Parallel research fan-out: up to 45 concurrent LLM calls per report (15 candidates x 3 task types) via LangGraph Send.
Provider concurrency caps: Ollama 2, OpenRouter 3, Groq 5, Google 5 concurrent in-flight requests.
Interview cap: 8 conversational turns before forced completion.
Report refinement loop: up to 3 synthesize-critique iterations.

Scalability Strategy

Per-provider concurrency semaphores mean the graph is tuned to what each provider''s tier can actually sustain rather than one blanket limit. The cheap relevance-check pass bounds how many candidates ever reach the expensive 3x research fan-out. Checkpointed state via AsyncSqliteSaver keeps the API layer itself stateless between calls, and the role-based model router means adding a fifth provider is a config change, not a graph change.

Outcome

A working multi-agent research pipeline that replaces one large opaque LLM call with a routed, checkpointed, parallel-fan-out graph — built to degrade gracefully when a provider is unavailable rather than failing the whole run.