Enterprise Deep Research: a steerable multi-agent research stack from Salesforce
Salesforce Enterprise Deep Research
At a glance
- What is it?
- EDR wraps a planning agent, four search agents and an MCP tool layer behind a FastAPI server and a React frontend. It is a research harness for teams that want to watch and interrupt the agent, not a drop-in report generator.
- Who is it for?
- Adopt EDR if you need a research agent whose loop you can inspect and steer, and if you already hold keys for Tavily plus one LLM provider, since the README lists no offline or key-free path. Skip it if you want a hosted product with a support contract, or if your queries cannot be decomposed into web, academic, GitHub and LinkedIn searches.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 105 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What EDR is for, and who ends up running it
The README frames Enterprise Deep Research as a multi-agent system built around five named parts: a Master Planning Agent that decomposes a query, four specialized search agents (General, Academic, GitHub, LinkedIn), an MCP-based tool ecosystem, a Visualization Agent, and a reflection mechanism that detects knowledge gaps and can revise the research direction. That list is the product. The intended user is not someone who wants a paragraph of prose about a topic. It is someone whose question has sub-questions that live in different places: a market question that needs a paper, a repository and a press page, or an internal data question that needs a SQL call plus a chart.
The repository ships both a CLI entry point and a web application, and the README describes the web app as the interactive path with real-time progress tracking and human-in-the-loop steering. Steering is the distinguishing feature here. The README lists real-time steering commands and optional human guidance during reflection, which means the loop is designed to be interruptible rather than fire-and-forget. If your workflow is a batch job that runs overnight and emails a PDF, most of that machinery is overhead you are paying for in tokens and latency.
One caveat on scope: the README says the components were validated on internal datasets, and the public evidence it points to is the EDR-200 trajectory dataset on Hugging Face plus leaderboard placements announced in the news section. Those are statements about the project's own evaluation, not about your data.
The agent loop: planning, four search agents, reflection, synthesis
The mechanism visible in the repository is a LangGraph application. langgraph.json sits at the top level, requirements.txt pins langgraph==0.3.22 and langgraph-checkpoint==2.0.23, and the README's project structure lists a src/ directory alongside services/, routers/ and benchmarks/. The graph is the orchestration layer; app.py wraps it in FastAPI and serves the pre-built React frontend from ai-research-assistant/.
Data flow, as the README describes it: the Master Planning Agent decomposes the query, the specialized search agents retrieve, the reflection step checks for knowledge gaps and updates direction, and the Visualization Agent turns results into charts. Tool access runs through MCP, and the dependency list includes mcp>=1.4.1 and langchain-mcp-adapters>=0.0.6, so external tools such as NL2SQL or file analysis are attached as MCP servers rather than hardcoded. That is the extensibility claim in the README, and the dependency list is consistent with it.
Search is Tavily by default. The .env.sample sets SEARCH_API=tavily and requires TAVILY_API_KEY. The sample also carries FIRECRAWL_API_KEY, JINA_API_KEY and SCRAPYBARA_API_KEY, and FETCH_FULL_PAGE=True, which suggests full-page retrieval is part of the default path, but the README does not explain how those three keys are used or which one is required. Treat that as unclear rather than optional.
Iteration is bounded. MAX_WEB_RESEARCH_LOOPS defaults to 10 in the README's optional settings and to 3 in .env.sample, which is a real discrepancy to watch: the value you get depends on whether you copied the sample or left the variable unset.
Installing EDR and running a first research query
Requirements are Python 3.11+ and Node.js 20.9.0+. The README gives a clone-and-setup sequence that creates a virtual environment, installs Python dependencies, copies the environment sample and builds the frontend.
git clone https://github.com/SalesforceAIResearch/enterprise-deep-research.git
cd enterprise-deep-research
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt
cp .env.sample .env
cd ai-research-assistant && npm install && npm run build && cd ..On Windows the README notes the activation line is venv\Scripts\activate. After the build, open .env and fill in the keys. The README lists TAVILY_API_KEY as required and exactly one LLM provider key from OpenAI, Anthropic, Groq, Google Cloud or SambaNova. Note the spelling of the SambaNova variable in the sample file: SAMBNOVA_API_KEY.
LLM_PROVIDER=openai
LLM_MODEL=o3-mini
MAX_WEB_RESEARCH_LOOPS=3Those three keys control which provider answers, which model is used, and how many research iterations run. The README's supported-model table lists o4-mini as the OpenAI default and o3-mini as an available option, so o3-mini is a documented choice rather than a guess.
Start the whole stack with one command. The README says this serves both the API and the pre-built frontend on port 8000.
python -m uvicorn app:app --host 0.0.0.0 --port 8000Open http://localhost:8000 for the interface, or http://localhost:8000/docs for the generated API documentation. For a scripted run without the browser, the README gives a benchmark runner:
python benchmarks/run_research.py "Your research question" \
--provider openai --model o3-mini --max-loops 3The flags mirror the environment variables, which is convenient for one-off questions. The README points to benchmarks/README.md for the full benchmarking guide rather than documenting the runner's output format here.
Where EDR stops being the right tool
The first limitation is dependency weight. requirements.txt pulls in pandas, matplotlib, seaborn, scikit-learn, plotly, numpy pinned below 2.0.0, PyPDF2, pdfplumber, python-docx, openpyxl, Pillow, pytesseract, opencv-python, SpeechRecognition, moviepy and whisper. That is a document-and-media processing stack, and it is why the install is not a small one. If your questions are text-only web research, you are installing OCR and video transcription libraries you will never call.
The second is the beta pin. requirements.txt specifies e2b-code-interpreter==1.2.0b1 while the project's own pyproject.toml, which carries the name e2b-research-agent, asks for e2b_code_interpreter>=1.1.1. A pre-release pin in a requirements file means the install resolves to a beta artifact, and the two files disagree about which version is acceptable. Anyone building a reproducible environment should reconcile those before freezing a lockfile.
The third is the missing operational surface. The README documents no rollback, no resume-after-failure behaviour, no cost estimate per run, and no rate-limit handling for the search or LLM providers. The repository does contain session_store.py and langgraph-checkpoint, which suggests state is persisted, but the README does not describe what a restart does to an in-flight research run. If your requirement is that a failed run resumes where it stopped, that is unverified from the documentation.
Finally, the evaluation story is the project's own. The news section reports a first-place placement on the LiveResearchBench leaderboard dated 2025/12/12 and a listing on DeepResearchBench dated 2025/11/13. Those are leaderboard results on public benchmarks, not evidence that EDR outperforms a simpler pipeline on your queries. The README says validation happened on internal datasets.
How EDR differs from a single-agent LangChain research chain
The closest comparison is a plain LangChain or LangGraph research chain: one agent, one search tool, a prompt that says research this and write a report. The difference is not the model. It is that EDR separates planning from retrieval and inserts a reflection step that can change the plan, and it routes retrieval across four named agent types instead of one general search call. A single-agent chain has no place to put a steering command mid-run, because there is no plan object to steer.
A second comparison is a hosted deep research product. Those give you a finished report and no visibility into which search produced which sentence. EDR's stated design goal is the opposite: EDR-200 exposes full trajectories across search, reflection and synthesis, and the README describes the dataset as capturing the reasoning process rather than only final outputs. If you need to audit why an agent concluded something, that trajectory format is the reason to pick this over a closed product. If you need a report by Friday and do not care how it was assembled, the closed product is faster.
A third point of difference is the MCP tool layer. Because tools attach through MCP, an NL2SQL server or a file-analysis server can be added without editing the agent graph, per the README's description of an extensible MCP-based tool ecosystem. That is a genuine architectural choice, and it is also the part the README documents least: there is an mcp_agent.secrets.yaml file in the repository root, but the README does not walk through adding a custom MCP server.
Maintenance, upgrade cost and the Apache-2.0 licence
The repository is not archived, and the last push was on 2026-06-02. That is roughly three and a half months before today, so the codebase is recent but the README gives no release cadence and no versioned releases were retrieved. There is no published changelog or upgrade guide, which means upgrading means reading diffs.
Upgrade cost concentrates in three places. LangGraph is pinned exactly (langgraph==0.3.22, langgraph-checkpoint==2.0.23), so a LangGraph major bump is a manual migration rather than a resolver decision. The Google integrations are pinned to ranges (langchain_google_genai>=2.1.3, langchain_google_vertexai>=2.0.0,<3.0.0). And numpy is capped below 2.0.0, which will conflict with any newer scientific package you add to the same environment. The e2b-code-interpreter beta pin mentioned earlier is the fourth: a beta dependency can change behaviour between patch releases without a semver signal.
On licensing, the repository is Apache-2.0 and LICENSE.txt is present, with how_to_license.md also in the root. Apache-2.0 permits commercial use and modification and includes a patent grant. What it does not settle is the cost of everything EDR calls: Tavily, your LLM provider, E2B, and the optional Firecrawl, Jina and Scrapybara keys are all separate services with their own terms. The README does not state which of those are mandatory beyond Tavily and one LLM key. This is a description of the licence file, not legal advice; check the terms of the external services yourself.
Editorial conclusion
Adopt EDR if you need a research agent whose loop you can inspect and steer, and if you already hold keys for Tavily plus one LLM provider, since the README lists no offline or key-free path. Skip it if you want a hosted product with a support contract, or if your queries cannot be decomposed into web, academic, GitHub and LinkedIn searches. Before committing, verify one thing: that the provider and model you intend to use appears in the supported-model table, because the README documents defaults per provider but not what happens when you pick a name outside that table.
Frequently asked questions
What is meant by deep research in the context of Enterprise Deep Research?
In this project, deep research means a multi-agent loop rather than a single search call: a Master Planning Agent decomposes the query, four specialized search agents retrieve, a reflection mechanism detects knowledge gaps and updates direction, and a Visualization Agent produces charts. The README describes this as enabling automated report generation with real-time streaming.
What is the definition of a research enterprise as Enterprise Deep Research uses the term?
The README does not define the phrase. It positions EDR for enterprise analytics and enterprise workflows, listing NL2SQL, file analysis and enterprise workflows as the kinds of tools the MCP layer is meant to attach, but it gives no definition of a research enterprise.
What is enterprise in AI, and how does Enterprise Deep Research fit that idea?
The repository does not define enterprise AI as a category. It shows one interpretation: EDR ships a FastAPI backend, a React frontend, a Slack agent, document analysis and citation management, and the README describes these as enabling enterprise deployment validated on internal datasets.
What is an enterprise data model, and does Enterprise Deep Research include one?
The README does not describe a data model. It mentions NL2SQL as one of the tool types the MCP-based ecosystem can support, which would connect to an existing data model, but no schema or data model ships with the repository.
Community notes