Law 39 · Architecture & Operations
Your Architecture Mirrors Your Org Chart
Ship a system shaped like your teams — so design the teams first.
The principle
Any system's structure ends up a copy of the communication structure of the organization that built it. Applied to AI: if three teams each own a model, you'll get three agents and a brittle seam between them — whether or not the problem wanted to be split that way. The agent boundaries you ship will trace your team boundaries unless you consciously fight it.
Why it happens
Conway's 1968 observation is that any system's structure is constrained to mirror the communication structure of the organization that designed it, because the interfaces in the software get negotiated along the same lines as the conversations between the teams. Applied to agents, if three teams each own a model, you ship three agents with a brittle seam between them whether or not the problem wanted to be partitioned that way, and those seams become where production bugs concentrate. Martin Fowler frames the practical response as the Inverse Conway Maneuver: rather than fighting the law, deliberately shape teams to match the architecture you want, so the boundaries you ship reflect the problem instead of the reporting lines. The leverage point is upstream, in team and ownership structure, not in the diagram you draw after the boundaries have already been socially negotiated.
Watch for
- Agent or service boundaries line up exactly with team ownership rather than with natural seams in the problem.
- Most production bugs cluster at the handoffs between components owned by different teams.
- A task that wanted to be one coherent flow was split because no single team owned the whole thing.
In practice
Three teams each own a model, so the system ships as three agents with a brittle handoff between them, even though the actual task wanted to be one coherent flow. Months later the seams between those agents are where every production bug lives, because each boundary was drawn around a team, not around the problem. Before you commit agent and service boundaries, ask whether they reflect the work or just your reporting lines, and be willing to reshape the teams to get the architecture you actually want.
Apply it
- Before committing boundaries, check whether each one reflects the problem's structure or just your reporting lines.
- Where a boundary serves the org chart but not the problem, reshape team ownership to match the architecture you want.
- Treat the seams between components as the highest-risk surface and design explicit contracts there.
The takeaway
Before drawing agent or service boundaries, check whether they reflect the problem or just your org chart — and reorganize teams to match the architecture you actually want.