You Can't Buy the Value of AI. Your People Have to Find It.
Nate B. Jones made an argument this week that deserves a wider hearing than the AI strategy crowd. In a video on how companies buy AI, he says procurement teams are stuck on the wrong question. Per seat or per token only tells you how the bill is metered. The real question is whether your company knows where to put the intelligence it has bought, and most don't. "So much of the value in that intelligence," he says, "needs to be discovered by the human using it."
He is right. And the problem he describes is not new. It is the oldest problem in human factors: a capability arrives, and its value depends on how well it fits the people and the work it lands in. The discipline has spent more than seventy years on that fit, and it has methods for it. This article lays out Jones's position fairly, shows where human factors, systems design, Safety Differently and learning teams take it further, and describes how we use those methods to do what he is asking for.
Key takeaways
Jones is right that the value of AI is found after the purchase, in the work, by the people who do it.
His "missing know-how" is the gap between work as imagined and work as done. That gap can be mapped before you buy.
"Allocating intelligence" is function allocation, a design decision with well-known traps. It should not be left to each person to work out alone.
Asking every employee to become a "manager of AI" moves the burden of finding value from the company to the individual, the same way a usage contract moves it from the vendor to the buyer.
Learning teams make that discovery routine: the people who do the work map it, help decide where AI belongs, and check what changed afterwards.
None of it works where people are not safe to say what they know. A program framed as headcount reduction closes that door.
What is Nate B. Jones actually arguing?
His case runs in four steps. First, AI is a new economic input. For as long as there have been companies, he says, there have been two inputs, people and capital. Now there is a third, intelligence, and seats and tokens are old boxes for it: "Tokens are a way to meter compute. Seats are a traditional SaaS measure."
Second, buying it is the easy part. "You can buy the capability before you've learned which work to assign to it, before you've learned how to change the surrounding processes, or even before you've learned how to tell when an answer is good." A model can be very impressive in a demo, he says, "while an organization remains very poorly equipped to use it." The usual contract leaves that burden on the buyer.
Third, know-how is the bottleneck, and there are a few ways to get it: forward-deployed engineers who work inside the customer's operation, deeper partnerships with suppliers, and outcome pricing where the work is a closed loop, like a patient calling at 2 a.m. to have a bill explained and paid.
Fourth, and this part is aimed at the viewer, every one of us is now allocating intelligence. His example is an engineer at an equipment company who notices a failure customers keep reporting. An agent can pull the maintenance records and compare earlier cases. The engineer knows which operating conditions matter, "which records are not reliable," and when an apparent pattern is really two different faults described in the same language. Across enough cases, the team starts to see a service the company could sell. His advice to individuals is to become "managers of intelligence before anyone gives us a management title." His advice to leaders is to stop treating AI as a cost-cutting exercise, put a team on revenue work they could never resource before, and see what comes back.
Where is he right?
On almost every diagnosis. The value of AI really is found in use, not in the purchase. Demos really do outrun operations. He is right that the questions that decide the return are, as he puts it, "people questions": whether people feel motivated, equipped and believed in, and whether they feel aligned to the mission. He is right that the frontline worker, not the steering committee, is usually the first to see where a tool helps, and that "leadership is learning from you." And he is right, and it is good to hear it from inside the AI world, that "we get into the wrong conversational track when we just think about cutting costs."
Where we part ways is on the how. He does say leaders have to work out how to help their people make the right bets and stay aligned, and he calls those hard questions: "Those are not questions you can ask Claude to solve for you." But he leaves them as questions. His practical advice rests on individuals: sharp, motivated people on the front line who teach themselves to direct AI well, and leaders who notice. Human factors would call that a system working by luck. The work is to make it work by design.
Why is the "know-how gap" really a work-as-done gap?
Every workplace runs two versions of the same job. Work as imagined is the version in the procedure, the process map and the vendor's slide. Work as done is what people actually do to get the job finished, safely and on time, with the tools and information they actually have (Hollnagel, 2014). The two are never the same, and the difference is not sloppiness. It is the adaptation that keeps the work running.
Look again at Jones's engineer. Knowing which records are unreliable, and when two faults hide under one description, is not AI skill. It is local expertise, built over years inside work as done, and no model trained on those records can supply it. When a company buys AI against work as imagined, the tool lands in the wrong place, at the wrong moment, asking for information people do not have yet. People quietly route around it. The dashboard still shows logins.
This is why Safety Differently starts where it does: people are not a problem to control but a resource to harness (Dekker, 2014). Our version is simpler. People aren't the problem. They're the solution we build around. The know-how Jones says is missing already exists. It is in the heads of the people doing the work, and the question is whether the organization has a way to go and get it.
Isn't "allocating intelligence" just function allocation?
Yes, and that matters, because function allocation comes with a long record of what goes wrong. Since Fitts (1951) first listed what people do better than machines and what machines do better than people, human factors has learned that deciding who does what is a design decision about the whole system, not a list. The people, the tool, the procedure and the data form one joint system, and it is the joint system that succeeds or fails (Hollnagel and Woods, 2005).
That record includes traps the "manager of AI" framing walks straight into. Bainbridge (1983) called them the ironies of automation: the more routine work a machine takes over, the more the person is left with the hard, rare parts, often with less practice at them. People who supervise automation drift out of the loop and lose the picture they need when the system hands control back. And reliance goes wrong in both directions: people over-trust tools that are usually right and abandon tools that once embarrassed them (Parasuraman and Riley, 1997).
Jones names two of the hardest design problems almost in passing: knowing "how to tell when an answer is good," and knowing when "to stop and talk to a human." In his telling, those are judgment calls each person makes. In a well-designed system, they are designed handoffs. Someone has decided, with the people who do the work, what a good answer looks like, how a wrong one would show itself, and where the tool stops and a person starts. Leave it to each individual and you get a different, invisible allocation at every desk, and no one sees the drift until something fails.
What's wrong with making everyone a "manager of AI"?
There is a neat irony in the argument. Jones points out that usage contracts leave the burden of finding value on the buyer. His advice to companies then does the same thing one level down: buy the licences, hand them out, and leave the burden of finding value on each employee. The champion who figures it out gets noticed. The one who does not, or who is too busy keeping the shift running to experiment, falls behind.
That is fragile in three ways. The learning lives in individuals, so it leaves when they do. It spreads by word of mouth, so it is uneven. And because nobody designed it, nobody can see it, so leaders cannot tell a good allocation from a risky one. In human factors, a system that only works because particular people keep compensating for it is not a strength. It is a warning sign.
His report example is worth keeping, though. Asking an agent to finish the monthly report faster is single-loop learning: the same work, done more efficiently. Asking it to help find why the report keeps showing the same customer problem is double-loop learning: questioning the work itself (Argyris, 1977). The organizations that get real value from AI will be the ones that make the second kind of question routine. That takes a method, not a mindset.
Do forward-deployed engineers close the gap?
They help, and Jones is honest about their limit. Forward-deployed engineers bring technical fluency into the customer's operation and build systems connected to its real data and processes. But they are outsiders, and what they learn tends to leave with the engagement. In his words: "If you just keep it at forward deployed engineering as a service forever and ever, you're probably not learning enough."
The answer is to pair the builders with a structure that keeps the learning inside. Engineers know what the tool can do. The crew, the dispatcher, the claims adjuster and the field technician know what the work needs. A learning team is where those two kinds of knowledge meet, and because the people who do the work hold it, what is learned stays with the organization after the engineers move on.
Why do psychological safety and just culture decide whether AI pays off?
Jones says "it has never been more important to have a motivated team," and frames motivation as skin in the game. We would put it differently. Motivation is not a mood leaders inspire. It is what people conclude from how the system treats them.
Finding where AI belongs means people have to describe their workarounds, admit where they cut corners to keep up, and say plainly when a tool does not work. They will only do that where it is safe to speak up (Edmondson, 1999) and where accountability is fair rather than punitive. If the AI success stories people hear about are headcount reductions, the people you most need to hear from will draw their own conclusions about what happens to the knowledge they share. People do not teach a system to replace them. Jones's warning about cost-cutting is not only good strategy. It is the precondition for the learning he wants.
How do we apply learning teams to AI adoption?
Learning teams bring together the people who do a piece of work to explain how it really gets done, what makes it hard and where they adapt to make it succeed (Conklin, 2019). They come from safety, where they are used after events and, even more usefully, before them. The same structure is the most direct way we know to do what Jones is asking for: find where intelligence belongs, with the people who will use it. This is how we run one around an AI decision.
Start with a piece of work, not a tool. Choose work that matters and that people describe as hard: call intake on a busy night, a recurring warranty failure, month-end close, discharge planning. The question is "what makes this hard?", not "where can we use AI?"
Learning session. Sixty to ninety minutes with the people who do the work. How does it usually go? What makes it hard? Which information can you not trust? What do new people struggle with? What do you do when it does not go to plan? No fixing yet, and no tool demonstration.
Soak time. A day or more for ideas to settle. This is often when the "two faults under one description" kind of insight surfaces.
Design session. The same group, now with the technical people in the room, decides where AI helps, where it adds friction and where it should not go at all. Together they set the allocation: what the tool does, what the person does, where the handoff sits, what a good answer looks like and how a wrong one would show itself. What should stay off limits goes on a Do Not Touch list. A leader with authority to act attends to listen, and responds in writing.
Pre-mortem, then a small pilot in the real workflow. Before the pilot starts, the team imagines it is a year from now and the pilot has failed, and explains why (Klein, 2007). Then the pilot runs in real conditions, on the busy day as well as the quiet one.
Second learning team, sixty to ninety days in. The same people describe how the work has changed: new workarounds, overrides, skills they are using less, places where they now trust the tool too much or not at all. This is the evidence Jones wants for the ROI conversation, gathered from work as done instead of a usage dashboard.
Close the loop where people can see it. What the team learned becomes a change to the system: the workflow, the training, the procurement criteria, the policy. The people who raised it see it happen. That visible response is what makes the next learning team worth attending.
Does this work in a corporation as well as an emergency service?
Yes, and Jones's own example shows why. His equipment company is a corporate story: field engineers, maintenance records, a service the company could sell. The method is the same whether the work happens on a dispatch floor, in an emergency department, on a claims team or in a field service operation. What changes is what is at stake when the allocation is wrong.
That is also where outcome pricing reaches its limit, as he concedes. A bill explained and paid is a closed loop you can count. A dispatcher's call, a patient handover or a customer's rebuilt maintenance program is not. In open, complex work you cannot measure AI by transactions. You measure it by how the work changed, which is what a learning team before and after is built to show.
His suggestion to leaders is a good one: pick a revenue project you could never resource before, put a team on it, and attribute what comes back to AI. We would add two things. Choose the project with the people who would do the work, and run a learning team at the start and again at the end. Then the attribution is evidence, not a story.
What should leaders ask before the next AI purchase?
Alongside the pricing conversation, five questions:
Where has our front line already found value in AI, and how would we know?
Who decides where AI goes in this piece of work, and is that decision designed or left to each person?
How will the people using it tell a good answer from a wrong one, under real conditions?
What happens to the skill the tool takes over, and who still practises it?
Is it safe here to say that a tool does not work?
If those questions do not have clear answers, the next step is not a bigger licence. It is a learning team.
How The Human Factor helps
We help emergency services, healthcare, government and corporations find where AI belongs in their work, with the people who do it. For a team weighing an AI investment, that means a learning team on the work the tool will touch, a design session that sets the allocation and the Do Not Touch list, a pre-mortem and pilot plan, and a second learning team that shows what changed. For leadership teams, our AI Decision Architecture Workshop maps how decisions really get made and where AI fits. Every engagement starts with how your work is really done. Talk to us about the work you are trying to change.
Frequently asked questions
What is a learning team?
A learning team is a facilitated group of the people who do a piece of work. They explain how it really gets done, what makes it hard and where they adapt to make it succeed. It usually runs as two sessions of sixty to ninety minutes with time to reflect in between, and a leader who listens and responds in writing (Conklin, 2019).
How is a learning team different from AI training or a focus group?
Training teaches people to use a tool someone else chose. A focus group collects reactions to a decision already made. A learning team starts before the tool, with the work, and the people who do the work help decide where the tool goes and how its success will be judged.
Isn't this slower than just giving everyone access?
Access is fast. Finding value is not, and leaving it to each person is slower still, because every desk relearns the same lessons alone. A learning team takes a few hours of the right people's time and turns individual discoveries into something the whole team can use.
Do we still need forward-deployed engineers or a vendor's implementation team?
Often, yes. They know what the technology can do. A learning team makes sure they build for the work as it is really done, and keeps what is learned inside your organization when the engagement ends.
What is Safety Differently, and why does it matter for AI?
Safety Differently is an approach, most associated with Sidney Dekker, that treats people as the source of safety and success rather than the main source of risk. For AI, it means designing the tool around the expertise people already have, instead of designing people around the tool.
Sources
Argyris, C. (1977). Double loop learning in organizations. Harvard Business Review, 55(5), 115–125.
Bainbridge, L. (1983). Ironies of automation. Automatica, 19(6), 775–779.
Conklin, T. (2019). The 5 principles of human performance. PreAccident Media.
Dekker, S. (2014). Safety differently: Human factors for a new era (2nd ed.). CRC Press.
Edmondson, A. (1999). Psychological safety and learning behavior in work teams. Administrative Science Quarterly, 44(2), 350–383.
Fitts, P. M. (Ed.). (1951). Human engineering for an effective air-navigation and traffic-control system. National Research Council.
Hollnagel, E. (2014). Safety-I and Safety-II: The past and future of safety management. Ashgate.
Hollnagel, E., & Woods, D. D. (2005). Joint cognitive systems: Foundations of cognitive systems engineering. CRC Press.
Jones, N. B. (2026, October 25). Are you buying AI per seat or per token? That's the wrong question. Ask this instead [Video]. AI News & Strategy Daily, YouTube. https://youtu.be/RvnQZQAHUDc
Klein, G. (2007). Performing a project premortem. Harvard Business Review, 85(9), 18–19.
Parasuraman, R., & Riley, V. (1997). Humans and automation: Use, misuse, disuse, abuse. Human Factors, 39(2), 230–253.
Cover photo: TechnicalWishlist Workshop, Munich by Jan Dittrich (WMDE), via Wikimedia Commons, CC BY 4.0, cropped.