Essay

Buying AI Is the Easy Part

Buying access to AI is easy. Durable implementation capacity depends on whether organizations can redesign workflows, train people, preserve learning, and switch providers without surrendering control to vendors or platforms.

Mark Howard

— 10 min read
Share

The harder question is who learns how to make it work

A local government can buy access to an AI system in an afternoon.

Making that system useful may take years.

That gap is easy to underestimate because access is visible. A contract is signed. A pilot is announced. Employees receive accounts. A vendor demonstrates what the system can do. The organization can now say it has AI.

Whether the institution has gained much capacity is a different matter.

A useful early example comes from Clariti AI Studio, a program built around the permitting systems used by cities and counties. Rather than beginning with a general presentation about AI, the program starts with a government’s actual permitting process and asks where the technology might help.

That sounds modest. It is also close to the heart of the implementation problem.

Permitting is not one task. It can involve intake, records, code review, routing, inspections, interdepartmental handoffs, public notice, legal requirements, staff judgment, applicant communication, and appeals. A routine residential permit has little in common with a major commercial development or emergency reconstruction after a disaster.

Dropping a chatbot into that system does not redesign it.

Someone must understand where the delays occur, which records matter, how the departments interact, what applicants need, which judgments can be supported by software, and where human authority must remain clear.

That knowledge is implementation capacity.

It may become one of the most important sources of power in the AI economy.

Access, adoption, integration, transformation

AI adoption is spreading quickly. Organizational transformation is not.

The first consolidated analysis from the UK Office for National Statistics found that reported AI use among businesses with at least 10 employees rose sharply between late 2023 and June 2026. Yet only a small share of adopting firms described their use as extensive. Most were applying AI to improve existing operations rather than redesigning products, markets, or organizational structures.

That is exactly what we should expect at this stage.

Employees experiment. Departments add tools. Managers approve pilots. A few workflows become faster. The institution changes around the edges.

Useful things can happen there. Drafting improves. Search becomes easier. Routine analysis takes less time. Customer-service staff receive better summaries. Software developers work more quickly.

But experimentation is not integration, and integration is not transformation.

These stages require different kinds of work:

  • Access means the organization can use the tool.
  • Adoption means people begin using it in ordinary tasks.
  • Integration means AI is connected to data, software, responsibilities, and workflows.
  • Transformation means the organization changes how work is divided, decisions are made, services are delivered, and value is created.

The stages do not arrive automatically. Plenty of organizations will live for years in the space between adoption and integration, accumulating subscriptions while wondering why the promised productivity gains remain shy.

That may be less a failure of the technology than a shortage of implementation capacity.

The organization has to know itself

AI cannot improve a process that no one understands well enough to describe.

That is a larger problem than it sounds.

Organizations often possess deep practical knowledge without having a clear map of how work actually moves. The official procedure may say one thing. Staff know that the real process depends on three spreadsheets, a weekly meeting, one experienced employee, and a workaround introduced during a software migration eight years ago.

The workaround has since become tradition.

Implementation begins by making that hidden system visible.

Who performs each step? Which data are required? Where do the data live? Which decisions follow rules, and which require judgment? Where do errors enter? Which delays protect something important, and which merely survive because no one owns the whole process?

Those questions are not technical preliminaries. They determine whether AI helps the institution or simply automates its confusion.

Clariti’s permitting workshops are interesting because they begin there. The company is not merely offering a model. It is offering a way to examine the process into which the model might be introduced.

Of course, Clariti is also selling permitting software.

That does not discredit the work. It does mean the vendor arrives with its own view of the problem, its own product architecture, and a fairly understandable preference for solutions that fit inside it.

Who defines the process is therefore closely connected to who defines the solution.

Implementation knowledge can become a control point

The AI industry is often described as a stack: chips, compute, cloud infrastructure, models, applications, and distribution.

Implementation may become another layer.

The organization that understands a customer’s workflows, data, software, compliance rules, bottlenecks, and internal politics occupies a powerful position. It knows where AI can be inserted. It also knows which models, integrations, and operating arrangements will be difficult to replace later.

Several implementation models are already taking shape.

The embedded-services model

Traditional consulting and technology-services firms can place engineers and specialists inside a client organization. TCS’s proposed corps of up to 8,900 forward-deployed engineers is one example. Microsoft Frontier Company is another, with plans to embed 6,000 industry and engineering experts with customers. These specialists would work closely with organizations to adapt and integrate AI systems into real operations.

The advantage is obvious. Most organizations lack enough internal expertise to redesign complicated workflows while evaluating fast-changing AI tools. Embedded specialists can shorten that learning curve.

But where does the learning remain?

If the service firm acquires the deepest understanding of the client’s processes, data connections, and model choices, the customer may become more productive without becoming much more capable on its own.

The consultants leave with reusable knowledge. The institution is left with documentation—sometimes excellent documentation, sometimes a folder whose most reliable feature is that everyone agrees it exists.

The integrated-platform model

A second approach absorbs implementation into the platform itself.

Products such as ChatGPT Work are moving beyond a standalone assistant toward an environment that gathers institutional context, connects applications, discovers tools, coordinates actions, and produces completed work. The platform does not merely answer questions. It begins to organize how tasks move across the institution.

This can make implementation much easier. A unified system reduces the need to assemble separate models, connectors, permissions, and interfaces.

It also makes the platform harder to replace.

Once files, organizational context, workflows, permissions, tools, and task history accumulate inside one environment, switching is no longer a matter of buying a different model. The institution may have to reconstruct part of its operating memory.

Convenience arrives first. Dependence usually sends a quieter announcement.

The persistent-agent model

Claude Cowork points toward a related form. Its remote sessions can preserve files and task history across devices, while scheduled tasks can run without the user’s device remaining online.

That continuity is useful. Many real tasks extend over hours, days, or weeks. An agent that remembers what happened yesterday and can act again tomorrow is more valuable than one that starts every conversation with the institutional equivalent of “remind me what we were doing.”

Persistence also creates a new kind of switching cost.

The model may be replaceable in theory while the accumulated work context is not. The implementation layer begins to merge with the memory layer, the execution layer, and the user relationship.

At that point, the institution is no longer buying only intelligence.

It is renting continuity.

Public agencies face a sharper version of the problem

Private companies can accept some vendor dependence as a business judgment. Public agencies must consider additional questions: public records, continuity of service, legal authority, procurement rules, transparency, data protection, and the obligation to explain consequential decisions.

They also face a basic capacity gap.

Large technology firms can hire model engineers, data scientists, product managers, cybersecurity specialists, lawyers, and organizational-design teams. A small city, school district, public hospital, or nonprofit cannot recreate that workforce.

Vendor support may therefore be essential.

California’s agreement with Anthropic offers public agencies discounted access, workforce training, technical assistance, and implementation support. New York’s enterprise cloud services agreement with AWS follows a similar logic, reducing procurement barriers while providing state agencies with AI, cloud, and workforce-training resources. These arrangements may help public institutions begin using AI sooner and with more support than ordinary procurement would provide.

The immediate benefits may be real.

Still, a central question remains: what does the institution know how to do when the vendor is no longer in the room?

Can staff evaluate a new model? Can they change providers without losing workflows and institutional memory? Can they identify when a system is failing? Can they renegotiate the process rather than merely request a product adjustment?

Public-sector implementation succeeds when the agency gains durable knowledge and authority, not only temporary access.

Procurement is part of the design

Procurement is often treated as the administrative step that happens after an organization decides what it wants.

With AI, procurement helps determine what the organization will become.

A contract can define:

  • who owns data and derived information;
  • whether logs are available;
  • how models are evaluated;
  • which integrations are permitted;
  • what happens when prices change;
  • whether the institution can use competing models;
  • how accumulated context can be exported;
  • whether staff receive training;
  • what documentation the vendor must provide;
  • how the service continues if the provider withdraws;
  • whether the system can be audited;
  • how responsibility is divided when something goes wrong.

These are not boilerplate questions. They shape the architecture of dependence.

A weak procurement process asks whether the product works.

A stronger one asks whether the institution can continue to function, learn, and exercise judgment after the product becomes embedded.

That requires technical knowledge, legal knowledge, operational knowledge, and enough bargaining power to turn those concerns into contract terms.

Smaller institutions frequently lack some or all of them.

This is why shared procurement capacity may become a form of civic infrastructure. States, professional associations, municipal networks, universities, and public-interest organizations can develop standard clauses, evaluation methods, vendor comparisons, and model contracts that individual institutions would struggle to produce alone.

The alternative is for every small buyer to learn the same expensive lesson separately.

Vendors tend to survive that arrangement quite well.

Training is not the same as learning

Workforce training is one of the most common promises attached to AI adoption.

It matters. Employees need to know how systems work, where they fail, what information should not be entered, and when human review is required.

But training can remain shallow.

A vendor demonstrates the interface. Staff complete a course. A few enthusiastic users become local experts. The organization has checked the training box.

Institutional learning goes further.

It captures what worked, what failed, how the workflow changed, which risks appeared, and whether the service actually improved. It creates feedback loops. It updates policy. It changes roles. It spreads knowledge beyond the original project team.

Most importantly, it preserves learning when people leave.

That last part is less exciting than a model launch, which may explain why it receives fewer keynote presentations.

Yet implementation capacity depends on it.

An organization that repeats the same pilot every two years has adopted AI several times and learned very little.

Who gains the capability?

This is where implementation becomes part of the concentration–dispersion contest.

AI can disperse capability in obvious ways. A small business gains research and marketing tools. A public employee can summarize a complicated record. A nonprofit can translate materials, draft grant applications, or analyze data that once required outside help.

Those gains matter.

At the same time, implementation may concentrate the knowledge needed to make AI useful.

A vendor may understand the customer’s process better than the customer does. A consulting firm may carry lessons from one client to the next. A platform may accumulate institutional context and workflow history. A cloud provider may become the place where models, data, tools, security, and execution come together.

The organization receives capability at the surface.

Control may deepen underneath.

The better outcome is capacity transfer. Outside expertise helps the institution learn enough to make informed choices, govern the system, change providers, and continue improving after the first project ends.

That is harder to sell as a product because success eventually makes the customer less dependent.

It is also closer to what durable implementation should mean.

Lane 7: implementation capacity

This is the central concern of Lane 7 — Implementation Capacity in The Race.

The lane asks who can turn AI capability into durable organizational competence.

That includes more than technical skill. Implementation capacity combines:

  • the ability to define the problem;
  • knowledge of actual workflows;
  • usable and well-governed data;
  • procurement and contracting skill;
  • systems integration;
  • cybersecurity and legal review;
  • workforce training;
  • evaluation;
  • organizational redesign;
  • institutional learning;
  • the ability to switch providers or approaches.

The list is long because implementation is not one thing.

It is the connective tissue between a model and an institution.

Without it, access produces scattered experiments. With it, organizations can decide where AI belongs, where it does not, and how to change their own operations without surrendering control of them.

What should we look for?

The early evidence suggests that implementation is still shallow across much of the economy. That is not surprising. General-purpose technologies usually arrive before organizations know how to reorganize around them.

The more revealing question is where implementation knowledge accumulates during the transition.

Several signals will matter:

Do organizations build internal teams capable of evaluating and redesigning systems?

Do vendor contracts transfer knowledge or merely provide service?

Can data, workflows, and accumulated context move?

Do workers participate in redesign, or receive a finished system after the consequential choices have been made?

Do public agencies share tools and lessons, or negotiate alone?

Does management understand how employees are already using AI, including the unofficial experimentation that rarely appears in strategy documents?

The UK evidence suggests that training and incremental operational improvement are currently more common than major workforce replacement or organizational redesign. That may be encouraging. It may also mean the decisive choices are still ahead.

There is still time for institutions to build capacity before today’s pilots become tomorrow’s operating systems.

The work behind the tool

Access matters. Knowing how to use AI well matters more.

Even that understates the work involved.

Implementation capacity is not the skill of writing better prompts or identifying a few promising use cases. It is the institutional ability to understand work, redesign processes, connect systems, train people, evaluate results, preserve learning, and change direction when necessary.

Organizations will often need vendors, consultants, and platforms to help them. The consequential question is what those relationships leave behind.

Does the institution gain knowledge, authority, and room to choose? Or does the implementation work settle permanently inside the provider?

Buying AI is the easy part.

The harder work begins after the account is activated.

References and Further Reading

Read more