A business can spend more on AI without becoming better at using it. The useful question is what remains after the work: a solved problem, a reliable procedure, approved information or a way to check the next answer.
In his June 14, 2026 essay, Satya Nadella uses token capital for AI capability a firm builds and owns, and argues for combining it with human expertise. That is a strategic argument, not evidence that every AI interaction automatically improves a business.
What Would Token Capital Mean in Practice?
A token is a unit of data processed by a model. Buying more token usage pays for processing; it does not, by itself, create a dependable company capability. Here, “capital” is a strategic metaphor, not a statement that AI spending qualifies as an accounting asset.
My practical interpretation is to look for work the team can reuse and inspect: an approved answer source, a tested process and examples of acceptable and unacceptable results. A valuable one-off task can still justify AI use. Not every answer needs to become a permanent system.
Repeated Use Is Not Automatic Learning
Saving a chat does not automatically train a model or change its underlying weights. Making approved material available as reference context, changing instructions and deliberately training a model are different mechanisms. Each requires an explicit process and a check that the result improved.
This matters when a team says its assistant “learns from every conversation.” Ask what actually changes, who approves it and how mistakes are kept out. Retaining every conversation can also retain obsolete facts or information the next user should not see.
Follow One Service Question Through the Process
Imagine an air-conditioning service company using an assistant to draft replies to booking questions. It needs to explain service coverage, assessment arrangements and what information a customer should provide. This is a possible workflow, not a claim about a deployed client system.
| Work product | What the company keeps | How it checks usefulness |
|---|---|---|
| Approved service information | A dated source for coverage and booking conditions, with an owner. | Operations confirms current facts before the assistant uses them. |
| Reply procedure | Instructions to answer from approved facts, ask for missing details and hand exceptions to staff. | A reviewer checks that no slot, price or diagnosis is invented. |
| Evaluation cases | Representative questions and expected behaviour, including an unsupported location or unclear fault. | The team runs the same cases before approving a change. |
| Correction record | The error, its cause, the approved correction and the version affected. | The next version is checked for both the original error and new regressions. |
Knowing the service area does not authorise the assistant to confirm availability. If it cannot read an approved live schedule, it should send a booking request for staff confirmation. A draft-response system and an agent allowed to change bookings need different permissions.
Build a Reviewed Improvement Loop
- Choose one bounded task. Start with drafting service replies, with a named person responsible for approval.
- Assemble the source. Resolve conflicting terms, record owners and dates, and supply only information appropriate for the task.
- Check representative cases. Include normal requests, missing facts, unsupported requests and situations needing a person. Define what counts as an acceptable answer.
- Use corrections deliberately. Decide whether a failure requires a source update, changed instructions, different permissions or a product fix. Do not put every reply straight into the knowledge base.
- Retest and release a version. Compare the changed process with the previous one before broadening its use.
This is where human judgement enters the system. A correction has value when someone verifies it and the workflow can apply it. The enterprise AI deployment analysis examines the integration and permission problems behind that work.
Measure the Capability, Including Its Cost
For this reply task, check factual errors, appropriate handoffs, staff review time and whether the customer receives a usable next step. Compare equivalent work. More messages, faster drafts or higher token use do not establish better service.
Count model charges alongside integration, checking, maintenance and recovery from mistakes. A process that saves drafting time but doubles correction work may not be an improvement. If the underlying service terms are unreliable, fix those before adding more automation.
Keep What You Need to Retain Control
Know where approved sources, instructions, evaluations and correction records live; who may access them; and what can be exported. Store only the information needed for the task, with a deliberate retention policy. “Company knowledge” is not a reason to expose customer records to every employee or assistant.
Keeping these materials separately can make a change of provider easier, but portability is not automatic. Another model can behave differently with the same instructions. Recheck permissions, costs and evaluation results before switching.
The next useful step is modest: select one existing AI-assisted task and list its source, reviewer, reusable output and failure check. If none can be identified, clarify the task before paying for a larger system.
Frequently Asked Questions
Does Spending More Tokens Build Token Capital?
Not automatically. Judge the useful work and retained capability, including the cost of checking and maintaining it.
Do Saved Conversations Train the Assistant?
Not simply because they are saved. Check the system's actual storage, retrieval and training behaviour rather than assuming they are the same thing.
Can a Small Business Start Without Training a Model?
Yes. A verified source, clear instructions and a repeatable review can improve one task without custom model training. The improvement still needs to be demonstrated.