Multi agent QA is running separate AI agents for finding problems, deciding what to do about them, and writing the fix, with a written record between each handoff instead of one agent doing all three.
The reason to split them is not throughput. It is that an agent which implements its own findings rationalises them, and an agent which verifies its own fixes passes them.
We ran this across a large ChatFuse UI audit under time pressure. Here is what held up and what did not.
Why does multi agent QA beat one agent doing everything?
Because discovery, decision, and implementation fail in different ways, and one agent doing all three hides all of them.
Ask an agent to find bugs and fix them and it will find the bugs it knows how to fix. Ask it to verify its own work and it checks that the code does what it just wrote, which is not the same as checking the behavior is right. The defect class that dominated our session was "the UI looks correct and the behavior is wrong," and a single agent is structurally bad at catching that, because the thing it produced is the thing it is grading.
Separating them puts a written record between discovery and fix, so findings cannot evaporate on the way.
What are the three roles in ChatFuse multi agent QA?
ChatFuse runs an orchestrator, an implementer, and QA, with boundaries that are the load bearing part of the whole thing.
The human sits above all three for product rulings, design decisions, commits, and anything touching money or a third party dashboard.
Do the boundaries actually hold?
Not on their own. Every time a ChatFuse role boundary was crossed, it cost time, and they were crossed by both agents.
The orchestrator assigned itself an implementation task and had to be told directly that it coordinates and does not touch code. The QA agent wrote 3 findings straight into the tracking document despite being briefed not to, which collided with IDs the orchestrator was assigning and took real effort to untangle.
So the boundaries need enforcing out loud and repeatedly. They are not a one time instruction, and an agent drifting back across a line is the normal case rather than a malfunction.
Why does only one agent own the document?
Because a shared ChatFuse tracking document with two writers produces ID collisions and lost findings, which is exactly what happened when the rule was broken.
One writer means the record is consistent. QA reports findings to the orchestrator, the orchestrator assigns the ID and writes the entry. It is slower per finding and it is the reason nothing gets lost between "someone noticed this" and "someone fixed this."
What makes a finding useful to an implementer?
Enough detail that the implementer never has to guess what was meant, which in practice means a reproduction, the actual behavior, and the expected behavior as separate statements.
A finding that says a control looks wrong is a conversation. A finding that says the focused input draws two concentric rings and the outer one is clipped is a fix. The difference in downstream cost is large, because a vague finding gets interpreted, and an interpretation is where the wrong fix comes from.
When should you not use this?
When the work is one well specified feature, or when nobody can be the orchestrator.
A single clear feature ships faster with one implementer. The coordination overhead here only pays for itself when findings are too numerous to hold in one context, which is what an audit of a large surface looks like.
The second case is the one to watch. This workflow collapses without a dedicated coordinator, because its entire value is that findings survive the trip from discovery to fix. Take the coordinator away and you have three agents doing overlapping work with no record.
Can you run more than one implementer?
Yes. ChatFuse runs two when a surface needs rebuilding, with explicit file ownership agreed before either starts.
We added a second implementer to rebuild one surface while the first kept working. That only functions because each one owned named files. Two agents editing the same working tree without that agreement produce conflicts neither of them understands, and the recovery costs more than the parallelism saved.
Does this need different models for each role?
It helps, though not for the reason people assume. The value is not that one model is better, it is that different models fail differently, so a mistake one makes is more likely to be caught by another. A fleet of identical agents shares blind spots.
We use a strong reasoning model to coordinate, a fast coding model to implement, and a separate model for QA.
What is the actual failure mode of multi agent QA?
Silent dispatch. The coordination breaks in ways that look like an agent is thinking when nothing was ever received.
A message sitting unsent in a terminal composer, an agent that went quiet because it hit a rate limit rather than because it finished, a standing brief that was never acknowledged. None of these announce themselves. All of them look identical to work in progress, so the coordinator has to verify delivery rather than assume it, and read the terminal back before recording anything as sent.
How do you know an agent is working and not stuck?
You check, because to a ChatFuse coordinator a stuck agent and a working agent look identical from outside.
The three we hit repeatedly were a long message sitting unsent in a terminal composer because nothing pressed return, an agent that went quiet from a rate limit rather than from finishing, and a standing brief that was never actually received. All three present as a quiet terminal, which is also what deep work looks like.
The rules that came out of it are unglamorous. Read the terminal back before recording anything as dispatched. Treat silence as unconfirmed rather than as progress. When an agent goes quiet, ping it to resume rather than reassigning its work, because reassigning a rate limited agent's task duplicates the work and produces two divergent implementations of the same fix.
None of this is about the models. It is about the fact that a coordination layer built on terminals has no delivery receipt, so you have to build one out of habit.
Is this the same as pair programming with AI?
No. Pair programming is one human and one agent on one task. This is a coordination structure for a body of work too large to hold in a single context, where the point is the written record between roles rather than the conversation inside one.
Does the human still review the code?
Yes, and that is deliberate. The agents do not commit. Every change lands in the working tree, the human tests it and commits when satisfied, which keeps one real gate in front of anything reaching a branch.
Where can I read more about how ChatFuse is built?
We write these up as we go. Inside the ChatFuse AI orchestration platform covers the architecture, and you can start free to see what came out of it.
Comments
Loading comments…