TL;DR
- Every traditional industry runs two systems: the official software that handles the clean path, and the human sidecar that handles everything the software could not express. The sidecar is scar tissue, and each piece of it formed around a real wound.
- Software ignored that work because encoding it was expensive. Every exception became a field, every judgment a rule, every rule three more screens. AI changes that arithmetic for the first time.
- The expert stays. The manual grind around the expert does not. If the work touches risk, capital, price, compliance or customer trust, someone inside the industry still has to own the result.
- Most of these systems should stay inside the business. A few pass a strict test and become the product the industry did not know how to ask for.
Power transmission companies often do not know what to charge carriers for tower access. No software tells them, and no vendor sells the answer.
The work does not live cleanly inside one system. It sits across contracts, tower assets, field constraints, carrier precedent, and the judgment of someone who has seen enough bad deals to know where the trap is. A model can read the documents. It cannot know, on its own, what this industry has learned to fear.
The work beside the software
Every traditional industry has work like this. The official software handles the clean path: ERP, CRM, billing, claims, dispatch, compliance. The names change, but the pattern does not. The system captures the part that could be standardized, and the rest lives beside it.
It lives in spreadsheets and email threads and approval chains, in the person everyone calls before the number goes out. A regulator's note from 2019. A pricing exception after a market shift. A workaround built after an acquisition, because the new system could not express the old promise.
Every one of them formed around a real wound. They are scar tissue.
Why software never took it on
Traditional software did not ignore this work because software people lacked imagination. It ignored it because encoding the mess was expensive. Every exception became a field, every judgment a rule, every rule three more screens. Eventually the software became bloat, and the human sidecar survived because it was cheaper than pretending the work was clean.
AI changes that economics. For the first time the sidecar work can run on software: read the contract, pull the asset record, compare precedent, draft the recommendation, route the exception. The expert stays. The manual grind around them does not. The reason that grind has to be observed before it is automated, rather than the other way round, is the subject of Instrumenting Work to Avoid Expensive AI Rollouts.
Someone still has to stand behind the answer
But the output still needs a human behind it. If the work touches risk, capital, price, compliance, or customer trust, someone inside the industry has to own the result. This is where the vendor story breaks: a license vendor can sell the tool and walk away. The buyer cannot.
So "I do not trust a vendor to know my world" is, more often than not, exactly right.
The labs themselves are proof of it. A frontier model on its own does not change a business, and they know it. OpenAI has stood up a separate company to send its own engineers inside customer operations, and Anthropic is building an enterprise services arm aimed at community banks, mid-sized manufacturers, and regional health systems. The model matters. So does sitting inside the work long enough to know what it is allowed to do. What that shift tells you about where value is moving is the argument in The Pause Is a Tell.
So who should own the workflow?
Which raises the question the vendors would rather skip: who should own one of these workflows?
Probably not a software company. More likely the operator who has already lived inside the mess, the one with the expert, the customer trust, and the long memory of exceptions. So build it for yourself first. Most of these systems should stay right there, inside the business, where they cut cost, raise quality, and make the company less dependent on one heroic operator. That alone is worth doing.
The test for the few that should leave the building
A few should leave the building.
The test is strict. Does the same workflow show up across your peers? Does it sit near money the customer already cares about? Does it get sharper with every exception it handles? Can you take it to market in language the industry respects?
When the answer is yes, the workflow stops being an internal efficiency project. It becomes the product the industry did not know how to ask for, whether that is internal IP, a licensed product, a joint venture, or a new company. Not because it sounds like AI, but because it sounds like the industry.
What to rent and what to build
None of this is the generic AI everyone is already buying. The writing assistants, the coding copilots, the search across the company drive: rent those, and let the labs make them cheaper every quarter. The work beside the software runs the other way. It does not get cheaper from someone else's training run, and no vendor is waiting to hand it to you.
The people who build it will probably not call it an AI product, or a new category at all. That language belongs to vendors. They speak in outcomes: which result has to be right, which exception has to escalate, which answer nobody should trust without a human name on it.
That is the difference between automation and opportunity. Automation makes the work cheaper. Opportunity is when the industry still needs someone credible to stand behind the result.
The operators who can carry these systems to market already know each other. Word of mouth among them moves faster than any sales team.
That is the premise behind what we build at Moative: the Guild for the operators who already carry the work, and the ventures and Foundry we form when one of those systems is ready to leave the building.
Someone will build the generic tools for everyone. No one is coming to build the work beside the software but you.
Where Moative fits
Moative works with operators who already carry this kind of work. The same pattern shows up in healthcare revenue cycle management, where the scar tissue sits between the EMR and the payer, and in claims processing, where the exception handling is the job.
Frequently asked questions
What is the work that sits outside enterprise software?
It is the judgment, exception handling and institutional memory that never fit into the ERP, CRM or claims system: spreadsheets, email threads, approval chains, and the one person everyone calls before a number goes out. Each piece of it usually formed in response to a specific past failure.
Why did traditional software never automate exception handling?
Because the cost of encoding it was prohibitive. Each exception needed its own field, each judgment its own rule, and each rule more interface. The result was bloated software, so the human workaround survived as the cheaper option.
Does AI replace the domain expert?
No. It removes the manual work around the expert: reading contracts, pulling records, comparing precedent, drafting a recommendation. Where the output touches risk, capital, price, compliance or customer trust, a person inside the business still has to own the result.
Should we build our own AI workflow or buy one?
Build the workflows that encode your own judgment, and rent the generic capabilities. Writing assistants, coding copilots and enterprise search get cheaper every quarter from somebody else's investment. Your exception logic does not, and no vendor is planning to hand it to you.
When should an internal AI workflow become a product?
When four things hold at once: the same workflow appears across your peers, it sits close to money the customer already cares about, it improves with every exception it handles, and you can explain it in language the industry respects. Short of all four, it is an internal efficiency project, which is a perfectly good thing to be.
Why are AI labs building services businesses?
Because a frontier model on its own does not change a company. Getting a model to work inside a specific operation requires sitting in the work long enough to know what it is allowed to do, and that is a services problem rather than a research one.
