Multi-Agent AI Systems

Orchestrator agents that decompose tasks, delegate to specialist worker agents, and synthesise the results. Worker agents specialised for specific subtasks, web research, database queries, document analysis, data transformation, API calls, and output generation. The orchestration layer that coordinates agent work and handles the handoffs that make the system reliable.

LangGraph supervisor/worker topology is the most common implementation pattern: the supervisor node receives the initial task, routes to specialist worker nodes based on task decomposition, and aggregates results into the final output. AutoGen multi-agent conversations provide an alternative when the workflow is better modelled as a back-and-forth between agents than a directed graph. CrewAI role-based agents work well for pipelines where each agent has a fixed professional role (researcher, analyst, writer, editor) with explicit task assignments. Orchestrator state is persisted to PostgreSQL or Redis between steps, so a multi-step workflow that spans several minutes can be inspected, paused, or resumed without re-running completed steps. Max iteration guards prevent runaway orchestration loops: a configurable step limit terminates the pipeline and routes to a human escalation path rather than burning inference budget indefinitely. Observability via LangSmith or Langfuse captures every agent call, tool use, and handoff payload so you can trace exactly which step produced an incorrect output and adjust the prompt or routing logic without re-running the full pipeline.

Multi-agent designs that run subtasks in parallel rather than sequentially, reducing total processing time for workflows where independent subtasks can proceed simultaneously. Fan-out patterns that dispatch multiple worker agents and a merge agent that synthesises results when all workers complete. Used for document analysis across large document sets, multi-source research, and batch processing pipelines.

Message passing between agents is coordinated via AMQP (RabbitMQ) or AWS SQS/SNS, depending on whether the deployment needs a managed queue service or an on-premises broker. Worker agents pull tasks from the queue, process their subtask, and publish results to a results queue that the merge agent consumes. This decoupled architecture means worker agents can scale horizontally, adding more consumers to the queue reduces end-to-end latency when batch size grows without requiring changes to the orchestration logic. Tool use parallelism is a distinct pattern: a single agent dispatching multiple tool calls simultaneously rather than waiting for each to complete before issuing the next. When a research agent needs to query three different data sources, parallel tool calls reduce total latency by the time of the slowest call rather than the sum of all calls. Conflict resolution in the merge step handles cases where parallel workers produce contradictory outputs, we design explicit reconciliation logic (majority vote, confidence-weighted merge, or escalation to a tiebreaker agent) rather than assuming parallel outputs will always be consistent. Choreography patterns, where agents react to events in a shared message bus without a central orchestrator, are used when workflow paths are highly variable and a hard-coded supervisor graph would become unmaintainable.

Producer-critic architectures where one agent generates output and a second agent validates it against defined criteria before it proceeds, catching errors that a single agent making the judgment itself would miss. Used for document extraction (extraction agent plus accuracy validator), content generation (writer plus editor), and decision workflows (decision agent plus compliance validator).

The critic agent is given explicit validation criteria in its system prompt, not generic instructions to "check for errors" but a structured checklist specific to the output type: for extracted fields, verify each required field is populated and matches the source document; for generated content, verify factual claims reference a specific source and no claim contradicts an earlier one; for decisions, verify the decision satisfies each compliance rule in the ruleset. Agent state machine persistence in PostgreSQL records the producer output, the critic's pass/fail verdict, and the specific failure reasons, so revision cycles are auditable and the history of what was rejected and why is queryable. Human-in-the-loop checkpoints activate when the critic agent fails the same output after a configurable number of revision cycles: the system surfaces both the original output and the critic's objections to a human reviewer rather than looping indefinitely. This is the correct risk posture for high-stakes outputs, legal documents, financial summaries, medical reports, where automated validation is a quality gate, not a final authority. Langfuse traces every producer-critic exchange, making it straightforward to identify which types of outputs fail critic validation most often and whether the failure is in the producer prompt, the critic criteria, or a genuine edge case in the data.

Agents with specific tool access: a research agent with web search, a data agent with database query, an execution agent with API call capabilities, a document agent with file system access. Agents that use the right tool for their specific subtask rather than one agent with access to all tools. Tool-specific agents are easier to evaluate, test, and improve because failure modes are isolated.

Multi-agent systems with defined human review checkpoints, the system runs autonomously to a defined stage, surfaces the output to a human for review, and continues after approval. Used when partial automation is the right risk posture: agents handle the research and drafting, humans review before any external action. Human review UI integrated with the agent pipeline so reviewers get the full context.

Shared memory and context management for multi-agent systems, episodic memory that agents can query for prior interactions, vector databases for semantic context retrieval, and structured state that persists across the agent pipeline. Memory architectures that give agents access to the context they need without overloading every agent's context window with irrelevant history.

Before designing any agent, we decompose the workflow into its natural subtasks, each step that requires different reasoning, different tools, or different data access. We identify where handoffs happen, what the output schema of each step needs to be, and where human review is needed. Workflow decomposition determines the agent architecture.

Each agent in the system gets its own evaluation framework, test cases for its specific subtask, metrics for its specific output type, and a pass threshold before it's included in the production pipeline. System-level evaluation for end-to-end performance. We don't deploy a multi-agent system without knowing each agent's individual reliability.

Multi-agent systems fail in specific ways: an agent produces an output in the wrong format, a tool call returns an error, context gets lost in a handoff. We design failure recovery into the architecture, retry logic, format validation at handoff boundaries, escalation to human review when the system can't recover, and complete logging for debugging. Production multi-agent systems need to handle failure gracefully.

Multi-agent systems have higher inference costs and latency than single agents. We design cost-optimised architectures: using cheaper models for simpler subtasks and frontier models only where reasoning complexity requires them. Parallel processing where possible to reduce end-to-end latency. Cost-per-workflow monitoring so you can track inference costs as usage scales.