Companies are spending serious money on AI. Pilots launch with real budget and executive attention. Results are disappointing. The tools look impressive in demos. They underperform in production. The organization concludes that AI is not ready, or that their data is not good enough, or that they need a better model. So they try a different vendor and repeat the cycle.
I have watched this happen enough times to see the pattern clearly. The technology is rarely the problem. The organization is.
Conway's Law applies to AI systems, not just software
Melvin Conway observed in 1967 that organizations design systems that mirror their own communication structure. A company with four siloed departments builds software with four disconnected modules. A company where no team talks to another builds APIs that do not talk to each other.
This law applies to AI systems just as cleanly — and the consequences are more severe.
When AI is deployed inside a traditional hierarchical organization, the AI systems reflect the organization's silos. The customer service team deploys a chatbot that knows nothing about inventory. The logistics team builds a forecasting model that cannot see customer behavior. The finance team automates invoice processing that is blind to the contract terms sitting in the legal team's system. Each AI tool works in isolation. Each one handles a narrow slice of information. None of them have the full business context needed to make genuinely useful decisions.
The result is not AI failure. It is AI that is technically functional but organizationally useless. The system can answer the question you asked — it just cannot answer the question you actually needed answered, because that question requires context from three departments that were never connected.
Siloed teams produce siloed systems. Siloed AI systems make weak decisions.
What "AI-first" actually means
The phrase gets thrown around in strategy decks. It usually means "we are using AI tools." That is not AI-first. That is AI-adjacent.
A genuinely AI-first organization builds a full AI stack — not a collection of point solutions. The stack has specific layers, and each layer depends on the ones below it:
- Models — the inference layer, selected and tuned for the tasks at hand
- Structured knowledge — your business data, organized and maintained in a form AI can actually use
- Memory — persistence of context across sessions, workflows, and time
- Agents — autonomous processes that act on the knowledge and complete multi-step work
- Integrations — connections to the systems where your business actually runs
The critical insight is that these layers must be vertically integrated. The agents must have access to the structured knowledge. The memory must persist across integrations. The models must be selected based on what the agents actually need to do. When you buy five separate AI products from five different vendors, you get five separate stacks — and none of them share context.
This is where most enterprise AI investment goes wrong. The budget goes to the top of the stack (models, tools, interfaces) while the bottom of the stack — structured knowledge, memory, integrations — gets left as an afterthought. You end up with powerful AI that knows nothing about your business.
The vertical integration advantage
There is a reason the companies building the most effective AI systems are the ones who own their stack end-to-end. It is not about cost. It is about knowledge accumulation.
When you own and control your AI stack, every decision the system makes adds to a body of institutional knowledge that stays inside your organization. The model sees your data. The memory captures your patterns. The agents learn your workflows. Over time, the system becomes genuinely better at your specific business — not at a generic version of your industry.
When you outsource the stack to external vendors, that knowledge accumulates on their servers. You pay for capability that improves for everyone equally. You never build a proprietary edge. The moment a competitor subscribes to the same service, your advantage disappears.
Owning the stack is not the same as building everything from scratch. You use foundation models, infrastructure services, existing APIs. But you control the integration layer, the knowledge structure, and the memory — the parts where your business context actually lives. That is the moat.
The organizational fix
If Conway's Law is the diagnosis, the prescription follows directly: change the communication structure, and the system structure will follow.
The teams building AI systems cannot be siloed by department. They need to be cross-functional — combining domain knowledge from the business, data engineering, AI implementation, and operational feedback — all working together on the same system with shared context.
This is harder than it sounds, for reasons that have nothing to do with technology. Siloed teams exist because organizations optimize for individual accountability. Each team owns their piece and protects it. Cross-functional teams require shared accountability, which requires shared goals, which requires leadership that actually means it when they say "AI is a priority."
The other structural requirement is tight feedback loops. The gap between when the AI system makes a decision and when the organization learns whether that decision was correct must be as short as possible. Long feedback loops mean the system keeps making the same mistakes for months before anyone notices. Short feedback loops mean the system improves continuously.
This is an organizational design problem. It requires that the people who see the AI's outputs — the operators, the customers, the business owners — have a clear, low-friction way to report back on quality. Most organizations have no such mechanism. The AI ships, the results are vaguely "fine," and no one ever systematically improves the system.
The entry point is not the destination
There is a practical question buried in all of this: where do you start?
The answer is a focused, high-value use case where the inputs are clear, the outputs are measurable, and the feedback loop is short. Data extraction is a common one — converting unstructured documents into structured records. Invoice processing, contract analysis, catalog enrichment. These tasks have obvious before/after metrics, they do not require deep organizational change to get started, and they build the foundational capability you will need later.
But it is important to understand what you are actually building when you start there. You are not building a data extraction tool. You are building the beginning of your AI stack — establishing the patterns for how data flows through your systems, how quality is measured, and how human feedback gets incorporated. If you build the data extraction tool in isolation, with no path to the broader stack, you have spent budget on a point solution that will not compound.
The destination is what I call an agent-driven enterprise: an organization where AI agents handle the execution of complex, multi-step workflows autonomously, while humans focus on strategy, judgment, and domain knowledge that the agents cannot replicate.
This is not science fiction. It is the logical end state of the stack I described earlier, built correctly. Orders route and reconcile themselves. Supplier data gets normalized without human involvement. Customer issues get triaged and resolved before they escalate. The humans in the loop are making decisions that actually require human judgment — not performing manual steps that exist only because no one built the automation.
What this means in practice
If you are evaluating AI strategy for your organization, the questions worth asking are not "which model should we use" or "which vendor should we buy." Those are implementation details. The questions that determine whether you actually get value are:
- Does the team building the AI system have access to the full business context it needs to make good decisions?
- Who owns the knowledge layer — the structured data and memory that the AI reasons over — and is it accumulating inside your organization?
- How fast does feedback travel from business outcomes back to the people improving the system?
- Are your AI investments building toward a connected stack, or toward a collection of isolated tools?
Technology is the easy part. The models are capable. The infrastructure exists. The hard part is structuring an organization and an architecture so that the AI has access to what it actually needs to be useful — and so that every hour it runs makes it more useful, not just more used.
Conway's Law is not a curse. It is a diagnostic. Fix the communication structure, own the stack, shorten the feedback loops — and the AI systems follow.
