Multi Agent Systems: Who Decides What Runs Next, and With What

Multi agent systems split one job among several AI agents, each with its own instructions and tools, and pass work between them. One design question shapes everything else: who decides what runs next? It can be you, through a fixed order drawn in advance. It can be a manager agent that delegates as it goes. Or the agents can decide their own hand-offs. Fix the order whenever you can draw the steps, and add a deciding agent only when the job cannot be planned ahead. Roles, memory, tools, approval and monitoring all follow from that answer.

Who decides what runs next in multi agent systems

An AI agent is a model that uses tools in a loop until a task is done. A system is several of them plus the plumbing between them. Microsoft's architecture guide describes that level as multiple specialized agents, with an orchestrator or a peer-based protocol managing work distribution, context sharing and result aggregation.^[1] Somebody, or something, has to do that managing. Picking a tool is mostly picking who.

Multi agent orchestration comes in three basic shapes. In a sequential setup the order is fixed: research, draft, check, send, each agent working on the previous one's output. In a concurrent setup several agents work at the same time and a collector merges what they return. In an orchestrator-workers setup a lead agent breaks the task down on the fly, delegates the pieces and synthesizes the answers.^[2] If the terms are new, what agentic AI means covers the vocabulary first.

The choice is about predictability. If you can draw the steps on paper, fix the order. A fixed pipeline is easier to test and to debug. Parallel work pays off when the pieces are independent, like fifty companies to look up. A manager agent earns its place only when nobody can predict the subtasks in advance.

Handing the decision to an agent is not free. The same Microsoft guide says every level of agent complexity adds coordination overhead, latency and cost, and advises using the lowest level that reliably meets the requirement. Anthropic, describing its own research system, puts a number on it: multi-agent runs used about 15 times the tokens of a chat.^[3] So the question before all others is does this job need more than one agent at all?

You decide: a fixed order drawn before the first run

When the order is yours, the design work moves to the hand-offs. Decide what travels with each one. The next agent can receive the full history, a summary, or one structured record with named fields. The record is usually the safest: it is short, it can be checked by a person, and it keeps one agent's wandering out of the next one's context. Memory, in a fixed chain, is mostly this record. First builds skip it.

Approval gets simpler too. Agents make mistakes, and a chain of agents passes a mistake down the line. In a fixed order you know which step sends, books, publishes or writes into a system of record, so a person goes in front of that step. Two products in our catalog start from a fixed order and ask for no diagram at all.

Genspark suits someone who would rather describe a process than draw it. Its two halves answer different needs: Workflows carry the recurring, triggered job, while GenTeam group chats seat agents next to colleagues in a conversation. Keep anything recurring in Workflows, since Super Agent cannot run scheduled jobs.

Plenty of jobs labeled multi-agent are really one agent that has to repeat itself or stop for a signature. A tool built for that narrower shape is not a full multi-agent AI platform, and for the right job that is a relief. There is less to design.

Lindy is for the person who wants recurring work done without designing anything: one assistant, several routines, a button to press. Sintra sits near the same spot and is plain about the boundary. Its help center says complex multi-step chained workflows are not yet available, and Sintra calls passing work between helpers inside one chat a feature still in development.

A lead agent decides: delegation and parallel helpers

Hand the decision to a manager agent and two things change. Roles start to matter, because a helper is only useful with one narrow job, its own tools and its own context. And monitoring stops being optional. You did not write the plan, so someone must be able to open yesterday's run and see which step went wrong. Ask it of every tool in this group. Is there a run history I can open?

Gumloop suits teams whose work arrives as events: a new ticket, an incoming email, a message in Slack. The split into helpers happens inside a task, which fits parallel specialist work such as checking many accounts at once. It is less of a fit when every hand-off has to be pinned to a diagram that a manager signs off.

Manus AI fits the list-shaped job: the same question asked about many items, such as every competitor or every vendor on a shortlist. Steps that depend on one another are the wrong shape for it. Manus itself lists invented citations among its failure modes, so check the merged table against its sources before anyone acts on it.

The agents decide: AI agent orchestration link by link

The third answer spreads the decision out. No single plan exists before the run. Each agent judges when its share is done and where the work goes next. That helps when requests vary too much for one path, and it is where tools and approval need the most care. For every link, settle three things: which actions can run without asking, where the approval request reaches you, and what survives the hand-off.

Relevance AI fits an operations person who thinks in flowcharts and wants the diagram to be the system. Its Workforce canvas is the closest thing here to drawing an org chart for agents, and the list of pending approvals becomes a daily to-do for whoever is in charge. Plan the build at a desk, because the builder runs only in a desktop browser.

Botpress belongs here when the system is a conversation with a customer. The agent talks freely, then drops into a fixed path for the step that must not vary, such as a payment or an escalation. If your process has no chat at the front, look at Relevance AI, Gumloop or Genspark instead.

All three answers in code: an open-source AI agent framework

The products so far hide the wiring behind a canvas, a chat or a prompt. An AI agent framework hands it to you. Agents, tasks, state and control flow are written in code, kept in version control and tested like any other software. That is the lane for a developer who needs custom logic between steps, or who wants the system to live inside an existing product. Here who decides is a line you write. You can change it later.

CrewAI's own guidance draws the line clearly: a Crew when the path is open-ended, a Flow when you control the steps, order and conditions, and for production a Flow with a Crew inside one step. Its docs advise starting sequential. Our guide to CrewAI Flows walks through that structure. One thing to know before you rely on budgets: Cost Limit policies only send an email. They never stop a run.

Mixing deciders: a spreadsheet, a fan-out and an approval queue

A problem this size is rarely solved by one tool. The most useful pairing needs nothing new: design the workflow in a sheet, one row per step, and run it by hand as a prompt chain in the assistant you already have. Our guide to agentic workflows shows that method. Move to a product when the hand-offs, parallel steps, retries and logs are more than you can track by hand.

Two products can also share a system. One split is a fan-out tool for gathering and an agent platform with approvals for acting: Manus AI researches a long list in parallel, then a Relevance AI or Gumloop agent picks up the finished table, routes each row and asks for approval before anything goes out. Developers can work the other way around. Prototype where changes are quick, then rebuild the stable version in code once the steps stop moving.

Name the decider first, then the job.

• You decide, a fixed chain with approvals, no code: Relevance AI or Genspark Workflows.
• You decide, recurring personal or team chores, no design work: Lindy.
• A lead agent decides, event-driven work with parallel helpers: Gumloop.
• A lead agent decides, the same task across a long list: Manus AI.
• The agent decides inside a customer conversation, with controlled steps: Botpress.
• Any of the three, with custom logic, code review, your own model keys: CrewAI.

Then check the limits against your volume. Count how often the system will run in a month, how long the longest step takes, and who answers approval requests when the usual person is out. Those three answers rule out more options than any feature comparison. Each product card above links to the page where its plans and limits are laid out.

Two agents, a fixed order and one approval come first

Pick one multi-step job you already do by hand every week. Split it into two roles, a doer and a checker, in a fixed order, with one approval before the result leaves the building. Run it ten times. Read every run. Add a third agent, a parallel branch or a manager only when the log shows the two-agent version failing in a specific, repeatable way. A small system you can read is worth more than a large one you have to trust.