Conway's Law was never about org charts

Conway's original formulation, published in Datamation in April 1968, reads: "organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations" (Melvin Conway, How Do Committees Invent?). The usual shorthand is that four teams produce four components. The deeper point is about coordination. Architecture emerges partly because people who need to agree on an interface have to communicate across a boundary, and the boundary ends up in the code.

That mechanism depended on something easy to overlook. The people writing the code were the same people who took part in the communication. They had been in the design review, heard why a boundary existed, and absorbed the exceptions nobody wrote down.

AI adds a participant who was not in the room

A coding agent can modify several modules, cross team boundaries, generate new interfaces, and refactor structure faster than any review cycle. What it cannot do by default is participate in the communication structure Conway described. It was not in the architecture meeting. It did not hear why one dependency was deliberately prohibited. It does not know which of two similar services exists for regulatory isolation and which is simply legacy.

The old chain looked like this:

Organization structure
        |
        v
Communication patterns
        |
        v
Architecture
        |
        v
Code

With agents, a step appears in the middle that the organization does not control by default:

Organization structure
        |
        v
Architectural decisions
        |
        v
Agent context   <-- whatever the agent was handed
        |
        v
Generated code

If the decisions never reach the agent's context, the agent reconstructs intent from the code it can see. That reconstruction is sometimes right. When it is wrong, the result is locally correct code that breaks the architecture.

The architecture is richer than the repository

Architectural intent lives in ADRs, RFCs, design review threads, platform standards, security requirements, post-incident reviews, and the memory of people who were there. The repository contains the result of many of those decisions, but rarely their rationale or their constraints. An agent inferring architecture from code alone is reading the output of a process and guessing its rules.

A simple example. Two services have nearly identical data models. They are separate because one handles regulated customer data and must stay isolated. An agent asked to reduce duplication sees two similar modules and consolidates them. The change is clean, tested, and technically sensible. It is architecturally wrong, and nothing in the code explained why.

The Inverse Conway Maneuver meets AI

Teams that understand Conway's Law sometimes use it deliberately. The Inverse Conway Maneuver shapes team boundaries around the architecture the organization wants, so the communication structure pushes the system in the intended direction.

That strategy assumes the people writing code sit inside the team structure. Once agents write a meaningful share of the implementation, shaping human communication is no longer sufficient on its own. The architectural intent those team structures were designed to produce also has to reach the agents, in a form they can use at the moment they change code.

Architecture has to become machine-readable

This does not mean putting every architecture document into a model's context. Three different capabilities tend to get conflated:

  • Retrieval gives the agent relevant architectural context.
  • Applicability determines which decisions actually govern the change in front of it.
  • Enforcement checks the change against the decisions that can be checked mechanically.

Retrieval alone still leaves the agent free to ignore what it retrieved. The failure modes of context-only approaches are covered in why context alone doesn't prevent architectural drift.

Decisions become an engineering artifact

Code, tests, schemas, dependencies, and policies already have identity, versions, and review. Architectural decisions usually do not. In an SDLC where agents implement, decisions need the same treatment: a stable identity, provenance, a lifecycle from proposal to acceptance to supersession, a scope that says what they govern, and where possible a rule that can be checked. That is the difference between an ADR folder and a decision corpus. See are your ADRs enforceable?

What engineering organizations should do now

  1. Identify the architectural decisions that genuinely constrain implementation, not every preference.
  2. Separate prescriptive decisions from advisory documentation.
  3. Attach each decision to the repositories, services, or paths it governs.
  4. Make those decisions discoverable to coding agents at the moment they change code.
  5. Check generated changes against the decisions that can be checked mechanically.
  6. Keep a record of which decision produced which verdict.

None of these steps require a particular tool. They require treating architectural intent as something the organization transmits deliberately, instead of something that leaks through meetings.

Where Mneme fits

Mneme is one implementation of this approach for architectural decisions in a repository. It turns accepted decisions into scoped rules, returns deterministic verdicts against proposed changes, and, through its local MCP server shipped in 0.9.0, lets an agent retrieve the decisions that apply to the paths it is working on. It does not claim to capture every kind of organizational intent, and not every architectural decision can be reduced to a mechanical rule.

Conway's Law still holds

Conway explains where architecture comes from. Brooks explains why coordination gets expensive as contributors multiply, and agents intensify both; the companion piece is Brooks's Law after AI.

Conway's Law says software reflects how organizations communicate. In an SDLC where AI writes a growing share of the code, that communication needs a machine-readable form. Otherwise the agents writing the code sit outside the very structure that was supposed to shape it.

Related governance concepts