six_patterns

Six Patterns, Six Failure Modes

The six architecture patterns in Harness — Pipeline, Fan-out/Fan-in, Expert Pool, Producer-Reviewer, Supervisor, Hierarchical Delegation — look interchangeable in the README table. They are not. Each pattern encodes a specific failure mode it is good at preventing, and the wrong choice is the single most expensive error a Harness user can make.

Most readers encounter the six patterns in the README's Architecture Patterns table. It is a tidy, six-row block with one-sentence descriptions. Pipeline is "Sequential dependent tasks." Fan-out/Fan-in is "Parallel independent tasks." Expert Pool is "Context-dependent selective invocation." Producer-Reviewer is "Generation followed by quality review." Supervisor is "Central agent with dynamic task distribution." Hierarchical Delegation is "Top-down recursive delegation."

That table is a vocabulary list. It does not yet tell you which one to pick. To get that, you have to walk into skills/harness/references/agent-design-patterns.md, where the six patterns are unpacked against the failure mode each one is built to defend against.

The argument of this chapter is straightforward: the six patterns are not team shapes. They are team defenses against specific failure modes, with shapes. Treating them as shapes produces wrong choices. Treating them as defenses produces better ones.

Key Takeaways

• Pipeline is the only pattern where Harness explicitly notes that team mode is *limited in benefit* — the sequential dependency absorbs the advantage of shared task lists.
• Fan-out/Fan-in is the most team-mode-natural pattern. The spec says: *"반드시 에이전트 팀으로 구성해야 한다"* (you must compose it as an agent team).
• Producer-Reviewer is the only pattern where Harness enforces a retry cap (2–3 iterations). Without it, the loop is infinite.
• Hierarchical Delegation is capped at two levels. Three or more levels costs latency and context without buying quality.
• Composite patterns (Fan-out + Producer-Reviewer; Pipeline + Fan-out) are the rule, not the exception, in production teams.
• The execution-mode coupling (team vs sub-agent) is part of each pattern's spec, not a separate decision.

What the patterns are actually defending against

| Pattern | Failure mode defended | Team-mode verdict | |---------|----------------------|-------------------| | Pipeline | Mid-pipeline drift (B depends on A's output; if A is incomplete, B produces nothing useful) | Limited team-mode benefit | | Fan-out/Fan-in | Siloed discovery (researchers don't share findings until late) | Must be agent team | | Expert Pool | Over-eager routing (router calls the wrong specialist) | Sub-agents sufficient | | Producer-Reviewer | Acceptance of unverified output (no quality gate) | Team useful | | Supervisor | Underutilized workers / starved workers | Team useful (shared task list) | | Hierarchical Delegation | Premature decomposition (sub-tasks broken before enough is known) | Team mode limited (nested teams forbidden) |

The table is not in the source as a single block — it is synthesized from the per-pattern prose in agent-design-patterns.md. But the substance is in the source. Each pattern section opens with "적합한 경우" (when to use) and "주의" (caution), and the cautions are the failure modes. Pipeline's caution is *bottleneck propagation*: each stage can stall the whole line. Fan-out/Fan-in's caution is *integration quality*: the consolidation step determines the whole result. Expert Pool's caution is *router accuracy*: misclassification is the failure mode. Producer-Reviewer's caution is *infinite loop*: the retry cap is the defense. Supervisor's caution is *supervisor bottleneck*: the central agent becomes the system's choke point. Hierarchical Delegation's caution is *context loss at depth*: three or more levels lose too much.

The patterns, in other words, are defined against their own failure surface. A correct pattern choice is one whose defense matches the dominant failure risk of the task. An incorrect choice is one that defends against a failure you do not have, while leaving the one you do have undefended.

A worked example — code review

You have a code-review task that needs security, performance, and test-coverage perspectives. The obvious choice is to spin up three reviewers. The question is *how*.

The naïve reading says "Fan-out/Fan-in: three reviewers in parallel, then one integrator." That looks right. It is also wrong in a specific way — security issues and performance issues are correlated. An SQL injection vulnerability is also a performance vulnerability (a query that fails validation is one that runs unbounded). If security-reviewer and performance-reviewer are isolated, neither will see the cross-domain pattern.

The Harness-spec-correct answer is Fan-out/Fan-in plus a Producer-Reviewer composite. Three reviewers fan out. Each reviewer's output is itself reviewed by a peer. The integrator collects both passes. The spec calls this Fan-out + Producer-Reviewer and lists it as one of the standard composite patterns in team-examples.md §복합 패턴.

The point is not that you must use composite patterns. The point is that *the pattern choice is a diagnosis*, and the diagnosis is wrong as soon as you treat the patterns as shapes.

flowchart TD
    Q["Code Review Task"]
    Q --> SR["Security Reviewer"]
    Q --> PR["Performance Reviewer"]
    Q --> TR["Test Coverage Reviewer"]
    SR <-->|SendMessage| PR
    PR <-->|SendMessage| TR
    SR -.cross-domain findings.-> TR
    SR --> SI["Security Integrator"]
    PR --> PI["Performance Integrator"]
    TR --> TI["Test Integrator"]
    SI --> INT["Lead Integrator"]
    PI --> INT
    TI --> INT

    classDef teamMember fill:#fde68a,stroke:#b45309;
    classDef integrator fill:#bae6fd,stroke:#0369a1;
    class SR,PR,TR teamMember;
    class SI,PI,TI,INT integrator;

Each pair of reviewers talks directly (SendMessage) when one finds something that bears on the other's domain. The integrators are sub-agents per reviewer, and the lead integrator collects the three streams. This is a fan-out with cross-domain signalling, and it is closer to what the spec describes than the naïve parallel-plus-merge.

Why Fan-out/Fan-in must be an agent team

The decision tree at the top of agent-design-patterns.md is worth quoting directly:

에이전트가 2개 이상인가?
├── Yes → 에이전트 간 통신이 필요한가?
│         ├── Yes → 에이전트 팀 (기본값)
│         │         교차 검증·발견 공유·실시간 피드백으로 품질 향상.
│         │
│         └── No → 서브 에이전트도 가능
│                  결과 전달만 필요한 생성-검증, 전문가 풀 등.
│
└── No (1개) → 서브 에이전트
              단일 에이전트는 팀 구성 불필요.

For Fan-out/Fan-in, the answer to "do they need to communicate?" is almost always *yes*, because the value of fan-out is precisely that researchers discover things during their investigation that reshape the other researchers' investigations. The skill-writing guide makes this claim sharply: *"팀원들이 서로 발견을 공유하고 도전하며, 한 에이전트의 발견이 다른 에이전트의 조사 방향을 실시간으로 수정할 수 있어 단독 조사 대비 품질이 크게 향상된다."* (Team members share and challenge each other's findings; one agent's discovery can redirect another's investigation in real time, yielding quality improvements over isolated investigation.)

The spec's position is that for Fan-out/Fan-in, the team mode is not optional. The reasoning is concrete: in sub-agent mode, sub-agents return only to the main agent. They cannot signal each other. The cross-discovery loop is structurally impossible. So the pattern requires the mode that supports the loop, and that mode is the team.

You have a code-review task. Which pattern? The right answer is whichever pattern defends against the dominant failure mode of *your* code review. If your dominant failure mode is *missed issues*, Fan-out + Producer-Reviewer. If your dominant failure mode is *missed dependencies between modules*, Supervisor (with a router that watches for cross-module concerns). If your dominant failure mode is *test coverage gaps in unfamiliar subsystems*, Expert Pool (with a router that classifies subsystems and calls the right specialist).

The README's table does not teach you this. The reference file does.

The cap on Hierarchical Delegation

Hierarchical Delegation is the pattern most likely to be overused. The shape — top agent, mid agents, worker agents — looks sophisticated, and there is an instinct to reach for it whenever a project is large. The Harness spec pushes back.

*"깊이 3단계 이상은 지연과 컨텍스트 손실이 커짐. 2단계 이내 권장."* (Depths of three or more cause large delays and context loss. Two or fewer levels recommended.)

The spec adds an operational constraint: agent teams cannot be nested. A team member cannot create a sub-team. So if you want a two-level hierarchy in team mode, you implement it as *flat teams with explicit supervisor roles* — the second level is "another team member with the supervisor role," not "a nested team."

For most projects, the cap on Hierarchical Delegation is the right answer. A two-level structure covers the realistic cases (lead → domain leads → workers). A three-level structure is almost always a sign that the agent boundaries are wrong — the workers should be merged into the domain leads, or the domain leads should be split into smaller workers.

The trap is treating sophistication as a virtue. Hierarchical Delegation looks more impressive than Pipeline. In production, Pipeline plus Fan-out is usually higher-quality than Hierarchical Delegation beyond two levels, because the simpler structure has fewer context-loss surfaces.

Producer-Reviewer's retry cap

Producer-Reviewer is the only pattern where Harness *requires* a retry cap. The reason is structural. Producer-Reviewer is the classic closed loop: producer creates, reviewer evaluates, if review fails, producer retries. Without a cap, the loop can be infinite when the reviewer and producer cannot converge.

The spec's cap is 2–3 iterations. After that, the work is forced to PASS with a warning. The justification is in team-examples.md Example 3 (webtoon production): *"2회 재생성 후에도 REDO인 패널은 경고와 함께 PASS 처리"* (panels still REDO after two regenerations are forced to PASS with a warning). The same rule applies to all Producer-Reviewer use cases. The cap is the defense against infinite-loop failure, and the warning preserves the audit trail.

For users, the operational implication is: when you set up a Producer-Reviewer pair, write the retry cap into the orchestrator explicitly. Do not leave it implicit. The default may not match the producer's tendency to convince itself, and an uncapped loop can drain tokens without producing convergence.

The composite table

The source ships a small table of composite patterns and their typical use cases. It is in agent-design-patterns.md §복합 패턴:

| Composite | Example | |-----------|---------| | Fan-out + Producer-Reviewer | Multilingual translation — 4 languages in parallel, each reviewed by a native reviewer | | Pipeline + Fan-out | Sequential analysis → parallel implementation → sequential integration test | | Supervisor + Expert Pool | Customer inquiry routing — supervisor classifies, then routes to the right specialist |

Composite patterns are how real teams are usually built. Single-pattern teams are the exception. The factory's design vocabulary is six words, but the sentences are combinations.

| Composite | What it defends against | |-----------|------------------------| | Fan-out + Producer-Reviewer | Missed issues (peer review catches fan-out slips) | | Pipeline + Fan-out | Bottleneck propagation (parallel sections absorb throughput pressure) | | Supervisor + Expert Pool | Routing error (supervisor refines the classification before calling the expert) |

The lesson: pattern choice is rarely single-pattern. It is pair-wise, and the pair is chosen against the dominant and secondary failure modes of the task.

What the six-pattern vocabulary does for the factory

The seven-phase pipeline (Chapter 1) is the production line. The six patterns (this chapter) are the design vocabulary the production line exposes. The factory's claim is that *every* multi-agent task can be classified against the six failure modes, and the classification produces the correct pattern. That is a strong claim. The source backs it by:

• Forbidding patterns beyond the six (no "free-form" or "ad-hoc" pattern).
• Coupling each pattern to an execution mode (team or sub-agent) at the pattern level, not the team level.
• Shipping composite patterns as named, recognizable constructions.
• Capping the dangerous ones (Hierarchical Delegation at two levels, Producer-Reviewer at 2–3 retries).

If the patterns were interchangeable shapes, none of those constraints would be necessary. They are not, and the constraints are the evidence.

---

References:

• skills/harness/references/agent-design-patterns.md — Six patterns, mode coupling, composite patterns, retry caps
• skills/harness/references/team-examples.md — Five worked examples including SF novel writing (Pipeline + Fan-out) and webtoon (Producer-Reviewer)
• skills/harness/SKILL.md — Phase 2-2 pattern selection, Phase 2-3 agent separation criteria

---

The six patterns tell you what shape to build. The execution modes tell you how to run what you built — and that decision is the one the factory will not let you defer. Chapter 3 is about that decision, and the one structural constraint (one team per session) that makes it harder than it looks.