Conway’s Law in a workplace shared by humans and AI agents

I have always found Conway’s Law useful in both directions. Show me how an organization communicates, and I can reasonably guess the systems it will build. Show me the systems, and I can often work backward toward the organization. The seams are there if you know where to look.

Sometimes they are elegant interfaces between teams that understand one another. Sometimes they are three definitions of the same customer and a nightly batch job trying to negotiate a peace treaty.

Now we are adding AI agents to the work. Some help individual employees. Others divide assignments, select tools, consult other agents and carry decisions from one task into the next. Increasingly, they participate in designing the systems themselves.

That raises a question I cannot leave alone: what happens to Conway’s Law when some of the participants can assemble their own working relationships, and those relationships never appear on anyone’s org chart?

In The Flower and the Seed, I explored what changes when knowledge can persist beyond the person or agent that developed it. Here I want to look at what happens between those participants. Who talks to whom? Whose conclusions get reused? Who gets to decide?

Before we declare that AI has broken another perfectly useful idea, let us understand the idea.

The organization leaves fingerprints

Melvin Conway introduced his argument in a paper published in 1968. On his website, he gives this formulation:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

That is Conway’s Law.

The phrase to keep is communication structure. Reporting lines influence it, but so do working relationships, shared vocabulary, access to information and the practical difficulty of getting another team to make a decision.

Imagine an online retailer with separate engineering groups supporting sales, warehouse operations and finance. Each group has its own priorities, backlog and definition of success. Sales wants a smooth checkout. The warehouse wants accurate picking and shipping. Finance wants the books to reconcile.

It would be unsurprising if the software developed three substantial boundaries in the same places. The sales system knows an order as a purchase. The warehouse knows it as a shipment. Finance knows it as a receivable. Those distinctions can be useful. Trouble begins when nobody owns the relationships between them.

A customer returns half an order. The warehouse records the items as received, the sales application still says the return is pending, and finance is waiting for a different event before issuing the refund. Every department can explain why its part is working correctly. The customer would still like their money.

The coordination problem has become a software problem.

Think of a house built by three contractors, each responsible for a different set of rooms. They can all do excellent work. If they do not agree on where the doors go, you will discover their communication problem every time you try to get to the kitchen.

Conway included an almost suspiciously tidy example in his original paper: five people assigned to a COBOL compiler produced a five-phase compiler; three assigned to an ALGOL compiler produced a three-phase compiler. It is an illustration, not a formula for predicting software from headcount. But it is hard to forget. (Original paper)

And this is more than a favorite story among architects. Lyra Colfer and Carliss Baldwin reviewed 142 empirical studies of the related “mirroring hypothesis.” They found mirroring common in firms and industries, with significant exceptions; the evidence from open collaborative projects was much less supportive. Calling it a law should not make us treat it like gravity. It is a powerful organizational tendency with conditions and limits. (Research review)

Reading the fingerprints backward

Now turn the exercise around.

Suppose I examine that retailer’s architecture before meeting its teams. I find separate customer records, different meanings for “complete,” and elaborate translations at departmental boundaries. I would want to know whether the people responsible for those systems plan together, or mostly exchange requirements after decisions have already been made.

Suppose instead that every small product change requires editing a shared database and coordinating one enormous release. I would look for concentrated ownership, a central approval bottleneck, or teams whose work is more entangled than their titles suggest.

These are hypotheses to investigate. Acquisitions, purchased software, old constraints and deliberate design choices can leave similar traces. An architecture may also preserve the shape of an organization that disappeared five years ago. The current team gets to explain the plumbing it inherited. Lucky them.

Still, the exercise is useful. You can learn a great deal about a household by looking at which doors are worn, which are locked and which rooms can only be reached by walking through someone else’s bedroom.

This is what I mean by reading Conway backward: using technical dependencies as evidence about the communication patterns that produced them.

A related practice has a more specific name: the inverse Conway maneuver. That means deliberately changing how teams are organized and communicate to encourage the architecture you want. Martin Fowler describes it as a practical response to the law. (Fowler’s explanation)

For our retailer, that might mean forming a returns team with the engineering skills and business authority to own the whole return experience. Give those people a shared objective and the ability to make decisions together. A coherent returns service now has an organization capable of building and maintaining it.

The old software will still need work. Moving boxes on a slide does not migrate a database. But you have changed the conditions under which the next design decisions will be made.

Give every department an agent

For this discussion, an AI agent is a model operating inside software that lets it pursue a task through multiple steps: inspect information, choose an action, use a tool, evaluate the result and continue. Some systems also let agents delegate work or communicate with other agents.

Start with the simplest deployment. Give each department an agent, preserve the existing access boundaries, and require every exchange to follow the existing workflow.

The sales agent knows the purchase. The warehouse agent knows the shipment. The finance agent knows the receivable. They can process their portions faster, but the meaning of “return complete” remains unresolved.

We have given the departmental walls faster clerks.

The same applies when agents help write software. If one group’s coding agents cannot inspect another group’s contracts, tests or design decisions, their output still has to survive that information boundary. Producing code faster does not automatically produce agreement about what the code should do.

Real agent systems already contain familiar organizational choices. Anthropic’s published research architecture uses a lead agent that assigns work to specialized subagents and combines their results. In that implementation, the subagents could not directly coordinate with one another, and the lead waited for batches of work to finish. The engineers described the resulting bottlenecks. (Anthropic’s engineering account)

That is a useful reminder: using AI does not remove the consequences of deciding who can talk to whom. It gives us another place to make that decision.

Then let the agents find one another

Now change the conditions.

Suppose our retailer allows a support agent to discover and consult approved specialists. A return problem arrives. The agent asks a warehouse specialist about the received items, a billing specialist about the refund, and an engineering specialist about the mismatch between their records.

The specific collaboration forms around the problem. No manager had to schedule that exact combination of participants in advance.

The mechanisms for this already exist. Microsoft’s AutoGen documents a pattern in which agents select handoffs to other agents from configured destinations. The A2A protocol documents descriptions called Agent Cards and ways to discover agents by their capabilities. These enable choices within an available environment; they do not grant unlimited access or authority. (AutoGen documentation, A2A discovery documentation)

Humans do something similar. We find the person who actually understands the problem, regardless of where their box sits. Anyone who has worked inside a large company knows the official process and the person you call when you need something to happen.

An org chart is a little like a campus map showing the paved sidewalks. Actual communication includes the footpaths people wear through the grass. Agents can make additional paths through tool calls, delegated tasks and shared records. If we only inspect the paved routes, we will misunderstand how the work gets done.

None of this requires agents to invent a secret language or develop an urge to hide from management. A relationship can be unknown to humans simply because nobody is collecting or examining its evidence.

The messages may be ordinary text. The missing piece is our visibility.

A conversation is not yet an architecture

We need to be careful here. Two agents exchanging information while handling a refund have demonstrated a workflow. That alone does not demonstrate Conway’s Law shaping a new software architecture.

The architectural consequence appears when the collaboration influences what gets designed or changed.

Continue the retailer example. The agents identify a recurring mismatch between warehouse receipt events and finance’s refund rules. Engineering agents from the relevant domains compare assumptions, propose a shared event contract, update the affected code and submit the changes for review. If the organization accepts that design, the temporary collaboration has helped create a lasting interface.

The human reporting structure stayed the same. The effective design team crossed it.

That is where I would expect Conway’s insight to remain useful: the new interface reflects a collaboration we would miss by studying only the human org chart. This is an application of the idea to a plausible scenario, not evidence that every agent exchange produces a matching software component.

It also reveals the upside. Agents could make it less expensive to bring the right knowledge together across boundaries. A company might improve parts of its architecture without putting every employee through another reorganization.

I suspect that benefit alone would receive enthusiastic support from everyone who has survived three reorganizations without changing desks.

What actually changes

Informal relationships, temporary teams and indirect communication all existed before AI. Conway’s original paper even emphasized organizational flexibility as designs evolve. We should give him credit for the argument he made, rather than simplify it until we can announce that we have defeated it. (Original paper)

What deserves an extension is the ability to delegate the formation of working relationships to the software doing the work. Several consequences follow.

A team can become a temporary computational resource. A system can create specialized workers for one task, assign their roles and discard them afterward. The participants may exist for minutes while their accepted design decisions remain in production for years. A directory of permanent employees will tell us very little about that team.

Shared memory can connect participants that never meet. One agent records an assumption about how returns work. A later agent reads it while designing a billing change. No direct handoff, but information crossed between them and affected the result. Human documents have always done this; agents make it practical to repeat the process at a scale and pace that can outrun casual oversight.

This is where The Flower and the Seed comes back into the picture. Persistent memory carries mistakes as readily as useful knowledge. For purposes of understanding the organization, the write into memory and the later read belong on our communication map.

The collaboration rules can themselves become objects of design. If authorized to do so, an agent might propose or change delegation rules, specialist descriptions or the workflow that selects its collaborators. Decisions made during one task could then influence how later tasks are organized. Humans already redesign organizations; the change is that parts of this work can now happen inside the software execution itself.

That creates a feedback loop: the working structure shapes the design, and accepted changes to the design can shape the next working structure.

The cost of crossing a boundary changes unevenly. Starting another agent may be easy. Giving it useful context, resolving conflicting assumptions and verifying its conclusions can still be expensive. Access controls, context limits, tool availability and the cost of coordination determine which relationships are practical.

We should expect those constraints to leave their own architectural fingerprints. Cheap messages do not guarantee shared understanding. A thousand agents can misunderstand the same requirement with remarkable efficiency.

The organization you have to observe

Reading the architecture backward now requires a wider investigation.

A shared component might reflect a human platform team. It might also reflect one central agent service that everyone’s assistants rely on. Repeated design assumptions might come from conversations between engineers, a common agent instruction, or a shared memory entry that nobody has questioned.

The architecture still offers clues. Identifying the organization behind those clues requires knowing which humans and agents contributed, what information they exchanged and whose decisions were accepted.

I would want to distinguish three things: who was allowed to communicate, who actually communicated, and which exchanges changed the outcome. Permission settings describe possibilities. Execution records describe activity. Accepted changes show which activity mattered.

Anthropic describes monitoring agent decision patterns and interaction structures to understand unexpected behavior in its research system. That is the kind of evidence this broader application of Conway needs. (Engineering account)

From a security perspective, one implication deserves particular attention. Suppose an agent proposes a design and another reviews it. If the reviewer inherits the proposer’s unsupported assumption through shared memory, two separate agent names may conceal one chain of reasoning. The apparent separation of duties is stronger than the actual separation of judgment.

We need to know where information and authority flow together. Who can propose a change? Who can approve it? Can the proposer modify the evidence or criteria used by the reviewer? Where does a human decision remain necessary?

The answer is not to make every agent talk to every other agent. Some boundaries protect useful independence. Others merely preserve an old departmental inconvenience. Designing the organization means knowing which is which, and checking that the actual behavior matches the intent.

Conway’s Law 2.0

My conclusion is that AI agents do not invalidate Conway’s central insight. They make a narrow, human-only reading of the organization increasingly inadequate.

The original formulation is broad enough to remain useful. But I think an explicit extension helps us apply it to a workplace in which software can participate in design and help organize that participation.

Here is my proposed Conway’s Law 2.0:

Systems tend to reflect the effective communication and decision structures of the humans and AI agents that design and change them, including structures assembled dynamically during the work.

“Effective” matters because a connection drawn in a diagram may never be used, while an undocumented dependency may shape every decision. “Decision” matters because exchanging information and having the authority to act on it are different things. “Dynamically” matters because the relevant team may form after the task begins and disappear before anyone updates a chart.

This is a proposed working principle, not a newly proven law. Its practical extension is straightforward: when we delegate the organization of work to agents, the rules governing that delegation become architectural decisions.

We still have to honor Conway. We have to give people and agents the information, interfaces and decision rights needed to build coherent systems. We also have to observe the relationships that emerge, preserve independent review where it matters, and correct arrangements that produce the wrong dependencies.

There is real opportunity here. Useful collaboration could form around a problem much faster than a company can reorganize itself. There is also a new management responsibility: understanding an organization that can partly assemble itself while we are looking elsewhere.

The team may disappear before lunch. The interface it designed can be with us for ten years.

I would like to know who was in that meeting. Maybe I need a Conway AI agent to attend on my behalf 🙂

I know this blog post was long and mahalo for reading.

Aloha –TK