Stuck with a Multi-Agent Chaos mid Migration. Please Help!

Hello,

We currently have a Copilot in production that I built with LangGraph. It works, but it is very basic. It can only do one thing at a time: either call internet search once, or perform RAG once. It cannot do both in a single flow, for example: fetch data from the internet and then run RAG over that information.

Example of something it cannot do:

Find what day of the month it is, call that number X, and then find the top X people mentioned in Section A.

With the recent release of DeepAgents and LangChain 1.0, I thought this would be a good time to migrate to a more modern plan and execute workflow, where dynamic interactions like the example above are possible. In that model, the planner would create multiple steps. Each step calls a different node and either replans based on the result or passes that result as input to later nodes.

This is where I am getting confused.

Assume I have four agents:

  • Agent 1: Performs RAG and returns an answer

  • Agent 2: Judges the answer and returns PASS or FAIL

  • Agent 3: Generates a citation-rich answer and returns the final answer (with [1] style citations) and sources

  • Agent 4: Performs web search and returns an answer for a given query, along with sources (of web type)

Now suppose there is a query that needs web search first and then RAG to answer it. Conceptually this sounds simple, but I am running into design issues.

Assume my planner / DeepAgent calls the agents in this order:

Agent 4 → Agent 1 → Agent 2 → Agent 3.

Questions

  1. After Agent 4 runs, it returns a web search answer (a string) to the planner, and this also lives in the state. Am I supposed to assume that the DeepAgent will then call Agent 1 or Agent 2 with the relevant query and context?

    If I do assume that, how do I prevent the web search citations from being lost when the answer is reconstructed later? Because citation generation is a separate step, I cannot see the original web citations once another agent has overwritten the answer field. Designing each node to inspect and handle every other node’s fields feels like a workaround, not a clean solution.

  2. In DeepAgents, what is the best way to design these subagents?

    Should they simply take state and output state or a state update? If I do that, does it prevent the DeepAgent from having direct access to the “real” answer, so it can use that answer as input when choosing and configuring subsequent agent calls?

I think my conundrum is more of a context management problem.

hi @langchain

try to split the entire situation into smaller unit real problems and let’s try to solve them one by one.
Share as much code as you can per each problem.

Thanks. Yes, that makes sense. I have all the agents in agents folder. Each of them are already set in a way that they take AgentState and output updates to it.

I’ll go ahead and break down the orchestrator logic and get back