Getting everyone using AI isn't the same as getting value from it

Almost every AI programme measures the same thing: how many people are using it. It is the easiest number to get and the one most likely to be on the slide. It also stops predicting anything useful almost immediately.

Getting everyone onto a chatbot is a starting line. The companies that will get paid for AI are not the ones where the most people use it. They are the ones where it goes deepest into the actual work, and where the quality of what comes out is measurably going up.

Those are different projects. Most companies are only running the first.

The chatbot ceiling

Watch how AI is typically used in a company that has rolled it out broadly. Someone has a task. They open a chat window, describe the task, get an answer, read it, judge it, copy the useful part into the real system, and fix what does not fit.

That is genuinely useful. It is also structurally limited, because the human is still doing all the work of moving information around. They fetch the context, they carry the output, they do the checking. The model contributes thinking to the middle of a process a person is still operating end to end.

This is the chatbot ceiling, and you hit it quickly. Once everyone in the company is asking good questions and getting good answers, you have captured most of what that shape of usage has to offer. Adoption keeps rising. Return flattens.

The interesting question is not how to get the last 20% of staff onto the tool. It is what happens when AI stops answering and starts doing.

What depth actually means

Depth means AI completing a piece of work end to end, inside the systems where the work lives, to your organisation's standard.

Two things made that practical, and neither is the model getting cleverer.

The Model Context Protocol (MCP) is an open standard for connecting AI to tools and data sources. It is the difference between an assistant that can tell you how to update a record and one that can read the record, apply the rule and write the result. Once a model can reach the systems, the ceiling above moves a long way up.

Agent Skills are folders of instructions, scripts and reference material that a model loads when the task in front of it calls for them. A Skill is where the part that is specific to you goes: your format, your thresholds, your escalation rules, the four things everyone forgets, the way your regulator expects it presented.

Put those together and you get something the industry has wanted for thirty years and kept failing to afford.

The part that should interest a CFO

Here is what actually changes, in budget terms.

Automating a business process has always been a software project. Someone writes a requirement. It joins a backlog. It gets scoped, estimated, prioritised against everything else, built, integrated, tested, and maintained forever. Realistically that is weeks to months and tens of thousands of pounds, which sets a floor on what is worth automating at all.

Below that floor sits almost everything. The weekly reconciliation that takes a person half a day. The report that gets rebuilt by hand each month. The intake triage nobody has time to formalise. Each one is too small to justify a project and collectively they are enormous. This is where most of the drag in a company lives, and it has been economically untouchable.

MCP and Skills move the floor. Describing a task and connecting it to the systems it touches is not a software project. It is closer to writing a good procedure note, and the people who understand the task can do it themselves.

So the set of things worth automating expands, and it expands in exactly the region where the unglamorous, unmeasured, genuinely expensive work has been sitting all along. No headcount reduction required for it to pay, incidentally. Half a day a week returned to a finance team is a real number, and unlike most AI benefits it attaches to a named process you can point at.

Speed is only half the number

Now the harder half, and the one I think gets skipped.

If output gets faster and worse, you have not gained anything. You have moved cost from a place you were measuring to a place you were not, which is precisely the failure described in our piece on why AI returns go missing.

Software is the one function where output quality can be measured objectively at scale, which makes it the canary. GitClear analysed 211 million changed lines of code authored between 2020 and 2024, and found roughly fourfold growth in duplicated code blocks, with copy-pasted lines rising from 8.3% to 12.3% of the total. Refactoring, the work of consolidating and simplifying what already exists, fell from 25% of changed lines in 2021 to under 10% in 2024. For the first time on record, copy and paste exceeded moved code.

Read that as an operating story rather than an engineering one. Output volume went up. Output quality went down, in the specific sense that each unit of work made the next unit slightly more expensive. The bill does not arrive this quarter. It arrives when somebody has to change the thing.

Software is simply the only place we can watch this happen. Nothing about the mechanism is specific to code: the same pressure applies wherever AI produces a draft that looks finished, which now means proposals, analyses, policies and reports. The difference is that those functions have no equivalent of a commit history, so the quality signal stays invisible until something goes wrong.

Volume of AI output is not a success metric. It is a leading indicator that needs a quality metric next to it.

Quality inside a company is a variance problem

Here is the observation that changed how I think about this.

Give the same model to ten people in the same team and you will get ten very different standards of output. Not because some are cleverer, but because some have worked out how to brief it, what context it needs, what it gets wrong, and when to push back. That knowledge is real, it is hard-won, and it currently lives entirely in individual habit.

Which means the practical question inside a company is not "is the model any good". The model is a constant. The variable is the person driving it, and the spread between your best and your median user is enormous.

Most AI strategies attack this with training, aimed at raising the average. Skills attack it differently and, I think, correctly: they let the best practitioner's method become the thing everybody runs.

Your strongest analyst has worked out how to produce an excellent draft assessment. Today that is a personal habit. As a Skill, it is the default. Everyone's output moves to roughly the standard of your best person's method, not their own. You have raised the floor rather than the ceiling, and the floor is where nearly all of your volume is.

This is also why it compounds in a way that training does not. A Skill can be reviewed, corrected and improved once, and everyone gets the improvement immediately. A prompting course improves the people in the room, decays, and has to be run again for new joiners.

Anthropic's own usage research points at the same bottleneck from the other direction. Its analysis of enterprise API traffic found businesses use AI overwhelmingly for automation rather than back and forth assistance, with 77% of API transcripts showing automation patterns against 12% for augmentation, and noted that sophisticated deployment appears to bottleneck on organisations' ability to centralise dispersed contextual data.

That is the whole thing in a sentence. The constraint on deep AI use is not model capability. It is whether your organisation can gather up what it knows and put it somewhere the AI can use it. A Skill is a unit of exactly that.

What to measure instead

If breadth is the wrong number, these are better. None require a new platform to start.

1. Share of a task completed without a human moving data. The clearest single indicator of depth. If a person still copies output into the system of record, you are at the ceiling.
2. Repeat usage of defined Capabilities. A published Capability run 400 times last month is a real result. A chatbot opened 400 times is an activity metric.
3. Rework rate. What proportion of AI output needs substantive fixing before it is used? Track it over time. If it is not falling, quality is not improving and speed gains are being spent invisibly.
4. Spread between best and median. Sample output across a team. A narrowing spread means your good practice is actually propagating, which is the whole game.
5. Time from someone inventing a good method to everyone having it. Currently, in most companies, infinite.

That last one is worth sitting with. In most organisations there is no route at all from "one person figured out something excellent" to "the team does it that way now". No mechanism, no owner, no timeline. It happens by accident, at lunch, or never.

The short version

Breadth was the right first move and it is nearly finished. Everybody has the tools. Very little of the value has arrived, because access was never the constraint.

Depth is the second move, and it needs three things: AI connected to the systems where work actually happens, your organisation's own standards written down somewhere the AI reads, and a quality metric sitting next to every speed metric so you can tell the difference between faster and better.

That is what Connor is built around. Take the methods your best people have already worked out, publish them as Capabilities the whole team can run, keep them connected to the systems the work lives in, and record every run so you can prove the output is getting better rather than just quicker.

The companies that win the next two years will not be the ones where the most people used AI. They will be the ones where AI did the most work, to a standard that kept going up.