Picture a repository on an ordinary Tuesday. Three coding agents are at work inside it, each competent, each pointed at a task that, taken on its own, it handles well. The first refactors a module and watches its tests go green. The second, reading the same ticket a little differently, undoes part of that refactor to satisfy a constraint the first one never saw. The third shows up to a merge conflict, resolves it cleanly, and ships something that compiles, passes review, and is not what any of the three set out to build. No agent failed at its job. The repository failed anyway.
I keep coming back to that scene because it breaks a habit the field has not yet noticed it has. We buy agents, benchmark them, and govern them one at a time, on the quiet assumption that a collection of competent parts will give us a competent whole. For most of the history of software, that assumption was close enough to true that we built a discipline on top of it. Once autonomous agents are working a shared codebase together, it stops holding, and the evidence that it stops is now sitting in public datasets rather than in anyone’s hunch.
What forty-two thousand commits reveal about a young field
Late in 2025, a group of researchers did something the excitement around multi-agent systems had mostly skipped. Rather than asking how clever the agents are, they asked how the systems that host them are actually built and kept alive, and then they went and read the record. Liu and colleagues (2025) worked through the development history of eight of the most used open-source multi-agent frameworks, among them LangChain, CrewAI, and AutoGen: more than forty-two thousand commits and over four thousand seven hundred resolved issues. What comes back is a portrait of a field moving fast and holding together by its fingernails.
The maintenance record tells the first part of it. Across these projects, the largest slice of work, just over forty percent of all commits, goes into adding and polishing features, while only a bit more than a quarter goes into repairing what already exists (Liu et al., 2025). A young technology fighting for adopters will always pour its energy into capability, and there is nothing irrational in that choice. The cost is quiet, and it is paid later. Every feature that ships ahead of its fixes leaves a small debt for whoever comes to depend on the project, and in these ecosystems the debt is piling up faster than anyone is paying it down.
Look at what people actually open issues about and the strain takes on a specific shape. Bugs come first, infrastructure next, and then, large enough to stand as its own category, the trouble of agents coordinating with one another (Liu et al., 2025). That last category repays a moment of attention. Coordination trouble is not what you see when one program misbehaves; it is what you see when several moving parts have to agree, and it has grown common enough that the people maintaining these systems now log it as a kind of failure in its own right. The same record shows the volume of issues climbing steeply from 2023 onward, which is what tends to happen when a system’s complexity outruns the practices meant to hold it steady.
Two further details finish the picture. Problems here get resolved on wildly uneven timelines, most of them inside a day, a stubborn minority dragging on for weeks (Liu et al., 2025), and that long tail is where coordination defects like to hide, since no one person owns them and no single change makes them go away. The frameworks themselves do not mature at the same pace either. Some are tended continuously while others surge forward in bursts and then fall quiet for a stretch, so a team that wires its production workflow to one of them takes on whatever rhythm it happens to have, and usually learns which rhythm that is in the middle of an incident.
Where the failures actually live
If Liu and colleagues show that the house is shaking, a second study from the same year tells us which joints are giving way. Cemri and colleagues (2025) put together the first careful catalogue of how multi-agent systems break, sitting six expert annotators down over more than two hundred tasks run across seven widely used frameworks and sorting every failure they could find. The headline figure is difficult to look away from.
Across seven current multi-agent systems, between 41 and 86.7 percent of tasks ended in failure, and most of those failures arose not inside any single agent but in the space between them, in how the work was specified, in how the agents read one another, and in whether anyone ever checked the combined result (Cemri et al., 2025).
Stay for a moment with where that failure lives. The agents themselves are competent, which is the premise of the whole exercise rather than the thing in doubt. What goes wrong goes wrong in the seams. A task is handed to a group in words, and words do not bind the way a typed interface does. When two agents read the same sentence and quietly assemble different pictures of what it is asking, neither of them has broken a rule, because no rule was ever written down precisely enough to break. Software engineering spent decades learning to guarantee correctness by checking each piece against its contract, and that whole apparatus goes dark the instant the contract becomes a paragraph of natural language that two readers can hold in two different ways.
The part that should unsettle us most is verification, because it is the part most teams are confident they have handled. “The agent passes its own tests” has the sound of safety, and it is safety, for the agent. A test built around one contribution confirms that the contribution behaves the way its author imagined. It has nothing to say about whether those expectations survived the other agents rearranging the shared state beneath them, and nothing to say about whether the assembled result is what anyone actually wanted. A defect that exists only in the whole stays invisible to a test that only ever examines a part, which is the same reason a glowing score on an isolated benchmark can tell you almost nothing about the system you are really running.
The unit of analysis was wrong
There is a reflex in software engineering, an old one and mostly a good one, to go looking for quality in the artifact. We read the commit, we lint the file, we run the test, we score the model. That reflex grew up in a world of human teams coordinating through written specifications, the world in which Conway (1968) warned that a system tends to come out shaped like the communication of the people who build it, and in which Lehman (1980) showed that software left to itself drifts toward greater complexity as it ages. Both of those observations took for granted that the ones doing the communicating were people.
Take the people out of the loop and the old reflex begins to lead you astray. The human in the loop was never only a safety check. She was the part of the system that carried a model of what the work was for and quietly absorbed the ambiguity that every formal specification leaves lying around. In my own studies of how organizations take up generative AI, the thing that separated the teams that got real value from the teams that did not was hardly ever the raw strength of the model; it was whether the tool fit the way people already worked and who those people were (Russo, 2024). The multi-agent case is that same finding with the volume turned all the way up. An agent’s individual competence still counts for something, yet on its own it buys you very little once several agents are editing the same code at the same time, faster than any reviewer can follow and with far less sense of why a given line is there.
This is what I have come to call emergence in AI-native software ecosystems: behavior that belongs to the whole and cannot be read off from, or reduced to, the agents that produce it (Russo, 2026). The two studies are looking at one animal from different sides, one of them catching it as it strains under its own growth, the other catching the instant it tears. You will not find the animal by inspecting a single agent, however closely you look, which is exactly why an industry that keeps evaluating agents one at a time keeps walking straight past the thing that is hurting it.
Put plainly, the question is not how clever each agent is but what the assembled system does to the people who have to live with it, to whether they can still understand the thing they are accountable for and keep it running (Russo et al., 2024). A system that produces correct commits no engineer can account for has not solved the engineering problem so much as moved it somewhere the current tools do not look. The reassuring part is that looking in the right place does not call for exotic instrumentation. It calls for recording a few facts about the system rather than the component, things like how much the shared code shifts while a change is still in flight, how often two changes land on top of each other, how often a combined result ships with nobody having checked it. Any repository that remembers its own history already holds this. What goes missing is rarely the data. It is an owner, someone whose actual job is the system as a whole, because a thing no one has been made responsible for is a thing no one ends up measuring.
A thirty-minute drill: find out where your reliability lives
Here is something you can run with your team this week. It is built to tell you, fairly quickly, whether you are busy governing your agents when the thing that needs governing is the system they form together.
1. Write down every autonomous or semi-autonomous agent that can open, change, or merge code in your busiest repository. Count an orchestrator that farms work out to sub-agents as well; one tool spawning several is still a multi-agent situation.
2. Next to each agent, note the one metric you currently lean on to justify keeping it around, and mark whether that metric was measured on the agent by itself or on your actual repository.
3. Add up how many of those are isolation metrics. That total is your exposure, the part of your confidence that rests on the very dimension least likely to be where the trouble is.
4. Pull your last twenty incidents or reverted changes that involved an agent, and sort each one into two piles: faults where an agent simply produced the wrong output for its own task, and faults that came from the seams, a misread specification, two changes colliding, a combined result nobody verified.
5. Look at the ratio between the piles. If the seam faults are winning, then buying and benchmarking agents one at a time cannot fix what you have, because that is not the dimension that is failing.
6. Find out who owns the seam. If the honest answer is that no one does, you have just located the real gap, and it is an organizational gap well before it is a technical one.
If steps four and five take longer than everything else put together because the data was never captured, that absence is itself your finding. You cannot govern what you never wrote down.
Next moves
For the Builder
Treat what an agent hands you as a contribution to something that is still moving, not as a finished piece of work. Before you accept a multi-agent change, take a look at what shifted in the shared branch while the work was underway. Keep a quiet log of the failures you run into and mark each one as living inside an agent or between agents, and within a few weeks you will have built your own small version of the failure catalogue for your own codebase. When you do wire several agents together, write out the specification you are handing the group in plain and explicit terms, because the ambiguity an agent cannot resolve on its own has a way of becoming your incident.
For the Manager
Stop letting an isolation benchmark stand in for evidence that a system is ready. Ask the vendors and the internal champions for failure data gathered in a shared repository under concurrent change, and when they cannot produce it, treat that silence as information. Give the seam an owner, someone who is genuinely accountable for how work gets specified to the group, for how the agents coordinate, and for whether the combined result is ever checked, since those are the places the 2025 evidence says the failures gather (Cemri et al., 2025). Guard your review capacity rather than spending the speed the agents give you on yet more throughput, because the coordination load these systems generate comes to rest on your engineers.
For the Roadmap Owner
Pay for ecosystem-level measurement as a capability in its own right rather than as a reporting line you bolt on afterward. The governance you have built, almost all of it mapped to individual systems and individual tools, was never designed for risks that surface only when many agents interact, and it will quietly leave those risks uncovered. Be suspicious of the procurement logic that reaches for the agent with the best isolated score and assumes the composition comes for free, since the 2025 record shows the composition is precisely where the bill arrives (Liu et al., 2025). And fund the unglamorous foundations the same study flags as thin, the testing infrastructure, the documentation, the steady maintenance, because that is the ground any multi-agent bet is actually standing on.
Closing thought
For two years, the comfortable story has been that enough capable agents will add up to a capable team. The 2025 evidence does not tell that story, and the gap it exposes is not the kind that closes on its own as the tools improve, because it comes from how any system of many interacting parts behaves once no single mind is holding the whole. That is the thread I am pulling on in a longer argument about emergence in AI-native software ecosystems (Russo, 2026), and it is where I plan to put my attention next. For now I would rather hand you the question than a neat answer. Go and look hard at your busiest repository, and work out whether your failures are coming from inside your agents or from the spaces between them. The honest answer to that is what decides where your governing should be aimed.
This is the last Software Insights before the summer. I will be back at the end of August to carry the emergence argument further and to ask what it means for the way we measure and govern these systems. Until then, I wish you all a relaxing break.
Daniel Russo, Ph.D., is a Professor of Software Engineering whose research examines the intersection of human cognition and artificial intelligence. Through “Software Insights,” he translates empirical research into actionable guidance for software practitioners and organizations.
If this issue surfaces a problem your organisation has been trying to name, I work with engineering leaders to diagnose exactly that kind of challenge, using the same methods behind the research you just read. No frameworks. No opinion without evidence.
danielrusso.org/advisory (Opens in a new window)
References
Cemri, M., Pan, M. Z., Yang, S., et al. (2025). Why do multi-agent LLM systems fail? Proceedings of the Conference on Neural Information Processing Systems (NeurIPS), Datasets and Benchmarks Track.
Conway, M. E. (1968). How do committees invent? Datamation, 14(4), 28–31.
Lehman, M. M. (1980). Programs, life cycles, and laws of software evolution. Proceedings of the IEEE, 68(9), 1060–1076.
Liu, D., Upadhyay, K., Chhetri, V., Siddique, A. B., & Farooq, U. (2025). A large-scale study on the development and issues of multi-agent AI systems. In 2025 IEEE International Conference on Big Data (BigData) (pp. 7785–7792). IEEE.
Russo, D. (2024). Navigating the complexity of generative AI adoption in software engineering. ACM Transactions on Software Engineering and Methodology, 33(5), 1–49.
Russo, D. (2026). More is different: Toward a theory of emergence in AI-native software ecosystems. arXiv:2604.19827.
Date
June 30, 2026