How to implement Dynamic Runtime Subagents in DeepAgents + LangGraph

OSS Product Help Deep Agents
,
1

Hi everyone,

I’m trying to understand the best way to implement dynamically generated subagents at runtime.

My goal is slightly different from the standard DeepAgents subagent pattern. Instead of predefining all subagents, I want the orchestrator to:

  1. Analyze the incoming task.
  2. Generate a specialist agent definition at runtime.
  3. Allocate a custom system prompt, tools, permissions, workspace/file access rules, and context.
  4. Execute the specialist.
  5. Verify the output using a reviewer/critic agent.
  6. Return the result to the orchestrator.
  7. Dispose of the temporary specialist and continue the workflow.

Conceptually:

Orchestrator
↓
Agent Architect
↓
Runtime Agent Factory
↓
Specialist Agent
↓
Verifier
↓
Aggregator

From my research, it seems DeepAgents supports custom “CompiledSubAgent” runnables, and LangGraph provides dynamic worker execution through “Send”. This makes me wonder whether a runtime-created LangGraph workflow or DeepAgent instance could be treated as a temporary specialist worker.

My questions:

  • Is this architecture aligned with how DeepAgents and LangGraph are intended to be used?
  • Has anyone implemented runtime-generated specialists or agent factories in production?
  • Would you recommend using LangGraph as the orchestration layer and DeepAgents as workers, or keeping everything inside DeepAgents?
  • Are there existing examples of combining “CompiledSubAgent”, “Send”, and dynamic tool allocation for this pattern?
2

In your Runtime Agent Factory, who authorizes the specialist’s tools and workspace/file access: the generated definition itself, or runtime checks independent of it? Putting permission rules in the system prompt isn’t the same as enforcing them.

3

Current workspace-level access grants permissions to all sub-agents accessible by the main orchestration agent.

4

Hello @mrsknetwork welcome to Langchain community,
This is a reasonable architecture, but separate runtime-generated plans from runtime-generated permissions.

I would generally use LangGraph for orchestration and DeepAgents as workers when specialists need filesystem access, long-running planning, or their own subagents. Send is useful for dynamic fan-out, while CompiledSubAgent can represent a worker but neither provides authorization or sandboxing.

The agent architect should return a validated declarative spec containing things like the model, tools, workspace, and budget. A separate policy layer must authorize that spec before execution:

effective permissions =
caller permissions ∩ environment policy ∩ approved capabilities

Never let the generated prompt grant permissions or load arbitrary tools. If all subagents inherit workspace-level access, they share that authority; narrower access must be enforced by tool wrappers, scoped filesystems, credentials, or isolated processes.

For verification, use deterministic checks followed by a reviewer with limited permissions. The reviewer should return a structured approval, retry, or rejection decision.

For simple model routing, you likely do not need to compile a new graph per request. Classify once, store the route in state, and select from a static allowlist of models. This is easier to observe, secure, and maintain.

5

@mrsknetwork if everything is clear, please mark the answer as solution otherwise let me know if you have any more questions, would love to help you out :slight_smile:

6

@keenborder786 thanks for your suggestion and solution. I also noticed that Langchain recently released their beta version of the SDK update that has dynamic sub-agents. Which I was looking for. Dynamic subagents - Docs by LangChain