Law 39 · Architecture & Operations
Your Architecture Mirrors Your Org Chart
You ship a system shaped like your teams, so design the teams first.
The principle
Any system's structure ends up mirroring the communication structure of the organization that built it. For AI, that means 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 fight it on purpose.
Why it happens
Systems tend to mirror the teams that build them. If three teams each own a model, the product often becomes three agents with handoffs between them, even when the user problem wanted one coherent flow. Those handoffs then become the places where state, ownership, and accountability break. The Inverse Conway Maneuver is the practical answer: shape ownership to match the architecture you want. For agents, that means deciding whether a boundary reflects the work itself or just the org chart that happened to fund it.
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 you draw agent or service boundaries, check whether they reflect the problem or just your org chart, and reorganize the teams to match the architecture you actually want.