Essay · October 2026
AI adoption was the easy part
What adopting AI meant, what adapting to it takes and how to go about it, from someone doing it inside a business every day in San Francisco.
This is my boots-on-the-ground perspective on what adopting AI has meant inside businesses and what adapting to it will take from here. It's built to be skimmed, with expandable detail under each section.
I wrote it to synthesize where I think we are in the adoption cycle of this technology, and to share it in a way that's useful. It's about the operating side, how AI gets applied inside companies and changes the work, not the model race or how individuals use it on their own. My hope is that this piece could lead to some good conversations.
For context, today I lead AI operations and adoption at Canary Technologies, a growth-stage startup in San Francisco. I work with these tools every day. These views are my own.
g@gurtejgill.com LinkedInThe big picture
Adoption is largely done. The payoff comes from adapting to the technology, and that climb has barely started.
The last three years were about adopting the technology, and the flight draws where that got us. What comes next is a different job, adapting ourselves to it. Most of the AI-forward companies I see have lifted off and not yet begun the climb, and everything in this piece flows from that transition.
Adopting is getting the technology into everyone's hands, connected to the company's data and used every day on real work.
Where adoption stands, and why it was the easy part
Code went first, last year, and the rest of the business followed this year. Proficiency is still building, and people are doing remarkable things with it already, but at the AI-forward companies I see that part is largely done. It was the easy part, because none of it changed the work underneath.
Adapting is changing the way we work, the way the business runs and the way the technology itself functions, until the gains show up in the numbers.
What the climb is for, and how far along it is
The gains a technology like this is supposed to produce, in productivity, in earnings, eventually in GDP, haven't shown up materially yet. I think they will, and the way there is the climb. Cruising altitude is the new steady state on the other side, and almost all of the climb is still ahead of us. That is where the work is.
What adoption was
Adoption happened in layers, each one on top of the last, and none of them changed the work underneath. That is what made it fast, and it is also why the gains from it have a ceiling.
Access, connectivity, use, application.
Companies gave employees access, a team plan and a login. They set up the MCPs and connectors so the model could reach the data. People started using the tools, a model open all day and the prompts and skills that stick passed around by hand. Then they applied the tools to their own work, a skill here, a small tool there, the pieces of a job a person can reach. At the AI-forward companies I see all four are in place, and larger and slower companies are working through the same four. The approach was to give everyone access and let a thousand flowers bloom, and it was the right first move.
Redesign is where the earnings show up
On the ground
Walk into most companies in San Francisco and the usage is already there, and what spread was almost never what leadership pushed. The pull was real, and the job was noticing it more than driving it.
In the world
When McKinsey's 2025 survey set twenty-five organizational moves beside whether AI shows up in earnings, fundamentally redesigning workflows was the one most associated with it, and about a fifth of the companies using AI had done it. The 2026 survey has nearly three quarters of the high performers redesigning workflows, against one in four of everyone else. The counter-example is customer support, where the best-known field study put an assistant inside the process five thousand agents already ran and found a fifteen percent lift in issues resolved per hour, with the least experienced agents gaining the most. Bolting it on works when the work was already a conversation in a text box, and most work isn't.
The meter came with the layers, and nobody knows what a token is worth yet.
Adoption's bill arrived before its return did. Team plans hid what it costs. Cross into enterprise and the meter turns on at a multiple of the team plan, right as the labs cut list prices at the top. Every token got cheaper and the company's bill went up. That is when spend, ROI and the token budget entered the conversation, as byproducts of adoption rather than anything anyone planned. Underneath is a market with no settled price. The labs are still working out what it costs them to generate a token, buyers are still working out what one is worth, and this year's pricing is both sides trying to find the number.
Where the meter shows up, and what the transition credit tells you
The interruptions I hear about this year are almost never about a model being wrong. They're about access. A team gets going and hits a credit ceiling. A budget sized for seats meets metered usage. A tool runs on a card nobody owns and goes dark mid-meeting. Somebody ends up owning the meter by default, because nobody else is watching it. And the vendors know the cliff is coming, because they've started softening it. The structure I'm now hearing about is a transition credit, a year of credit against metered billing when you move to enterprise, and then your real spend begins. That's a subsidy with an expiry date and a bet attached, that you'll grow into the meter and learn to manage it before the year is up.
The gains landed inside each person's scope, and that is the upper limit of what adopting alone can do.
The byproduct that matters most is the quietest one. A person can only apply the technology to the part of a process they can change, and that part is set by their job, so the gains are real and local by construction. Everyone I talk to feels faster, and almost nobody can show it in a number yet. The gains are clearest where the person doing the work can change the work and the output is countable, which is why operational roles see it first. Where the work is relationship-shaped and the number only lands at the end of a quarter, which is most of sales, marketing and customer success, it is still invisible. Some people went further and built their own software for one job, and that is the scope ceiling again, a person building for the piece they own.
It's an attribution problem before it's a value problem, and a scope problem before that. A thousand improved pieces never add up to a redesigned process, because nobody working inside it has the authority to change the whole. Adoption keeps going past this point, and people keep getting better with the tools. What tops out is the return, and the sharper risk on the far side of the ceiling is a team running the wrong process faster and better than it ever has. The step change is on the other side, in adapting.
Why the first honest read is usually flat, and who built their own tools
The gains land person by person and then hide in the average. A sales floor gets a new skill and the roster average barely moves, because a couple of reps carry half the volume and the spread between reps is wider than any lift you'd expect.
The second problem is that the tool writes the numbers you would grade it on. An assistant drafts the call notes, updates the record, sends the follow-up. Notes logged goes up. Records touched goes up. Those are the numbers plenty of teams already use as their productivity proxy, so the dashboard moves before anything about the business has. The proxy was never very good, and now the tool is the one filling it in.
So the measure I would trust is one the tool cannot write into. How much more work did the team absorb without adding people. It is slower than any dashboard, it takes a couple of quarters to read, and it is the one a finance team will believe. Even that number needs a comparison, the same work before and after or one team beside another, because demand or staffing can move it without the tool being the reason. And it has to carry quality and the AI bill alongside the people time.
Expect it to get worse before it gets better. The redesign is paid for up front, in the mapping and the rebuilding and the hours people spend learning a new way to work, and the gains arrive after that. Measured productivity dips through the middle of it and then turns. A flat read six months in is what that middle looks like, not a verdict. That holds only if the pieces you have rebuilt are getting faster or more reliable without pushing cost or rework somewhere else. If that evidence is missing, waiting longer is not a strategy.
The ones who built their own software
Some people went one layer further and built the interaction layer that sits on top of the systems of record, purpose-built for one job, with the automations and skills embedded in it. Not Salesforce or Slack rebuilt, a cockpit for one piece of work. Building one got cheap enough to be worth trying, and whether it moves productivity is still being tested. The part being worked out is where on the org chart this happens. For twenty years the answer was engineering, and it is not only engineering now.
Companies used to build their own software, and a lot of real work ran on it. Payroll, inventory, order entry, custom because there was nothing to buy. Then packaged software arrived and renting beat building, so you took the fit you could get and saved the cost of the build. That trade was right for a long time.
Two qualifications. Building never went away, it narrowed. Companies bought the commodity systems and kept building the parts they competed on, and the internal tools team has been a fixture that whole time. And the swing back did not start with AI. Low-code platforms have been selling exactly this for a decade, an interaction layer over the systems of record put together by someone closer to the problem than engineering, and the industry was writing about citizen developers by the mid-2010s.
So what changed is not that building got cheap, because low-code had already done a lot of that. It is how far past a drag-and-drop canvas a non-engineer can now get. That pushes the open question off the tooling and onto the org chart.
Hand it to engineering and you have a faster version of the team you already had, which is a real gain and the same process. The new thing is a non-technical owner building it, and that only becomes real when someone answers the unglamorous questions. How much engineering support does one of these need. Who reviews what ships. What has to be true before a team can depend on it every day. When does engineering have to take it over.
Most of what I see today is individual. Somebody builds a small thing for their own job, uses it daily, and never tells anyone it exists. The company-level version, a purpose-built application for a role that a whole team depends on, is rarer than the conversation suggests. I am honestly not hearing many of them. This is the frontier edge, not a practice yet.
Where the cost moves surprises everyone. Writing the thing is fast, and knowing it is right is not. Review becomes the bottleneck, automated checks pass code that a person catches, and builders often say they understand the logic without being sure they built it well. Then comes the question nobody has answered, who owns the tool when its builder moves on.
Then you land back at the meter and the average. You built the thing, and now you have to show it did something. That is the same attribution problem with the same weak proxies. Then somebody asks which budget paid for it and which budget carries it from here. Building in-house is where the spend question and the measurement question turn out to be one question.
What adaptation takes
The climb has an order to it. Redesign the workflows is the consensus answer. Under it sit six more steps that are not settled yet, from who gets to change the work to what the person doing it will be looking at. This is the order I would run them in.
Step 1Decide to invest in redesigning the work, because the value of AI inside the old workflow is capped.
Layering AI onto the work as it was got us to lift-off. It also has a ceiling built into it, because each person can only change the piece of the process they own. The step change comes from redesigning the work end to end, and unlike adoption, that does not happen on its own. Someone has to choose it. Take a workflow from one end to the other and ask whether you would still design it this way now that AI exists. If the answer is no, decide to invest in the rebuild. The next six steps are how.
Why a thousand flowers can't add up to a redesign
Bottom-up adoption was the right way in, and the ceiling is structural. Everyone improves the piece they can reach. The seams between the pieces, where a lot of the waste in a process lives, belong to nobody. A rep can automate the notes. The rep can't decide that the notes, the handoff and the follow-up are one piece of work an agent runs overnight, because three other teams touch it.
It is also why the individual and the company versions of building your own software look so different. A person can build for the piece they own in a weekend. A tool a whole team depends on needs someone who can change the team's work, which is the next step.
Step 2The redesign needs an owner, and the owner needs a budget.
That has to be done by someone who can change the work. That puts it inside a function, at the level where people and agents get reorganized around a new shape. It is a different kind of work from picking up a tool, and it is not free. The mapping, the rebuilding, the agents themselves and the hours people spend learning a new way to work are a real investment. An investment has to be planned and budgeted before anyone can make it. None of that was true of adoption, which fit inside budgets that already existed. The redesign is the first time the technology needs a plan of its own.
When factories first got electricity, most swapped the steam engine for one big motor and kept the shaft and the belts. The productivity numbers barely moved for thirty years. No machinist could take the shaft out. Someone with the whole floor in their remit had to. When they did, the shaft came out and the floor was laid out in the order the work flowed. The numbers finally moved, in the 1920s.
Who sits in the seat, and the factory that learned it first
That decision sits with whoever owns the process, a function head, a COO, sometimes a general manager. It means mapping what the process actually is, deciding what it should be, and reorganizing people and agents around the new shape. The organizations I see making progress have put someone in that seat on purpose. The ones that haven't are adding up local gains and wondering why the total doesn't move.
The factory that bought a motor and kept the belts
Factories learned this the slow way. Steam ran a whole plant from one engine, which turned a single shaft down the length of the building. Every machine hung off that shaft on belts. The floor had to be laid out around the power, machines crowded close to the line and stacked on several storeys to share it, all of them turning whenever the shaft turned. When electricity arrived in the 1890s, most factories swapped the steam engine for one big motor and kept the shaft and the belts. Same layout, new power source, and the productivity numbers barely moved for thirty years.
The change came when motors got small and cheap enough to sit inside each machine. The shaft came out, and the floor could be arranged in the order the work actually flowed, spread out on one storey. Each machine drew power only when it ran, and stopped without stopping everything around it. The technology had been in the building for decades. What was missing was the redesign it made possible, and once the redesign happened, the numbers that had sat flat for thirty years finally moved.
Step 3Plan in units of work, and let the token become an input to the price.
Work doesn't get reorganized until it's in a plan with a number next to it, and the number answers two questions. How much are we willing to spend on this right now, and where are we willing to spend it. Today the number is tokens, because tokens are the unit we have. They are the electricity bill, useful to read and the wrong thing to plan against. Budgets are set against work, the jobs and outcomes and tasks. That is where this goes next, upstream of the token to some unit of work a company can model and price. The token becomes one input to that price, the way power is one input to the price of a finished part.
What the unit might look like, and why the annual plan is the wrong instrument
What has to exist before anyone can plan it is a unit. Cloud eventually got one, and it still took years before a finance team would treat the number as real. Intelligence spend has no agreed unit yet, which is the same hole the meter leaves open. A price per token is not it. The cost of a finished job carries the retries, the review and the model you chose, and that is the number a plan needs. My guess is the first companies through this invent something local and imperfect, work absorbed per month or jobs run per process, and defend it anyway. A rough unit somebody owns beats a precise one nobody does.
Cloud is the closest precedent, and what it teaches is a discipline. On the internal side it never got a line of its own. What it got was machinery. Tagging, showback and chargeback, a way to trace a bill back to the team that ran it, and eventually a named function to run all of that. What forced that function into existence was a mismatch in cadence, budgets set once a year against usage that moves every week, driven by whoever is most enthusiastic. Intelligence spend has the same mismatch, and an annual planning process is the wrong instrument for it whichever unit it ends up in.
Step 4Budget it in two shapes, agents that augment people and agents that run on their own.
Once there is a unit, the budget splits into two shapes, and both matter in the future state. Agents that augment a person, the harnesses and skills somebody has open all day, scale with how many people you have. They will most likely stay tied to labor spend in some form. Agents that run on their own, doing volume unrelated to how many people you employ, scale with how much work you send them. My call is that those get a budget line of their own, sized off the volume of work and defended by whoever owns the process. Nothing on the shelf was built to hold them. All of this is being figured out now, and it is where the price of the work settles as the market matures.
If a year from now nobody is forecasting agent work off the volume of work, by jobs run or work absorbed or something like it, I had the split wrong.
Why tooling is the wrong shelf, where the price settles, and what would prove me wrong
Tooling is where this lands today, because it is the nearest shelf and somebody has to close the budget. A tooling line was built for software you buy by the seat, renew once a year, and size by how many people need access. Agent capacity has none of those properties. You buy it by the unit of work, it moves every week, and the number of people involved tells you nothing useful about it.
The work itself already comes in a few shapes. Scheduled jobs that run a process end to end with nobody in the loop. Agents that keep working while you're offline instead of a copilot that waits for you, the shape the OpenClaw crowd has been living in for a while. And now agents with a computer of their own. Grok Bot took that shape to enterprise in September, so the work an agent can pick up is no longer limited to what an API exposes. None of them need to grow with headcount, and today all three land on the same tooling line.
Where the price settles
The price of the work is the half nobody has yet. Over the next six months the supply side opens first, when a frontier lab puts audited financials on the record and the cost of running this business stops being a guess. One lab filed a confidential registration in June, picked its exchange, and is working toward a listing inside this window, market conditions permitting. What a filing gives you is not a per-token cost, and anyone expecting a prospectus to print the price of a thousand tokens will be disappointed. It gives cost of revenue and a gross margin across a whole product mix. On the analysts' estimates, paid inference margins have moved from the low teens last year into the fifties and sixties this year. Roughly thirty-five to forty dollars of every hundred a model company earns goes back to the three large clouds. You can reason about a business from that even without the unit.
The demand side opens slower. Most of the enterprise deals I hear about carry a credit, a flat seat, or a rate somebody set to win the logo. Few buyers have had to say out loud what a token is worth once the discount is gone. The first renewals at a metered price are the real experiment, and they run through the next six months. When they settle, the number stops being a guess and a finance team will let you plan against it. Each of the two shapes above gets a price.
What would prove me wrong is the plainest outcome, which is that this stays inside labor budgets for good, as a percentage on top of what a team costs. That happens if autonomous agents turn out to be mostly attached to people after all, running errands on somebody's behalf rather than running a process on their own. I don't think that is where it goes, and a year is long enough to find out.
Step 5Map the work from the trigger to the delivery, and find the nodes.
From there it is about understanding what the new units of work are, and this is new territory. Manufacturing mapped its work down to the station decades ago, and most knowledge-work businesses have never done it. The map runs across the core work streams of the company. It follows a piece of work from the trigger that starts it, through triage, execution and review, to delivery. Along the way it marks the nodes where the work actually happens. Every node needs its context written down, where the data lives, what the process actually is, what a good result looks like. It will be complicated and probably messy, and it is what makes the next call possible, which nodes get an autonomous agent and which get a person with one.
The way through is piecemeal
On the ground
The agents are genuinely good at helping build the map. Every team I've watched start this has underestimated it, mine included.
The way through, as far as I can tell, is piecemeal. Take a job apart into the pieces of work inside it, write down what each piece needs to know, hand one piece to an agent and see if it holds, then do the next one. That's the next couple of quarters for most of us, and it's a lot less glamorous than the demos.
The context is the part that has been buried. Where the data lives, what the process actually is, what a good result looks like. Most of it has been out of date for years or lives in someone's head, and now it is what stands between a company and agents that can run its work. A company that can't map its own process can't show what the agent did for it either, which is where the ROI conversation goes next.
In the world
The last time businesses set out to redesign work from the ground up was reengineering in the nineties, whose own authors reckoned that half to seventy percent of the attempts never got the dramatic result. The tools are far better this time, and the map still has to be drawn by the people who know the business.
Step 6Build the agents so the market works for you, on more than one model.
As the nodes get defined, the next investment is how the agents run and how people will work with them. The architecture is worth building flexibly on purpose. The best model changes every few months, and the frontier labs and the open models compete with each other. A company that can move work between them keeps pushing quality up and cost down. Today an agent tends to live inside one lab's harness, Anthropic's or OpenAI's, with the MCPs, the access controls and the context it runs on. Right now that is the best place for the work that augments a person, and a lab has every reason to keep the work there. The work that runs on its own cares less about the harness a person sees. It can run on a horizontal platform like Notion or Glean, or on something homegrown, on whichever model is the most cost-efficient at the quality the job needs.
Build two lanes and keep the work portable between them. Agents and context for the labs' harnesses, where the work that augments a person is done best today. A lane of your own where open models run the autonomous work. Then point each unit of work at whichever lane does it best, and let the tokens follow it.
Both bets at once, and the power analogy
On the ground
Talk to teams in San Francisco and you hear both bets at once. Some are standardizing on a lab's own agent product because it's the fastest way in. Others refuse to be single-model on principle and are building on harnesses that let them swap the engine underneath. The second group has a cost argument that gets stronger every time an open model closes the gap. After a summer where a flagship was switched off by government order for nineteen days, they have a resilience argument too. The horizontal work tools, Notion and Glean among them, are building toward the same layer. None of them yet moves at the pace of a lab shipping into its own harness.
In the world
Over the summer one lab folded its coding agent and its work agent into a single desktop app, then open-sourced the harness underneath. Another shipped an agent with its own computer for twenty dollars a month. A third bought the leading AI code editor outright for sixty billion. The labs have also started pulling access from rivals. Anthropic limited Windsurf in June 2025, cut off OpenAI's access to Claude a month later, and in January shut third-party tools out of Claude subscription logins. In August, weeks after that code editor changed hands, OpenAI said it will pull its models from it in November. Four times in fifteen months, every one aimed at a surface the lab doesn't own. The labs are buying the interface, which is why I'd keep the model swappable.
The routing, and why as code
The lanes have to exist before the routing can, which is why I'd build every agent as code in a repository you own and keep the context and the integrations yours. Once the work is scoped, budgeted and allocated, you point each unit of it at whichever lane does that job best. Quality, cost and speed decide. Swapping the model still takes testing and sometimes rebuilding, but you start from something you own.
If there is an analogy
It is the power one again. A plant that can draw from two utilities and its own generators sends each load to whichever source is cheapest and most reliable that hour. It can only do that because the machines are its own and the wiring is standard. The models are the power. The work and the wiring are yours, and that is the part worth owning.
Step 7Build the interface for the role.
Today most people are working inside a chat window, and they largely manage their own process and their own use of the technology. A skill is a package of context. It only works when people know it exists, know when to call it and keep it current. That is the same upkeep problem every process document has always had. In a world adapted to the technology, I believe people will have a single interface, or a few, through which they do their role. The context, the skills and the process live inside those interfaces, maintained by whoever owns the process. We don't need everyone designing their own processes, and the most AI-native and operationally minded people will anyway.
The end state looks a lot more like the applications we already have. An interface built for the role, probably shaped like a traditional SaaS app, that the company builds and maintains for the people who were never asked to design their own process.
Why the company version changes and the personal one doesn't
In May I wrote that skills were the leverage layer, and for an individual I still think that's right. The skills that stay personal are the ones you write for yourself, like a morning brief laid out the way you like it. For an organization the leverage is moving into the interface, and skills become the plumbing under it.
The reason is who has to do the building. Tools and process have historically been an operations or engineering job, and the people in sales or customer success were never asked to design the workflow they run. Where this goes is a tailored interface for the role, with the skills and context maintained underneath it by whoever owns the process. Whether that keeps the shape of a traditional application or turns into something new, the context gets embedded deeper into it as it matures.
The parallel I keep coming back to is the personal computer. For its first years the way in was a terminal, and the people who got the most out of it were the ones willing to learn its commands. The graphical interface didn't make the machine more capable. It made the capability reachable for everyone else, and the machine stopped being a specialist's tool. A chat window is the terminal of this technology, and the same move is coming.
The platforms are already moving the interface. Generated interfaces that build the screen for the task are shipping from three labs. The protocol layer under agents went GA this summer with an explicit contract for carrying them, and voice agent builders are a product category. Each of those is a way to take an action without knowing which skill to call.
Work through those seven steps and the way we work, and frankly the way we live, ends up far more integrated with this technology than it is today. That is where the large productivity growth is, and a company can start toward it now. It has to be done intentionally, because it is not a trivial change to manage, and the ones that move first will have a sizable advantage. Lift-off happened to everyone at once. The climb is done on purpose, one process at a time.
Takeaways
In summary, here are some of the key takeaways when you weave the threads of this piece together. I've linked the threads under each one so you can see how they fit, but mostly I wanted to consolidate them in one place.
Adoption put the technology in everyone's hands and left the work underneath unchanged.
Three years of adoption gave everyone a model, connected it to the data and got people using it every day. None of it changed how the work runs, which is why the gains have not shown up in productivity, earnings or GDP yet. The payoff is on the other side of the climb, and the climb has barely started.
The thread · The big picture to The four layers
The value of AI shows once it is no longer capped by each person's scope. Look for it in the outcome numbers a tool can't write.
Today the gains are real and local, because each person could only improve the piece of the process they own. Once the work is redesigned end to end, the gain belongs to the whole process, and that is when it can show in a number that matters. Watch the outcome numbers no tool fills in for you, work absorbed without adding people, deals closed, tickets resolved. Expect them to dip through the redesign before they turn, so read flat at six months as the middle, not the verdict.
The thread · The ceiling to The decision to invest
Adaptation is organizational. It needs an owner, and the owner needs a plan.
Redesigning work end to end is a different kind of work from picking up a tool, and it is not free. Someone with the authority to change the whole has to own it and treat it as the investment it is. Plan it in units of work rather than tokens, and budget it in two shapes, agents that augment people and agents that run on their own.
The thread · The owner, and the budget to The unit of work to Two shapes of spend
Map the work before you change it, then redesign it one node at a time.
Most knowledge work has never been mapped the way a factory floor was. Draw each work stream from the trigger to the delivery, mark the nodes, and write down what each one needs to know. Then hand one node to an agent, see if it holds, and do the next.
The thread · The map
Build for more than one model, and build the interface for the role.
Build two lanes and keep the work portable between them. The labs' harnesses take the work that augments a person, and a lane of your own takes the autonomous work. Then build the interface for the role, with the context and the skills living inside it, so nobody is left running their job from a chat window.
The thread · More than one model to The interface
Start the climb now, on purpose.
Lift-off happened to everyone at once, and the climb is done one process at a time. It is not a trivial change to manage, and the companies that move first will have a sizable advantage. Work through the seven steps and the way we work ends up far more integrated with this technology than it is today.
The thread · The big picture to The seven steps
Thanks for reading. If any of this was useful, or you think I've got something wrong, I'd love to hear it.
g@gurtejgill.com LinkedIn