A multi-agent system is software in which several autonomous agents pursue a shared goal by acting independently and coordinating through an environment, messages, or shared state. In AI-assisted development that means multiple LLM agents — coding, review, QA — working the same project under explicit coordination rules rather than colliding in it.
The term comes from decades of distributed-AI research, but it stopped being academic the day teams started running Claude Code, Cursor, and Codex against the same repository in the same week. This guide covers the architectures that matter in practice, what they look like in AI development, and the failure points to design against.
What counts as a multi-agent system
Three properties qualify a system: the agents are autonomous (each makes decisions inside its own context), they are concurrent (work happens in parallel, not as one long chain), and they coordinate (some mechanism keeps their work coherent). Drop the third property and you do not have a multi-agent system — you have several single-agent systems sharing a blast radius.
Note what is not required: the agents do not need to talk to each other directly, run the same model, or live in the same tool. A Claude Code session on your laptop and a Cursor agent on a teammate's machine form a multi-agent system the moment they coordinate through something — and an accidental one the moment they don't.
Multi-agent architecture: four coordination shapes
Orchestrator-worker. A manager agent decomposes the goal and delegates to workers. Maximum control, but the orchestrator is a bottleneck and a single point of failure — and it must hold the whole plan in one context, which is the very limit you were trying to escape.
Pipeline. Roles form a sequence: backend implements, frontend integrates, QA verifies. Predictable and easy to reason about; rigid when work does not fit the sequence, and slow when one stage starves the rest.
Blackboard (shared state). Agents read from and write to a shared workspace — tickets, contracts, scan results — and react to what they find. No central controller, no message bus; agents in different tools coordinate by watching the same state. This is the shape that survives heterogeneous setups best.
Market-style claiming. Tasks sit in a shared pool; agents claim what they can handle. Pairs naturally with the blackboard: claiming is just a write to shared state that others respect. It load-balances without anyone scheduling.
Multi-agent system architecture in practice
Real systems blend the shapes. A practical AI-development setup looks like: a blackboard as the substrate (shared tickets, scanned API contracts, mismatch reports), market-style claiming on top (agents take open tickets for their role), and pipeline discipline inside each ticket (implement, then validate, then close — with a human verification gate at the end). Roles like backend, frontend, and QA are tracked independently, so a ticket only closes when every role has accounted for itself.
This is the architecture AppHandoff implements as a hosted service: the blackboard is an MCP server at https://api.apphandoff.com/api/mcp-bot that any spec-compliant agent connects to. An agent reads real project state with get_project_summary and get_api_spec, claims work by calling update_handoff_request to move a ticket to in-progress, and files new work with report_handoff_request — coordination as tool calls instead of architecture you build yourself. The Claude Code, Cursor, and Codex walkthrough shows the full loop.
Where multi-agent systems go wrong
The failure modes are consistent enough to have a taxonomy: ambiguous specs interpreted differently by different agents, duplicated work from missing claims, contract drift between sides of an interface, and unverified results treated as done. We cover each — and the structural fix for each — in why multi-agent LLM systems fail. The summary: every failure is a coordination failure; none is fixed by a better model.
If you are choosing between building this coordination yourself with a framework or adopting it as a service, start with the concepts in what is agent orchestration and the orchestration platform overview — then make the build-vs-buy call with your actual team size in view. Most teams discover they want the coordination layer to exist already.