# A Simple Multi-Agent Workflow Example With Protocols and Architecture

*Use Case — 2026-04-04 — by Mahmoud Zalt*

A clear multi-agent workflow example: roles, message protocol, orchestration loop, and how to skip the plumbing entirely with hired AI Employees.

**Short answer.** A simple multi-agent workflow is one orchestrator routing a task across three specialist agents (researcher, writer, reviewer) using a shared message bus and a tiny JSON protocol. That is the textbook shape behind CrewAI, LangGraph, and AutoGen. The same outcome on Sistava is a hired team plus a sprint plus a delegation tool: no Python project, no message bus, no orchestrator code to write. Both paths work. The one you pick depends on whether you want to ship value or ship an agent framework.

## What does a simple multi-agent workflow look like in practice?

The simplest useful multi-agent workflow has three roles and one coordinator. A researcher pulls source material from the web or a knowledge base. A writer turns those notes into a draft. A reviewer checks the draft against a checklist (factual, on-brand, formatted). The coordinator routes the task between them, decides when one finishes, and stops the loop when the reviewer says ship. Each agent has a narrow role, a system prompt, and a small toolbelt (search, write, score). Messages between them are tiny JSON envelopes: who sent it, what role is next, what the payload is, and a status field. That is the entire shape. CrewAI, LangGraph, AutoGen, n8n agent nodes, and most homegrown setups are variations on this pattern. The interesting design choices are not the agents themselves: they are the protocol, the memory, and the stop condition.

## At a Glance

- **3** Specialist agents in the minimal pattern
- **1** Orchestrator routing the task
- **4 fields** Per message: from, to, payload, status
- **2 conditions** Stop: reviewer approves, or max loops hit

## What communication protocol do multi-agent systems actually use?

Most working multi-agent systems use a tiny in-process message envelope, not a fancy standard. The envelope carries four things: a sender id, a target role, a payload (the actual task or draft), and a status (pending, in-progress, done, blocked). On top of that, you usually add a thread id so messages on the same task stay grouped, and a correlation id for tracing. Anthropic has published a Model Context Protocol for tool calls, and there is informal interest in agent-to-agent standards, but in production today the protocol is almost always app-local JSON over function calls or a queue. The shape that matters is: who is allowed to speak next, when does the orchestrator hand control over, and how does an agent signal it is finished or stuck. Get those three right and the rest is plumbing.

## Benefits

### Envelope shape

from, to_role, payload, status, thread_id, correlation_id. Keep it boring and serializable.

### Turn taking

Orchestrator picks the next role based on status, not the agent picking itself. Prevents loops.

### Stop condition

Reviewer marks done, or a max-step budget trips. Never trust agents to self-terminate.

### Shared memory

One scratchpad per thread plus a small long-term store. Agents read, only the writer mutates the draft.

### Tool boundary

Each agent has its own toolbelt. Researcher cannot publish, writer cannot search. Keeps blast radius small.

## How do you actually orchestrate the agents step by step?

The orchestration loop is short. The orchestrator owns a state machine that reads the current message, decides which role runs next, calls that role with the right slice of context, then writes the result back into shared state. Each role is a function: it gets the thread state, runs its LLM call with its tools, returns an updated envelope. The orchestrator never reasons about the content: it only reasons about routing. That separation is what keeps small multi-agent systems debuggable. If you bake routing into each agent prompt, you end up with three agents arguing about whose turn it is. Below is the five-step loop that covers maybe 80 percent of real-world workflows including content drafting, lead research, support triage, ops checklists, and code review.

1. **Receive task** — Orchestrator gets a user request, opens a new thread, writes the initial envelope with status=pending and to_role=researcher.
2. **Researcher runs** — Researcher reads the task, calls its search tool, writes findings to the shared scratchpad, sets status=done.
3. **Writer runs** — Orchestrator routes to writer. Writer reads scratchpad, drafts the output, attaches it to the envelope, sets status=ready-for-review.
4. **Reviewer runs** — Reviewer scores the draft against a checklist. Approves and sets status=done, or rejects with feedback and sets to_role=writer.
5. **Stop or loop** — If status=done, orchestrator returns the draft. If max steps hit without approval, escalate to a human and stop.

That loop is roughly fifty lines of Python if you write it bare, a few CrewAI annotations with a framework, or a single LangGraph state graph if you want a typed compile step. n8n and Lindy give you a visual version with drag and drop nodes. The choice is about how much code you want to maintain, not what is possible. The same shape powers production systems and weekend hacks. What changes between them is reliability: retries, memory, observability, and human handoff. That is the part tutorials skip and the part that quietly eats your time once a prototype turns into a workforce.

Before the framework comparison, a word on what changes past a demo. A three-agent loop on your laptop is one weekend. The same loop with logging, retries, memory, integrations, scheduled runs, and an audit trail is a real engineering project. Most solo founders bounce off that wall and either ship something fragile or quietly abandon the build. The next two sections are what I wish I had read before writing my first orchestrator: when to build, and when to hire.

## Which framework should you use to build a multi-agent workflow?

If you are committed to writing code, the four serious choices in 2026 are CrewAI, LangGraph, AutoGen, and a homegrown loop on top of the OpenAI or Anthropic SDK. CrewAI is the friendliest if you want named roles and a sprint-style brief: it leans into the AI Employees metaphor and gives you decorators that look like job descriptions. LangGraph is the most rigorous if you want typed state, branching, and a visual graph: it pays off when the workflow has more than a linear path. AutoGen from Microsoft is the strongest if you want agents to talk to each other in free-form conversation rather than strict routing: useful for code review or paired research. Bare SDK loops win when the workflow is short and you want zero magic. For visual builders, Lindy and n8n cover the same ground without code, with the tradeoff that you trade some control for speed.

## Benefits

### CrewAI

Named roles, sprint-style briefs, friendly decorators. Closest to the AI Employees metaphor in code.

### LangGraph

Typed state, branching graphs, visual compile. Best when the workflow has more than one path.

### AutoGen

Agents converse freely. Good for code review, paired research, and exploratory loops.

### Lindy / n8n

Visual no-code builders for the same orchestration shape. Faster to ship, harder to customize.

## When should you skip the framework and just hire an AI Employee?

Skip the framework when the outcome is the point, not the orchestration. If the real goal is content shipped, leads researched, support replied, or a launch sprint executed, you do not need to build a multi-agent workflow at all. You need a team doing the work. Sistava ships pre-built AI Employees (marketing, sales, support, ops) that already have the researcher, writer, reviewer shape wired inside a single hire, plus memory, integrations, scheduled runs, and a delegation tool. You pick a role, give it a sprint, and the orchestrator part is the product, not your problem. Frameworks are right when you are selling agents themselves, learning the field, or have a workflow so weird no off-the-shelf hire fits. For ninety percent of solo founders and small teams, hiring beats building.

## Frequently asked questions

## FAQ

### What is the simplest multi-agent workflow example?

Three roles plus one orchestrator: a researcher pulls sources, a writer drafts, a reviewer approves or bounces it back. Messages move through a small JSON envelope with sender, target role, payload, and status fields. That pattern covers most real-world use cases from content to support.

### What is the difference between orchestration and choreography in agents?

Orchestration means a central coordinator decides who runs next, which is the safer default for production. Choreography means each agent decides on its own based on broadcast events, which is more flexible but harder to debug. Almost every reliable multi-agent system in 2026 is orchestrated, not choreographed.

### Do I need a special protocol like MCP or A2A for agent communication?

Not for a small workflow. Most production systems use a tiny in-process JSON envelope on top of function calls or a queue. Anthropic's Model Context Protocol matters for tool calls and shared context, but agent-to-agent traffic stays app-local for now in most working setups.

### Is CrewAI better than LangGraph for a beginner?

CrewAI is friendlier for a beginner because the syntax mirrors a job description and roles feel natural. LangGraph is stronger when the workflow has branches, retries, or typed state. Pick CrewAI to ship a linear demo fast and LangGraph when the graph itself is the hard part.

### Can I run a multi-agent workflow without writing code?

Yes, on two paths. No-code builders like Lindy and n8n give you the same orchestration shape with visual nodes. Hired AI Employee platforms like Sistava skip the workflow layer entirely: you hire a role with the multi-agent loop already inside it, and delegate work like you would to a person.

If the team angle is the real interest (how multiple AI Employees coordinate on a goal without you writing an orchestrator), the next read goes deeper. It walks through how a hired team divides work, who reviews whom, where memory lives, and what the founder has to approve. Use it as the companion once you have decided whether to build the loop yourself or skip straight to staffing.

The honest framing: a simple multi-agent workflow is not really about agents. It is about a tiny orchestration loop, a four-field message envelope, and a clear stop condition. Pick CrewAI, LangGraph, AutoGen, or a bare SDK loop and you can ship that loop in a weekend. The harder part shows up later, when memory, retries, integrations, scheduling, and audit trails turn the weekend project into a maintenance burden. If you want the outcome and not the engineering, hire instead of building: a Sistava AI Employee has the multi-agent shape inside the hire, so you delegate work the way you would to a person. Build when the loop itself is the product. Hire when the work is.

**Tags:** multi-agent-workflow, agent-orchestration, communication-protocols, agent-architecture, ai-employees, crewai-alternative, langgraph-alternative