Correct parts, wrong system
Graph Engineering pattern 4 of 15: Feature Fan-Out/Fan-In. Parallelism is cheap; composition is not — why the integrator is a first-class node with real, adversarial work.
Parallel agents producing individually correct components does not produce a correct system. That sentence is the whole reason this pattern exists — and the reason it is not just a bigger star.
Context for new readers: pattern 4 of 15 in the Graph Engineering series, on designing agent organizations as graphs. Pattern 1 (the star) covers work whose parts are independent. Feature development looks like that from a distance and is not: backend, frontend, tests and docs can proceed in parallel, but their outputs must compose — the frontend must call the API the backend actually built, the tests must exercise the behavior that actually shipped, the docs must describe the product that actually exists.
The topology
Backend
/
Planner -----+ Frontend -----> Integrator
\
Tests
\
Docs
A planner turns the feature into a specification precise enough to parallelize: interface contracts, acceptance criteria, division of labor. Specialist workers execute in parallel. Their outputs converge on an integrator, whose job is adversarial: assemble the system, run it end to end, and find the seams where individually correct components disagree.
Integration is a node, not a step
Most of what goes wrong in parallel development is invisible from inside any single workstream. It lives in the seams — so the topology assigns the seams to a dedicated node with real work, rather than a final step that staples artifacts together. Small mismatches the integrator resolves; contract-level mismatches return to the planner, because a broken contract is a planning failure, not an integration failure.
The two edges that matter more than the fan
The re-planning edge. An integrator that can observe mismatches but not send work back is a spectator. The return edge to the planner must exist and must be used — it is how the organization learns that its contracts were imprecise.
Tests and docs in the fan-out. Placing them as peer workstreams with the same spec is deliberate. Bolting them on after integration reintroduces the serial tail the pattern exists to remove — and produces tests written to the implementation rather than the contract.
Where it breaks
- Vague fan-out. If the spec does not pin the interfaces, the parallel phase manufactures divergence at full speed. The planner's contract precision is the ceiling on everything downstream.
- Integrator without authority. Observation without a return edge changes nothing.
- Assembly as concatenation. The star's failure mode, inherited — an integrator that does not run the system end to end is a stapler with a better title.
The dimension answers
| Dimension | Answer |
|---|---|
| Nodes | Planner, specialist workers, integrator |
| Edges | Fan-out from planner; fan-in to integrator; re-plan return edge |
| Cycles | One: integration failure → planner |
| Humans | Optionally approve the spec and/or the integrated result |
| Exit rule | Integrated system passes end-to-end acceptance criteria |
The fan-out buys parallelism. The fan-in buys correctness. Teams that keep the first and skip the second get speed they pay back at the end, with interest.
Next: pattern 5, the Incident Command Graph — coordination under uncertainty, where the org chart matters most and the usual one fails.
Building this with design partners → rysh.ai/design-partner