Most of the AI conversations I've watched play out inside organizations over the last two years have been about the wrong thing. Not because the participants are unsophisticated, and not because the technology is poorly understood. The conversations are about the wrong thing because they're focused on the tool, and the tool is the least important part of the equation.
The shape of the conversation usually goes something like this. A vendor pitches an AI platform that will become the organization's Work OS. The pitch is comprehensive and credible. The platform will integrate with what you have, will sit at the center of how your people operate, will make work faster and smarter and more measurable. Leadership listens. The pitch resonates because it suggests a clean answer to a messy problem, and clean answers to messy problems are what leadership is structurally biased to buy. Pilots get approved. Budgets get redirected. The organization commits.
Six to twelve months later, the pattern becomes visible. The platform has opinions about how work should be done, and those opinions are narrower than the pitch suggested. Your workflow doesn't fit the opinions cleanly, so you adapt the workflow. The adaptations layer on top of each other. The platform that was supposed to flex around your organization turns out to be the same kind of opinionated SaaS product the organization has bought ten times before, and the organization is doing what it's done ten times before: bending its operations around the product's assumptions about what those operations should look like.
The reason leadership goes along with this, in my experience, isn't laziness or inertia. It's that organizational leaders frequently treat SaaS vendors and their products as a substitute for subject-matter expertise the organization doesn't trust itself to have. The reasoning runs along these lines: the vendor has built a product. The product has opinions about how the work should be done. The vendor has thousands of customers who use the product. Therefore the vendor's opinions presumably reflect how the work should be done, and if our organization's process doesn't match the vendor's opinions, the right move is probably to update our process rather than to push back on the product. This logic is rarely stated out loud, because stated out loud it sounds slightly absurd, but it's the working assumption behind a lot of buying decisions. Vendor opinions are interpreted as encoded best practice, and the act of adopting the product is interpreted as adopting that best practice.
The problem with this assumption is that vendor opinions are not encoded best practice. They are the design choices a particular company made to build a particular product that could be sold to a particular market segment at a particular moment in time. Those choices may be reasonable. They may also be arbitrary, or convenient for the vendor, or shaped by the technical limitations of the platform the product was built on, or optimized for a customer profile that doesn't match yours. The vendor's product reflects a worldview, but the worldview is the vendor's, not the field's. Organizations that adopt the product and adopt the worldview without distinguishing between the two end up with their operations shaped by decisions they didn't make, in service of assumptions they didn't examine.
If you've been in IT for any length of time, you've watched this happen in slow motion across an entire category of work, and the cleanest example I can point to is the data landscape. The arc has been visible for two decades. Organizations started with data warehouses built on Kimball or Inmon principles, which were rigorous, opinionated, and reasonably well-suited to the problems they were solving. Then Hadoop arrived, promised that the rigor of structured warehousing was unnecessary because compute was now cheap enough to brute-force the queries, and a generation of organizations migrated to Hadoop-shaped solutions. Then Spark arrived and offered a better execution model on top of similar storage assumptions. Then it became clear that the lack of ACID guarantees in the lakehouse model was a real problem after all, and Iceberg and Delta Lake emerged to layer transactional semantics back onto the storage layer the previous generation of tools had stripped them from. Which is to say, the field spent fifteen years migrating away from Kimball and Inmon and then engineered its way back to most of what Kimball and Inmon had been doing in the first place, with a different vendor stack and a longer list of dependencies.
I'm not knocking the evolution. The underlying technology is genuinely better in 2026 than it was in 2006, and some of the detours produced real capabilities that the original warehousing approaches couldn't have. But across that arc, a remarkable number of SaaS vendors built businesses on the assumption that their particular take on data infrastructure was the correct one, and a remarkable number of customer organizations adopted those vendor opinions as if they reflected an industry consensus that didn't actually exist. The consensus shifted every three to five years. The customers shifted with it. The vendors got rich while the assumptions kept getting revised.
The cautionary version of this story misses something, though. Twenty years ago, organizations did not have data analysts. They did not have data scientists. They did not have data engineers, analytics engineers, ML engineers, MLOps engineers, data platform engineers, or any of the other roles that now populate the data org chart at most mid-sized companies. They had DBAs. The DBA managed the warehouse, and that was the function. The work of "doing things with data" was an adjacency to a few other roles rather than a profession with its own career ladder.
The data tooling cycle didn't just produce vendor churn and abandoned platforms. It produced an entire new category of professional work. The job titles, the certifications, the conferences, the salary bands, the educational pathways, the consulting practices, all of that emerged from the same fifteen-year arc that also produced the Hadoop-to-Spark-to-Iceberg migrations and the proliferation of barely-distinguishable ETL tools. The two things happened together. The vendor cycle was extractive and the vendor cycle was generative, simultaneously, and pretending it was only one or the other misses how this kind of technological moment actually works.
This matters for the AI case because the same thing is almost certainly about to happen. There will be entire categories of work that emerge from the AI moment that we cannot fully name yet, because the work hasn't been invented. Some of the early candidates are already appearing in job postings. AI engineer is starting to mean something specific. Prompt engineer briefly meant something and then mostly stopped. Agent engineer is starting to be a category. AI ops, AI architecture, AI governance, AI integration specialist. Some of these labels will harden into real professions with real career ladders. Some will turn out to be transitional. We don't yet know which is which. What we do know, from the data analog, is that some of them will end up being where significant amounts of value get produced over the next decade, and the people who position themselves to do that new work early will be the ones who end up with the most leverage.
The cleaner illustration, if the warehousing arc feels too sweeping, is just the ETL market by itself. Look at how many ETL and ELT tools exist. Talend, Informatica, Pentaho, Fivetran, Stitch, Airbyte, Hevo, Matillion, dbt, Airflow, Prefect, Dagster. That's a small fraction of the actual list. Every one of them is a highly opinionated product solving the same superficial business problem, which is moving data from one place to another. The opinions are not the same opinions. Each vendor encodes a different worldview about how data should be transformed, where the transformation should happen, what the unit of work should be, who should be authoring the transformations, what governance should look like. Organizations select an ETL tool and inherit a set of opinions that shape how their data engineering function operates for years. The opinions are not best practice. They are choices.
This is the cycle AI is at the front end of. The technology is genuinely new. The dynamic isn't.
What's different right now is that AI vendors are at a temporary stage in their lifecycle where they're unusually receptive to enterprise feedback. They take feature requests seriously. They iterate on their platforms in response to customer signal. The codebase is young, the market position isn't fully defined, and the company needs the adoption to lock in for them to survive or for their value proposition to become tangible enough where they get bought by someone else. This responsiveness creates the impression that AI vendors are categorically different from the SaaS vendors that came before them. They are not categorically different. They are at a particular phase of the same lifecycle, and the phase is going to pass.
Three years from now, the AI vendors that survive the consolidation will have mature codebases, defined market positions, and the same "we'll consider it for the roadmap" responsiveness as every other mature SaaS company. The organizations that committed to those platforms in the receptive phase will discover that the responsiveness was a function of the vendor's needs, not a feature of AI as a category, and they'll be doing the same workarounds against the same opinionated products they've been doing for years. Different label. Same dynamic.
The reason this matters is that the conversation about AI inside organizations is almost never about the problem the organization is actually trying to solve. It's about the tool the organization is considering buying. Those are different conversations, and confusing them is the structural mistake that produces the cycle I just described.
The problem is rarely "we need an AI platform." The problem is something like "we can't get a coherent picture of our enrollment funnel because the data is in four systems and the people who interpret it have left," or "our service desk is drowning in repetitive tickets that we don't have headcount to triage manually," or "our advancement team is making decisions about donor outreach without the synthesis of past interactions they'd benefit from." Those are real problems. AI might be part of the answer to some of them. The conversation that starts with the problem and asks whether AI is part of the answer is a very different conversation from the one that starts with the AI platform and asks what problems it can be pointed at.
Organizations are mostly having the second conversation. The vendors are happy to encourage it, because the second conversation produces sales and the first one might not. The result is a lot of AI spend pointed at problems that AI doesn't actually solve, or that AI solves only after the organization has done the harder upstream work of clarifying what the problem actually was, which is the work the vendor pitch implicitly suggested wouldn't be necessary.
If the cycle is going to repeat, the practical question for any organization right now is what to actually do about it. Not how to opt out, because the technology is real and the pressure to adopt is real. The question is how to engage with the AI moment in a way that captures the generative side of what's about to happen while staying honest about the extractive side. The vendor cycle is going to play out. The new categories of work are going to emerge. The organizations and the individuals who position themselves well for both of those things are going to come out the other side stronger. The ones who only see the vendor pitches, or only worry about being displaced, are going to miss the part where new professional ground is being formed in real time.
That's the question for the next post. The short version is that organizations need a clearer view of where they actually are in the progression from AI-curious to AI-integrated, because most of them are much earlier in the progression than the vendor pitches let them talk like they are. The longer version is worth its own piece, and that's where I'll go next.
— Chris