Proposal: Separate retrieval flow in Langflow

[philnash]

When you ask the OpenRAG agent a question, it uses the Langflow-powered OpenRAG OpenSearch Agent Flow to both retrieve chunks from the OpenSearch index and generate the answer. However, when you perform a search, either within the OpenRAG Knowledge section or through the search endpoint of the API, it performs a direct search against OpenSearch using the available filters.

Right now, the OpenSearch retrieval section of the Agent flow in Langflow only consists of embedding the search term and performing the search against the OpenSearch Langflow component. If the retrieval became more complicated, for example, returning more results and using a re-ranker to re-order chunks, then there would be a difference between a regular search and how the agent searches. You would have to either commit to keeping the search endpoint code in line with the retrieval flow, or you would get different results through your agent compared to search.

Secondly, if you want to edit your agent flow and evaluate the retrieval for metrics like recall and precision, you currently cannot do so. If you use the search API, but you’ve added more components in Langflow, then you are not evaluating the same thing.

I propose that a retrieval flow is separated from the Agent flow and used as a subflow, like the URL ingestion flow, within the agent flow. It should then also be exposed to be used as an API endpoint.

This would mean there is a single place where all your retrieval customizations can go, and they can be used by a search endpoint, by the agent and by the MCP server, enabling other agents to use and evaluations to test against the retrieval pipeline.