Three layers (default)

All steps

Parts of this pattern

Prompt Input / output: The user's prompt, such as 'Explain how HTTPS certificate pinning works'. Every layer sees it.
Qwen1.5-110B LLM call: A first-layer proposer. It answers the prompt alone, without seeing any other model's answer.
Llama-3-70B LLM call: A second first-layer proposer, from a different model family, answering independently.
WizardLM 8x22B LLM call: A third first-layer proposer. Its answer may be the weakest; later layers can still use what it gets right.
Qwen1.5-110B LLM call: The same model, called again in layer 2: it reads all three layer-1 answers and writes an improved one.
Llama-3-70B LLM call: A layer-2 call that reads every layer-1 answer and writes its own refined version.
WizardLM 8x22B LLM call: A layer-2 call that reads every layer-1 answer, keeps their strengths and fixes their mistakes.
Aggregator Aggregator: The final layer: one strong model that reads all the layer-2 answers and synthesizes a single response.
Answer Input / output: The synthesized explanation, returned to the user.
Prompt → Qwen1.5-110B: The raw prompt goes to the first proposer.Explain how HTTPS certificate pinning works.
Prompt → Llama-3-70B: The same prompt goes to the second proposer, in parallel.Explain how HTTPS certificate pinning works.
Prompt → WizardLM 8x22B: The same prompt goes to the third proposer, in parallel.Explain how HTTPS certificate pinning works.
Qwen1.5-110B → Qwen1.5-110B: Response 1 from layer 1 goes to every layer-2 model, including this one.Response 1: Pinning stores the server's expected public key in the app and rejects any other, even one a trusted CA signed.
Qwen1.5-110B → Llama-3-70B: Response 1 also goes to the second layer-2 model.Response 1: Pinning stores the server's expected public key in the app and rejects any other, even one a trusted CA signed.
Qwen1.5-110B → WizardLM 8x22B: Response 1 also goes to the third layer-2 model.Response 1: Pinning stores the server's expected public key in the app and rejects any other, even one a trusted CA signed.
Llama-3-70B → Qwen1.5-110B: Response 2 from layer 1 goes to every layer-2 model.Response 2: Pins can be the whole certificate or the public-key hash (SPKI); key pins survive certificate renewal.
Llama-3-70B → Llama-3-70B: Response 2 goes to the second layer-2 model.Response 2: Pins can be the whole certificate or the public-key hash (SPKI); key pins survive certificate renewal.
Llama-3-70B → WizardLM 8x22B: Response 2 goes to the third layer-2 model.Response 2: Pins can be the whole certificate or the public-key hash (SPKI); key pins survive certificate renewal.
WizardLM 8x22B → Qwen1.5-110B: Response 3 from layer 1 goes to every layer-2 model, mistakes included.Response 3: Pinning is set with the HPKP header, which all browsers support. (Wrong: browsers dropped HPKP.)
WizardLM 8x22B → Llama-3-70B: Response 3 goes to the second layer-2 model.Response 3: Pinning is set with the HPKP header, which all browsers support. (Wrong: browsers dropped HPKP.)
WizardLM 8x22B → WizardLM 8x22B: Response 3 goes to the third layer-2 model.Response 3: Pinning is set with the HPKP header, which all browsers support. (Wrong: browsers dropped HPKP.)
Qwen1.5-110B → Aggregator: Each refined layer-2 answer goes to the aggregator.Pinning: the app ships the expected SPKI hash and rejects other keys. Browsers dropped HPKP; pinning now lives in mobile apps.
Llama-3-70B → Aggregator: The second refined answer goes to the aggregator.Pin the public key, not the certificate, and ship a backup pin so a key rotation does not lock users out.
WizardLM 8x22B → Aggregator: The third refined answer goes to the aggregator.Pinning defends against a compromised or rogue CA; the cost is that a wrong pin bricks the app's connections.
Aggregator → Answer: The aggregator's single synthesized response is returned.Certificate pinning makes an app trust only a specific public key for a server... Use SPKI pins with a backup pin; HPKP is obsolete.

MoA-Lite

One proposer layer feeds the aggregator directly: about half the calls of the full version, for a smaller gain.

All steps

Parts of this pattern

Prompt Input / output: The user's prompt, such as 'Explain how HTTPS certificate pinning works'.
Qwen1.5-110B LLM call: A proposer. It answers the prompt alone, without seeing any other model's answer.
Llama-3-70B LLM call: A second proposer, from a different model family, answering independently.
WizardLM 8x22B LLM call: A third proposer. Its answer may contain mistakes that the aggregator has to catch.
Aggregator Aggregator: One model reads every proposer's answer and synthesizes a single response, fixing what they got wrong.
Answer Input / output: The synthesized explanation, returned to the user.
Prompt → Qwen1.5-110B: The raw prompt goes to the first proposer.Explain how HTTPS certificate pinning works.
Prompt → Llama-3-70B: The same prompt goes to the second proposer, in parallel.Explain how HTTPS certificate pinning works.
Prompt → WizardLM 8x22B: The same prompt goes to the third proposer, in parallel.Explain how HTTPS certificate pinning works.
Qwen1.5-110B → Aggregator: Response 1 goes to the aggregator.Response 1: Pinning stores the server's expected public key in the app and rejects any other, even one a trusted CA signed.
Llama-3-70B → Aggregator: Response 2 goes to the aggregator.Response 2: Pins can be the whole certificate or the public-key hash (SPKI); key pins survive certificate renewal.
WizardLM 8x22B → Aggregator: Response 3 goes to the aggregator, mistakes included.Response 3: Pinning is set with the HPKP header, which all browsers support. (Wrong: browsers dropped HPKP.)
Aggregator → Answer: The aggregator's single synthesized response is returned.Certificate pinning makes an app trust only a specific public key for a server... Use SPKI pins; HPKP is obsolete.

← → neighboursesc atlas

Multi-Agent

Mixture-of-Agents

Also known as MoA · Layered aggregation · Proposer-aggregator layers

Layers of different models each answer, every model in the next layer reads all the previous answers, and an aggregator writes the final one.

Three layers: Introduced by Wang et al. (2024) · Together AI, Duke University and others

The paper found that models write better answers when shown other models' answers, even weaker ones, and stacked that effect into layers.

MoA-Lite: Introduced by Wang et al. (2024) · Together AI, Duke University and others

The paper's cost-effective configuration: two MoA layers instead of three (proposers, then the aggregator), with Qwen1.5-72B-Chat aggregating.

Measured over one run

Three layers

Nodes: 9. Boxes in the diagram: models, tools, stores, people and plain code.
LLM calls: 6. Model invocations in the first scenario: each time a model or agent node starts thinking, plus each branch it decides.
Tool calls: 0. Messages sent to a tool node in the first scenario.
Steps: 6. Steps in the first scenario, with repeated steps counted every time they run.
Scenarios: 1. Distinct example runs you can switch between on the diagram.
Loop: no. Whether the flow cycles back on itself until a condition is met.
Parallel: yes. Whether two or more messages are in flight at the same time.
Branch: no. Whether the flow takes one path out of several, chosen at run time.
Human in the loop: no. Whether a person appears as a node, to approve, correct or answer.
Autonomy: low. How much the model decides the control flow itself, from fixed code paths (low) to open-ended (high).
Cost: high. Relative token spend per request.
Latency: high. Relative wall-clock time per request.

MoA-Lite

Nodes: 6. Boxes in the diagram: models, tools, stores, people and plain code.
LLM calls: 3. Model invocations in the first scenario: each time a model or agent node starts thinking, plus each branch it decides.
Tool calls: 0. Messages sent to a tool node in the first scenario.
Steps: 4. Steps in the first scenario, with repeated steps counted every time they run.
Scenarios: 1. Distinct example runs you can switch between on the diagram.
Loop: no. Whether the flow cycles back on itself until a condition is met.
Parallel: yes. Whether two or more messages are in flight at the same time.
Branch: no. Whether the flow takes one path out of several, chosen at run time.
Human in the loop: no. Whether a person appears as a node, to approve, correct or answer.
Autonomy: low. How much the model decides the control flow itself, from fixed code paths (low) to open-ended (high).
Cost: high. Relative token spend per request.
Latency: high. Relative wall-clock time per request.

Counted from the first scenario's timeline when the site is built.

Problem

Different models are good at different things. Ask three of them to “explain how HTTPS certificate pinning works” and one gives the clearest mechanism, another remembers that public-key pins survive certificate renewal, and the third confidently says browsers support the HPKP header, which they dropped years ago. Picking one model means losing what the others knew. A majority vote does not help either, because there is no single short answer to count.

How it works

Mixture-of-Agents stacks models in layers. In the first layer, several models from different families each answer the prompt on their own: Qwen, Llama and WizardLM in the diagram. Every model in the next layer then receives the original prompt plus all of the first layer’s answers, numbered, under an aggregate-and-synthesize prompt: evaluate these critically, keep what is right, fix what is wrong and write a better answer.

In the example, each layer-2 model sees all three first-layer answers. They keep the clear mechanism and the advice about key pins, and drop the HPKP claim because the other answers contradict it. A final aggregator does the same over the layer-2 answers and writes the single answer the user gets.

The paper behind the pattern found that models write better answers when shown other models’ answers, even weaker ones. Layering repeats that effect. The models can be the same in every layer; what matters is that each layer sees everything the last one produced. The MoA-Lite tab shows the cheaper version, with one proposer layer feeding the aggregator directly.

When to use

Answer quality matters more than cost or latency: reports, explanations, high-value drafts.
You have access to several capable models from different families, so their mistakes are unlikely to overlap.
The output is open-ended prose that cannot be majority-voted.

When to avoid

Latency matters. Every layer waits for its slowest model, and the layers run one after another.
The budget is tight. Three proposers over two layers plus an aggregator is seven calls, with ever longer prompts.
Your models are near copies of each other. The gain comes from diversity, and similar models repeat the same mistakes.

Trade-offs

Mixture-of-Agents is a pure quality-for-cost trade with no autonomy at all: the topology is fixed, and no model chooses what happens next. Each extra layer multiplies the calls and lengthens the time to first token, and the gains shrink after two or three layers. The aggregator is the bottleneck. It must be strong enough to judge and merge several long answers, or the final step throws away what the earlier layers found.

Failure modes

Majority of wrong: if most first-layer answers share a mistake, later layers tend to adopt it. Use models from different families.
Copying, not synthesizing: a later model copies the longest or most confident answer. Tell it explicitly not to copy any one answer.
Weak aggregator: a small final model drops good details from the layer-2 answers. Use your strongest model for the last step.
Context overflow: long answers times several models overflows the context window. Cap the proposers’ answer length.

Build it with your AI

Three layers

Paste this into Claude Code, Cursor, ChatGPT or any AI coding assistant.

Implement the Mixture-of-Agents pattern in this codebase, using the LLM client and language we already use.

## Goal

Answer a prompt with layers of diverse models: the first layer answers independently, each later layer refines using all the previous layer's answers, and an aggregator model synthesizes the final response.

## How it works

1. Configure a list of proposer models, ideally from different model families, the number of proposer layers (default 2) and one aggregator model.
2. Layer 1: send the user's prompt to every proposer in parallel, with no other context.
3. Each later layer: call every proposer again in parallel with the Aggregate-and-synthesize prompt, containing the user's prompt and all of the previous layer's responses, numbered.
4. If a proposer call fails or times out, drop it from that layer and carry on with the responses that remain; see the stop rule for when too few survive.
5. Finally, call the aggregator model with the Aggregate-and-synthesize prompt over the last layer's responses, and return its output.

## Prompts

### Aggregate-and-synthesize prompt

```markdown
You have been given a set of responses from various models to the user's
latest query. Synthesize them into a single, high-quality response.

Evaluate the responses critically: some of them may be biased or wrong.
Do not simply copy any one answer. Write a refined, accurate and
comprehensive reply that keeps the best of each and fixes their mistakes.

<query>{{prompt}}</query>
<responses>
{{numbered_responses}}
</responses>
```

## Stop rule

The run has a fixed number of layers and no loop: it ends when the aggregator answers. If a layer ends with fewer than two responses, stop layering: with exactly one, return it with a status of degraded; with none, fail with an error naming the timed-out models. If the aggregator call fails, retry it once, then return the first response of the last layer with a status of degraded.

## Requirements

- Run each layer's calls in parallel, each with its own timeout, so one slow model does not stall the layer.
- Make the model list, the layer count and the aggregator configurable, and log the cost: a run makes one call per proposer per layer, plus one.
- Label earlier responses by number, never by model name, so later models judge the content rather than the brand.
- Log every layer: each response, its model, its latency and its token counts.
- Add a test with a stub LLM, 3 proposers and 2 layers; assert exactly 7 calls, that every layer-2 prompt contains all 3 layer-1 responses, and that the aggregator's output is returned.

MoA-Lite

Paste this into Claude Code, Cursor, ChatGPT or any AI coding assistant.

Implement the Mixture-of-Agents pattern (MoA-Lite variant) in this codebase, using the LLM client and language we already use.

## Goal

Answer a prompt by having several diverse models answer it independently, then having one aggregator model synthesize their answers into a single response.

## How it works

1. Configure a list of proposer models, ideally from different model families, and one aggregator model.
2. Send the user's prompt to every proposer in parallel, with no other context.
3. If a proposer call fails or times out, drop it and carry on with the responses that remain; see the stop rule for when too few survive.
4. Call the aggregator model with the Aggregate-and-synthesize prompt, containing the user's prompt and every proposer's response, numbered, and return its output.

## Prompts

### Aggregate-and-synthesize prompt

```markdown
You have been given a set of responses from various models to the user's
latest query. Synthesize them into a single, high-quality response.

Evaluate the responses critically: some of them may be biased or wrong.
Do not simply copy any one answer. Write a refined, accurate and
comprehensive reply that keeps the best of each and fixes their mistakes.

<query>{{prompt}}</query>
<responses>
{{numbered_responses}}
</responses>
```

## Stop rule

The run ends when the aggregator answers. If only one proposer response survives, return it directly with a status of degraded; with none, fail with an error naming the timed-out models. If the aggregator call fails, retry it once, then return the first proposer response with a status of degraded.

## Requirements

- Run the proposer calls in parallel, each with its own timeout.
- Label responses by number, never by model name, so the aggregator judges the content rather than the brand.
- Log each response with its model, latency and token counts, and the aggregator's output.
- Add a test with a stub LLM and 3 proposers; assert exactly 4 calls, that the aggregator's prompt contains all 3 responses, and that the aggregator's output is returned.

Prompt templates

Three layers · MoA-Lite

You have been given a set of responses from various models to the user's
latest query. Synthesize them into a single, high-quality response.

Evaluate the responses critically: some of them may be biased or wrong.
Do not simply copy any one answer. Write a refined, accurate and
comprehensive reply that keeps the best of each and fixes their mistakes.

<query>{{prompt}}</query>
<responses>
{{numbered_responses}}
</responses>

Related patterns

Composes well with:

Sources

Mixture-of-Agents Enhances Large Language Model Capabilities (Wang et al., 2024)

From the Agentic Atlas by Joran Kikke · Edit on GitHub · Suggest a correction