CIOs Reverse Conway's Law To Build Agent Architecture Around Business Outcomes First

In 1967, computer scientist Melvin Conway published a paper showing that a system's design copies the communication structure of the organization that builds it. The idea became known as Conway's Law. Teams that talk to each other build parts that fit together, and the seams show up wherever the conversation stopped. It holds steadily enough that software teams learned to run it in reverse, building the team structure they want the architecture to have and letting the code take that shape.

Nearly 60 years later, marketing, sales, and service each run their own AI assistant, and none of the three connect. Companies are buying agents faster than they are deciding who owns what. Agents hand work off to each other, and a handoff between two teams that never talk is a handoff that fails. The way agents connect is the org chart, whether anyone drew it that way or not.

Christoph Wargitsch has spent his career on that boundary. He is Founder and CEO of WARGITSCH Transformation Engineers, a German consultancy that guides organizational change for mid-sized companies and large corporations across Europe, North America, and Asia-Pacific. He held leadership roles across the automotive and IT sectors, running CRM at Audi and sales and marketing IT for Volkswagen, before founding the firm in 2008.

A physicist by training with a doctorate in business informatics, he thinks most companies have Conway's Law backwards. They design the organization, then let AI reflect it, when the outcome should decide both. "You always have to think backwards from the outcome. What do you want the organization to achieve?" he says.

Structure shapes systems

Wargitsch put the law to work at Volkswagen, where he ran sales and marketing IT. Getting the manufacturer, the wholesale operation, and the dealerships to work as one chain kept getting skipped, because no unit owned that link and no executive sponsored it. Every unit stayed busy with the piece in front of it. He built a team whose only job was that link, and the systems came out shaped around it. "When I had a head of vertical integration and a team of 30 or 40 people, they designed the solution landscape exactly the way they were set up," he says.

The law is consistent enough to plan around, which is why guidance now reaching AI programs says to settle the operating model first. Whatever structure exists when the build starts is the one the software inherits.

Boundaries start dissolving

Most large companies run three structures at once. The first is the reporting line on the org chart. The second is the project and program layer, where agile teams form for a delivery and disband after. The third is the looser network of working groups that gather around a shared problem and stay as long as the problem does. Conway's Law was written when the first one governed almost everything. AI has moved solution building out of IT and into the business units, where the other two decide how the day actually goes. "People do not care much which unit they belong to anymore, because their daily work is shaped by the project teams and working groups rather than the reporting line," Wargitsch says.

Running the law in reverse only works if the structure a company builds stays in place long enough to produce something. Wargitsch is describing companies where that no longer happens. Bottom-up tech sprawl is not new, but it now comes from more directions at once. Legacy platforms, low-code builds, and AI systems accumulate in parallel at different levels of the company, with no clean break between one era and the next. "Parts of Conway's Law will vanish, because there is nothing solid left to take hold of," he says.

Tools arrive first

Enterprise software used to be hard to like. It needed training, the interfaces were clumsy, and people avoided it until IT made them use it. AI tools are the opposite. Employees find them on their own and start building with them, which means the technology lands before the decision about how the company should work.

That order creates two problems. The first is what the tools are touching. Company data moves through software nobody reviewed, which is where an agent governance layer earns its place, along with a clear answer on where data physically sits. "If you have AI regulations, you have to update them every month to keep up with the speed here," Wargitsch adds.

The second problem is choice. New models, retrieval systems, and AI features keep appearing inside software companies already pay for, and the tool a team picked in January may not be the right one by March. "When you license one model from one supplier at the start of the month, by the end of the month it might already be outdated, because something new has come up that fits much better," Wargitsch says.

Each swap costs more than the license. Teams have to learn the new tool, rebuild the workflows around it, and work out all over again when to trust what it produces. That runs at the speed people absorb change, which is why so many companies hold a long list of pilots and a short list of pilots reaching production. "You cannot learn at the same speed as this development is happening right now, and that is the core problem," he says.

When building gets cheaper

Delivery frameworks are already adjusting. Scaled Agile released AI-Native SAFe in June 2026, treating AI as a core contributor to how work gets planned rather than a capability bolted onto existing practice.

Wargitsch reads the shift through systems theory. When more people can build, the organization has more ways to move, and it moves further between the moments anyone checks. The fix is to check more often. Governance built on quarterly reviews is measuring a company that has already changed several times since the last look, which is why agentic era governance is moving toward shorter, continuous cycles. "If you want to stay on the border of chaos and not jump over it, you need shorter cycles for controlling the developments," Wargitsch says.

When more people can build, some of them build things the company used to buy. Wargitsch describes a software team that decided the license cost and vendor dependence on its internal ticketing system had become untenable, so it built a replacement. "Instead of 50 people, two or three control the whole thing, and the development work is done by agents," he says.

That headcount matches where software engineering is heading, toward smaller engineering teams of four or five people, sometimes fewer. Companies have always built their own small tools. What moves is the ceiling. Application software complex enough to require a vendor is coming into range for a handful of engineers, which reopens build-versus-buy for categories that settled years ago. The infrastructure underneath it, where data has to be stored, governed, and held in the right jurisdiction, is not the part a three-person team takes on. "The speed of new business models coming up by just creating new software will increase dramatically," he adds.

Designing backwards

Run the sequence the usual way and the existing org chart gets rebuilt in software, faster and at higher cost than the version it replaces. The companies avoiding that tend to be the ones where managers own the workflows instead of treating AI as something IT delivers. The same shift is visible inside engineering, where agents are moving upstream into planning rather than sitting at the build stage.

The redesign does not stop at the company line. Choosing partners and linking systems across a supply chain has taken years of negotiating shared standards. Agents on both sides that can read and evaluate what the other offers cut that down to something closer to a conversation. "That flip will happen, and not only inside companies. It will happen between them," Wargitsch says.