Agent Design Issues

[Yeon1007]

I'm currently designing an agent. The general process and objective are as follows:

1. When a user inputs a question, if the input follows a fixed format (or has pre-defined keywords), the agent will extract certain keywords from the format and store them in a variable. Then, based on this variable (e.g., A1, B1, C1), a switch statement will be used to trigger different APIs (API 1, API 2, API 3).

2. When the user's input doesn't follow the specified format or lacks keywords, it triggers an await response, displaying a dropdown list for keyword selection. Different keywords match and trigger different APIs.

However, there are a few issues:

1. How to design and determine if the user's input follows the specified format or contains keywords?

2. For method 2, I'm using await response + switch. For example, my await response key and name are both "Color," and the dropdown list has three options (Red, Green, Blue), each corresponding to a different API. In the switch activity, if I use Equals, such as Color equals Red, it triggers API 1. However, regardless of the dropdown list selection, it always reaches the else branch in the switch (I've set a message activity: "color is not in color list"). Is this due to a design flaw in my switch activity? When I use equals, Contains, or Start with, the response is always "'dict' object has no attribute 'lower'." How can I resolve this?

3. Can RAGFlow display different dropdown lists for different users?

4. Can RAGFlow call functions of other agents within the agent, such as n8n?

5. RAGFlow occasionally throws an AttributeError("'NoneType' object has no attribute 'id'"), although no adverse effects have been observed. Why is this happening? @dosu

[dosubot[bot]]

Here’s how you can address each of your issues:

1. To detect if user input matches a fixed format or contains keywords, use RAGFlow’s Categorize component to classify input into predefined categories using examples and descriptions, or use the keyword_extraction function to extract keywords with an LLM prompt. Both approaches let you branch logic based on detected intent or keywords (source), (source).

2. The switch activity error happens because dropdown selections from Await Response are often dicts (with metadata), not plain strings. The Switch component expects a string or number, so when it gets a dict, string operations like .lower() fail, causing the "'dict' object has no attribute 'lower'" error and always routing to the else branch. To fix this, make sure you extract the actual value (e.g., Color['value'] if the dropdown returns a dict) before passing it to the switch. This ensures the switch compares strings as intended (source).

3. RAGFlow does not support displaying different dropdown lists for different users at runtime. Dropdown options are defined statically in the agent configuration and are the same for all users (source).

4. RAGFlow agents can call external APIs or tools by defining them as ToolBase subclasses, but there’s no built-in way to call other agents (like n8n) directly. To integrate with n8n, expose it as a custom tool/API and register it in your agent’s toolset (source).

5. The intermittent AttributeError("'NoneType' object has no attribute 'id'") usually means some code expected an object (like a task or DB row) but got None—often due to a missing, deleted, or stale record. This is common in task cancellation or progress update logic and usually doesn’t break the workflow, but it’s best to add checks for None before accessing attributes (source).

Let me know if you want code examples or more details on any of these!

To reply, just mention @dosu.

---

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

   

[Yeon1007]

The await response does indeed return a dictionary, such as {"name": "Color", "optional": false, "options": ["RED", "GREEN", "BLUE"], "type": "options", "value": "RED", "key": "Color"}. Through what activity can I extract the "RED" value from this dictionary and use it in a Switch activity?@dosu

[Magicbook1108]

Q1: Try categorize component, it uses a llm to categorize query or content into different categories.
Q2: Could you share the workflow with me via [email protected] so that I can examine it in more detail and provide more in-depth assistance?
Q3: I won't suggest you to consider any multi/different user scenario in open source situation.
Q4: I don't know
Q5: Ignore this since no actual error observed except for this message.

[Yeon1007]

so based on this logic (using title chunker before token chunker), if the chunk size is set to the same as the general chunking method, seems no any difference between using the title chunker first and then the token chunker? @dosu

[dosubot[bot]]

There is a practical difference. When you use the title chunker before the token chunker, the title chunker first splits your document by heading levels (like H1/H2/H3), preserving the document’s structure. The token chunker then only splits or merges those heading-based chunks if they exceed your token limit. This means you keep semantic section boundaries as much as possible, and only very large sections get further split to fit the token size.

If you use only the token chunker, it ignores headings and just splits the text by token count and delimiters, so you lose the original document structure and may break up sections mid-topic.

However, if your title-based chunks are already smaller than the token limit, the token chunker won’t do anything, and the result will be the same as using only the title chunker. If your title-based chunks are larger, the token chunker will split them, but it can also merge smaller chunks together to fill up to the token size, which can blur section boundaries.

So, chaining both is useful if you want to preserve section structure but still enforce a strict token limit. If you want to avoid merging and keep pure section boundaries, use only the title chunker and set your chunk sizes accordingly. More details and examples are in the official discussion and docs.

To reply, just mention @dosu.

---

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

   

[Yeon1007]

After designing a logic using the agent function, I can retrieve data from the database and generate answers. However, after that, Can I implement a feature that, based on the retrieved data, provides the user with some options, such as Option A. Create data visualization based on this data; Option B. Export this data; Option C. Search online for data on this topic and compare it, or could an LLM automatically generate options that might allow for further actions based on this data? @dosu

[dosubot[bot]]

You can present actionable options to users after retrieving data in RAGFlow, but the options (like "visualize", "export", "search online") must be statically defined in your workflow using the Await Response component—these can't be dynamically generated by the LLM or based on the retrieved data at runtime. The typical pattern is: show the answer with a Message node, then use Await Response to let the user pick their next action, and branch your workflow accordingly (e.g., trigger visualization, export, or online search logic) see docs.

You can prompt the LLM to suggest possible next actions in its output text, but these suggestions won't automatically become interactive UI elements—you need to manually map them to Await Response options in your workflow. There’s currently no built-in way for the LLM to generate and render actionable UI options dynamically based on the data or its own suggestions; all interactive choices must be preconfigured source.

For chaining actions, just design your workflow so each Await Response collects user intent and triggers the corresponding logic for visualization, export, or online search. If you want the options to reflect the retrieved data, you’ll need to predefine all possible actions in advance.

To reply, just mention @dosu.

---

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

   

[Yeon1007]

For Agent function, I'm using a REST API, which is using the same URL, but it retrieves different data depending on the body. However, when using the HTTP request component of the agent, I can only edit the header and not the body. How can I solve this?@dosu