AI Is Not Primarily a Technical Challenge

For the past several years, I have been trying to understand how to think clearly about AI without overstating what I know or retreating into vagueness because the technology is moving too quickly.

If I am honest, I have sometimes let the short half-life of AI ideas make me too cautious about holding a point of view at all. The models improve, the interfaces shift, new capabilities arrive, old assumptions fall apart. It is easy to conclude that any strong view will soon look dated. I have felt that instinct myself.

But that no longer feels like the right answer.

There is no outrunning an exponential. At some point, one is better off taking one’s chances and saying what one believes — carefully, provisionally, but clearly. In a landscape changing this fast, certainty is not available. Still, leaders need principles. Not eternal truths. Not fixed doctrine. Just convictions solid enough to act on while staying honest about what may change.

This essay is my attempt to name a few of those convictions.

The most important one is this:

AI adoption is primarily an organizational challenge, not a technical one.

That belief has roots in two different phases of my own experience.

The first began in 2008, when I was first exposed to ideas like ontology, data architecture, and software as a way of modeling the real world. To be clear, I was not then thinking about AI as we know it today. We were not talking about modern language models. We were not imagining ChatGPT. What we were thinking about were the deeper concepts underneath: how information should be structured, how systems should represent reality, how human beings might interact with machine-mediated intelligence, and what it might mean to harness that intelligence in operational settings.

Those questions stayed with me.

The second phase began with the arrival of modern language models. That was the moment when many of those structural ideas suddenly met a profoundly different interface. For the first time, we were dealing with machines that could meet us in language, even as they required us to learn a new kind of fluency in return.

And now, as of 2026, we are entering something else again: the early agentic era. Systems are beginning not just to respond in language, but to persist across tasks, take action with increasing autonomy, and display forms of capability that feel much closer to what many people would have associated with general intelligence only a few years ago. Whatever labels ultimately prove correct, the practical implication is already clear: the distance between “tool” and “collaborator” is shrinking.

That change strikes me as more important than many people initially appreciated. It was not just that the software had gotten better. It was that the relationship between humans and machines had changed. The interface had changed. The terms of collaboration had changed. A machine no longer needed to be encountered primarily through code, menus, or rigid workflows. It could now participate in something much closer to dialogue. It could respond in natural language, reason in ways that felt legible, and help generate analysis, synthesis, and first drafts on demand.

Since then, my interest has been less in AI as a spectacle than in AI as a lived operating reality: how people work with it, how organizations resist it, how leaders misframe it, and why so many efforts stall despite extraordinary technical progress.

Again and again, I come back to the same conclusion.

Most leadership teams are treating AI as a question of tools, vendors, and use cases. Those things matter. But they do not sit at the top of the stack. The harder questions come first.

What deal are you making with your people?

How is work itself going to change?

And is your business structured coherently enough for machine intelligence to operate inside it?

That is why I believe the right sequence is people, then work, then systems.

If you get that order wrong, you can spend a great deal of money and time producing motion without transformation. You can roll out tools, sponsor workshops, hire consultants, approve pilots, announce initiatives, and still end up with an organization that has not actually changed.

The reason is simple. AI does not enter a company as a neutral technology. It enters as a force that immediately raises human questions, behavioral questions, and structural questions. Ignore those, and the technical layer has nothing stable to land on.

1. People: The Social Contract Comes First

The first layer is people.

I have come to think of this as the social contract, and I keep returning to that phrase because it names something most organizations would prefer to leave implicit. AI changes the deal between the company and its people. It changes expectations about leverage, productivity, skill, headcount, value creation, and what kinds of work will remain scarce.

Yet many leaders try to tiptoe around this reality.

They announce AI initiatives without naming the implications. They talk about innovation, enablement, and experimentation, but avoid the harder sentence underneath. They reassure rather than clarify. They hope that if they keep the language vague enough, they can preserve flexibility and avoid discomfort.

In practice, the opposite happens.

Ambiguity is not neutral. Your people will fill it with fear, suspicion, silence, rationalization, or denial. They will guess at the deal if you do not state it. They will watch what leadership does, infer what is happening, and protect themselves accordingly.

That is where many AI efforts begin to fail before they even start.

Not because the technology is weak, but because the human context around it is unstable.

When people do not understand the deal, they do what people always do when stakes are high and intentions are unclear. They become cautious. They experiment in the shadows. They nod in meetings and disengage in practice. They tell themselves stories about what is really happening. They assume leadership is being less honest than it should be. They wonder whether “AI transformation” is a euphemism for cost reduction, whether the new tools are really for them or against them, whether experimentation is safe, whether their judgment still matters, whether they are expected to become something fundamentally different without anyone saying so out loud.

None of this is irrational. It is the predictable response to uncertainty.

That is why the social contract has to come first.

A leadership team has to be willing to say plainly what it believes. What are we optimizing for? What does greater leverage mean here? What are we asking people to learn? What are we prepared to invest in them? What are we not promising? What will not change, and what probably will?

These are not communication details. They are foundational acts of organizational design.

Until the deal is named, every AI initiative in the company is running on ambiguity.

And ambiguity has downstream costs. It creates quiet resistance. It encourages performative adoption. It turns real fear into polite compliance. It leads executives to misread the room because they see activity and assume commitment, when in fact the organization is withholding belief.

The companies that navigate this transition best will not be the ones that have the slickest AI messaging. They will be the ones that are most honest about the new deal.

That honesty does not require brutality. It does require clarity.

A leadership team can say, in substance: we believe AI will change how work is done here. We believe greater leverage is possible and necessary. We intend to invest in our people so they can grow with that shift. We are going to ask more of you. We are also going to equip you more seriously. We are not going to pretend that nothing is changing, because it is.

That kind of clarity creates stability, even when the underlying reality is unsettling.

The social contract is not a side conversation. It is the human foundation on which everything else rests.

2. Work: Fluency Is Behavioral, Not Theoretical

Once the deal is explicit, the next question is whether the organization is actually changing how work gets done.

This is the second layer: work.

Here I think many companies fall into a different trap. They mistake awareness for fluency and training for transformation. They run workshops. They circulate prompt libraries. They measure attendance. They count licenses. They talk about adoption as if familiarity with the tools were the same thing as capability.

It is not.

Fluency is not knowing what ChatGPT is. Fluency is not being impressed by what a model can do. Fluency is not attending a training and leaving with a handful of techniques.

Fluency is the ability to work meaningfully with AI in the context of a real job.

It means restructuring tasks, judgment, sequence, and workflow around a new kind of capability. It means understanding where the machine is unusually strong, where it is weak, where it is unreliable, where human judgment remains central, and how the combination can produce better outcomes than either could alone.

That is why I believe the unit of change is not the training session. It is the workflow.

If you want to know whether a company is becoming fluent, do not ask how many employees completed an AI workshop. Ask which recurring workflows have actually been rebuilt. Ask where AI is now a first-class participant in the work. Ask whether teams are producing better outputs, making faster decisions, reducing friction, or increasing throughput in ways that can be observed.

Tool training without behavior change is theater.

This distinction matters because the introduction of AI is not merely a software event. It is a redesign of the relationship between intention and execution.

Many forms of first-draft thinking, synthesis, analysis, summarization, exploration, and iteration can now be produced on demand. That changes the economics of knowledge work. It does not eliminate the need for people, but it does shift where value lives.

More and more, the scarce layer is not raw production. It is framing, judgment, taste, orchestration, and the ability to direct machine capability toward meaningful ends.

This is the deeper reason fluency matters. It is not just about efficiency. It is about learning how to work at the new frontier between human judgment and machine capability.

That frontier is not stable. It keeps moving. Which means fluency is not a one-time learning event. It is an ongoing operating discipline.

The organizations that grasp this early behave differently. They do not isolate AI into a side initiative. They embed it into real tasks. They protect time for experimentation. They encourage teams to bring concrete work into the loop. They compare outputs. They establish feedback loops. They normalize iterative collaboration with the machine. They teach people how to interrogate outputs, refine instructions, challenge assumptions, and build better working patterns over time.

In other words, they make fluency behavioral.

This is one place where I think the novelty of the current moment still goes underappreciated. For the first time, we are dealing with machines that can meet us in language, even as they require us to learn a new kind of fluency in return. That matters because language is not merely a convenience layer. It is the medium through which much of human coordination, thought, and judgment already flows.

When a machine becomes meaningfully available in language, it does not just become easier to use. It becomes easier to incorporate into thinking itself.

That is why some people experience AI initially as a curiosity and others experience it as a deep shift. The latter group has usually discovered, sometimes almost by accident, that they are no longer just using software. They are learning how to think with a new kind of counterpart.

That does not mean the machine is a person. It does not mean it understands the world as we do. It does mean that the collaborative surface has changed. And the people who learn how to operate effectively at that surface will gain advantages that are hard to overstate.

Organizations that ignore this will keep treating AI as either a novelty or an appliance. Organizations that understand it will start redesigning work around it.

Over time, that difference compounds.

3. Systems: The Business Must Become Computable

The third layer is systems.

I have been living with and thinking about this concept since 2008, long before today’s AI moment made it newly legible to a wider audience. Long before language models made these ideas feel immediate to executives, I was exposed to a way of thinking about software not merely as applications, but as systems for representing reality: the objects that matter, the relationships between them, and the actions that change them over time. That early foundation is part of why I keep returning to this layer now. The technology has changed dramatically. The structural question has not.

This is where the conversation gets more technical, but the point is still organizational. Here I think the most useful word is ontology, precisely because it sounds more intimidating than it really is.

Every business already has an ontology whether it knows it or not. It has objects that matter, relationships between those objects, and actions that change them over time.

Customers. Orders. Invoices. Shipments. Contracts. Routes. Claims. Tickets. Assets. Facilities. Employees. Products.

These are not just data fields. They are the nouns and verbs of the business itself.

When I speak about ontology, I am really speaking about whether the business has described itself coherently enough that intelligence can operate inside it.

This is where the concept of computability becomes powerful.

The question is not whether AI is smart enough. The question is whether your business is computable.

A computable business is one whose key entities, relationships, rules, and state changes are defined clearly, represented consistently, and made accessible through a coherent unified layer such that machine systems can reason across them, act on them, and support meaningful decisions inside them.

A non-computable business may still have plenty of dashboards, reports, and software. But its core definitions are fragmented. Its systems disagree about what a customer is. Its workflows are encoded differently in different functions. Its data lives in silos. Its rules are inconsistent. Its processes exist more in tribal memory than in operational logic.

In that environment, AI can generate interesting outputs. It can summarize. It can brainstorm. It can comment on the business. But it struggles to enter the bloodstream of the business itself.

This is why the ontology question matters so much. It is not academic. It is structural.

It determines whether AI will remain a layer of commentary on top of the company or become part of how the company actually works.

When the business is well modeled, AI can do far more than generate content or answer questions. It can help monitor, route, prioritize, simulate, forecast, reconcile, and participate in workflows that matter operationally. It can interact with the business not just as text, but as structure.

When the business is poorly modeled, AI remains trapped at the edges — clever, occasionally useful, but hard to operationalize.

This is the hidden reason many organizations feel underwhelmed after the initial excitement. They assumed that model intelligence alone would be enough. In reality, model intelligence only becomes truly consequential when it has something coherent to work on.

The gap is not always in the model. Often the gap is in the business.

And here again, the sequence matters.

Many organizations want to start with tools, because tools feel concrete. They want to evaluate platforms, launch pilots, compare vendors, debate architecture, and make decisions that signal seriousness.

But if the business has not done the definitional work — if it has not named its key objects, clarified its relationships, aligned its functions, and established consistent logic about how the company actually works — then tooling can only solve so much.

You cannot buy your way out of an alignment problem.

This is why I increasingly believe that ontology is not first a technology artifact. It is a leadership artifact.

It is leadership’s job to help the business define itself clearly enough that systems can embody that clarity. Technology teams implement it. They do not originate it alone.

Once that becomes visible, a great deal of confusion falls away. The problem is no longer “Which AI platform should we buy?” The problem becomes “Have we defined the business in a way that allows intelligence — human or machine — to operate coherently inside it?”

That is a much better question.

The Order Matters

Seen this way, the sequence becomes clearer.

The social contract comes first because people need to understand the deal.
Fluency comes next because the work itself has to change.
Ontology comes after because systems have to become coherent enough to support that change at scale.

Put differently: first align the humans, then redesign the work, then make the business computable.

This, to me, is why AI adoption is primarily an organizational challenge rather than a technical one.

The technical layer is real. It matters. Model quality matters. Infrastructure matters. Security matters. Tool selection matters. But for most leadership teams, these are not the first-order constraints.

The binding constraints are upstream.

Leadership has not named the deal.
The organization has not changed its working habits.
The business has not defined itself coherently enough for intelligence to compound inside it.

That last phrase is important. What is at stake here is more than successful tool adoption. It is whether an organization can become more adaptive than it was before.

The companies that get this right earliest will not simply save time or run a few better pilots. They will build an internal capacity to learn faster, redesign work faster, and operationalize intelligence more effectively than peers who continue to treat AI as a series of disconnected experiments.

Over time, that gap will widen.

This is one reason I think the market still tends to misread what is happening. Many leaders are trying to decide whether AI is overhyped or underhyped, whether it is moving quickly or too quickly, whether it is primarily a risk or primarily an opportunity.

Those are understandable questions. They are just not the most useful ones.

The more useful question is: what kind of organization are we becoming?

Are we becoming an organization that tells the truth about the transition?
One that helps people build real fluency rather than performative familiarity?
One that structures its systems so intelligence can actually operate?
Or are we still treating AI as an interesting layer on top of a company whose deeper architecture remains unchanged?

That is the strategic question.

The enduring advantage will not go to the companies with the most demos, the loudest posture, or the broadest experimentation. It will go to the ones that get the architecture right: people, then work, then systems.

A Final Note on Principles

I said at the start that these are not eternal truths. I mean that.

The capabilities will improve. The interfaces will change. Some assumptions in this essay will age well; others will not. That is part of the territory.

But I no longer think the right response to that reality is to hold no point of view until the dust settles. The dust is not settling. That is not the world we are in.

So these are the principles I know how to hold today.

AI adoption is primarily an organizational challenge, not a technical one.
The right sequence is people, then work, then systems.
The social contract must be named.
Fluency must become behavioral.
And the businesses that become computable earliest will be positioned to build advantages that others will struggle to catch.

That is where my own thinking has landed, at least for now.

And if I had to compress it to one line, it would be this:

The question isn’t whether AI is smart enough. The question is whether your business is computable.