ragflow [Question]:

Self Checks

[x] I have searched for existing issues search for existing issues, including closed ones.
[x] I confirm that I am using English to submit this report (Language Policy).
[x] Non-english title submitions will be closed directly ( 非英文标题的提交将会被直接关闭 ) (Language Policy).
[x] Please do not modify this template :) and fill in all the required fields.

Describe your problem

How can an agent call other defined agents?

Dec 10 '25 07:12 yiyu986

In RAGFlow, an agent can call other defined agents by configuring them as tools or sub-agents in your workflow. The lead agent loads its sub-agents as tools (using the tools field in the agent's configuration), and then invokes them asynchronously as part of its reasoning and planning cycle. This is managed by the Agent class, which treats each sub-agent as a callable tool and coordinates their execution using a ReAct-style loop for planning, tool invocation, and reflection. You can see this pattern in both the code and workflow templates:

In the code, the Agent class manages its tools (which can be other agents) and calls them asynchronously during its _invoke_async lifecycle. The invocation is handled via use_tool_async, which calls the sub-agent and collects results for further reasoning and synthesis. See implementation
In workflow templates, you define a lead agent and specify downstream agents (sub-agents) in the JSON config. The lead agent coordinates the sub-agents by sending instructions and aggregating their outputs. Example multi-agent workflow
The documentation describes how to add tools and agents to an Agent component, enabling multi-agent collaboration and orchestration. Agent component reference

The invocation lifecycle is fully asynchronous, and agents communicate by passing messages and outputs downstream. This setup allows you to build complex multi-agent workflows where agents delegate tasks to each other and synthesize results.

If you want a visual overview, here's a simple diagram of a lead agent orchestrating sub-agents:

graph TD
    A["Lead Agent"] --> B["Outline Agent"]
    A --> C["Body Agent"]
    A --> D["Editor Agent"]

Let me know if you need a concrete configuration example or details on best practices for multi-agent workflows!

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

Dec 10 '25 07:12 dosubot[bot]

In RAGFlow, an agent can call other defined agents by configuring them as tools or sub-agents in your workflow. The lead agent loads its sub-agents as tools (using the tools field in the agent's configuration), and then invokes them asynchronously as part of its reasoning and planning cycle. This is managed by the Agent class, which treats each sub-agent as a callable tool and coordinates their execution using a ReAct-style loop for planning, tool invocation, and reflection. You can see this pattern in both the code and workflow templates:

In the code, the Agent class manages its tools (which can be other agents) and calls them asynchronously during its _invoke_async lifecycle. The invocation is handled via use_tool_async, which calls the sub-agent and collects results for further reasoning and synthesis. See implementation

In workflow templates, you define a lead agent and specify downstream agents (sub-agents) in the JSON config. The lead agent coordinates the sub-agents by sending instructions and aggregating their outputs. Example multi-agent workflow

The documentation describes how to add tools and agents to an Agent component, enabling multi-agent collaboration and orchestration. Agent component reference

The invocation lifecycle is fully asynchronous, and agents communicate by passing messages and outputs downstream. This setup allows you to build complex multi-agent workflows where agents delegate tasks to each other and synthesize results.

If you want a visual overview, here's a simple diagram of a lead agent orchestrating sub-agents:

Let me know if you need a concrete configuration example or details on best practices for multi-agent workflows!

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

need a concrete configuration example or details on best practices for multi-agent workflows. @dosu.

Dec 10 '25 09:12 yiyu986

Here's a concrete example and best practices for multi-agent workflows in RAGFlow:

Concrete Configuration Example

You can configure a lead agent to orchestrate sub-agents as tools using the tools field. For example, the generate_SEO_blog.json template defines a Lead Agent that coordinates three sub-agents (Outline Agent, Body Agent, Editor Agent), each with their own prompts, roles, and tool integrations. Here’s a minimal illustrative snippet:

{
  "component_name": "Agent",
  "name": "Lead Agent",
  "params": {
    "sys_prompt": "You are the Lead Agent. Parse user input, generate a plan, instruct sub-agents, and merge outputs.",
    "tools": [
      {
        "component_name": "Agent",
        "name": "Outline Agent",
        "params": {
          "sys_prompt": "Create a blog outline.",
          "tools": [ /* e.g., search tools */ ]
        }
      },
      {
        "component_name": "Agent",
        "name": "Body Agent",
        "params": {
          "sys_prompt": "Write blog content based on outline.",
          "tools": [ /* e.g., search tools */ ]
        }
      },
      {
        "component_name": "Agent",
        "name": "Editor Agent",
        "params": {
          "sys_prompt": "Polish and finalize the blog post."
        }
      }
    ]
  }
}

The Lead Agent delegates tasks to sub-agents, each focused on a specific stage. The workflow is orchestrated via the tools field, and message passing is handled automatically. For a full real-world example, see the SEO blog workflow template.

Best Practices

Delegate simple subtasks (like retrieval, rewriting, formatting) to lightweight sub-agents using smaller, faster models, and keep complex reasoning in the lead agent with a more capable model. This reduces latency and cost without sacrificing quality (source).
Use concise prompts and explicit output length limits for sub-agents to minimize output tokens and speed up responses.
For complex tasks (multistep reasoning, synthesis), maintain planning, reflection, and verification steps in the lead agent’s prompt (source).
Structure your workflow modularly: Begin → Lead Agent → Sub-Agents → Message. Each agent should have a clear, focused responsibility (source).
Use the Agent component’s error handling parameters (max_retries, delay_after_error, etc.) to make workflows robust (source).
Leverage framework-level prompt blocks (task_analysis, plan_generation, reflection, citation_guidelines) for advanced delegation and orchestration (source).

Troubleshooting Tips

Ensure all nodes are connected in series; isolated nodes won’t execute.
Use the latest RAGFlow version to avoid bugs.
If you get empty results, try prepending USER: to your input query (source).

Let me know if you want a more detailed breakdown of any part of the configuration or workflow!

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

Dec 10 '25 09:12 dosubot[bot]

I want to implement the example shown in the above figure, where subagents-1 and subagents-2 are existing agents, and then create a new lead agent to call subagents-1 and subagents-2.

Dec 10 '25 09:12 yiyu986

To implement a hierarchical workflow where a lead agent calls subagents-1, which then calls subagents-2, you define each agent inline as a tool in the configuration. Agents are not referenced by global name or ID—they are included as full configuration blocks under the parent agent’s tools field. For sequential delegation (lead agent → subagents-1 → subagents-2), you nest subagents-2 inside subagents-1’s tools array. The lead agent’s planning logic (prompt or plan blocks) determines the execution order, not just the config order. Here’s a minimal example:

{
  "component_name": "Agent",
  "name": "Lead Agent",
  "params": {
    "sys_prompt": "You are the lead agent. Delegate to subagents-1, then subagents-2.",
    "tools": [
      {
        "component_name": "Agent",
        "name": "subagents-1",
        "params": {
          "sys_prompt": "You are subagents-1. Delegate to subagents-2.",
          "tools": [
            {
              "component_name": "Agent",
              "name": "subagents-2",
              "params": {
                "sys_prompt": "You are subagents-2. Complete the final task."
              }
            }
          ]
        }
      }
    ]
  }
}

This structure matches the flow in your diagram. If subagents-1 and subagents-2 are already defined elsewhere, you need to copy their configuration blocks into the new lead agent’s config—there’s no import-by-reference mechanism. To enforce strict sequencing, make sure your prompts or plan blocks in the lead agent and subagents-1 clearly instruct the order of delegation. For more details, see the SEO blog workflow example and Agent class implementation.

Diagram for clarity:

graph TD
    A["Lead Agent"] --> B["subagents-1"]
    B --> C["subagents-2"]

Best practices: keep each agent’s responsibility focused, use concise prompts, and handle errors with retry/delay parameters. If you want to reuse agents in multiple workflows, consider maintaining their config blocks in a shared location for easy copy-paste.

To reply, just mention @dosu.

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

Dec 10 '25 09:12 dosubot[bot]

We are working on it. Currently not available.

Dec 10 '25 11:12 Magicbook1108