TL;DR
- Most organizations were built the way ants build apartment blocks. One team adds a workflow, another adds an approval, a third adds a reconciliation step, and over time the colony hardens into structure.
- Functional complexity is real and comes with the job. A hospital is complex because medicine, regulation and reimbursement are complex. Incidental complexity is residue, and it is a choice.
- The most common reason enterprise AI fails is not hallucination or agent reliability. It is that the enterprise itself is incoherent, and the model was asked to consume the whole mess in one sitting.
- "Data readiness" is treated as a permanent condition of enterprise life. It is more likely a transitional problem that will look faintly ridiculous in hindsight.
For most of business history, we have built organizations the way ants build apartment blocks.
An ant does not have a design philosophy. It does not sit around wondering whether the plumbing stack should be elsewhere, or whether a load-bearing wall has now become an obstacle to future growth. It spits. That is the move. It has one material, one instinct, and a lot of repetition. Over time, the colony hardens into structure.
A lot of enterprises are not meaningfully different.
How the colony hardens
One team adds a workflow. Another adds an approval. A third adds a reconciliation step because two systems now disagree. Then somebody hires a team to manage the handoff between those teams. Then comes the integration layer, because the first system was never meant to speak to the second. Then the data team shows up because five departments have created five definitions of the same customer and all of them are somehow “correct.”
The whole thing hardens. Oh there is always a queen or king ant which is to be pleased.
At some point, this dried spit gets renamed. Process. Governance. Controls. Enterprise architecture. Digital transformation. The words get fancier as the structure gets uglier.
And because we are used to living inside these colonies, we start calling all of this “enterprise complexity,” as if it were some unavoidable tax of being a serious company.
Functional complexity and incidental complexity
I don’t think that’s true. At least not anymore. Buddha has not arrived. AGI has, I suppose.
Some complexity is real. A utility is complex because the grid is complex. A hospital is complex because medicine, regulation, liability, staffing, and reimbursement are complex. A trading firm is complex because markets are complex. That is functional complexity. It comes from reality. It comes with the job.
But an enormous amount of what passes for complexity inside large firms is not functional. It is incidental. It is not the business. It is the residue left behind by humans trying to coordinate with other humans through software that was too dumb, too fragmented, or too politically compromised to hold a clean shape.
That residue shows up first in data.
The residue shows up first in data
One customer, six IDs. One contract, four interpretations. One number in sales, another in finance, and a third in operations because somebody built a local workaround in 2021 and it quietly became canon. Then we act shocked that enterprise AI struggles.
The current conversation about enterprise AI still misses this in a big way. We talk about hallucinations, reasoning failures, agent reliability, and benchmark scores. Fine. Some of that matters.
But the most common reason enterprise AI fails is much less glamorous: the enterprise itself is incoherent.
The model did not create semantic drift. The model did not create a jungle of brittle integrations, spreadsheet sidecars, unofficial workflows, and approval theater. The model simply had the misfortune of being asked to consume the full mess in one sitting.
We say AI fails. Often AI just discovers that the company has been failing in slow motion for years. Why that discovery does not respond to a better model is the argument in Reliable AI vs. Coin Flip.
Data readiness is a transitional problem
Right now, people talk about “data readiness” as though it is a permanent condition of enterprise life. Of course the data is messy. Of course the systems don’t agree. Of course integrations are fragile. Of course business rules live in Linda’s head. Everyone says this with the resigned tone of people discussing weather in January.
But I’m not convinced this remains true for very long.
Three years from now, as agents increasingly work with agents, a lot of the slop that humans introduce into systems starts to reduce. Not disappear entirely. Reduce enough to matter. Fewer people re-keying things. Fewer people dragging context from one app to another. Fewer informal interpretations of policy. More state changes created directly from machine-readable context. More actions taken against structured semantics instead of tribal memory.
Seven years from now, I suspect “enterprise data readiness” in the form we know it will look like one of those transitional problems that once consumed budgets and committees and PowerPoints, and then suddenly feels faintly ridiculous in hindsight.
Business stays hard
Not because business gets simpler.
Business will stay hard. Pricing will be hard. Risk will be hard. Regulation will be hard. Supply chains will be hard. Credit decisions will be hard. Running the business will still require judgment, domain depth, nerve, and taste.
But the incidental complexity we have wrapped around those problems (Ahem, the human slop, the translation layers, the handoff tax, the semantic drift, the accidental spaghetti), that part should no longer be treated as destiny.
The better question
And once incidental complexity is no longer destiny, it changes the question.
The question is not “how do we add AI into the current org design?”
That is the safe, consultant-shaped question. It assumes the colony is right and the only job is to move faster through the tunnels. Consultants and well-meaning C-Suite will tell each other that we will change the DNA. Ants with wings. Whole org on RedBull.
The better question is: what kind of organization should exist when humans are no longer the main creators of incidental complexity?
That is a much more uncomfortable question, because it points at org design, not tooling. It points at roles that exist mainly to reconcile the output of other roles. It points at whole software categories that survive because one bad system needed another bad system to explain it. It points at managerial structures whose real purpose is to absorb the friction created by fragmented state and bad memory.
What the one-person company meme is actually pointing at
This is why the one-person company idea gets attention. Not because every serious business is about to become a solo operation. That part is unserious. A refinery is not a creator business. A utility is not a Shopify storefront with good prompts. Many opportunities in the real economy still require teams, specialization, field operations, trust, escalation, and human judgment.
But the one-person company meme is pointing at something real: businesses of the future should be designed to avoid incidental complexity, not just staffed to manage it.
That means fewer human-generated state changes. Fewer handoffs. Fewer reconciliation rituals. Fewer translation layers between functions. Fewer systems whose main purpose is to compensate for the stupidity of the last system.
In other words, don’t use AI to preserve the ant colony.
Use it to ask why the walls were built that way in the first place.
The firms that win won’t just be the ones that adopt AI. Plenty of companies will do that in the same way enterprises adopted dashboards, CRMs, and “digital transformation”: expensively and with self-congratulation.
The firms that win will be the ones that redesign themselves around a simple premise: functional complexity is part of the game; incidental complexity is a choice.
For a long time, we treated that choice as unavoidable. Soon we won’t be able to.
And when that day comes, a lot of organizations will discover that what they called enterprise-grade was just dried spit with a budget.
Where Moative fits
Moative works with mid-market operators on that second question rather than the first. Our starting move inside a business is to separate the complexity that comes from the work from the complexity that came from coordination, because only the second kind is worth removing and only the second kind responds to automation. In healthcare revenue cycle management the split is usually obvious once you look: payer rules are functional complexity, while six definitions of a patient encounter are residue.
Frequently asked questions
What is incidental complexity in a business?
It is complexity that comes from how people coordinate rather than from the work itself: reconciliation steps between systems that disagree, approval layers that exist to catch the last system's errors, and roles whose main output is translating one team's data into another team's format. It is removable, unlike the complexity the business is actually in.
Why does enterprise AI fail so often?
Usually not because of the model. The more common cause is that the organization is internally inconsistent: one customer with six identifiers, one contract with four interpretations, and business rules that live in people's heads. A model asked to work across that mess is being asked to resolve contradictions no one has resolved.
What is enterprise data readiness?
It is the state of having data consistent, defined and accessible enough for systems to act on it. Today it is treated as a permanent condition to be managed, but as more state changes are created by machines against structured semantics, much of the mess that makes data unready has a smaller source.
Is data readiness a permanent problem?
Probably not in its current form. A large share of the inconsistency is generated by humans re-keying, dragging context between applications and interpreting policy informally. As that shrinks, so does the source of the drift.
Should we redesign our organization for AI or add AI to what we have?
Adding AI to the existing design is the safe question, and it assumes the current structure is correct. The more useful one is which parts of the structure exist only to absorb friction that a machine no longer creates. That points at org design rather than tooling, which is why it is rarely the question asked.
What is the one-person company idea really about?
Not that serious businesses will run solo. Refineries, utilities and clinical operations need teams, specialization and escalation. The useful version of the idea is that a business can be designed to avoid coordination overhead rather than staffed to survive it.
