AI adoption is measured by what changes, not what ships

The announcements that landed today keep circling the same distinction: the gap between adopting an AI tool and actually changing how work gets done. A licence bought is not a task finished, and the studies and awards below all measure value at the point where work is completed and data is joined up, not at the point where a tool is switched on.

That distinction matters more than it sounds, because it changes how you should read any vendor's claims when you are choosing software. "We rolled out AI" tells you almost nothing. What you want to know is whether a task that used to take a person an afternoon now takes them ten minutes, whether the second draft is closer to final, and whether the data the tool needs is actually reachable. Everything below is a way of testing that question against the day's news.

The last mile between a draft and finished work

The most useful frame today came from a Dropbox-sponsored study of professionals who already use AI at work [1]. The headline finding is about a gap: AI is now often where work *starts*, but getting from that start to something you can send, publish, or file still takes manual effort. That final stretch — the checking, the corrections, the missing context, the judgement about what is good enough — is the last mile.

The concept is worth understanding on its own terms. A generated first draft compresses the blank-page problem, which is real and valuable. But the cost of a task is rarely the blank page. It is the reconciliation: does this number match the source, does this tone match the customer, is this claim one we can stand behind. Those steps do not disappear when a model writes the first version. Sometimes they grow, because now someone has to read the draft closely enough to catch a confident mistake.

For a business choosing tools, the practical test is simple. Ask a vendor not "can it produce a draft" but "what does the last mile look like here." Where does the output land, who reviews it, and how much rework does the review usually require. A tool that produces a plausible first pass but leaves a long, manual last mile has moved the work, not removed it. This is the same reasoning we wrote up in what AI should and should not do in your business: the useful line is between drafting and deciding, and the deciding stays with a person.

Why "we rolled it out" is not evidence

Zapier published its 2026 Zappy Award winners today, and the framing is a good antidote to rollout theatre [2]. Most organisations, the piece argues, still count AI by inputs — seats bought, licences assigned, pilots launched. Those numbers prove a company has started. They do not prove anything about whether the work changed.

The teaching point is about the difference between an activity metric and an outcome metric. Seats assigned is an activity metric: it is easy to gather, it goes up reliably, and it is almost uncorrelated with value. An outcome metric is harder — tickets resolved per person, days to close a book, hours reclaimed on a recurring report — but it is the only kind that answers the question you actually care about. When you evaluate your own AI spending in six months, the honest measure is not how many people have access. It is what a specific process now costs in time and error.

This is worth building into how you buy. Before you sign, write down the one or two outcome numbers you expect to move, and the baseline they sit at today. If you cannot name them, you are buying activity. We covered how to pick those numbers in what to measure in the first 90 days, and the discipline is the same whether the tool is AI or anything else.

Start from the work, not the tool

A companion Zapier profile makes the same point from the inside of one company. Writing about an AI adoption lead at Jobber, the piece observes that organisations "often start with what they rolled out: the model, the license, the training program, or the pilot" [3] — and that the more productive starting point is the work itself.

The idea is an ordering. If you begin with the tool, you go looking for problems it can solve, and you tend to find shallow ones. If you begin with the work — the task people dread, the report that eats every Friday, the follow-up that slips — you can ask which part of it is genuinely repetitive and rule-bound, and only then whether software should take it. This is the test we laid out in how to tell whether a task should be automated: automate the parts that are stable and high-volume, and leave the parts that need judgement to a person. Starting from the work is what keeps you from automating the wrong thing quickly.

When software starts absorbing services

The funding news of the day sharpens the build-versus-buy question. Ema, an enterprise AI company, raised a fresh round and now reports having "raised $140 million to date" with "more than 50 enterprise customers, including Google and Microsoft" [4]. The framing around the raise is that AI is beginning to absorb work that used to be sold as software licences *and* as human services.

For a buyer, the useful lesson is not about one company's valuation. It is that the boundary between "a tool we license" and "a service we hire out" is moving, and that changes how you should scope a purchase. When a product promises to do work that you currently pay people to do, the questions get sharper: who is accountable when it is wrong, what does the handoff to a human look like, and can you get your data and your process back if you leave. A tool that quietly becomes the only place a workflow lives is a dependency, not just a subscription.

Joined-up data is the precondition, not the feature

The last item is a reminder that most AI value depends on something unglamorous. Salesforce described how two universities are using AI agents, noting that "By using AI to connect fragmented data and handle routine tasks, colleges can rethink how they support students in their educational journeys" [5]. The interesting word is *fragmented*.

An AI agent is only as good as the data it can reach. If a student's record lives in five systems that do not talk to each other, an agent has to be pointed at all five, or it answers from a partial picture. The same is true in any business: an assistant that can see the CRM but not the support history will confidently give half an answer. This is why the connective work matters before the clever work, a point we made in why your tools do not talk to each other. The agents get the headlines; the integration is what makes them worth having.

Running through all five items is one instruction for anyone choosing tools this week. Do not buy the rollout. Buy the change — and make sure you have written down, in advance, the specific work you expect to be different and the number that will tell you whether it was. Yesterday's edition, the SaaS daily briefing for 22 September, made a related case, and the two read well together.