Multi-agent systems: architecture and orchestration

By Ai Flowi · Published 10 October 2026

A multi-agent system divides a task among agents with different responsibilities and coordinates their work. Its architecture defines who can act, what each agent receives and how results reach the next stage. Agent orchestration is the control of those handoffs, including stopping and rejection; delegation gives another agent a bounded task.

Start by naming the handoff that one agent cannot handle clearly. A research, drafting and checking exercise is useful because each stage has a different acceptance rule. More agents introduce more boundaries to inspect; they do not establish higher accuracy simply by agreeing.

Choose a multi-agent architecture

These are architectural choices, not a list of tested product modes. The report proposal below uses Sequential Crew to examine the research-to-draft dependency; the other patterns help decide whether that dependency needs a team at all. A catalogue entry cannot establish reliable recovery or successful coordination.

What you need before configuring agents

Prepare a synthetic source packet, a research question and the expected final report outline. Configure model access with an account and API key from your chosen provider, which bills its usage separately.

The exercise below uses only catalogue components and has no external write step. A source packet can be supplied as task text, so a search service is unnecessary for this first design. Any later tool needs its own credentials, input contract and failure check. Read the agent, workflow and chatbot comparison for the platform’s terminology.

Step 1: define the handoff contracts

For research, require a finding, a source identifier, the supporting excerpt and unresolved questions. The drafting stage receives accepted findings and produces prose that keeps source identifiers attached to claims. The checking stage receives the draft and original source packet, then returns a decision with specific unsupported claims or omissions.

Use the prompt-chaining review rule for source access at the checking stage.

Give each participant a named packet: research receives the question and source bundle; drafting receives the accepted finding identifiers and report brief; checking receives the candidate report and matching source-bundle revision. The checker returns accept or reject, the affected finding identifiers and a reason for each rejection. If research omits a required source identifier, withhold that item from drafting rather than forwarding it as an incomplete fact.

Step 2: configure distinct task responsibilities

example configuration, not a recorded test

On each Sequential Task Agent, propose allow_code_execution=false, allow_delegation=false, async_execution=false and memory=false. These explicit settings keep the intended exercise narrow; their runtime enforcement still needs checking. Connect a configured Language Model’s model_output to llm, whose accepted type is LanguageModel.

Step 3: inspect the orchestration contracts

Use the CrewAI integration reference for the sequential components’ input inventory and task-object connection types.

For this report exercise, set Sequential Crew’s memory=false, share_crew=false and use_cache=false; inspect what those settings actually exclude before supplying anything beyond the synthetic packet. Choose a provider-appropriate request budget before a trial. These choices do not establish default behaviour or a working multi-task connection.

Review each handoff against its receiving responsibility: can drafting identify which findings were accepted, and can checking reach the same source revision used by research? A connection that transfers text without those distinctions cannot satisfy the proposed architecture. Inspect packet contents before continuing, and retain rejected findings with their reasons outside the draft’s accepted evidence set.

Step 4: specify stopping and delegation limits

Stop when required source evidence is absent, the checker rejects the draft or a provider fails. Return the unresolved question to a person instead of repeatedly asking another agent for a more confident answer. Define any retry budget before a run. A repeated model attempt can reuse the same wrong premise.

The function-calling tool contract explains Flow as Tool; delegation additionally needs a named recipient and a bounded return packet.

For example, delegate only the question about the cancellation clause, not the whole report. The specialist receives that question, its permitted source identifiers and the required finding format. It returns an excerpt-backed finding or an unresolved item, without assigning work to another participant. The coordinator must decide whether that return satisfies the original task before releasing the next packet.

Suppose research returns finding F1 from bundle revision A, but the drafter uses a clause supplied in revision B. The checker should reject the mixed packet and name the mismatch. Keep the candidate report out of the final delivery path; rebuild the affected handoff from one reviewed bundle. A rejection instruction in a prompt is not an enforced stop: confirm that downstream work cannot start on a rejected packet. The catalogue does not establish such a conditional execution gate for Sequential Crew, so this first exercise ends with manual inspection of each handoff.

Step 5: compare with one bounded agent

Give one Agent the identical question, source packet, read-only tools and final-report requirements. Use input_value for the task and system_prompt for the evidence rule; select a finite max_iterations before testing. The Agent reference owns the full field inventory.

For both designs, examine supported claims, missing evidence, rejected cases, provider failures and observed node usage. Keep credentials and source access equivalent. Do not compare a tool-enabled team with a single agent denied the same sources. Record actual calls and failed attempts before drawing conclusions about cost or usefulness.

What output and limits should I expect from a multi-agent system?

The intended output is a report containing source-linked findings and a separate checking decision, with unknowns visible. No report from this proposed configuration was recorded. The sequential components are documented in the catalogue; not production-tested by Ai Flowi. Typed ports establish interface compatibility, not successful execution or independent judgement.

Avoid this design when a fixed rule answers the question, when one model call and human review are adequate, or when an external action requires an approval boundary the proposed graph lacks. For bounded action decisions, see autonomous AI agents. The use-case hub provides existing starting patterns with their own evidence scopes.

Workflow usage

Plans: Go from USD8/month billed yearly (USD10 monthly), Plus from USD16 (USD20 monthly), Pro 100 from USD80 (USD100 monthly), Pro 200 from USD160 (USD200 monthly) and Pro 500 from USD400 (USD500 monthly), with 5,000 to 250,000 Flowi Tokens/month and top-ups; 1 token per node run; third-party API and model usage is not included.