Five Qwen3.8-27B Models Team Up to Beat Fable 5: The Memdoor Multi-Agent Approach

Why can a team of small models beat a larger model?

An open-source project from GitHub called Memdoor recently sparked discussion on Hacker News: its team-solve workflow organizes 5 Qwen3.8-27B models into a "team" that beats Fable 5 on LiveCodeBench Hard. A single 27B-class model is not advantaged on hardcore programming problems, but through a combination of multi-agent collaboration and memory mechanisms, the team's performance exceeds that of a stronger single model. This result points to a direction that is being repeatedly validated: the ceiling of model capability does not necessarily have to be broken through parameter scale alone—orchestration and collaboration are equally effective levers.

According to the project repository's examples/workflows/team-solve documentation, the core of this approach is not simply copying the same problem to multiple models for parallel answers, but rather having agents with different roles take on different responsibilities such as decomposition, solving, and verification, with Memdoor's memory layer passing context among them. The Hacker News post received 243 points and 115 comments, with discussion heat concentrated on the controversial question of "whether multi-agent systems can truly and reliably surpass a strong single model."

How Memdoor's team-solve is organized

Role division, not repeated sampling

The common "multi-model voting" approach is to have multiple models independently answer the same question and then select the majority answer. team-solve differs in that it is role-based: some agents are responsible for decomposing complex programming problems into executable subtasks, some agents focus on writing code, and still others are responsible for review and testing. This division of labor resembles how human engineering teams collaborate—each member devotes full attention to their own stage rather than having every model try to solve the entire problem at once.

Multi-Model Voting is a common inference enhancement strategy, also known as Self-Consistency sampling: the same model (or multiple isomorphic models) independently solves the same problem with different random seeds or temperatures, and the final answer is selected by majority vote. Its theoretical basis is the "wisdom of crowds"—when each individual's errors are independent of one another, majority voting can reduce the overall error rate. But this method has a limited payoff: all samples share the same model's knowledge boundary, so when encountering problems the model systematically cannot solve, voting only reinforces the erroneous consensus; moreover, each sample requires a full inference run, and cost grows linearly with the number of samples. team-solve's role-based division of labor bypasses this limitation—different agents handle different parts of the problem, and their outputs are complementary rather than redundant, so the system's problem-solving breadth can be expanded without increasing the equivalent amount of inference.

The memory layer is the glue

The "mem" in the Memdoor project name points to the memory mechanism. In a multi-agent workflow, if every agent starts understanding the problem from scratch, the benefits of collaboration are offset by context loss. The role of the memory layer is to keep intermediate artifacts—problem decomposition, failed attempts, verification conclusions—flowing continuously among agents, so that later stages do not need to repeat the reasoning costs of earlier stages. This is also the most essential difference between team-solve and simply "spinning up a few more models."

Context Window refers to the upper limit of tokens a model can hold in a single inference run, and it is one of the core constraints of current large models. In a multi-agent system, each agent usually has an independent context; without additional design, the decomposition plan, failure logs, and verification results produced by one agent cannot be automatically passed downstream—the downstream agent can only see the original problem, and all prior reasoning investment is wasted. Explicit shared memory essentially builds an external state store outside the model's context window, which agents read from and write to as needed, thereby breaking the capacity limit of a single window and ensuring information consistency. This is akin to retrieval-augmented generation (RAG), except that RAG targets static knowledge bases, whereas multi-agent memory targets dynamic intermediate reasoning states and must handle additional issues such as write conflicts, version management, and relevance filtering.

Cost advantages of small models

Qwen3.8-27B is a medium-scale model, and its per-inference cost is far lower than that of frontier large models. Five such models collaborating may still cost less in total than calling one top-tier closed-source model, while achieving better results on LiveCodeBench Hard. For teams that need to process programming tasks in batches, this cost-effectiveness signal is more practically meaningful than a simple leaderboard ranking.

What this result shows

LiveCodeBench Hard is a programming benchmark known for its difficulty, with problems covering competition-level algorithms and complex implementations. On this benchmark, the marginal returns from model scale are becoming less certain, while innovation at the orchestration layer is beginning to show independent value. Memdoor's results show at least two things: first, medium-scale models under clear division of labor can unleash capabilities beyond the single-model level; second, memory and context management are key variables determining the success or failure of multi-agent systems, not optional add-ons.

According to discussion in the Hacker News comment section, skepticism mainly focuses on reproducibility and generalization ability: whether a lead on a single benchmark can be maintained across more task types, and whether the additional latency and engineering complexity of multi-agent workflows are worth it—these are questions teams need to weigh before adoption. The project is released as open source, and its code and workflow definitions can be viewed directly, which provides conditions for external reproduction.

LiveCodeBench is a benchmark specifically designed to evaluate the programming capabilities of large models. Its distinguishing feature is a "time-slicing" strategy: it uses only new problems released after the model's training cutoff date to reduce inflated scores caused by training data contamination. LiveCodeBench Hard is its most difficult subset, with problems mostly drawn from recent competitions, emphasizing complex algorithm design and edge-case handling, and placing high demands on both the depth of model reasoning and code correctness. For this reason, a lead on this benchmark is more convincing than on older benchmarks such as HumanEval. However, it should be noted that absolute scores on a single benchmark are affected by problem sampling and evaluation configuration, and generalization performance across benchmarks still requires more evidence.

Practical implications for developers

If you are building AI programming tools, Memdoor's approach offers several points you can directly borrow. First, decomposing complex tasks into role-based subtasks is more reliable than asking a single model to "think it through all at once." Second, design explicit shared memory among agents rather than relying on their independent context windows. Third, when selecting models, collaboration among multiple medium-sized models may be a more economical path than a single large model, especially in scenarios with large task volumes and sensitivity to cost.

This approach is not without costs: multi-agent workflows are harder to debug, and locating problems when errors occur requires tracing through multiple stages. The project is provided on GitHub as an example workflow, suitable as a starting point for modification rather than direct copying.

The engineering complexity of multi-agent systems is an often-underestimated adoption cost. Compared with a single model, multi-agent workflows introduce additional failure modes: coupling between role prompts, the read/write timing of the memory layer, and full-chain interruptions caused by one stage's output format not matching downstream expectations. Debugging often requires tracing the complete trajectories of multiple agents, and locating the root cause of a wrong answer may require backtracking through a dozen or more intermediate states. In addition, serial orchestration significantly increases end-to-end latency, while parallel orchestration must handle result merging and conflict resolution. Therefore, in practice it is usually recommended to first validate the benefits with two or three roles, then gradually expand, and to set clear output contracts and timeout fallback mechanisms for each stage.

FAQ

What is Memdoor? An open-source multi-agent orchestration project; team-solve is one of its example workflows, used to organize multiple models to collaboratively solve programming problems.

Why can 5 Qwen3.8-27B models beat Fable 5? According to the project's demonstration, the key lies in role division and context passing through the memory layer, which enables collaboration among medium-scale models to produce results exceeding those of a strong single model.

Can this result be reproduced? The project's code is open source, but the performance of multi-agent systems is greatly affected by prompt design and workflow configuration, so reproduction requires configuring the environment according to the repository's instructions.

One-line Summary

Memdoor uses 5 role-based 27B models collaborating to beat a stronger single model on LiveCodeBench Hard.