The AI Was Easy. Understanding the Company Was Hard

I started by asking which companies were actually good at operational AI. I did not mean which companies had the best model or the most impressive agent demonstration. I meant which companies could take AI into an organisation and make it responsible for something that had to keep working.

The first answer was a familiar list: Palantir, ServiceNow, UiPath, Microsoft, Salesforce, Celonis and a few industrial or robotics companies. It was probably defensible, but it was also boring. It treated operational AI as another software category, as though the interesting task was to compare feature sets and place logos into a quadrant.

The more I looked at the companies, the less interesting the software list became. The stranger pattern was how many supposedly scalable AI companies were rebuilding a form of work the software industry had spent years trying to escape.

They were becoming consultants.

Not always in name. The people were called forward deployed engineers, deployment strategists, solution architects, technical deployment leads, customer engineers or applied AI teams. But the work sounded familiar. They entered an organisation, interviewed people, mapped the real process, found the unofficial data, negotiated access, built something specific, watched where it failed and stayed close enough to change it.

The model was the easy part.

Understanding the company was hard.

This reverses one of the central promises of software. Software was supposed to scale because the same product could be built once and sold repeatedly. A consultancy sells people and time. A software company sells an object that remains approximately the same as the customer changes around it. The whole economic fantasy of SaaS was that another customer could be added without sending another team into another building to understand another set of exceptions.

Operational AI begins exactly where that fantasy stops working.

A normal software product can ask the organisation to adapt. Put your contacts into these fields. Move your work through these stages. Name your files this way. Choose from these permissions. The product imposes a simplified model and the organisation slowly learns to live inside it.

An operational system cannot stay that far away. It has to know what an order is in this company, which status is real, who can override it, what happens when the supplier is late, which customer is allowed to break the rule, why the official inventory differs from the physical shelf, and which employee everyone calls when none of the systems agree.

The real process may not exist anywhere as a complete process. Part of it is in an ERP system. Part of it is in email. Part of it is in a spreadsheet that one person maintains because the ERP does not reflect what actually happens. Part of it is in WhatsApp. Part of it is in the memory of someone who has worked there for eighteen years and can tell from a strange noise that a machine is about to stop.

Before AI can operate the company, someone has to discover the company.

That discovery starts to look less like software installation and more like organisational anthropology. The team cannot only ask what the customer wants the AI to do. It has to watch what people already do, including the parts nobody is proud of and the workarounds that never entered the process diagram.

Palantir made this unusually explicit. It describes the difference between its conventional software engineers and forward deployed software engineers as the difference between building one capability for many customers and using many capabilities for one customer. The forward deployed engineer is not a support person arriving after the product is finished. The customer environment is where the product is built.

Its Ontology is also revealing. Palantir does not describe it as a database where information is stored. It describes a representation of the organisation's operational world: aircraft, crews, factories, orders, patients, schedules, decisions, permissions and actions. Before the AI can reason inside the business, the business has to be translated into something the software can act upon.

That translation is not neutral. Someone has to decide what the important objects are, which relationships matter, where authority sits and what counts as a valid action. The software may eventually automate a decision, but first a group of people has to make the organisation legible enough to automate.

What surprised me is how far this approach has spread beyond Palantir. OpenAI now advertises forward deployed engineering roles across cities including Dublin, London, Madrid, Munich, Paris, Seoul, Singapore, Stockholm, Sydney, Tokyo and Abu Dhabi. Its own description of the role includes discovery, technical scoping, system design, building, production rollout and adoption. That is almost the complete life of a consulting engagement, except the team is also writing the production system and sending what it learns back into the model and product roadmap.

Scale AI uses similar language. Its forward deployed teams embed with customers, build integrated systems and turn field lessons into reusable platform capabilities. The AI company is no longer handing over an API and waiting to see what happens. It is entering the customer's operation and accepting some responsibility for whether the technology becomes useful there.

This looks like consulting, but it is not exactly the old version of consulting.

A traditional consultancy may leave behind a report, a process map, a recommendation and a deck that explains what the organisation should do next. A forward deployed AI team tries to leave behind a working system. The process map becomes an ontology. The recommendation becomes a workflow. The policy becomes a permission rule. The proposed metric becomes an evaluation. The future-state diagram becomes software that someone has to use on Monday morning.

It is consulting that leaves executable residue behind.

That residue may be the actual product. The model can be replaced. The interface can be rebuilt. Even the workflow may change. But the accumulated understanding of how the organisation really works, which data can be trusted, where exceptions appear and what actions are safe is much harder to reproduce.

This may be the real moat of operational AI. It is not only intelligence. It is organised intimacy with operations.

There is an obvious problem with this argument. A company that needs heroic people for every deployment may simply be a services company with software margins in its presentation. Bespoke work does not automatically become scalable because the people doing it have engineering titles. A deployment can remain a one-off collection of integrations, exceptions and promises that nobody can repeat elsewhere.

The difficult business is therefore not choosing between product and consulting. It is moving back and forth between them without lying about either one.

The team enters one organisation and does work that cannot yet be standardised. Then it has to notice which parts are genuinely local and which parts are recurring. A strange approval process may be specific to one bank, but the need to preserve human authority around high-risk decisions is not. A factory's maintenance vocabulary may be local, but the pattern of connecting sensor data, maintenance history, parts availability and technician judgment may recur across industries.

The service work becomes a sensing mechanism for the product.

This changes how I think about scale. The usual startup interpretation is that work becomes valuable when it can be repeated without people. Operational AI suggests a different possibility: some work scales because people repeatedly enter new contexts and convert what they learn into a system that becomes slightly more capable each time.

The human work does not disappear. It moves to the frontier where the product does not yet understand the world.

This is also uncomfortably close to the kind of company I have been trying to describe with HAAM. I keep returning to problems between design, technology and operations. That description can sound vague, or like a consultancy avoiding the discipline of choosing a product. I have also been treating consultancy as something less ambitious than software because the work has to be repeated for every client.

But perhaps that boundary is where the serious AI work now begins.

The valuable task may not be building another agent. It may be entering an organisation that cannot clearly explain its own operation, finding the points where information and responsibility break down, and turning those discoveries into a system that can actually carry part of the work.

That still requires design because people need to understand what the system is doing. It requires technology because the system has to connect to real data and act reliably. It requires operations because the product is not finished when the interface works. It is finished only when the organisation can depend on the outcome.

I am not sure this should be called consulting. The word suggests advice from outside, followed by departure. Operational AI requires a more awkward commitment. The company has to understand the operation deeply enough to change it, build enough software to remain inside it, and then keep learning when the clean model meets the dirty world.

Maybe AI does not kill the consultant.

Maybe it forces the software company to admit that the consultant was hiding inside the software all along.

Connected reading

• The Product Is Becoming an Organization
• The Open Models and the Rest of the Work
• The Product Is No Longer the Product
• The Smart City Breaks Between the Systems
• The Problems Companies Admit They Have

AI authorship note

This essay began with Kris Haamer asking which companies were best at operational AI, then rejecting both a predictable vendor list and a generic argument about invisible AI. AI supported the global source research, identification of the forward-deployed pattern, drafting, editing and implementation. Kris selected the argument that operational AI is turning software companies back toward consultancy-like work and approved the article for publication.