An LLM-Based Multi-Agent (LMA) system is a multi-agent system whose interacting agents are driven by large language models. A multi-agent system in general is a computational framework composed of multiple interacting intelligent agents that collaborate to solve complex problems or achieve goals beyond the capability of any single agent, communicating, coordinating and sharing knowledge and often bringing specialized expertise to bear on different parts of a task. LLM-Based Multi-Agent Systems for Software Engineering: Literature Review, Vision and the Road Ahead defines an LMA system as comprising two primary components: an orchestration platform and the LLM-based agents it coordinates. In that formulation each agent can be represented as a node in a graph whose edges are the interactions between agents.
Usage
The orchestration platform is the core infrastructure managing interaction and information flow. The same paper characterizes it along three axes. Coordination models define how agents interact — cooperative, competitive, hierarchical, or mixed. Communication mechanisms define how information flows, with channels organized centrally (a central agent facilitates communication), decentrally (agents communicate directly), or hierarchically (information flows through layers of authority); in software engineering contexts the exchanged data may include code snippets, commit messages, forum posts, bug reports, or vulnerability reports. Planning and learning styles determine how tasks are allocated and coordinated, with strategies including Centralized Planning, Decentralized Execution and Decentralized Planning, Decentralized Execution.
The agents themselves may be predefined or dynamically generated by LLMs, and homogeneous (identical functions) or heterogeneous (diverse functions and expertise).
The motivation that paper gives for the form is that a single LLM-based agent runs into limits because real-world problems span multiple domains; multiple specialized agents working in concert are argued to enable autonomous problem-solving, to improve robustness through cross-examination in decision-making, and to scale to complex systems by adding agents and reallocating tasks. The same paper contrasts the arrangement with the Mixture of Experts paradigm, where specialized components are dynamically activated by a gating mechanism but do not communicate with one another.
LLM-Based Multi-Agent Systems for Code Generation: A Multi-Vocal Literature Review approaches the same subject from the evidence side rather than the architectural one, reviewing 114 academic and grey-literature studies on code generation specifically. It finds that the stated reasons for adopting such systems fall into nine categories, led by performance enhancement (12 of 114 studies, 10.5%) and by handling complex tasks through decomposition into smaller coordinated sub-tasks (9 studies, 7.9%). Its authors read that distribution as positioning multi-agent architectures mainly as a technical mechanism for accuracy, efficiency and workflow coordination, with adaptability and autonomous execution appearing less often and still emerging rather than central.
The same review records what goes wrong. Correctness and reliability is its largest challenge category, reported by 26 studies (22.81%), led by hallucinations, low accuracy and orchestration failure; the solutions it reports against orchestration failure are structured and schema-based communication protocols that replace unrestricted natural-language exchange with well-defined machine-readable message formats, together with explicit assignment of responsibility for individual files, services or processes to prevent conflicts and non-terminating interactions. Its other challenge categories are security and privacy risk, computational and resource constraints, context and memory limitations, benchmark challenges, verification challenges and prompt design challenges.
On the models that drive these systems, that review counts 83 instances of LLM usage across its corpus, 57 closed-source and 26 open-source, with OpenAI’s GPT series accounting for 43 and Meta’s Llama the most common open-source choice at 17. It notes that the reliance on proprietary platforms may raise concerns about data privacy, security and dependency, while open-source alternatives offer deployment control, cost efficiency and improved data privacy.
A third source approaches the same subject as an operations handbook rather than as architecture or evidence. A chapter of Jimmy Song’s online handbook 智能体构建指南 sets out four concerns it treats as the practical content of building such a system, and its standing caution is against over-engineering: a framework supplies mechanism, but coordination overhead can cancel out the gains from specialisation, and where a task is sequential and tightly coupled, or a single well-designed agent with better prompt engineering would do, a complex framework is only unnecessary cost.
Role separation. The roles it names are Planner (decomposing the task and setting strategy),
Worker (carrying out a sub-task, possibly as a domain specialist), Reviewer (checking and improving
results) and Orchestrator (dispatching work and making the final decision), with the boundaries drawn
so that responsibility does not overlap. It notes that CrewAI carries this in
configuration as role and goal attributes per agent, and that
LangGraph’s Supervisor pattern realises the Orchestrator as an agent routing
requests to sub-agents.
Consensus and arbitration. Where agents disagree, it names three strategies: majority or ranked voting, as in AutoGen’s debate arrangement where solver agents argue over rounds and an aggregator settles the final round by majority; confidence-weighted voting across several models, which it attributes to the ReConcile framework; and trust-value routing, in which an agent’s weight is adjusted from its past performance so that more reliable agents’ opinions carry further.
Tracing. Its recommendation is a unique trace ID per agent interaction, tying logs and call context together, on top of whatever state the framework already persists — LangGraph’s graph state, CrewAI’s Flow States. It notes each framework’s own observability facility (CrewAI’s Tracing & Observability, LangGraph’s LangSmith integration) and suggests callbacks to emit each agent’s decision detail into one log.
Containment. Because multi-agent runs generate excess calls and cost, it names per-agent or per-workflow token and call quotas, budget monitoring that terminates or degrades past a threshold, retry limits and circuit breaking, and input filtering — noting that the last has to be implemented by the user in open-source frameworks.
That chapter also states a limit it says none of the six frameworks it compares resolves: efficient context transfer between agents. The available approaches are to share everything, which is slow and expensive, or to share summaries, which lose detail; selective, semantic transfer is what would decide a multi-agent system’s economics, and it argues teams should choose a framework knowing that the framework does not solve it. Its warnings about over-engineering run the same way — coordination overhead can cancel out the gains from specialisation, and structure added to compensate for a current model’s limits should be built so it can be removed when a better model arrives. These are stated there as positions, with nothing measured behind them.