Ask a frontier LLM to generate an n8n workflow JSON and it will produce something beautiful, confident, and broken. The node names are almost right. The parameters look plausible. And the import fails, because the model is pattern-matching what n8n configs look like instead of knowing what they are.
Ground the model in real schemas
HatAssembly indexes all 794 n8n node schemas into Supabase pgvector with OpenAI embeddings. When a build request comes in, the retriever pulls the exact schemas for the nodes the workflow needs — and the builder model only ever sees real, current parameter definitions. It cannot hallucinate a config it is reading from the source.
Three agents, one artifact
- Enhancer — turns a vague plain-English brief into a precise workflow specification (trigger, stages, error paths).
- Retriever — semantic search over the 794 schemas; returns only the node definitions the spec needs.
- Builder — Claude + Gemini assemble the workflow JSON from retrieved schemas, then output is validated against the schema before delivery.
The validation gate matters as much as the RAG
Retrieval shrinks the hallucination surface; validation eliminates the remainder. Generated JSON is checked against the actual schema before anyone sees it — invalid output loops back with the validation error attached. The user-facing contract is simple: what comes out imports cleanly, every time.
The general lesson travels well beyond n8n: when an LLM needs to produce machine-consumed artifacts, retrieval plus a hard validation gate beats a bigger model every time.
from the system this note is based onHatAssembly — full case study →