VI · Multi-AgentEmerging

SOP-Encoded Multi-Agent Workflow

also known as Standard Operating Procedure Multi-Agent, Assembly-Line Agents, Software-Company Agents

Encode a human Standard Operating Procedure (roles, ordered phases, standardised hand-off artefacts) into a multi-agent pipeline so that agents communicate through structured documents rather than free-form chat.

Context

A team is automating a complex, repeatable task — software development, document production, a regulatory submission — that already has a well-known human Standard Operating Procedure (SOP). The SOP names specific roles (product manager, architect, engineer, quality assurance) and specifies the deliverables that pass between them: a requirements document, then a design, then code, then a test report. The shape of the work is already understood; what is being automated is the execution.

Problem

If the agents simply chat freely, they hallucinate context the SOP would have pinned down, drift off-task between roles, and produce no auditable trail of which agent did what. Without typed hand-off deliverables, agents redo each other's work or quietly skip steps, and ambiguity that the SOP would catch at a phase boundary propagates to the end. The team ends up with a multi-agent system that looks lively in the transcript but produces worse artefacts than a single human following the same procedure would.

Forces

  • The model is good at playing a role; it is bad at inventing the workflow that connects roles.
  • Free chat between agents is cheap to write but expensive to debug.
  • Defined artefacts (PRD, design doc, test plan) compress context across role hand-offs.
  • Rigid SOPs lose the model's ability to adapt; the SOP has to leave room for the role to think.

Example

A four-agent product-development chat keeps drifting because agents talk free-form and re-do each other's work. The team rewrites it as an SOP-encoded pipeline: PM writes a typed PRD artefact, Architect transforms PRD into an Architecture artefact, Engineer transforms Architecture into Code, QA transforms Code into Test Report. Each phase boundary is a typed contract, not a chat. Drift stops, the trail is auditable, and review focuses on the artefacts rather than the conversation.

Diagram

Solution

Therefore:

Encode the SOP as: (a) a fixed set of named roles each with role-specific prompt and tool palette, (b) an ordered sequence of phases, (c) a typed artefact contract for each phase boundary (e.g. PRD → design doc → code → test plan → user manual). Agents communicate via the artefacts; a shared message pool plus a subscription filter routes only relevant context to each role.

What this pattern forbids. Agents may not communicate outside the artefact contract; a role's output that does not conform to the next role's expected schema is rejected at the phase boundary.

The smaller patterns that complete this one —

  • usesRole Assignment★★Assign each agent a named role (researcher, writer, critic, planner) with a role-specific prompt, tool palette, and acceptance criteria.
  • usesBlackboard·Give multiple agents a shared, queryable workspace they can read from and write to as they collaborate.
  • usesStructured Output★★Constrain the model's output to conform to a JSON Schema (or similar typed shape).

And the patterns that stand alongside it, or against it —

  • complementsSupervisor★★Place a coordinating agent above a set of specialised agents and route work to them.
  • complementsSpec-First AgentDrive the agent loop from a human-authored specification document rather than free-form prompts.
  • alternative-toHero AgentAnti-pattern: stuff every capability into one agent with one giant prompt.
  • complementsChat ChainDecompose a long, multi-disciplinary task into ordered phases; within each phase, run a paired-role chat between two agents until the phase artefact is signed off; pass the artefact to the next phase.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.