What is your goal?
I am building a Make scenario to perform a multi-model comparison.
The architecture is designed as follows:
- Trigger: A Custom Webhook receives a prompt.
- Distribution: A Router distributes this single prompt in parallel to three different AI modules simultaneously:
- DeepSeek AI (Create a Chat Completion)
- Anthropic Claude (Create a Prompt)
- OpenAI (Create a Chat Completion)
- Final Objective: I want to collect the text responses generated by all three models and pass them together into a final Google Gemini AI module, so Gemini can act as a “judge” and provide a comparative analysis of the three answers.
What is the problem?
I am facing a structural/routing limitation in Make regarding how to merge or pass these parallel outputs into the final downstream module:
- If I use a linear sequence (Webhook → DeepSeek → Claude → OpenAI → Gemini), the models execute one after the other instead of in parallel, or the data mapping becomes cumbersome.
- If I use parallel branches via a Router, Make’s design prevents multiple direct lines from converging into a single destination module (Google Gemini) because a module expects a single incoming primary stream.
- I initially tried using Array Aggregators on each branch, but I ran into configuration roadblocks (e.g., “Source Module must not be empty” or errors mapping individual text strings into an array structure meant for looping, since these are single text completions, not lists of items).
What is the best practice or correct design pattern in Make to fan out a prompt to multiple AI engines in parallel and then gather their individual text outputs into one final evaluation module (Gemini)?
I have attached screenshots of my current scenario layout and configuration for reference. Any step-by-step guidance or pattern recommendation would be hugely appreciated!
What have you tried so far?
I tried using Array Aggregators on each parallel branch, but encountered configuration errors (“Source Module must not be empty” and warnings about unused data). I also tried mapping individual text outputs into a single downstream module, but Make only allows a single primary incoming stream per module, preventing the three parallel branches from converging directly into Google Gemini.
Screenshots: scenario setup, module configuration, errors
Hey there,
You don’t need the router here. Delete it and just run the three models one after the other.
Hello @Mandalorian,
Simplest approach - you can go with Stoyan’s solution - simply run them sequentially - one after another. Consider adding Resume Error Handler if you want to execute workflow in case any of AI is unresponsive.
You can also use “magic formula” trick – store output of each model as variable and on very last route add Get Variables module to pass them to Gemini.
With this approach you can manage scenario easily, modify it or add proper error handling so in case any AI fails - you will be able to execute Gemini.
Hey! Ran into this exact headache last month. 
The Router splits your data into separate bundles, so your final Gemini module is only seeing one at a time, not all three.
You actually need to drop an ‘Array Aggregator’ (or use a Set/Get Variable combo) right before Gemini to catch and merge the outputs. Have you tried setting up the aggregator yet? It’s a bit tricky to map the fields, but it’s the only way it works.
That’s false. An array aggregator does nothing here.
this is the simplest and cleanest way.
Thank you everyone for the feedback!
You confirmed the structural constraint: using the Router here splits execution into separate bundles that cannot merge cleanly back into a single evaluator module without complex Set/Get Variable workarounds. Stoyan’s point on sequential chaining makes sense within Make’s execution model.
While migrating to a single Make AI Agent works for a simplified linear flow, the core goal remains a true Multi-Agent / LLM-as-a-Judge architecture: querying 3 models in parallel (OpenAI, Claude, DeepSeek) and having a 4th model (Gemini) evaluate, cross-check, and synthesize their outputs into a final response.
Since native parallel branch merging isn’t built into Make without workarounds, what platform or architecture would you recommend for this specific pattern? Is handling this via an orchestrator like n8n, Dify, or custom LangGraph code the standard way to avoid latency and bundle bottlenecks?
Ok but why are you splitting this in branches to begin with?
Nothing in this flow suggests splitting. You have one bundle, you pass it throw three LLMs and then the fourth one evaluates the outputs. Why does this need to be split up in branches?
Thanks @Nicolas_Medina and @Stoyan_Vatov for pushing the discussion forward!
To answer Stoyan’s question on why branches vs. a sequential chain:
-
Zero Bias / Independent Reasoning: Running models sequentially inevitably leads to context contamination if earlier outputs are passed along, or creates massive cumulative latency (T1 + T2 + T3) if run in isolation. Splitting into parallel branches ensures 3 frontier models evaluate the exact same prompt independently without knowing what the others answered.
-
True Redundancy & Risk Mitigation: In mission-critical workflows (financial modeling, technical logic, automated legal or code validation), relying on a single model’s reasoning or chaining them sequentially is a massive vulnerability. LLMs hallucinate and carry individual blind spots. Having 3 independent opinions allows a 4th supervisory model (the Judge) to cross-examine facts, discard outliers, and synthesize the highest-fidelity answer.
-
Commercial Value: While compute/token costs are higher, the cost of an undetected hallucination in production is far greater. Packaging this consensus pattern (Parallel Multi-LLM + Judge Arbiter) as a reliable microservice represents a huge commercial leap compared to standard single-prompt pipelines.
The issue isn’t the logical architecture itself, but the fact that Make’s Router treats branches as separate sequential bundles rather than allowing a native parallel fork-and-join (Merge). That is why moving the concurrent orchestration outside (e.g., async serverless / n8n / LangGraph) and returning the consolidated JSON to Make becomes necessary.
To make the point even clearer with a real-world analogy:
Running models sequentially is like the game of “Telephone” (or “Chinese Whispers”).
If Model 1 introduces a subtle hallucination or bias, Model 2 takes it as ground truth and builds on it. By the time it reaches Model 3 and the Judge, the entire premise is distorted and contaminated.
In real life, critical decision-making never relies on a chain of whispers. If you need a high-stakes medical, legal, or structural assessment, you commission 3 independent experts who work in parallel without talking to each other. Then, an arbitrator compares their uncorrupted findings to verify the truth and catch discrepancies.
It definitely costs more time and compute, but eliminating catastrophic hallucinations makes it the only reliable path for mission-critical automation.
You don’t run the models using the output of the previous module mate, you run the the exact same way you would after a router, except without the router. On the original input. Just because two modules are placed one after the other it doesn’t mean the second one runs on the output of the first one. It just means they run one after the other.
Also it doesn’t matter if you are running them with a router or sequentially, they will still take the same time to run overall.
The path in Make specific the sequence in which modules get executed. This is not the same as the sequence in which the data flows. You map where the data goes. Just don’t change the mapping and don’t feed the output of one model to the next one.
Hello @Mandalorian , were you able to solve this?
In Make, the tricky part with parallel branches isn’t the fan-out. It’s the convergence. The clean pattern is to attach an Array Aggregator to each parallel branch’s model output, then map that combined array into the Gemini judge module’s prompt — without that step, a single downstream module will only see whichever branch produced the last bundle. Also worth checking your Router module: by default it picks one route based on the first matching filter, so if you want all three providers to actually fire every time, you probably want a true parallel fan-out pattern rather than relying on Router’s conditional branching. One concrete thing to verify in your setup is whether the Aggregator’s “Source module” is pointed at each branch’s individual HTTP/AI module rather than at a downstream module, otherwise the bundle ordering can get confusing when you reference items like 1.body, 2.body, 3.body in the Gemini prompt.
No its not. Did you even read the thread so far?
I feel for you. @Stoyan_Vatov I think you may be answering AI generated posts. People (or bots) are not reading your well constructed information which is clear and correct. I’d flag these posts but I don’t care that much. lol.
@Greatness_Solutions just tagging you both so you see the update above. Thanks again! Hi everyone, sorry for going quiet, the last couple of weeks got busy.
Quick update: I moved this project to another platform in the end, and it’s done now, working the way I needed.
@Stoyan_Vatov you were right, and I owe you that one. Running the models one after the other on the same original input doesn’t mix anything up. I was confusing the order the modules run in with how the data flows, so my “telephone game” example didn’t really apply. Thanks for taking the time to explain it twice.
Thanks also to Michał for the Set/Get Variables tip, it helped me understand how the pieces fit together, and to Greatness Solutions for checking in: yes, it’s solved.
And fair point. English isn’t my first language and I leaned on AI to write my earlier posts. I should have kept them shorter and in my own words.
Thanks again, all.
The reason I switched: this ended up growing into a bigger project than a single scenario. I needed several AI models running at the same time, plus a judge, on my own server, and for that setup n8n self-hosted was a better fit for me. Make is great for what it does, it just wasn’t the right tool for this particular job.
Awesome i already grab the idea at once happy you were able to solve your issue
