Multi-Agent Coding Architecture: Hierarchical vs Graph vs Event-Driven

Multi-agent systems are not defined by the number of model calls alone. An architecture is the set of rules that controls task ownership, communication, state, tool access, retries, and completion. A simple workflow with one agent and carefully selected tools may be better than a group of agents when the task does not need parallel expertise or independent context.

The original comparison used unsupported error-reduction and cost multipliers, plus broad claims about enterprise adoption. Those numbers are removed here. The practical question is which control pattern fits the dependency structure of the work and which evidence can prove that the resulting system is reliable.

What You Will Learn

• How hierarchical, graph, and event-driven designs differ
• Where routing, orchestrator-worker, and parallel patterns fit
• How LangGraph, CrewAI, and AutoGen describe their architecture tools
• How to test reliability, cost, security, and human approval on your workload

What a Multi-Agent Architecture Controls

A multi-agent architecture controls the flow of work between specialized components. It decides which agent receives an input, what context that agent can see, where its output is stored, and which component decides the next step. It also defines how failures are reported and whether a human can pause or approve a risky action.

These choices are more important than a framework name. Two systems can both use several agents while having very different behavior. One may use a central manager and sequential delegation. Another may route messages through a graph. A third may publish events to independent actors that react asynchronously.

Document four control decisions before implementation: assign an owner and acceptance criteria to every task, define the context and tools each agent can see, specify how messages or events are stored, and name the component or person that approves completion. Retain those decisions with the task record, state snapshot, communication record, and final test result.

Start by drawing the task as a dependency map. If every step depends on one previous response, a graph or sequential workflow may be clearer. If tasks can proceed independently, parallel workers may reduce waiting. If work arrives as events over time, an event-driven design may be the natural boundary.

Hierarchical Manager-Worker Design

Hierarchical architecture places a manager or orchestrator above specialist workers. The manager receives the goal, breaks it into subtasks, assigns those subtasks, collects results, and decides what happens next. Workers can focus on code exploration, testing, documentation, data extraction, or another bounded responsibility.

This pattern is easy to explain because ownership is visible. It works well when a central planner can decompose the work and when the final result needs one synthesis point. It can become a bottleneck when every minor decision must pass through the manager or when the manager receives too much raw output.

Use explicit worker contracts. Each worker should know the input, output format, files or tools in scope, acceptance test, and escalation rule. A worker that cannot complete its task should return a structured failure rather than quietly inventing a result.

The long-running agent guide provides a related discussion of checkpoints and resumable work. Those same checkpoints make hierarchical delegation easier to inspect.

Graph and State-Machine Workflows

Graph architecture represents agents and deterministic functions as nodes connected by edges. State moves through the graph, and conditional edges can route a task based on a result. A state machine can express approval gates, retries, validation branches, and terminal failure states more clearly than a long prompt.

LangGraph's official workflow guide distinguishes predetermined workflows from dynamic agents and documents prompt chaining, routing, parallelization, and orchestrator-worker patterns. It also describes persistence, streaming, debugging, and deployment support. The graph does not make a system correct by itself. It makes the control flow visible enough to test.

A useful graph has a small state schema. Store only information that later nodes need, such as task status, source references, test output, and approval state. Avoid treating the entire conversation transcript as an unstructured database. That makes retries and audits harder.

Read the official LangGraph workflows and agents guide. For a coding-specific benchmark distinction, see the Terminal-Bench and SWE-bench comparison.

Event-Driven Actor Systems

Event-driven architecture lets agents react to messages or events instead of waiting for a central manager to call each worker synchronously. An event may represent a new task, a completed test, a changed file, a review request, or a failure. Independent actors subscribe to the events they understand and publish the next event when their work is complete.

Microsoft's AutoGen Core documentation describes an event-driven, distributed, scalable, and resilient AI agent framework based on the Actor model. It documents asynchronous messaging, request and response communication, Python and Dotnet interoperability, modular tools and memory, and observability.

Event-driven designs can separate producers and consumers, which helps when work arrives continuously or when different services must operate independently. They also introduce operational requirements such as message identity, delivery guarantees, replay behavior, dead-letter handling, and idempotency. Without those controls, a retry can create duplicate work or inconsistent state.

See the official AutoGen Core documentation for the actor and event model. The related feature-flag architecture guide shows why controlled rollout and rollback matter when event-driven agents affect production systems.

Orchestrator-Worker and Router Patterns

Orchestrator-worker and router patterns sit between a fixed graph and a fully independent event network. An orchestrator plans a set of work items, sends each item to a worker, and synthesizes the results. A router classifies an input and directs it to one or more specialists.

LangGraph documents these patterns as separate workflow choices. LangChain's multi-agent guide also notes that context engineering is central. The key design task is deciding what each worker should see and what the synthesizer must verify before accepting a result.

Use a router when the input type is the main uncertainty. Use an orchestrator when the work breakdown is generated at runtime. Use parallelization only for independent work. Use a chain when later steps depend on exact earlier output.

Context, Memory, and Shared State

Context engineering decides which information each agent receives. A specialist may need a code module and its tests but not the entire repository. A security reviewer may need the final diff, dependency manifest, and threat policy. A synthesizer needs worker results, provenance, and unresolved conflicts.

Memory can be conversation history, a state object, a file system, a database, or an event log. Each form has different retention and consistency behavior. Make the source of truth explicit. If two agents can update the same state at once, define how conflicts are resolved.

Do not confuse memory with learning. Persisting a task record lets a workflow resume or audit a decision. It does not mean the underlying model has permanently learned the project. A clean state schema is safer than relying on implied memory inside a long prompt.

The AI voice agent implementation guide provides another example of why tool boundaries, state, and approval rules should be specified separately.

Communication and Coordination

Agents can communicate through direct calls, shared state, asynchronous messages, files, queues, or event streams. Direct calls are easy to follow and work well for short chains. Files and shared state create durable artifacts. Asynchronous messages decouple timing but require identifiers, retries, and observability.

Every message should carry enough metadata to be useful later. Include the task ID, sender, recipient or topic, schema version, timestamp, source references, and status. Avoid sending unbounded transcripts between agents. Summaries should preserve the evidence needed for review, not only a conclusion.

Coordination failures often look like model failures. A worker may have produced a correct result that the lead never received, or two workers may have used different versions of a shared file. Logging the communication path makes those failures diagnosable.

Reliability and Failure Handling

Reliability requires explicit failure states. Define what happens when a tool times out, a worker returns malformed output, a test fails, a message is delivered twice, or the model reaches a permission boundary. A retry policy should include a limit and should not repeat a destructive action without an idempotency check.

Test recovery separately from the happy path. Stop the workflow after a completed node, reload the saved state, and confirm that the next node can continue without duplicating work. If recovery cannot be demonstrated, do not describe the system as resilient.

Cost and Capacity Measurement

Do not reuse the old article's unsupported claim that multi-agent systems always cost two to five times more or can reach ten to twenty times peak cost. The actual result depends on model calls, token volume, parallelism, retries, tool usage, storage, queueing, and human review.

Measure the workflow on a representative task. Record the number of model calls, input and output tokens, elapsed time, tool failures, retries, duplicate work, merge conflicts, and reviewer minutes. Then compare the result with a single-agent or deterministic baseline.

A workflow is not cheaper because several calls run at once. Parallel calls can reduce wall-clock time while increasing total tokens. Report both. If the system produces a faster but harder-to-review result, the trade-off should be visible.

Framework Mapping: LangGraph, CrewAI, and AutoGen

Framework names are useful when they describe a concrete implementation boundary. LangGraph focuses on graph-based workflows and agent patterns such as routing, parallelization, and orchestrator-worker execution. CrewAI documentation describes agents, crews, and flows, including state, persistence, sequential or hierarchical processes, guardrails, callbacks, and human-in-the-loop triggers. AutoGen Core focuses on event-driven actors, asynchronous messaging, distribution, and observability.

Pick the framework that makes the required control flow easiest to inspect and test. Do not choose only because a demo uses more agents. A small graph with visible state transitions may be safer than a large crew with unclear ownership.

Read the official CrewAI documentation for its current agents, crews, flows, process, persistence, and guardrail concepts.

Security and Human Approval

Every agent is a potential path to a tool, credential, repository, or production system. Give each worker the least access needed for its task. Separate read and write permissions where possible. Protect the main branch and require a human before deployments, data deletion, billing changes, credential use, or external publishing.

Store secrets outside prompts and generated artifacts. Restrict outbound network destinations and log tool calls. If a worker needs additional access, make the request explicit and time-limited. A workflow that stops safely is more useful than one that completes a risky action without review.

Use staged releases and rollback controls when agent output can affect users. The AI prompt engineering guide also illustrates the value of explicit constraints and verification criteria before accepting generated work.

Choosing and Testing an Architecture

Choose a pattern from the dependency structure. Hierarchical designs fit clear delegation. Graphs fit visible state transitions and conditional checks. Event-driven actors fit asynchronous messages and independently scaling consumers. Routers fit requests that must be classified before specialist work begins.

Run a controlled test before expanding the system. Use a fixed task, repository or data snapshot, model configuration, tool set, acceptance criteria, and reviewer process. Compare the architecture with a single-agent baseline. Record quality, latency, model calls, tokens, retries, failures, security events, and human correction time.

1. Map: list tasks, dependencies, tools, state, and approval boundaries.
2. Select: choose the simplest pattern that expresses those dependencies.
3. Instrument: record model calls, messages, state changes, tool results, and failures.
4. Verify: run tests, schema checks, source checks, and security controls.
5. Review: inspect the final artifact and compare it with the baseline.

For deployment-focused engineering, see the AI agent implementation guide and the staged rollout guide.

Conclusion: Architecture Is a Control Decision

Hierarchical, graph-based, and event-driven multi-agent systems solve different coordination problems. Official framework documentation supports distinct patterns, not a universal winner. Start with clear ownership and state, select the smallest architecture that fits the dependency map, instrument every handoff, and verify cost, reliability, security, and human review on real work before scaling.