boundary-designlisted

# Boundary Design **Problem shape:** something must be split, wrapped, or interfaced — a system into modules, a workflow between human and tool, a product between build and buy — and the current boundary leaks implementation detail, transaction cost, or cognitive load across it. ## Relevant geniuses | Agent | Use when | |---|---| | [coase](../../agents/genius/coase.md) | build vs buy; team/service boundary placement — compare transaction costs across the boundary, not ideology | | [hopper](../../agents/genius/hopper.md) | users forced to think in implementation vocabulary — build the translator; debugging under-invested; a tool defended out of familiarity | | [engelbart](../../agents/genius/engelbart.md) | "automate this" proposed where augmenting the person is the real win; the team doesn't use its own tool; design for expert ceiling, not just novice floor | | [kay](../../agents/genius/kay.md) | decisions hardcoded that could bind late; tight coupling via direct calls; users need to modify the system at runtime | | [alexander](../../agents/genius/alexander.md) | decompose by misfit; the design needs a generative sequence of patterns rather than a top-down blueprint | | [simon](../../agents/genius/simon.md) | the system should be nearly decomposable — strong interactions inside modules, weak between; hierarchy as the default shape | | [liskov](../../agents/genius/liskov.md) | the boundary is an interface — write the behavioral contract so implementations are substitutable