I’m looking for a Make.com expert with experience in building RAG agents inside make.
In the current phase we have the following:
- Complete data flow architecture including 2 RAG agents + 3 LLM’s generating an output.
For the RAG open ai embeddings works fine but for the LLMs we suggest Gemini.
- This also includes the database mapping for each entry. We can discuss in detail how we want the schema.
I’ll share a Miro board link for a visual understanding of how the data would flow.
Once that is complete we’ll move to building the complete product together.
Prompts for agents will be provided by us and knowledge base for RAG.
This is an urgent project we need completed in 3-4 days. So, if you believe that’s possible for you, do reach out and lets get on a call..
1 Like
Hi Kartik — quick honest take on doing RAG inside Make.com:
Make is great for the orchestration layer (chunk → embed → retrieve → call LLM → return) but the actual vector search needs to live elsewhere. The two architectures that work:
A) Pinecone / Weaviate / Qdrant as the vector store, called from Make via HTTP modules. Simple, scales, costs ~$0-70/month at small scale.
B) Supabase + pgvector. Cheaper, single source of truth if you already use Postgres, slightly more setup.
What Make handles really well: doc ingestion pipelines (Google Drive trigger → chunk → embed → upsert), and the retrieval-then-LLM-call composition. What Make does not do well: high-volume realtime queries (latency stacks up across modules) — for query-side, a small FastAPI sidecar in front of the same vector store is usually better.
For “urgent” — what’s the use case + deadline? RAG-on-knowledge-base for a chatbot is 4-7 days end-to-end. RAG-on-customer-data for sales enablement is 1.5-2 weeks (data pipeline is the long pole).
Background: I’ve built multi-agent LangGraph orchestration platforms with retrieval at multiple agent steps, so the “make RAG actually work in production” problem is familiar territory.
Email me at [email protected] with the use case + when you need it live, and I’ll come back with a 1-pager + scope.
— Priyanshu
linkedin.com/in/priyanshu-axiom
Hi. I can help with the Make/RAG architecture.
I would start with one paid slice: validate the data schema, one RAG agent path, one LLM output contract, and failure logging before expanding to the full product. That should quickly show whether the architecture is solid.
For a Make RAG build, I would start with one retrieval path that your team can verify end to end.
The build should lock the source documents, embedding store, retrieval query, prompt inputs, model routing, output schema, and error logging. Once one representative request produces the right structured output, the second agent and extra LLM steps can be added without guessing at the data contract.
TinyOps Studio can quote a fixed RAG rescue/build sprint for the first verified retrieval path, with the schema, run log, and handoff notes included.
Send the Miro flow, knowledge base source, and one expected input/output example, and I can confirm the scope.