Multi-agent AI workflows, explained

An agent workflow is a goal carried out in steps by an AI model that can use tools: it plans a step, acts, checks the result and decides the next one. A multi-agent workflow splits those steps across several agents, which buys an independent check and costs hand-offs. In GATE, you talk to one agent that runs your workflows, and separate sessions run inside a job only where fresh eyes pay off, such as a contract review or a code change.

This guide shows the common shapes, what research says about when splitting helps, and how GATE runs multi-step work.

What is an agent workflow?

An agent workflow is a goal carried out in steps by an AI model that can use tools. The model plans a step and acts on it, for example by reading a file, querying a system or drafting a reply. Then it looks at the result and decides the next step, and it keeps going until the goal is met or a stop condition is hit.

That loop is what separates an agent from a chatbot. A chatbot answers and waits, and nothing happens unless you copy its answer somewhere. An agent does the work between your messages.

Most agent workflows are built from a handful of shapes:

• A chain. Fixed steps in order, each working on the output of the last: research, then draft, then format.
• A router. One step decides which path a request takes, such as a refund question or a bug report.
• Parallel steps. Independent parts run at the same time, and a final step merges the results.
• An orchestrator with workers. One step breaks the goal into sub-tasks, hands them out and judges what comes back.
• A writer and a checker. One step produces, another evaluates, and the work loops until the check passes.

What makes a workflow multi-agent?

A workflow becomes multi-agent when its steps are carried out by separate agents, each with its own instructions, its own context and often its own tools, passing results along. One agent can follow every shape above inside a single long conversation. A multi-agent workflow gives each step to an agent that sees only what that step needs.

Two arrangements cover most real systems, and many mix them:

• Coordination. Agents work side by side on different parts of a problem, and a merge step gathers their results and drops the duplicates. No single agent sees the whole picture; the merge step does.
• Delegation. A lead agent breaks a goal into sub-tasks, hands each to a worker suited to it and judges what comes back. The lead does not need to know how to do every sub-task, only who does it and what a good result looks like.

How does multi-agent collaboration work?

Agents do not chat the way colleagues do. They collaborate through hand-offs:

1. A brief. Each agent gets the goal, its inputs, what a good result looks like and the format to return it in.
2. Its own context. It works with only what the brief and its tools give it.
3. A fixed shape back. It returns something the next step can read without guessing, such as a list of findings, a diff or a filled-in form.
4. A shared record. A ticket, a document or a pull request holds the state of the work, so no agent has to remember what the others did.
5. A decision. A merge step, a lead agent or a person decides what happens next, and a person approves anything that is hard to undo.

The seams between those steps are where things break. The 2025 study Why Do Multi-Agent LLM Systems Fail? sorts the ways multi-agent systems fail into 14 failure modes in three groups, and labels more than 1,600 traces from seven popular frameworks with them:

• System design issues: agents that ignore their task or role, repeat steps, lose the conversation history or do not know when to stop.
• Misalignment between agents: drifting off the task, not asking for clarification, withholding information or ignoring what another agent said.
• Task verification: stopping too early, skipping or cutting short the checks, or checking wrongly.

Why can one agent hit a wall?

There are three good reasons to split a job, and each has research behind it.

• Context crowding. One agent holding a whole job carries every instruction, file and intermediate result in the same context. The study Lost in the Middle found that language models do best when the relevant information sits at the beginning or end of a long input, and significantly worse when it sits in the middle. An agent with a short, focused context has less to lose track of.
• Grading its own work. An agent that reviews its own output reuses the reasoning that produced the mistake. The ICLR 2024 paper Large Language Models Cannot Self-Correct Reasoning Yet found that models struggle to correct their own reasoning without outside feedback, and that their performance sometimes drops after trying. A separate checker with fresh context is that outside feedback.
• One path at a time. A single agent works in sequence. When parts of a job are independent, running them side by side saves time, and independent answers can be compared. In a 2023 study of multiagent debate, several model instances that proposed and debated answers over a few rounds improved reasoning and factual accuracy across a range of tasks.

When is one agent enough?

For a small business, most of the time. Every hand-off loses some context, every extra agent adds model calls, and every seam is a new place for the failures above. Answering a support question, posting to social media, booking a meeting or entering a receipt does not need a committee.

A practical rule: start with one agent that has real tools, a memory of the business and a person approving what goes out. Split a job only when one of these is true:

• Being wrong is expensive, so you want a check the producer cannot rubber-stamp: a contract, a code change, a large payment.
• The job holds genuinely different skills, such as writing code and testing its security.
• The parts are independent and large, so running them side by side saves real time.
• The job is too big for one context to hold well.

A worked example: a code change with a separate checker

Say the goal is “implement this feature and make sure it is safe to merge”. A multi-agent workflow can run it like this:

1. Writer. Reads the issue, the surrounding code and the project’s conventions, then makes the change on its own branch.
2. Checker. Gets the diff with fresh context and one job: find what is wrong. It never saw the writer’s reasoning, so it does not inherit the writer’s blind spots.
3. Security reviewer, where it matters. Reads the same change looking for abuse: inputs that can be misused, data that can leak, trust placed in the wrong side.
4. A decision. Real findings go back to the writer for a fix, and the loop repeats until the checks pass. Then a person, or a rule they set, decides whether it merges.

Most of the value comes from one fact: the agent that checks the work did not write it.

How does GATE run multi-step work?

GATE recommends one named agent for the whole business, sometimes two, rather than an agent per job. You brief it in plain language, each subject gets its own chat, and it works from one memory of your company, so nothing it knows about your customers is lost in a hand-off between agents. Inside a job, GATE runs separate sessions where fresh eyes or a clean workspace pay off:

• Contract review. A review in GATE’s legal documents tool runs five reviewer sessions side by side, each with its own angle: Defender, Adversary, Inspector for Swedish company law and basic tax, Judge and Gap-Finder. Each reads the document itself. When they are done, one more session turns their findings into suggested edits for each clause, and a person accepts, rejects or defers every finding; nothing in the document changes until they save. A review takes 4 to 6 minutes, and if one reviewer fails, the review names it and keeps the other findings.
• Code changes. Your agent turns a request into a GitHub issue and hands it to a code session. The session works in its own copy of the repository on its own branch, opens a pull request and runs a self-review pass on it before your agent merges. Your repository’s branch rules still apply, and you can watch or stop the session from the chat. AI coding agents shows the whole flow.

In GATE’s sales tool, every action has its own setting: off, suggest, approve or automatic. By default each email and meeting invite waits in the Inbox until a person approves it, and only a person’s press counts as approval, so the agent cannot approve its own work. In the ads tools, new campaigns start paused and budgets wait for a person to confirm the amount. Each step the agent takes shows in its chat, tool by tool, and a code session keeps a full transcript.

How do you govern a multi-step AI workflow?

The same rules hold whether one agent runs the workflow or five:

• Give every loop a limit. A cap on attempts, follow-ups or time, so a stuck step stops instead of spinning. GATE’s sales follow-ups stop at 20 touches per contact.
• Put a person in front of what is hard to undo. A first email to a new contact, a payment, anything published.
• Start risky things switched off. An ad campaign that starts paused spends nothing until someone turns it on.
• Keep the checker apart from the writer. Fresh context is the point of the check.
• Keep a record of every step. When something goes wrong, you need to see which step did what.
• Give each agent only the access its step needs. A checker that can only read cannot break anything.

The takeaway

An agent workflow is a model working through a goal step by step with tools. Splitting those steps across agents buys focus, a real second opinion and parallel speed, and it costs hand-offs, model calls and new ways to fail. For most small-business work, one agent with a memory of the company, real tools and a person approving what goes out is the better trade, with a separate checker added where being wrong is expensive. That is how GATE is built, and it is invite only while we onboard a small number of businesses.