Open Deep Research

Key Takeaways

Hi there. Today you're going to learn all about the Langchain deep research agent and how you can use it as a starting point for your projects. It's highly configurable and allows you to add your own MCP servers and is open source so you can tailor it to your own specific use cases. Let's see how it works. So later this year, my roommates and I want to take a trip to Amsterdam and Norway. We want to leave New York on September 12th and get back on the following Sunday. I want to ask Deep Research if it can help me plan the cheapest trip possible. Let's go ahead and run this. We can see that the agent immediately asks me a few clarifying questions. My initial question was a bit vague, so I can give it some more context here. With this additional context, the agent has just kicked off a deep research process. Right now, the agent is iteratively calling tools and searching the web to try and plan the cheapest possible vacation for me and my roommates. This will take a minute or two. We'll check back in on it later, but while it's running, let's go ahead and take a deeper dive into our agent architecture and understand exactly what's going on under the hood. There's three main phases of our deep research agent, and we'll walk through each of these in more detail. The first phase is scoping the problem. The agent has the option to ask clarifying questions to the user and then compress the entire chat history into a single cohesive research brief. Once we have a clear research brief, we start the research phase. The research phase uses a supervisor to spawn sub aents to research specific subtopics. The sub aents will then return their findings to the supervisor. The supervisor reflects on these findings and either spawns more sub aents or decides to conclude research. When the supervisor is satisfied with the research, our final step is to write the report in a singleshot generation. We take all of the findings that we've accumulated from the sub aents and present these to a writer LLM in a single request. This creates the final report which we then return to the user. Let's take a look at each phase in detail. In our scoping phase, there are two steps to ask clarifying questions with the user and to write a research brief. Asking clarifying questions is all about gathering necessary context from the user. Users often forget to provide sufficient context in their initial request. And so, we give our agent the option to ask follow-up questions in order to get any additional context it might need. Once we finish clarifying with the chat back and forth, we compress the list of chat messages into a condensed research brief. Now, why do we do this? At this point, our conversation might include a few turns of back and forth or maybe even a prior report from a previous question. Synthesizing the entire conversation so far, which is often times a long list of chat messages, into a single research brief, can help our agent focus and iterate against a clear target. Let's take a look at the Langsmith trace for the question that we just asked about our trip to Amsterdam in Norway. Langmith is an observability and evaluation tool that I used extensively while iterating on this agent. Here we can see the trace for the user clarification step. You can see here that I use structured output in our LLM to decide whether or not we need clarification. Now, I was intentionally vague in my initial question about our trip. And so, the LLM asked me to clarify that piece with an outputed message. In my next message, I responded with that additional context. We can see that in the same clarify with user step, the agent has now decided it no longer needs more clarification and that the context is sufficient. We then proceeded to the write research brief step. And here I use an LLM call with structured output again to create a single research brief condensing this list of chat messages into one research target. This brief gets saved in our agent state and we'll reference this brief at several points later on in our research and writing phases. With our research brief now in hand from the scoping phase, we're now ready to kick off research. Research is a really open-ended task. There are a lot of different types of questions that a deep research agent might face and we need to be prepared and flexible enough to handle all of them. Our initial research phase therefore has very minimal scaffolding. The supervisor analyzes the research brief and reasons about if there are pieces to the question that it can parallelize. The supervisor really has a simple job. It delegates tasks to the right number of sub aents to research topics in depth and in parallel. This is really just a context engineering technique. Instead of reasoning about the research brief itself as one whole, the agent can split it into individual pieces whenever it's applicable. The benefit here is that each sub aent conducts research on a single subtopic siloed in its own separate context window. Alternatively, the agent can also choose to research questions in a single thread if the research brief doesn't make sense to split up. Here we can actually see that our researcher kicks off three research topics in parallel. First, we want to find the best way to get from New York to Amsterdam and then to get back from Norway to New York. We also have a second topic that's focused specifically on travel within the trip. How do we get from Amsterdam to Oslo and then around Norway using different modes of transportation? And then finally, we're looking for accommodations in a separate research step. These three pieces of research are fairly independent and so we're able to conduct them separately. Now each of these research sub aents is really just a tool calling loop. One of the chief advantages to this is that it's very configurable. The agent can make use of our default chavility search tool or any MCP tools that we provide to it. In this case I provided the agent with a bunch of MCP tools from arcade specifically for searching flights and hotels on Google. The flexibility of the tool calling loop allows our agent to be maximally configurable armed with whatever tools we choose to give it. Just like we saw before, this is the prompt that the supervisor has written for our sub agent. It's clear and also specifies the anticipated research effort. Our researcher can just focus on this sub question. And now this tool calling loop continues until the agent decides to call a special tool called research complete. Research complete doesn't actually do anything, but it signals to us that the LM is satisfied with its research. Now, before the sub agent returns to the supervisor, it has one additional compression step to synthesize all of its research findings. This is important because it's hard to control the tool outputs of agent tool calls. Tool outputs can be pretty messy. Looking at these flight search results, we can see a huge JSON including irrelevant information and tokens scattered throughout. Dumping all of this into raw context in our supervisor can lead us to a few problems. The token bloat can push us towards context window limits and there can just be a lot of messy and irrelevant information that the supervisor doesn't need to consider. The sub agent makes use of a cleaning step here to give the supervisor a nice comprehensive mini report of its findings. When I wrote the system prompt, I really emphasized that I wanted to preserve all relevant information and sources. I framed this to the agent as a cleaning step rather than a summary or a synthesis to really try and deter it from accidentally leaving out valuable information. Our output from this LM call gives us a result that lists out all of the searches and tool calls that were made, the fully comprehensive list of findings, and then also at the bottom, a full list of sources that are agent referenced. Once all of our sub aents return nice compressed findings to our supervisor, the supervisor is then in charge of analyzing all of the new findings. This is key. The supervisor can now choose with all of this context to either complete research or to continue to research follow-up questions. This gives the supervisor maximal flexibility on how to conduct research. It mimics how we as humans will look things up. For simpler questions, a service level understanding might be enough. But for more complex questions, I can choose to dive deeper and deeper as I learn more about the topic. Now, at some point, the supervisor is going to be satisfied with the research that's been conducted. Then, it's time to put everything together in a final report. When we write the final report, we found that parallel report writing was pretty finicky. Trying to write sections of a report in parallel led to disjointed and not very cohesive reports. We found that the best approach was to oneshot the report generation with all of our condensed research findings. This is the trace for our final report. With our research brief along with all of our findings, we can write the report in a single shot. Again, we can do this because of our compression step when coming back from each sub aent. When we tried this out without the compression step, we found that those messy tool outputs from sub aents often overloaded the context window of the supervisor for writing this final report. Here the agent gets a nice list of findings from each sub aent without any of the croft. We just walked through the full architecture of our open deep research agent. Like I mentioned earlier, this agent is open source and built on langraph. Now I want to show you how we can run this locally. This is pretty simple. There's just a few steps. First, you should navigate to our Open Deep Research repository and clone the repo locally. Once you've cloned the repo, you can open it in the IDE of your choice and create a virtual environment and install the required dependencies. Make sure that you have the necessary API keys set in the M file. You'll need API keys for models that your deep researcher uses. By default, we use OpenAI models. We also use tability search by default. So you can generate an API key or edit the configuration later to not use that search tool. I've also hooked the agent up to Langmith which is how we saw all of those traces earlier. And this can be really useful for debugging and testing. You can see that in our langraph.json file, we point to the deep researcher graph in our deep researcher.py file. This is where the agent is implemented. Feel free to tweak the prompts or the architecture to tailor it to your use case. Finally, we can start langraph studio by running langraph dev which will start a local development server. The studio UI is a great way to iterate on and test agents especially with different configurations. The open research agent is built to be super configurable. Like I mentioned earlier, you can choose between our default to search or some of the model provider native search tools. You can also connect to MCP servers and give your agent more tools in addition to search. Of course, you can choose the models that are used for different steps in the research pipeline, including for summarization, research, and final report writing. We found that our defaults work well, but you can try out different models from different providers. Finally, let's check back in on the vacation planning request that we kicked off a while ago. This is the output that we get. We can see a report that fully answers our question. This includes an overview of the trip as well as a series of flights that we can book to make sure that we get to the cities that we want to. We also have some options for transport within Europe itself between the different cities that we want to visit. We also have some accommodation options along with the direct booking links along with a sample itinerary for our day-to-day activities which can be helpful as we plan out exactly what we want to do while we're there. At the very bottom, we can see a full list of the sources that were referenced in creating this research report. Now, I can copy this report directly and send it straight to my roommates. This UI that we're looking at right now and that we ran the deep research agent in is called open agent platform. If you don't want to clone the code and run the graph yourself locally through studio, open agent platform is a really easy way to try out the research agent. It exposes a nice UI for you to configure agents with those various tools and models. Like I explained earlier, all you have to do is set up your API keys in the settings page and then you're good to go. We've also written a blog that goes into more detail on some of our design decisions which you can check out, too. Thanks for watching.