The Problem
Teams building research agents face a common bottleneck: stitching together LLM calls, search APIs, and report generation into a coherent workflow. Most solutions are either closed-source, model-locked, or require significant custom glue code. This repo addresses that by providing a configurable, open-source deep research agent built on LangGraph that works across multiple model providers and search tools.
What This Does
opendeepresearch is a LangGraph-based agent that performs multi-step research: it takes a user query, iteratively searches sources, summarizes findings, compresses them into a knowledge base, and produces a structured final report. The core logic lives in src/opendeepresearch/deepresearcher.py, with configuration in src/opendeepresearch/configuration.py and prompts in src/opendeepresearch/prompts.py. The agent supports model selection via LangChain's initchatmodel() API, so it works with OpenAI, Anthropic, OpenRouter, Ollama, and others.
The repo includes a src/legacy/ directory with earlier single-agent and multi-agent implementations, plus an evaluation suite under tests/ with pairwise and benchmark evaluation scripts. Example research reports are in examples/ for arxiv, pubmed, and inference market topics. A langgraph.json file defines the agent graph for deployment.
How To Use It
Setup: The repo uses uv as its package manager, with dependencies in pyproject.toml and a lockfile (uv.lock) present.
git clone https://github.com/langchain-ai/opendeepresearch.git cd opendeepresearch uv venv source .venv/bin/activate uv sync
Configuration: Copy .env.example to .env and set your model provider API keys (e.g., OPENAIAPIKEY) and search API credentials. Model selection (summarization, research, compression, final report) is configured in src/opendeepresearch/configuration.py via the LangGraph Studio UI.
Running it: Launch the LangGraph server locally:
uvx --refresh --from "langgraph-cli[inmem]" --with-editable . --python 3.11 langgraph dev --allow-blocking
This starts the LangGraph Studio UI at http://127.0.0.1:2024, where you submit queries and adjust configuration.
Real-World Use
A research analyst at a consulting firm could deploy this as an internal tool. A user submits "Analyze the competitive landscape of vector databases as of Q3 2025." The agent searches multiple sources, summarizes each result, compresses findings into a structured knowledge base, and outputs a markdown report with citations. The same setup can be pointed at different model backends depending on cost or quality requirements per engagement.
Code Health & Issues
Med - Duplicate/legacy code: src/legacy/ contains older implementations that overlap with the main src/opendeepresearch/ module. This complicates maintenance and increases the surface area for bugs. The legacy.md and vibecode.md docs suggest this is acknowledged but not cleaned up. Med - Dependency hygiene: pyproject.toml declares dependencies without a lockfile (though uv.lock is present, which mitigates this). The repo also references uv pip install -r pyproject.toml in the README, which is not a standard uv pattern. Low - Security: src/security/auth.py exists, but there's no evidence of authentication being enforced in the main agent flow. For a tool that hits external APIs and generates reports, this is acceptable for local use but needs hardening before production deployment. Low - CI/CD: GitHub Actions are configured for Claude code review, but there's no evidence of automated test runs in CI. Tests exist under tests/, but they appear to be evaluation scripts rather than unit tests asserting agent behavior.
The codebase is otherwise well-structured with clear separation of concerns (state, configuration, prompts, utils), and the README is thorough.
The Bottom Line
This is a solid, production-usable reference implementation of a deep research agent, backed by a strong ecosystem (LangChain, LangGraph) and a public leaderboard ranking. The main caveats are the legacy code clutter and the lack of enforced CI testing. It's well-suited for teams that want a working starting point for research automation and have the capacity to maintain and extend it. Solo developers should expect some cleanup work before relying on it in production.