July 5, 2026 / 9 min read
MoA, Agent Teams, and the missing piece in coding-agent workflows
MoA looks like a model-diversity story at first. In coding-agent workflows, the stronger lesson may be role design, stopping conditions, and verification loops.
Apparently I've been using a variation of MoA for a while without knowing there was a term for it, I recently stumbled across the term and decided to make a bit of investigation to either confirm or discard my empirical knowledge regarding this methodology and hopefully give you, the reader, a practical perspective on this topic so you can improve your coding agents workflows.
What is Mixture of Agents (MoA)
As far as I could investigate, this is the paper that 1 coined the term, I'll just quote it on the part I believe it's somehow making a definition.
we construct a layered MoA architecture wherein each layer comprises multiple LLM agents. Each agent takes all the outputs from agents in the previous layer as auxiliary information in generating its response.
Now to put it in my own words, MoA uses a variety of agents through different layers in which some act as proposers and others act as aggregators. The idea is you start with a problem, get mixed perspectives from a myriad of models (proposers), another model piles everything up together (aggregator) and hand it to the next layer.
MoA claims back in 2024
The original paper showed that a set of open source models applied in MoA had better results in the AlpacaEval 2.0 than GPT-4o (the best model at the time), the difference was +7.6 points2. the cost of the two approaches was almost the same and they even had a lite version of this MoA that did 1.8+ points better than GPT-4o for less cost.
They also claimed that both the diversity of models and the number of models improved the performance of MoA.
Self-MoA in 2025
Self-MoA was a term coined by another paper3 that was published roughly 8 months after the original MoA one, it explicitly had the term "Rethinking MoA" because the findings were kind of negating some of the claims of the first paper.
To keep it simple, they saw -6.6 points of degradation when they mixed models vs parallel sampling with just a good single model.
When I read this it was shocking to me because what I saw in my experience with MoA was more aligned with the original paper but maybe I don't even understand yet what I'm doing in my harness and it's not just MoA after all.
Enough of papers, show me the empirical stuff!
Yeah yeah... sorry, Let's move on to the muddy empirical stuff. So I don't recall exactly when I started to create the "harness" to be able to do MoA in Claude Code (with Codex and Gemini as additional models), I remember I started with a simple skill for planning features, I called it multi-plan and nowadays I have a dozen or a bit more of these multi skills, they all use different model families and I can use them in multiple coding agents (Claude Code, Codex, OpenCode).
Even tho I don't remember the exact date of when I created multi-plan I'm pretty sure that Claude Code's feature Agent Teams4 wasn't created yet5, and I know that for sure because when the feature came out I did experiments in which I gave the same prompt to my workflows and to Agent Teams to see the results.
Since Agent Teams feature in Claude Code used a lot of tokens I wasn't able to test them side to side too many times, I think I did it like 3-5 times and at least in those particular tests my harness did better.
At this point I thought to myself, well, definitely model diversity is doing something special here if Claude Code's feature can't keep up to it... and I know, I know, Agent Teams is not exactly MoA6.
The effect of one bad agent.
Sadly I didn't really go deep into what Claude Code Agent Teams was doing back then, but it could be that it was trying to use too many Haiku Models, it turns out that in MoA if you use too many weak models the results will degrade pretty quickly, the statement is something like "one bad agent nullifies the gains of MoA".
Now, let's see what Agents Teams is trying to do nowadays, I'm sure they've improved it in the last 5 months, here's an example of a team it will compose to accomplish a task that touches different parts of a system I'm working on.
This looks pretty good and the balance between the different models seems like it might yield very interesting results, I haven't really tested the feature since then so I might have to give it a try again. Problem is, token usage. This was the final output I put here, in my first ask it presented Fable 5 as a possible option for documentation...
YIKES!
People using this feature not knowing that their team of agents could have Fable 5 could become a mess pretty quickly. I'm setting my alerts for HackerNews, Reddit and such and such for Jul 7, 2026 (at the time of writing)7.
Anyway, as I said, maybe Agents Teams was using too many Haiku Models back then hence why it couldn't do better than the home-made harness I put in place.
So does diversity really help?
The "Rethinking MoA" paper says that diversity wasn't really an important factor in MoA and I was like really? But then I made myself aware of something I was also doing in my harness, I had different layers depending on the problem the workflow was intended to tackle and in some cases the sampling was coming from the same strong models (exactly what the paper claimed). So a bit of it from diversity... maybe... but the strong signals were still coming from frontier models. Also, my harness wasn't MoA strictly, entering...
SMoA but this time I won't cite the paper, sorry not sorry.
SMoA8 comes into play. To simplify it.
- It does response selection, not just aggregation.
- It introduces the idea of halting the process in case an answer is good enough.
- Models enter into the workflow with roles (role-based diversity).
After checking the paper, I believe Claude Code's feature fits better into this methodology. Also, what I was doing with my "MoA" harness was definitely more aligned with what's presented in this methodology.
So there's still something missing in what I actually do in my harness and I couldn't find it in either MoA or SMoA.
Verification/validation loops
So, all of my multi harness have a specific goal hence they know when to stop or when to continue, also have halt conditions and steps in which agents will loop until fulfilling a goal, with number of iterations limited on those loops tho, I learnt that the hard way.
When Codex and Claude Code released /goal I was like... what do I use this for? then Claude Code throws the bomb of not letting use claude -p with subscription and I understood why they went for /goal as a feature at that point, they reverted that decision tho, temporarily9.
I think this is a very strong part of the harness, because in these steps is where we actually improve the results from the coding agents, sadly, this is anecdotal because I haven't kept a success/error rate of these skills, still, I can tell that most of the time they do work pretty well.
Conclusion
I would love to talk more about some of the skills I use, that would make this post too long tho, so I'll leave it for another one.
MoA was pretty good back in 2024 when the paper came out, model diversity was an advantage given the models that existed in that time. Entering 2025 it was shown that diversity wasn't necessarily why MoA worked, instead the parallel sampling of the same prompt with a strong model achieve similar gains as MoA claimed.
SMoA appeared in late 2024 and proposed different ideas to improve MoA, which we can see were later implemented in features like Claude Code's Agents Teams.
Lastly, verification/validation loops are showing very good results in the space of coding agents. There are a lot of papers in this topic that we would have to review in another occasion.