A Hierarchical Multi-Agent Architecture for Software Engineering

Abstract

I present a hierarchical multi-agent architecture for software engineering, organised as 18 specialised agents in a four-tier hierarchy (orchestrator, advisory, implementation, validation) with cross-cutting utility agents. The system replaces flat agent pools with department-style coordination: a Tier 0 orchestrator dispatches Tier 1 advisory agents for design and audit, partitions work to Tier 2 implementation agents along non-overlapping file scopes, and gates results through Tier 3 validation. I report on three core contributions. First, a cost-of-reversal model routing strategy assigns Opus to decisions that are expensive to reverse (architecture, security, code quality, live testing), Haiku to throwaway exploration (research, prompt generation, work recording), and Sonnet to balanced workloads (implementation, debugging, review). Second, a Haiku-grade prompt-writer agent inserted between the orchestrator and the implementing sub-agent reads relevant files, pulls in conventions, and structures tasks with explicit acceptance criteria, reducing sub-agent input tokens by 40 to 60 percent and average retries from 1.5 to 0.6 per task. Third, a deny-all permission baseline restricts each agent to only the tools its role requires (architects cannot write files, security agents cannot run bash, only the implementation tier carries write access). Across 48+ measured sessions on personal and professional software engineering projects, the system delivers approximately 55 percent per-module time reduction (per-module hours falling from 18.5 to 26.5 serial to 8.25 to 12.5 with the multi-agent substrate) and a session throughput increase from 1 per day to 2.9 per day. I further report a JSON state artifact convention for cross-session continuity that supersedes markdown-based state, and an adversarial 9-agent Super Engineer Review Board pattern for high-stakes verification.

Keywords: hierarchical multi-agent systems, software engineering automation, model routing, context engineering, prompt-writer pattern, permission minimisation, cross-session continuity.

1. Introduction

1.1 Motivation

Single-agent code-generation pipelines have a structural ceiling. As task complexity grows beyond what a single context window can hold, a single agent must either truncate, summarise, or oscillate between exploration and execution. Each strategy degrades quality. Truncation loses convention; summarisation loses precision; oscillation produces silent partial completions where the agent generates plausible code that diverges from the project's invariants. The failure surfaces hours or days later in code review or production incidents.

Flat multi-agent pools (where peers exchange messages without a coordinating apex) trade one failure mode for another. Without a coordinator that owns scope partitioning, peers either collide on the same files or leave gaps between scopes that no agent felt responsible for. The orchestration overhead of negotiation between equals consumes the parallelism gain it was meant to unlock.

The system reported here was developed in response to these failure modes during production software engineering work. The design hypothesis was that engineering teams already solve these problems through hierarchy: a tech lead owns scope partitioning, individual contributors own implementation, and reviewers gate quality. Mapping that structure onto an LLM-driven agent system, with tier-aware model selection and tool restrictions, should yield comparable benefits with comparable cost discipline.

1.2 Contributions

This paper reports on the design, implementation, and operational validation of a hierarchical multi-agent architecture for software engineering. I make five contributions.

1.3 Paper Organisation

Section 2 surveys related work. Section 3 describes the four-tier system architecture. Section 4 details the methodology, including model routing, the prompt-writer pattern, and permission minimisation. Section 5 covers implementation, including six matured workflow patterns and the adversarial review board. Section 6 reports measured results across 48+ sessions. Section 7 discusses limitations, gotchas, and future work. Section 8 concludes.

2. Related Work

2.1 Multi-Agent Conversation Frameworks

AutoGen (Wu et al. 2023) introduced a general-purpose multi-agent conversation framework in which agents exchange messages to solve tasks collaboratively, with human-in-the-loop options. The framework is intentionally agnostic about hierarchy; agents are configured per-task. The system reported here inherits AutoGen's premise that complex tasks decompose into agent conversations, but commits to a fixed four-tier hierarchy because production software engineering benefits from scope-partitioning discipline more than from negotiation flexibility.

CAMEL (Li et al. 2023) frames agent collaboration as role-playing between an "AI user" and an "AI assistant" with inception prompting to keep the conversation on-task. The pattern is elegant for open-ended exploration but does not translate cleanly to file-scoped engineering work where parallel non-overlapping execution is the gain.

2.2 Multi-Agent Software Development

MetaGPT (Hong et al. 2023) and ChatDev (Qian et al. 2023) are the closest prior work. Both encode software-engineering roles as agents (product manager, architect, engineer, tester) and orchestrate them through standardised operating procedures or simulated company workflows. This system shares the role-as-agent framing but differs in three ways. First, the hierarchy is shallower (four tiers) and the orchestrator is explicitly read-only with respect to file edits, dispatching Tier 2 agents rather than producing code itself. Second, models are routed by cost-of-reversal rather than by role symmetry, so different agents in the same tier may run on different models. Third, a Haiku-grade prompt-writer is inserted between the orchestrator and the implementing agent (Section 4.3), a pattern not reported in MetaGPT or ChatDev.

2.3 Reasoning and Self-Refinement

ReAct (Yao et al. 2023) interleaves reasoning traces with actions, allowing an agent to plan, observe, and revise within a single trajectory. Self-Refine (Madaan et al. 2023) iterates: an agent produces output, critiques it, and refines based on the critique. Both patterns operate within a single agent. This system applies the same insight at the multi-agent level: Tier 1 advisory agents produce designs, Tier 2 agents implement, Tier 3 validation agents critique, and the orchestrator routes corrective work back through the appropriate tier.

2.4 Generative Agents

Park et al. (2023) demonstrated that generative agents with memory, reflection, and planning can simulate believable social behaviour. Their architecture motivated the cross-session continuity work in this system (Section 4.5): without persistent state, an agent system cannot resume work after a session boundary, and complex engineering tasks routinely span multiple sessions.

2.5 Context Engineering

Anthropic's "Effective Context Engineering for AI Agents" (Anthropic 2025) argues that agent quality depends more on what is in the context window than on raw model capability. The position aligns with the economics observed in this system: a Haiku-grade prompt-writer that pre-computes a dense, file-scoped prompt yields better Sonnet output than dispatching Sonnet directly with a vague task description. The prompt-writer pattern (Section 4.3) is the concrete instantiation of context engineering applied at the inter-agent boundary.

3. System Architecture

The system is an 18-agent department-style hierarchy organised in four tiers, with cross-cutting utility agents. Each tier has a distinct purpose, a model assignment by cost-of-reversal, and tool permissions drawn from a deny-all baseline.

3.1 Tier 0: Orchestrator

A single Opus-grade orchestrator coordinates the system. It reads plan documents, dispatches advisory agents and supervisors, aggregates results, and makes escalation decisions. The orchestrator does not directly edit files. It dispatches the agents that do. This separation is load-bearing. It prevents the highest-cost model from being burned on mechanical edits, and it gives the orchestrator the bandwidth to focus on partitioning, sequencing, and verification.

3.2 Tier 1: Advisory (Read-Only Thinking Layer)

Four advisory agents operate read-only and are invoked proactively before implementation begins. The architect (Opus) produces system design and module plans. The researcher (Haiku) explores the codebase quickly and reports patterns. The security agent (Opus) audits for vulnerabilities and compliance issues. The code-quality auditor (Opus) performs deep pattern analysis. None can write files. The blast radius of a Tier 1 mistake is bounded by what the next tier accepts.

3.3 Tier 2: Implementation

Seven implementation agents (Sonnet) carry write and bash access scoped to their domains. The roster covers backend implementation, frontend implementation, chaincode implementation, infrastructure work, container deployment, database schema management, and CQRS specialist work. Parallel execution across non-overlapping file scopes is the throughput gain; the orchestrator's partitioning prevents merge conflicts.

3.4 Tier 3: Validation

Five validation agents gate quality after implementation. The tester (Sonnet) writes and runs unit and integration tests. The e2e-tester (Sonnet) runs Playwright browser flows and smoke tests. The live-tester (Opus) runs an interactive see-decide-act-verify loop with screenshot analysis, the only Tier 3 agent that needs Opus capability because live decisions are expensive to reverse. The reviewer (Sonnet) audits code quality. The debugger (Sonnet) diagnoses root causes when something fails.

3.5 Utility Agents

Three cross-cutting agents support the tiers. The supervisor (Sonnet) coordinates multi-track work for the orchestrator. The prompt-writer (Haiku) generates context-optimised prompts for sub-agent dispatch (Section 4.3). The work-recorder (Haiku) appends continuous session documentation with strict no-overwrite semantics.

Table 1 summarises the agent roster.

Table 1. Agent roster, model assignments, and tool permissions.

4. Methodology

4.1 Cost-of-Reversal Model Routing

The model assignment principle is cost-of-reversal: the more expensive a mistake is to undo at a given tier, the more capable the model assigned to that tier. Three tiers result.

The principle does not align with role seniority. A junior implementer in a human team might handle exploration tasks; here, the Haiku researcher does, because the cost structure is governed by reversal cost rather than by analogy to human hierarchies.

4.2 Permission Minimisation from a Deny-All Baseline

Every agent starts with no tools. The configuration adds only the tools the role requires. Architects and researchers cannot write files. Security agents cannot run bash. Only the implementation tier carries write access. The validation tier is mostly read-only with limited bash for test execution.

Two consequences follow. First, autonomous execution becomes safer: a researcher exploring the codebase cannot accidentally delete files, and a reviewer performing quality checks cannot introduce changes. Second, the permission boundaries clarify ownership: when something changes on disk, the responsible agent is one of a small set, narrowing diagnostic scope.

4.3 The Prompt-Writer Pattern (Critical Innovation)

The prompt-writer is the single most consequential innovation in the system. It is a Haiku-grade agent inserted between the orchestrator and the implementing sub-agent. Its job is mechanical context assembly, not architectural reasoning.

Without the prompt-writer, the naive dispatch reads "implement the X use case in service Y." The implementing sub-agent then has to find the directory structure, identify the use-case convention, find a similar use case to mimic, find the relevant repository port, locate the test directory, and guess at acceptance criteria. Failure modes are silent: the sub-agent may deviate from architectural rules, miss a transitive dependency, omit the test, or import from the wrong path.

With the prompt-writer, the dispatch becomes a focused, dense prompt with explicit file paths, mimic patterns, acceptance criteria, and rule references. The implementing sub-agent has unambiguous instructions and does not need to explore the codebase to find conventions.

The cost structure is favourable. The prompt-writer consumes approximately 2,000 input tokens (Haiku, fast) and emits a roughly 2,000-token prompt. The implementing sub-agent consumes approximately 5,000 input tokens (focused), down from approximately 12,000 input tokens without the prompt-writer. Output tokens hold steady at approximately 3,000. Average retries per task drop from 1.5 to 0.6.

Table 2 summarises the empirical token economics across 48+ measured sessions.

Table 2. Token economics with and without prompt-writer (per dispatch).

Two failure modes apply. First, insufficient context discovery: the orchestrator's plan named the wrong source files, and the prompt-writer dutifully reads them. Mitigation: the orchestrator validates file paths in the plan before dispatching the prompt-writer. Second, convention mismatch: a project rule changed but the prompt-writer was reading an older conventions file. Mitigation: rules in the rules directory are the canonical source; the prompt-writer always reads from there, never from cached or summarised versions. Both failure modes are cheap to detect (the implementing sub-agent's first verification step catches the divergence within seconds) and cheap to retry (one additional prompt-writer call, approximately 30 seconds and 2,000 tokens).

4.4 Workflow Concurrency

Concurrency limits emerged empirically. The system runs at most two to three supervisors, two to three implementation agents (to prevent conflicting file edits), four prompt-writers (fast and cheap, the bottleneck is rare), and one to two debuggers (on-demand only). Beyond these limits, API rate limits dominate and orchestration overhead consumes the parallelism gain. Five to ten concurrent agents is the practical sweet spot for most multi-track work.

4.5 Cross-Session State via JSON Artifacts

Long-running engineering work spans multiple sessions. The system preserves state in JSON artifacts under a progress directory: per-feature checklist files track completion status and pass/fail counts, and a current-module file tracks which module is in progress with timestamps. The orchestrator reads these at session start to resume work.

JSON was chosen over markdown because LLMs hallucinate during loose-format updates. Markdown's permissive structure tempts the model into "improving" the document during a state write, which silently changes the meaning of fields. JSON's strict schema rejects malformed updates and constrains the model to discrete field-level edits. Across 48+ sessions, JSON state artifacts have proven more reliable than the markdown predecessors they replaced.

4.6 Adversarial Review: Super Engineer Review Board

For high-stakes verification (architecture locks, pre-release audits, large security remediations), the system invokes a 9-agent Super Engineer Review Board pattern. Nine specialised reviewers run in parallel adversarially, each scoped to a distinct quality axis (security, performance, maintainability, test coverage, documentation, error handling, operational readiness, API contract integrity, and naming and conventions). The orchestrator aggregates findings, dispatches resolution agents in a second wave for each surfaced issue, and re-runs the board until the issue queue is empty. The pattern scales beyond code review to architecture corpora: a 9-agent design review followed by 9-agent resolution waves can gate large architectural commitments.

5. Implementation

5.1 Configuration Surface

The system uses Claude Code as the LLM driver, with all configuration resident in a project-local operating directory. The directory contains three subdirectories: an agents directory holding agent definitions (model, tools, system prompt, invocation triggers), a skills directory holding 33 reusable skills callable via slash commands, and a rules directory holding 10 enforcement rules loaded into every agent's context.

5.2 Reusable Skills (33)

Skills are composable workflows that any agent can invoke. The catalogue is organised into five domains.

The catalogue grew from 8 skills in early 2026 to 33 by mid-2026 because each shipped skill became a reusable building block. Compounding skill catalogues are a property of the architecture, not an accident.

5.3 Enforcement Rules (10)

Rules are loaded into every agent's context to ensure consistency across the agent population. The 10-rule canon covers clean architecture, CQRS and outbox patterns, container monorepo handling, git workflow, language and naming standards, database schema management, production-grade code (no any, no ts-ignore, no silent fallbacks), security standards, the testing pyramid (Testing Trophy methodology), and work record conventions.

5.4 Six Matured Workflow Patterns

Six primary workflow patterns emerged from production use. Each pattern is a directed acyclic graph of agent invocations.

Table 3. Six matured workflow patterns.

The Enterprise Orchestration pattern is the most distinctive. Each work package follows a strict five-step protocol: prompt-writer (Haiku, approximately 30 seconds) generates the dense prompt, implementation agent (Sonnet, 2 to 5 minutes) applies changes and runs verification, debugger (Sonnet, on failure only) diagnoses and feeds new context back to the prompt-writer for retry, supervisor verifies build and lint and type checks, and work-recorder (Haiku, approximately 15 seconds) logs completion. After three retry cycles per work package, the supervisor escalates to the orchestrator.

5.5 Production Hooks

Two hook types eliminate manual intervention during long-running work. PostToolUse hooks trigger auto-formatting after file writes, ensuring style consistency without operator effort. SubagentStop hooks collect test results from terminating sub-agents, feeding the supervisor's verification step. Hooks are the operational glue that lets the agent system run unattended over multi-hour sessions.

6. Results

6.1 Per-Module Time Reduction

Across 48+ measured sessions of personal and professional software engineering work, the multi-agent substrate produces approximately 55 percent per-module time reduction compared to serial single-agent development. Per-module hours fall from 18.5 to 26.5 hours serial to 8.25 to 12.5 hours with the multi-agent substrate. Table 4 reports the comparison.

Table 4. Per-module time comparison (48+ measured sessions).

Session throughput rose from 1 per day (serial) to 2.9 per day (multi-agent), a 2.9-fold improvement in shipped work units per operator-day.

6.2 Token Economics of the Prompt-Writer

The prompt-writer pattern reduces sub-agent input tokens by 40 to 60 percent and average retries from 1.5 to 0.6 per task (Table 2). Over a typical session with 20 sub-agent dispatches, the savings compound to approximately 100,000 input tokens saved plus the time previously spent on retries.

6.3 State Persistence Reliability

JSON state artifacts under the progress directory survived all 48+ sessions without corruption. Markdown state in the predecessor configuration drifted in approximately one in five session transitions, where the model would re-format or summarise the markdown during a state write and lose information. JSON's strict schema eliminates this failure class.

6.4 Concurrency Limits in Practice

The empirical sweet spot is two to three supervisors and two to three implementation agents in parallel, with up to four prompt-writers fanning out under each supervisor. Beyond these limits, API rate limits dominate and observed wall-clock time stops decreasing. The implementation-agent limit is binding because file-edit conflicts surface immediately; the prompt-writer limit is governed by latency rather than conflict because prompt-writers are read-only.

7. Discussion

7.1 Hierarchy Beats Flat Pools at This Scope

Hierarchical coordination outperforms flat agent pools for the workloads measured. The four-tier structure (orchestrator, advisory, implementation, validation) maps directly onto how engineering teams actually divide work, and the orchestrator's ownership of scope partitioning prevents the collisions and gaps that flat pools produce. The deeper claim is structural: scope partitioning is the load-bearing operation, and a single owner can do it more efficiently than a negotiating peer set.

7.2 The Prompt-Writer is the Critical Innovation

Of the contributions reported here, the Haiku-grade prompt-writer pattern produces the largest per-dispatch quality improvement and the largest token saving. The pattern converted the system from a vibe-coded multi-agent dispatcher into production-grade orchestration. It is the discipline that keeps high-cost models focused on decisions and low-cost models focused on context assembly. The pattern is reusable beyond this codebase: any orchestration with a non-trivial gap between intent and execution benefits from a context-assembly stage.

7.3 Permission Minimisation as Safety, Not Just Hygiene

The deny-all baseline is often discussed as a security or hygiene measure. In autonomous agent execution, it is also a correctness measure. Bounded blast radius prevents runaway behaviour and clarifies diagnostic scope when something does go wrong. The discipline costs configuration effort once per agent and saves diagnostic effort indefinitely.

7.4 Limitations

7.5 Future Work

8. Conclusion

I have presented a hierarchical multi-agent architecture for software engineering, organised as 18 specialised agents in a four-tier hierarchy with cross-cutting utility agents. The system contributes a cost-of-reversal model routing strategy, a Haiku-grade prompt-writer pattern for context optimisation, permission minimisation from a deny-all baseline, and a JSON state artifact convention for cross-session continuity. Across 48+ measured sessions, the system delivers approximately 55 percent per-module time reduction and a session throughput increase from 1 per day to 2.9 per day. The prompt-writer is the critical innovation; without it, sub-agent dispatch is too vague to be reliable, and with it, the orchestration becomes production-grade. I conclude that hierarchical coordination, model routing by cost-of-reversal, and disciplined context engineering at the inter-agent boundary are the load-bearing primitives for autonomous software engineering at the personal and small-team scale.

References

---

The orchestrator decides. The prompt-writer prepares. The implementer executes. The validator gates. Hierarchy is the substrate; context engineering is the discipline.