Adopting AI was the easy part: now comes the hard part, adapting work to it

The article, written by a head of AI operations and adoption at Canary Technologies (a growth-stage tech company based in San Francisco), starts from a central distinction: adopting AI is not the same as adapting to it. According to the author, 2023-2025 was the adoption period —putting the technology in everyone's hands, connecting it to company data and getting it used daily— and that stretch is now practically over at the most AI-advanced companies he observes. What comes next is different and far harder: adapting the way people work, the way the business runs and even the technology itself, until the gains show up in the numbers. That is the phase that, in his view, has barely begun.

The reason adoption was "the easy part" is that it did not touch the substance of the work. The author describes adoption as four layers stacked on top of the workflow as it already existed: access (a license and a team plan), connectivity (the connectors and MCP that let the model reach the data), usage (a model open all day, with prompts and "skills" passed from hand to hand) and application (small tools and automations each person adds to the part of their own job they can control). The dominant pattern, he says, was to give everyone access and let a thousand different initiatives bloom, an approach he considers right as a first step but one with a structural ceiling: each person can only improve the slice of the process under their control, never the whole process, because the seams between tasks belong to no one in particular.

This adoption process brought with it two side effects that, according to the author, no one planned for. The first is the "token meter": team licenses hid the real cost, and on moving to enterprise plans, consumption-based billing jumps to a multiple of the team plan, just as the big AI labs have cut their list prices by between 20% and 80% since 2023. In other words, each individual token gets cheaper while the company's bill goes up, because what is really missing is a settled price: the labs have not disclosed what it costs them to serve a token, and buying companies do not yet know how much they are willing to pay for one. The author notes that the disruptions he hears about most this year have nothing to do with the model failing, but with access: teams hitting a credit ceiling, per-seat budgets colliding with consumption-based billing, tools going dark mid-meeting because no one was watching the card paying for them. As he reports, providers themselves have already begun to soften that jump by offering a "transition credit": a year of subsidized credit on moving to an enterprise plan, betting that the customer will learn to manage real consumption before the subsidy runs out. The piece also points to a change in the billing unit, from "per seat" toward models that combine seat and consumption or that bill per unit of work (it cites Microsoft and Salesforce's agents as examples, and a Gartner projection of strong growth for this model between now and 2028); providers have already decided what the unit is, but, according to the author, it is much less clear which budget that spending ends up landing in.

The second side effect, quieter but more important according to the author, is precisely that ceiling on scope: productivity gains stay trapped within each person's role, because everyone can only apply AI to the part of the process they can change. That explains why almost everyone feels faster while almost no one can yet prove it with a number. The gains show up first in operational roles, where one person's work translates directly into a measurable figure, and remain invisible in areas where the result only shows at the end of a quarter, such as much of sales, marketing or customer success.

To argue that a real productivity leap requires redesigning entire processes and not just adding AI on top of existing ones, the author draws on several survey findings cited in the article. From a McKinsey survey, he notes that among twenty-five possible organizational levers, "fundamentally redesigning workflows" was the one most associated with AI showing up in financial results, although only a fifth of the companies using AI had done it; in a later McKinsey survey, cited as from this same year, close to three quarters of the best-performing companies had redesigned their workflows, versus only one in four of the rest. As a counterexample he cites the now well-known case of a field study in customer support in which an AI assistant was added to a process already carried out by five thousand agents, achieving a 15% improvement in issues resolved per hour, with the greatest benefit for the least experienced agents; the author explains that this case worked because all the work already happened inside a text window, a condition that does not hold for most of a company's processes. He also reports, attributed to McKinsey and referring to large companies, that 40% are already scaling the use of AI agents but only 37% perceive any impact on operating profit (a figure said to be unchanged from the previous year), and, citing PwC earlier this year, that 56% of executives saw no improvement at all.

A substantial part of the article is devoted to warning about how AI's impact is measured, or mismeasured. The author points to two problems: first, the gains occur person by person and tend to be diluted in the team average, since a few employees usually account for a large share of the work volume; second, and more important, the AI tool itself ends up filling in the very metrics used to evaluate it (notes logged, records updated), so the dashboard improves before the business has actually changed. That is why he argues the reliable metric is a different one: how much additional work a team absorbs without hiring more people, a slower indicator that takes quarters to show up and that must be compared against an equivalent starting point, netting out changes in demand or headcount, and also factoring in the quality of the work and the cost of the AI itself. The author warns that it is normal, even expected, for measured productivity to get worse before it gets better while the redesign is under way, because it is paid for up front in hours of mapping, rebuilding and learning; a flat reading at six months could simply be that intermediate phase and not a final verdict, though only if there is evidence that the already-redesigned pieces are faster or more reliable without shifting the cost elsewhere in the process.

Another block of the article analyzes the trend, still nascent according to the author, of building custom, in-house software for a specific role, a kind of "cockpit" that sits on top of existing systems (it does not replace tools such as Salesforce or Slack, but adds a layer of interaction). The text puts this in historical perspective: before packaged software (SaaS) arrived, companies built their own custom applications; later, renting standardized software turned out cheaper and prevailed for years; low-code platforms have spent a decade selling exactly that partial return to building in-house, giving rise to the "citizen developer" phenomenon. What is genuinely new with AI, the author qualifies, is not that building has become cheaper (low-code already did that), but how far someone without a technical background can get beyond a visual editor. That shifts the key question to the org chart: if the building is taken on by the usual engineering team, you get a faster version of the same process; what would be genuinely different is for the process owner to build the tool themselves with engineers in support, which requires resolving still-open questions, such as how much technical support each tool needs, who reviews what goes into production, what conditions must be met before a team relies on it daily, and when engineering should take over. The author stresses that, for now, almost everything he observes is individual and discreet (someone builds a small tool for their own work and does not even mention it), while custom applications that support an entire team remain rare, more an emerging frontier than an established practice; moreover, writing the code is fast but verifying that it is correct is not, which makes review the new bottleneck, with no resolution as to who is responsible for the tool when its original creator changes jobs.

In the last section included in the available material, the author begins to lay out what he calls the seven steps needed to truly "adapt", of which the text received details only the first two. The first step is to decide, actively and consciously, to invest in redesigning a complete workflow, starting from the premise that AI's value within the old process has a ceiling; unlike adoption, which happened almost by itself, redesign does not happen by inertia and requires an explicit decision. The second step is that this redesign needs an owner with real authority to change the work (someone at the function or area level, able to reorganize people and AI agents around a new way of operating) and a specific budget, since process mapping, rebuilding and training hours represent a real investment that has to be planned for, something that was not needed during the adoption phase, which fit within existing budgets.

It should be noted that the downloaded article content cuts off abruptly mid-sentence, right as that second step is being developed, so the material received does not include the full treatment of the remaining five steps that the article's own table of contents announces (related, according to the section headings, to the unit of work, the two forms of spending, the process map, using more than one model, and the interface), nor the final conclusions section. This summary sticks strictly to what appears literally in the available text and does not fill in or speculate about those missing parts.