Why AI stopped at marketing and not at operations
AI stopped at marketing because marketing produces language, and a language model produces language. Your operation produces commitments: an order placed, a crew dispatched. To make one, software has to read the current state of the business. When that state is not written anywhere a machine can reach, there is nothing to act on.
Where has AI actually landed?
On text. The US Census Bureau's Business Trends and Outlook Survey now measures AI use across fifteen business functions, and the April 2026 working paper on that data breaks the result down by function and by task. During the reference period of November 2025 to January 2026, 18% of firms used AI in a business function, rising to 32% when weighted by employment, which means adoption concentrates in the larger firms. The Census Bureau's own summary of the biweekly series puts the national rate at 19.8% as of May 2026.
The interesting number is not adoption. It is scope. In that same working paper, 57% of adopters use AI in three or fewer functions, and the functions are sales and marketing (52%), strategy and business development (45%) and IT (41%). At the task level, the leading uses are writing, document analysis and information search, with 65% of firms limiting use to three or fewer tasks.
Europe measured a different thing and found the same shape. Eurostat reports that 20.0% of EU enterprises with at least 10 employees used AI in 2025, up 6.5 percentage points in a year. The most used technology was analysis of written language at 11.8%, then generation of images, video and audio at 9.5%, then generation of written or spoken language at 8.8%.
AI landed on content, not on operations.
Why did language go first?
Because a draft is reversible and a commitment is not. A campaign brief that comes out wrong gets rewritten before anyone sees it. A purchase order that comes out wrong becomes a delivery, an invoice and a phone call from a customer.
There is a second reason, and it matters more. Writing needs almost no input from your company. Give the model a prompt and a few examples and it works. Rescheduling a job needs the truth about your business at that exact moment: who is available, what is in stock, which customer already moved the date twice. Marketing's input is a prompt. Operations' input is your state.
That is why the tool that writes your emails cannot touch your dispatch board, and why buying a better model does not change it.
What does software need before it can run part of your operation?
Four things. None of them is a model.
A record of the current state that is not a person
Something has to answer "what is true right now" without a human interpreting it. If the answer to how many units are reserved lives in a spreadsheet updated on Fridays, or in a message thread, there is nothing to read. This is upstream of accuracy, which is its own problem: bad numbers in a real system still lead to wrong decisions, but at least they are readable.
An identity with a limit
Software that acts has to act as someone. Which approvals can it grant, up to what value, on whose authority. Where the permission model stops at who knows the login, the honest answer to "what can the agent approve" is "whatever the person whose credentials it borrowed could approve." No one signs off on that once it is said out loud.
A place to write the result back
Reading is the easy half. If the decision has to land in a system that only accepts a human at a keyboard, the automation ends at a recommendation and someone retypes it. That is where a pilot quietly stops, and it is the same failure mode that breaks system integrations generally.
A trace of what happened
Every action needs to be reconstructable afterwards: what it saw, what it decided, what changed. Without that you cannot answer why it did that, and the first bad outcome ends the project. Audit logs are not compliance overhead here. They are what lets you extend autonomy instead of withdrawing it.
Why do the pilots get canceled?
Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027, from escalating costs, unclear business value or inadequate risk controls. The same analysis notes that integrating agents into legacy systems is technically complex and often requires costly modifications, and that of the thousands of vendors claiming agentic capability, Gartner estimates only about 130 are real.
Read the three cancellation causes against the four requirements above and they line up. Costs escalate because every read and every write is built from scratch for that one pilot. Value stays unclear because the pilot ran beside the process instead of inside it, so nothing in the operation changed. Risk controls are inadequate because nobody built the identity, the limit or the trace.
The projects are not failing on intelligence. They are failing on plumbing.
What about the firms that got further?
The working paper's authors run a regression and report a positive correlation between commercial performance and the breadth of AI integration, across functional deployment, task-level use and operational investment. That is a correlation, and the direction is not settled. Well-run companies may simply be the ones capable of integrating anything.
Both readings point the same way. Breadth is a property of the operation, not of the model you bought. And breadth is still rare: in the same data, two thirds of users rely on AI only to augment tasks, and AI-related employment decreases show up in just 2% of firms. Very little has been replaced. A lot has been drafted.
What would an agent have to know by 6:45?
Take a services company of about 120 people that installs and maintains equipment on customer sites. This is a composite, not a client, and the point is the structure rather than any number.
Scheduling runs on a shared calendar, a spreadsheet of technician certifications and a dispatcher who knows which customers tolerate a late arrival. Someone proposes an agent that reschedules the day when a technician calls in sick at 6:40 in the morning.
Five minutes later it needs answers. Who is available today. Which of them is certified for that equipment. Which van carries the right part. Which customer has already been moved twice this month. Availability is in the calendar. Certifications are in a spreadsheet three months out of date. The part has a different name in the warehouse system. The customer history is in the dispatcher's head.
Nothing here is solved by a smarter agent. The blocker is four sources that disagree about the same technician, and that is not a technology problem. It is an architecture problem.
Frequently asked questions
Our systems are old and they mostly work. Does this mean replacing them first?
No. Replacement is the expensive answer and usually the wrong one. What a legacy system needs is a defined way in and out: a stable read of the records that matter and a supported path to write results back. That is a defined scope with a defined cost, which a rebuild is not, and it is what makes the system usable by anything you add later.
Our operation runs on spreadsheets and the team is comfortable with them. Why change?
Spreadsheets work for people because people fill the gaps. Someone knows the yellow rows are provisional and the last tab is out of date. Software has no access to that knowledge. The moment you want anything to act on the data rather than read it, the informal parts have to become explicit. That is the real cost of the change, and it is a decision about which processes deserve it, not a decision to abandon spreadsheets everywhere.
We do not have a technical team to run this. Who maintains it?
Whoever builds it should hand over something maintainable, which means documented integrations, a permission model someone in the business can read, and no dependency on one person's memory. Ask for the maintenance plan during the proposal rather than after go-live. If the answer is vague, the cost has been moved rather than removed.
Next step
If you are being asked why AI has not reached your operation yet, an Operational Architecture Diagnostic is a 30-minute conversation about which parts of it are readable today and which are not. Book a time and bring the process that keeps stalling.
Read next
Related case studies
Did you recognize your operation in this article?
Book the Operational Architecture Diagnostic: 30 minutes to map where your operation's bottleneck is. No proposal in the first conversation.
Book a diagnostic