I keep returning to one observation when I help organisations deploy AI, and it predates the technology by almost sixty years.
In 1968, computer scientist Melvin Conway wrote that any organisation designing a system will produce a design whose structure copies that organisation’s communication structure.
The computer scientist Fred Brooks later named it Conway’s Law in his book The Mythical Man Month.
The short version: your software looks like your org chart.
Conway described it with a small example: If one team writes a compiler, you get a one-pass compiler. If two teams write it, you get a two-pass compiler.
The number of passes follows the number of teams, not the needs of the problem. The people boundaries become system boundaries.
For decades, this was confined to software development. Today, it explains why so much AI work fails.
Your AI deployment copies your organizational structure
The silos in the organization become silos in the software, mirroring the structure that built it.
More than 80% of AI projects fail, twice the failure rate of technology projects without AI, according to the RAND Corporation. (MIT’s research pushes that number up to 95%.)
The common assumption is that the AI model is too weak, but the data points elsewhere.
RAND found that miscommunications about a project’s intent and purpose are the most frequent reason AI work collapses. The problem is human communication, which is the center of Mel Conway’s law.
Look at how most companies adopt AI today. Each team buys its own tool (leading to shadow AI). Marketing runs one assistant, sales runs another, operations runs a third.
Each system reflects the data, language, and assumptions of the team behind it. No shared AI capability appears across the organisation, because no shared communication channels exist across it.
Agentic AI strains the seams
Agentic AI raises the stakes. An agent doesn’t just write text: it takes actions, calls systems, and hands work to other agents.
The seams between those agents fall on the same lines as the communication breakdowns between your teams.
Martin Fowler writes that when an architecture is at odds with the development team, module interactions that were designed to be simple become complicated, because the teams responsible for them don’t work together well.
Swap “module” for “agent” and you have a precise description of AI deployments today. An orchestrator agent can coordinate only what the human teams behind each sub-agent agree to share. This can help or hinder business capability.
Take one task: resolving a billing dispute. It crosses customer records, payment history, and policy. If those three areas live in three departmental silos, you’ll build three agents that struggle to hand off to each other.
The task is cross-functional, but the agents, following your organisational boundaries, are not.
So, we see three patterns repeat:
First, agent boundaries copy team boundaries rather than task boundaries, so the work flows across functions while the agents stop at the org chart.
Second, AI governance follows team communication paths—but if nobody owns an agent that crosses two departments, nobody can agree on its guardrails, escalation path, or failure handling.
Teams without psychological safety (an underrated requirement for open communication) won’t raise these cross-functional risks, so the riskiest automations go ungoverned.
Third, prompt and tool design reflect internal language. If the people who built an agent (say, the product development team) only ever talked among themselves, the agent speaks their internal dialect, with internal product names and process codes. This breaks the moment a customer or another team meets it.
It all comes down to organizational design systems and effective communication.
The inverse Conway maneuver for AI
You can’t (and shouldn’t) fight Conway’s Law—the more practical move is to use it. Fowler describes three responses.
| Response | What it means for AI |
| Ignore | Deploy tools team by team and let the org chart decide the architecture by accident |
| Accept | Design the agent architecture to fit your real communication patterns, not the diagram |
| Inverse Conway maneuver | Reshape the teams first so they produce the agent architecture you want |
The inverse Conway maneuver, a term coined in 2011 by Jonny LeRoy and Matt Simons, means changing the team structure to encourage the system design you want. Fowler ties it to small, long-lived, business capability teams that hold every skill needed to deliver value.
Apply that to AI. Before you design the billing-dispute agent, build the cross-functional development team that will own it: customer success, finance, and product in one room, agreeing on scope, data access, and escalation. The agent design follows from that collaboration.
Loosely coupled teams produce loosely coupled agents, the same way this thinking gave us team topology and loose coupling in microservices.
The question your AI programme must answer
Most AI conversations open with model choice, tooling, and prompt design. Conway’s Law says the prior question comes down to organizational architectures: who talks to whom, and what are they allowed to share?
Get that wrong, and no amount of prompt engineering or workflow design will save your software developer or scrum master.