What is a Multi-agent system?
A multi-agent system is a setup where several language model agents take different roles and hand work to each other instead of one model answering alone. Open-source implementations range from a fixed pipeline that turns one prompt into a repository to runtime orchestrators and workspace managers built for fleets of coding agents.
How the coordination actually works
The mechanism is division of labour plus a handoff. In a single-agent setup one model call carries context, planning, execution and checking, so the same prompt has to do all four. A multi-agent system splits that into roles, and each role gets its own prompt and its own window of context.
MetaGPT is the clearest documented example of the fixed version. Our analysis says it assigns product manager, architect, project manager and engineer roles to LLMs and runs them through a fixed SOP, so one line of text becomes a repository. The order of the roles is the coordination itself: there is no negotiation, because the pipeline has already decided who speaks next. MetaGPT is MIT licensed and installs from PyPI.
The open version replaces the fixed order with a runtime. ChatDev 2.0 dropped the virtual software company of ChatDev 1.x for a YAML-driven orchestration runtime, which means the sequence of agents and workflows is configuration you can edit rather than code you have to fork. openai/swarm shows the smallest version of the idea: agents and handoffs coordinating a conversation with no server-side state, which our analysis describes as educational.
The fourth shape is orchestration around a coding tool instead of around a model. Our analysis of Yeachan-Heo/oh-my-claudecode says it wraps Claude Code in a team of orchestrated agents, reached through a terminal CLI and an in-session skill surface, with the plugin as the shortest install and the named autopilot profiles currently Linux-only.
What the agents share
What the agents share decides how much machinery you need.
openai/swarm keeps nothing. Our analysis says it shows how agents and handoffs can coordinate a conversation without server-side state, and that its README now points production users to the OpenAI Agents SDK instead. That is the cheapest arrangement available and the least forgiving one: the conversation is the only record, so a restart loses everything the run had worked out.
MetaGPT inverts the model. The output of the run is a repository, so the artefacts persist as files a person can read and a tool can diff. The cost moves from runtime state onto disk.
Gas Town applies the same idea to long-running coding work. Our analysis says it is a Go CLI that keeps multi-agent coding work in git-backed hooks and a Beads ledger so context survives agent restarts, and that the README aims it at fleets of 20 to 30 agents. That target is the warning label: the design assumes more agents than one person writes, and our analysis calls the install heavy.
OpenMAIC makes the shared thing a configuration. Our analysis says it turns a topic, a document or a slide deck into a multi-agent classroom with slides, quizzes and simulations, and that every capability depends on which providers you wire into .env.local, so the interesting state is the keys rather than the agents.
When you need several agents, and when one is enough
Multi-agent adds coordination cost to every task, so the threshold is whether the work genuinely divides.
Our analysis of NirDiamant/GenAI_Agents follows the order in which these techniques are usually learned: it starts with a while-loop agent written from scratch and only later reaches multi-agent systems on LangGraph. That ordering is the practical advice. If a single loop with a clear stopping condition gets you the answer, the roles are ceremony.
One agent is the right answer when the task produces a single artefact, when the steps must see each other's intermediate output in full, or when a wrong step is expensive and you want one mind on the work. Several agents earn their cost when the work fans out and then has to be synthesised, when each sub-task benefits from a different narrow prompt, or when a reviewer role has to judge the output of a writer role.
The cost of getting it wrong is not spread evenly. Extra agents multiply latency and tokens, and they multiply the places a run can go sideways: a role that receives a truncated brief, a handoff that drops a constraint, a reviewer that agrees with everything. Our analysis of openai-agents-python lists guardrails and tracing among what the package provides, which is the tooling answer to exactly that problem.
Limits worth knowing before you build one
Several limits are documented, and they are cheaper to read than to discover.
Maturity. Our analysis of MetaGPT records the last push to main as 2025-03-09, so a team that needs a maintained dependency should ask what its current state is rather than assume it. openai/swarm describes itself as educational and points production users at a different SDK, so treat it as a diagram of the pattern instead of a place to run a workload.
Platform coupling. openai-agents-python documents a Windows path that uses DockerSandboxClient with the openai-agents[docker] extra or a hosted sandbox client, so the sandbox story differs by operating system rather than being uniform.
Teaching material mistaken for a runtime. Two of the best-known references are documentation. Our analysis says muratcankoylan/Agent-Skills-for-Context-Engineering packages context engineering, multi-agent patterns, evaluation and harness design as installable Claude Code skills, that it is documentation and pseudocode rather than a runtime library, and that its README states the examples avoid dependency installations. GenAI_Agents is a set of Jupyter notebooks by the same standard: material to read, not a library you install and call.
Benchmark claims. Our analysis of camel-ai/owl records a 69.09 percent average on the GAIA benchmark, first among open-source frameworks, and acceptance at NeurIPS 2025. A recorded score tells you what was measured, not what your workload will produce.
Where the term shows up in open-source work
A short map of what these projects actually are, so a runtime and a teaching set are easy to tell apart.
Orchestration runtimes: ChatDev 2.0 with its YAML-driven runtime, and openai-agents-python, which our analysis describes as giving Python developers agents, handoffs, guardrails and tracing in one install.
Frameworks with fixed roles: FoundationAgents/MetaGPT, MIT licensed and on PyPI, running product manager, architect, project manager and engineer roles through a fixed SOP.
Orchestration around coding tools: Yeachan-Heo/oh-my-claudecode for teams working inside Claude Code, and gastownhall/gastown for long-lived fleets of coding agents with git-backed hooks and a Beads ledger.
Learning and reference: openai/swarm for the smallest handoff example, NirDiamant/GenAI_Agents for notebooks that build up to multi-agent systems on LangGraph, and muratcankoylan/Agent-Skills-for-Context-Engineering for context engineering patterns packaged as skills.
Task-specific multi-agent products: camel-ai/owl, which our analysis describes as a Python framework coordinating specialised agents for real-world task automation, and THU-MAIC/OpenMAIC, a self-hosted Next.js app that builds a classroom from a topic, a document or a slide deck.
In practice
A multi-agent system is worth building when the work divides into roles that each need a narrow prompt, and not one step earlier: our analysis of GenAI_Agents puts a single while-loop agent first for a reason. Start from openai-agents-python or a YAML-driven runtime such as ChatDev 2.0 if you want handoffs and tracing in Python, read openai/swarm if you would rather see the pattern in fifty lines, and check the last-push dates and platform requirements of anything you plan to depend on before you build on it.