What Is a Multi-Agent System?
A multi-agent system splits a task across several AI agents that each holds a specific role, rather than asking one model to do everything at once. Instead of one large prompt trying to research, write, and check its own work, each agent gets a narrow job — one researches, one writes, one verifies — and they pass work between each other in a defined sequence. That coordination layer, not the underlying model, is what turns a single LLM call into a system that can be trusted with a multi-step task.
Why a raw LLM call was never enough
The naive approach fails in three specific ways, and each of them showed up in practice.
The first is statelessness. An LLM has no memory beyond the context you hand it, so it loses direction in longer task sequences. For a chat exchange this is tolerable. For a pipeline that researches a topic, drafts platform-specific posts, and moderates them against quality criteria, it means you would have to stuff every piece of relevant context into every call, and you will never fit all of it through a chat window.
The second is hallucination. When a model has to search, analyze, and publish on its own without a verification loop, it fills the gaps with plausible fabrications. It was trained to produce an answer that looks like a satisfying output, and if it lacks the actual knowledge it will generate one anyway. For content that carries a company’s name on public platforms, that is disqualifying.
The third is what we called cascading risk. If you delegate full authority to the model, one small mistake early in the sequence propagates. A wrong fact picked up during research flows into the draft, survives the rewrite, and ends up published. The first task being wrong drags every downstream task down with it, which is exactly the failure pattern you cannot afford in an automated pipeline.
Agent equals model plus harness
The framing that shaped our design is a simple equation: an agent is a model plus a harness. The harness is the glue code wrapped around the raw LLM that gives it a controlled, interactive environment. In our session, we broke it into four parts.
Tools give the model access to the outside world, such as search APIs and databases. Guardrails protect format and content, for example JSON schema validation and toxicity checks on outputs. Feedback provides response channels and self-correcting data models, so a failed check produces information the model can act on rather than a silent retry. Memory supplies long-term storage so context survives beyond a single call.
The memory point deserves emphasis, because it addresses the statelessness problem directly. Research on long-running model sessions shows answers degrading the longer you work, partly because the context window overloads and partly because the model cannot retrieve everything from its own history. Giving it a long-term memory store reduces retrieval effort and lets it reuse knowledge it was already given, instead of hunting for it again.
Our takeaway from this framing was to prioritize orchestration architecture over model choice. The model is the engine, and the harness is everything that turns an engine into a drivable car.
What CrewAI actually gives you
CrewAI is a framework for designing, orchestrating, and managing AI agents that work as a team. Instead of one model handling everything, you set up separate working groups that coordinate with each other. Three concepts carry the whole framework.
An Agent is defined with a specific role, goal, and backstory, for example a Researcher or an Editor, which deliberately limits its working context. Rather than handing one model a huge job description in one enormous prompt, you split the work and distribute it, so each agent only cares about completing its own tasks. Tasks are written with clear instructions and specific expected outcomes, and each one is assigned directly to an appropriate agent. Tools let agents interact with the world, and everything gets grouped into a Crew that coordinates according to a defined process.
In practice, agents and tasks live in YAML configuration files holding the role, goal, and backstory, and you wire them together in a crew object in code. The default process is sequential, top to bottom, though agents whose work is independent can run in parallel. One easily missed default: if you do not explicitly assign a tool to specific agents, every agent in the crew can use it. We scoped each tool to the agents that genuinely need it, because unrestricted tool access is how an agent wanders off its task. For search we used the tool CrewAI provides, and the framework also lets you define your own MCP server when you need custom tools.
We would describe CrewAI as the easiest entry point in this space. It hands you a frame where you mostly change the text and the pieces you need, and it runs. It is open source with enterprise packages available, and for larger enterprise requirements alternatives such as LangGraph or AutoGen may fit better. For learning how multi-agent workflows behave, it was the right choice for us.
Two crews, a router, and a human in the middle
Our workflow follows a divide-and-conquer layout, orchestrated by CrewAI Flow. A research crew gathers and verifies material, a router checkpoint puts a human in the loop, and a content crew drafts and refines the posts.
The research crew has three agents. The Trend Hunter takes the user’s topic and scans news sources, X, and Reddit for the most current angle on it. The Deep Researcher digs into those trends, collecting concrete data, quotes, and supporting arguments that substantiate what the Trend Hunter found. The third agent is the one we would defend hardest: the Fact Checker, which plays a deliberately adversarial role. It verifies the Researcher’s output like an examination board doing a final review, and if it detects fabricated information it forces the flow to rerun. We score its verdict out of ten, and only a summary scoring above five goes forward for human review. In the live demo during the session, the research output came through at seven out of ten.
At the router, a human looks at the research summary in the React UI. Approving it, in our setup by clicking a button that triggers the next state, passes the material to the content crew. Rejecting it sends the research back to be redone. The point is that nobody granted the pipeline full autonomy, and the human decision sits exactly where the cascading risk would otherwise begin.
The content crew layers its guardrails in sequence. An Angle Judge evaluates the raw draft’s perspective using an ensemble, and the draft needs two out of three favorable votes to proceed. A group of specialized writers produces one version per platform, since an X post, a Facebook post, and a LinkedIn post follow different conventions. A Platform Critic then checks length, hashtag count, and formatting against strict per-platform criteria. Finally a Senior Editor acts as the last bottleneck, fixing whatever the critic flagged, merging, and optimizing tone before the result returns to the frontend. The editor resubmits to the critic until the draft passes.
Loops, memory, and knowing when to stop
The router logic generalizes beyond the human checkpoint. Between agents, the flow acts as a pass/fail switch on the previous agent’s output. A pass transitions the state, and a fail triggers a feedback loop: when the Critic or the Fact Checker returns fail, the flow forces a retry and attaches specific feedback so the agent can self-correct rather than blindly regenerate.
Loops need exits, so we applied a hard limit of three retries. Without it, an agent that cannot satisfy a criterion will happily burn tokens forever. In a business setting you might replace the fixed count with a quality score threshold supplied by the business side, but a hard ceiling has to exist either way.
For memory, we used LanceDB, which CrewAI supports as a store, as a custom long-term memory for the whole flow. Any suitable database would do, and this was simply the convenient default. Agents query it during research and generation to maintain long-term context, and data moving between crews and agents is packaged in state objects, written as dictionary-like classes, which also allow pausing the flow for human moderation. The practical payoff shows up on repeated topics: when a user rejects a draft and asks for a rewrite, the content crew pulls from memory instead of sending the research crew out again. Retrieval is semantic, so if a stored entry matches the query closely enough the flow prefers memory over a fresh search, and both the search depth and the retention window are configurable. The defaults expire entries automatically, so anything you want kept longer needs explicit configuration.
What we would tell you before you build one
The most useful discussion of the session came in the Q&A, and two points from it belong in any honest write-up.
First, multi-agent is not automatically better. A published comparison we discussed found that a single agent outperforms on simpler tasks whose steps are tightly connected and need to share context broadly, because one agent managing everything shares that context more efficiently. Splitting such work across agents creates noise. Multi-agent setups win when the subtasks are truly independent and a specialized, limited context per agent improves quality. Our problem decomposed naturally into research, writing, and review, which is why the crew structure paid off.
Second, an evaluator should not share a brain with the thing it evaluates. In our current setup all agents run on one underlying model, distinguished by persona and packaged as separate objects, and CrewAI lets you assign a different model to each agent. A colleague shared his experience that a single model with multiple personas serves a simple workflow fine, but a judge built on the same model tends to approve its own reasoning, since it already considers its own output correct. Giving the critic a different model makes the evaluation external, and that is the setup we would recommend.
This comes back to the harness framing. Design the orchestration first, and treat agent design and evaluation as one activity. The pattern reaches well past chat: the systems now shipping code and whole web applications run on the same idea, a capable model surrounded by a great deal of deliberate engineering.
How Axon Active Can Help
This kind of agent orchestration — deciding what runs autonomously, where a human checkpoint belongs, and how a system stays accountable when agents hand work to each other — is exactly the discipline behind our AI-First Software Engineering practice.
Source
- Building Sequential Multi-Agent Systems with CrewAI”, Axon Active AI Club session, June 3, 2026, presented by Le Bich Chieu (AI Workshop, Da Nang). Slides: “Multi-Agent Workflow with CrewAI” and session recording.
- CrewAI framework: https://www.crewai.com and https://github.com/crewAIInc/crewAI
- LanceDB: https://lancedb.com
- Related Axon Active articles: AI Changes the Practice. The Scrum Team Stays. · The Invisible Line Between Vibe Coding and Professional AI Engineering · Why AI Gains Are Real and Your Balance Sheet Doesn’t Show It
Frequently Asked Questions
Why is a single LLM call not enough for a pipeline like this?
Three failure modes showed up in practice. The model is stateless, so it loses direction in longer task sequences. It hallucinates, filling knowledge gaps with plausible fabrications. And mistakes cascade: a wrong fact picked up during research flows into the draft, survives the rewrite, and ends up published.
What are the core concepts in CrewAI?
An Agent is defined with a role, goal, and backstory, which deliberately limits its working context. Tasks carry clear instructions and specific expected outcomes and are assigned directly to an appropriate agent. Tools let agents interact with the world, and everything is grouped into a Crew that coordinates according to a defined process, sequential by default.
How does the pipeline keep a human in control?
A router checkpoint sits between the research crew and the content crew. A human reviews the research summary in the React UI and either approves it, which passes the material to the content crew, or rejects it, which sends the research back to be redone. That decision sits exactly where the cascading risk would otherwise begin.
When is a multi-agent setup the wrong choice?
A published comparison discussed in the session found that a single agent outperforms on simpler tasks whose steps are tightly connected and need to share context broadly. Multi-agent setups win when the subtasks are genuinely independent and a specialized, limited context per agent improves quality.
Should the evaluator run on a different model than the writers?
Yes. A judge built on the same model tends to approve its own reasoning, since it already considers its own output correct. CrewAI lets you assign a different model to each agent, and giving the critic a different model makes the evaluation genuinely external.
