OpenAPI Agent example

[markoviksten]

I´m looking for simple OpenAPI Agent Example. Sample openapi json file and langflow json sample which use it and works, do we have any?

[dosubot[bot]]

Yes, there is a working example in the repo. You can find a sample OpenAPI JSON file at docs/openapi.json, which defines an OpenAPI 3.1.0 spec with several endpoints related to Langflow itself.

For a Langflow flow that uses an OpenAPI Agent, check out src/backend/tests/data/Openapi.json. This file shows how to wire up components like JsonSpec (which points to an OpenAPI spec file), JsonToolkit, OpenAPIToolkit, JsonAgent, and a language model (e.g., ChatOpenAI) into a working flow. The JsonSpec node references a file path (e.g., api-with-examples.yaml), but you can substitute this with the path to your own OpenAPI JSON or YAML file.

For more details on the OpenAPI Agent component and its parameters, see the component documentation.

You can use these files as templates: point the JsonSpec node to your OpenAPI file, and make sure your flow connects the components as shown in the sample. This should get you up and running with an OpenAPI Agent in Langflow.

To reply, just mention @dosu.

---

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

[markoviksten]

@dosu what if I have custom RAG flow, meaning just adding vector database as a tool is not enough, but requires custom handling for result inside of tool? how can I do this?

[dosubot[bot]]

You can absolutely implement a custom RAG flow with internal result handling in Langflow by creating your own custom component and exposing it as a Tool for the agent. The key is to encapsulate your entire RAG pipeline—including any custom logic, post-processing, or multi-step handling—inside a single component method, and then register that as a Tool output.

Here's how you can do it:

1. Subclass the right base: For advanced tool integration, subclass LCToolComponent (or Component for simpler cases) in your custom component Python file.
2. Define your inputs: Use tool_mode=True on any input(s) you want the agent to pass automatically (e.g., the query string or parameters) example.
3. Implement your custom logic: Put all your RAG steps—retrieval, ranking, augmentation, post-processing—inside a method (e.g., run_model or a custom function).
4. Expose as a Tool: Implement a build_tool method that returns a StructuredTool using from_function, pointing to your custom logic function and a Pydantic schema for arguments example.
5. Register outputs: Make sure your outputs are typed (e.g., -> Message or -> Data) for UI compatibility.
6. Directory structure: Place your component in a category subfolder under your LANGFLOW_COMPONENTS_PATH so it shows up in the UI docs.

Minimal example:

from langflow.base.langchain_utilities import LCToolComponent
from langchain.tools import StructuredTool
from pydantic import BaseModel, Field
from langflow.schema.message import Message

class MyRAGSchema(BaseModel):
    query: str = Field(..., description="The user query")

class CustomRAGTool(LCToolComponent):
    display_name = "Custom RAG Tool"
    description = "Custom RAG pipeline with post-processing"
    name = "CustomRAGTool"
    # ... icon, etc.

    # Inputs
    inputs = [
        # ... other config inputs
        # This input will be passed by the agent
        StrInput(name="query", display_name="Query", tool_mode=True),
    ]

    def run_model(self) -> Message:
        # Your custom RAG logic here
        docs = self.retrieve_docs(self.query)
        ranked = self.rank_docs(docs)
        answer = self.post_process(ranked)
        return Message(text=answer)

    def build_tool(self):
        return StructuredTool.from_function(
            name="custom_rag_tool",
            description="Custom RAG pipeline with post-processing",
            func=self._rag_func,
            args_schema=MyRAGSchema,
            return_direct=True,
        )

    def _rag_func(self, query: str) -> str:
        # Same as run_model, but returns a string
        docs = self.retrieve_docs(query)
        ranked = self.rank_docs(docs)
        return self.post_process(ranked)

Connect the Tool output of your component to the agent’s tools input in the UI. The agent will now call your custom logic as a single tool, and you can handle the results however you want inside your component.

For more details and advanced options (like accessing intermediate outputs or handling multi-step logic), see the custom components guide and tool integration docs.

Let me know if you want a more concrete example or have a specific RAG pattern in mind!

To reply, just mention @dosu.

---

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

[markoviksten]

@dosu ok that might be one possible way although it would be a bit complex to build such an configurable custom component. I found out that alternative option might be organizing multiple agents on canvas where I have RAG Agent (with all customized functions) as it is and then I have Agent for supporting naturaly Tools component and then I have Master Agent running complete tools and custom RAG flow - it worked and was a way more simplier to build than customized rag custom tool

[dosubot[bot]]

That's a great use of Langflow's compositional design—organizing multiple agents on the canvas (e.g., a custom RAG agent, a tools agent, and a master agent) is a fully supported and effective pattern. This approach gives you modularity, lets you configure each agent or tool independently, and avoids the complexity of wrapping everything into a single custom component.

Langflow is built for this kind of orchestration: agents and tools can be chained or combined simply by connecting their outputs and inputs on the canvas—no special orchestration code is needed. If an agent exposes itself as a Tool, it can be used by another agent, enabling multi-agent setups like yours "Langflow's architecture is inherently compositional".

A few tips and caveats:

• Make sure each agent/tool is properly registered (sometimes tool visibility depends on config like tool_mode, input_types, or list/show flags) "tool registration and recognition".
• Passing context or data between agents (especially non-text data) may require explicit routing or upload steps "handling data between agents".
• For sequential or context-aware workflows, check out Sequential Task Agents or the Sequential Crew component, which are designed for multi-agent task pipelines with context retention "Sequential Task Agents".
• If you want to use different model configs (like temperature) per agent/tool, splitting into separate agents is the way to go "different configurations per agent".

If you run into edge cases (like tools not appearing, or context not flowing as expected), let me know—there are some known quirks and workarounds. Happy to help with more advanced orchestration patterns or troubleshooting!

To reply, just mention @dosu.

---

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