Building n8n Flo: My Journey Into RAG
Building a simple n8n workflow should take 30 seconds.
Building n8n Flo: My Journey Into RAG
Building a simple n8n workflow should take 30 seconds.
Instead, it often takes 20 minutes of clicking through nodes, configuring parameters, and fixing broken JSON.
So I built n8n Flo — a browser extension that generates working n8n workflows from plain English using RAG.
My First Attempt:
I built a quick prototype. ChatGPT → generate JSON → paste into n8n → Done.
It failed spectacularly, lol.
The AI would:
- Make up node types that don’t exist
- Generate syntactically invalid JSON
- Produce completely different results for the same prompt
- Have no reference point for “what good n8n JSON looks like”
I realized: Just asking an LLM to generate something isn’t enough. It needs context. It needs examples. It needs to know what correct output looks like.
That’s when I discovered Retrieval-Augmented Generation (RAG).
Understanding RAG (The Simple Way)
RAG is elegantly simple. Instead of asking: “Generate an n8n workflow”
Ask: “Here are 3 similar workflows. Now generate a new one based on the pattern you see.”
Now, the LLM isn’t smarter — it just has better context. It sees real examples of what good workflows look like, so it follows the pattern instead of hallucinating. Once I understood this, everything clicked!
How I Actually Built It

System Architecture
- Collected 126 real n8n workflows from various sources and stored them in a database on Airtable.
- Used embeddings to convert workflows into semantic representations, allowing the system to retrieve workflows based on meaning rather than exact keywords.
- Fed those examples to an LLM with the user’s request: “Based on these patterns, generate a new workflow”
- Validated the output to ensure it’s syntactically valid, and follows correct n8n’s JSON structure.
One thing I underestimated was how much retrieval quality affects generation quality. I experimented with 7 different retrieval configurations combining semantic similarity and keyword matching as shown in the table below.
I observed that: Keyword matching often retrieved workflows with similar words but completely different logic. Semantic retrieval performed better because it understood intent rather than literal phrasing.
This became one of the biggest lessons from the project: RAG works because retrieval + generation is better than generation alone.

Retrieval performance comparison across 7 retrieval weighting strategies.
Result: A browser Extension that generates n8n workflows from natural language descriptions in ~10 seconds.

Current limitations:
✅ What my system does: Generates valid workflow skeleton from plain English
❌ What it doesn’t do (yet):
- Configure individual node parameters (you still add your own API keys, sheet IDs, etc.)
- Hanging nodes, workflows with incomplete node connections (like you saw in the GIF above)
A system that works for 80% of cases in 10 seconds is more useful than one that works for 100% of cases in 2 hours.
My Next Plan of Action:
- Add multimodal input (upload workflow screenshots)
- Expand the template database
- Smarter node configuration
- Direct n8n integration for one-click deployment
Or… scale it to other low-code platforms like Zapier and make.com
But first, I want to see if this actually solves the problem people care about.
See the project on GitHub!
Thanks to my friends Devansh Gaur and Ajit Singh, and my academic mentor from my university, for helping me build n8n Flo.
메타데이터
- post_id
- 02bec24c0588
- slug
- building-n8n-flo-my-journey-into-rag-02bec24c0588
- url
- https://medium.com/@srujan_v/building-n8n-flo-my-journey-into-rag-02bec24c0588
- canonical_url
- https://medium.com/@srujan_v/building-n8n-flo-my-journey-into-rag-02bec24c0588
- author_url
- https://medium.com/@srujan_v
- status
- ok
- fetched_at
- 2026-06-09 15:37:30