Tencent Research Institute’s WeChat account has published an excerpt from Understanding the Token Economy by Du Ning, CEO of Ruige Taike (Beijing) Technology Co., Ltd. The excerpt is titled “Who Uses Tokens?” and centers on the demand side of the token economy. Its main argument is straightforward: tokens do not create value simply because they are consumed. What matters is the task they complete, the labor they replace, and the result they produce.
The piece opens with an illustrative scenario. On a Monday morning, a marketing manager at a consumer goods company is asked to deliver a competitive analysis report within two days, covering pricing, promotions, and user reviews for five brands across three channels. In the past, gathering industry materials, building comparison tables, and writing conclusions would take the full two days. This time, she imports 20 industry reports and e-commerce datasets into an AI analysis tool, describes the analytical framework in natural language, and receives a structured first draft two hours later. She then spends half a day revising the judgment calls, adding internal data, and adjusting the wording of the conclusions before submitting the report that same afternoon. The system bill shows that the work consumed about 500,000 tokens. The author notes that this is an illustrative setup meant to show the scale of token usage, not a specific real-world case.
From traffic economics to token economics
The article says the core object of measurement in the digital economy is changing. For more than two decades, traffic was the main yardstick: how many clicks users generated, how long they stayed, how often they shared, and how often they converted. In the token economy, the focus shifts away from how much information people consume and toward how many cognitive tasks intelligent systems complete, how many usable outputs they generate, and how much professional labor they save.
Put differently, if traffic economics measures attention, token economics measures completed cognitive work and usable outcomes. To explain that shift, the article revisits the older internet logic in which platforms competed for attention. It cites Herbert Simon’s 1971 observation that a wealth of information creates a scarcity of something else: the attention of its recipients. Search, social media, short video, and e-commerce platforms all built their business models around that scarcity.
In token economics, the user is no longer just a viewer, clicker, or browser. The user becomes a task initiator. People open AI tools not only to read content but to explain materials, generate text, revise plans, analyze data, translate contracts, write code, organize meetings, or let an agent handle a multi-step process. On the surface, they are talking to a model. In practice, they are handing over part of their cognitive labor to an intelligent system.
The article breaks this shift into four changes. First, demand is driven less by content consumption and more by task completion. Second, demand no longer comes only from human clicks; software systems and agents can trigger token use automatically in the background. Third, the digital economy’s focus moves from time spent to tasks completed. A strong AI system may finish in 10 seconds what once took two hours. A weak one may keep users engaged for longer without creating much value. Fourth, demand moves from obtaining information to obtaining capability. Search engines return webpages, while generative AI can write, revise, calculate, draw, code, analyze, compare, plan, and execute.
The author cites McKinsey’s estimate that generative AI could create $2.6 trillion to $4.4 trillion in annual economic value, with strong potential in customer operations, marketing and sales, software engineering, and R&D. The piece also references Anthropic research based on millions of Claude conversations, which found that AI use is heavily concentrated in software development and writing tasks and spans both human augmentation and automation. Together, those studies are presented as evidence that token demand is forming around tasks rather than content.
The article does not frame traffic economics and token economics as mutually exclusive. AI applications may still depend on traffic and attention, and traffic platforms are also embedding task-oriented services. The relationship is described as additive and convergent rather than one replacing the other. Traffic economics remains in place, but token economics introduces another growth logic: individuals use AI as an extension of capability, enterprises embed tokens into organizational workflows, and agents consume tokens automatically in the background.
Who consumes tokens: individuals, enterprises, and agents
The article first separates final demand from triggering mechanisms. Individuals and enterprises are the ultimate demand-side actors because they bear payment, decision-making, and responsibility. Government, education, and healthcare institutions also fall into that category. System software and agents, by contrast, are triggering actors that consume tokens automatically on behalf of those end users. Developers are usually attached to either individuals or enterprises.
On the surface, token consumption can come from many places: a person opening a chatbot, a company integrating a model API, a developer calling a model interface, or an agent running tasks in the background. But the economic logic behind each case is different. Individuals consume tokens to extend their capabilities. Enterprises consume tokens to reorganize efficiency. Agents consume tokens in a way that expands demand from human-triggered to machine-triggered usage.
Individuals: from information access to capability extension
The article describes individual users as the earliest and most intuitive source of token demand. In the search era, people mainly used keywords to find webpages. In the mobile internet era, they consumed content through recommendation systems. In the generative AI era, they increasingly hand tasks to models. Writing emails, revising text, explaining papers, generating images, tutoring math, planning travel, translating materials, and interpreting medical checkup reports can all become token-consuming actions.
One example in the article is an independent writer who produces WeChat articles and product manuals for multiple companies. In the past, a 3,000-word assignment required research, outlining, drafting, and repeated revision, usually taking a full day. Now she gives the model product materials and competitor information, asks it for a structured outline and draft paragraphs, and then focuses her own time on adjusting the argument, refining the style, and checking details. The same work can be compressed to less than half a day. The more important change, the author says, is that she now accepts technical assignments she would not have taken before. That is not because she suddenly mastered chip manufacturing or cloud architecture, but because the model helps her digest technical materials quickly, leaving her to translate them into language readers can understand. The article stresses that accuracy still depends on her own verification.
The point is not that individuals have gained another Q&A tool. The point is that ordinary users can now access cognitive capabilities that previously required specialists, organizations, or expensive software. A non-programmer can ask a model to explain code. A parent can ask for a study plan for a child. A freelancer can use a model to help draft a proposal. A founder can ask for a market research framework. In the article’s framing, the value of tokens on the individual side shows up first as capability extension.
That extension has three dimensions: lowering the barrier to acquiring knowledge, improving expression and production capacity, and expanding the range of actions an individual can take. The article links this to repeated discussion of the “one-person company” and the “super individual” in the era of large models. A person can temporarily assemble writing, design, research, customer service, marketing, and coding capabilities through models and tools. Even so, the individual side is still mostly in an augmentation phase rather than full automation. Once the model generates content, the human still has to judge, revise, integrate, and take responsibility. Anthropic research cited in the piece says about 57% of AI use is closer to augmenting human capability, while about 43% is closer to automating requests.
Enterprises: from tool trials to workflow restructuring
If individuals represent the breadth of adoption, enterprises determine the scale and depth of the token economy, according to the article. Companies do not consume tokens just to experiment. They do so because organizations contain large volumes of knowledge work. Customer service teams answer questions. Sales teams write proposals. Legal teams review contracts. Finance teams read reports. HR screens resumes. R&D writes code. Management reviews operating analysis. These tasks are information-heavy, repetitive, and often structured, but they still require understanding, judgment, and expression.
The article argues that the first areas to change are usually not the most complex strategic decisions. Instead, tokens first reshape high-frequency tasks such as meeting notes, document summaries, customer service assistance, sales scripts, code completion, and knowledge-base Q&A. It cites Microsoft and LinkedIn’s 2024 Work Trend Index, which found that 75% of knowledge workers already use AI at work. At the same time, many leaders see AI as critical to competitiveness while lacking a clear implementation vision and plan. The article reads that as a sign that employee-level tool adoption is moving faster than organization-level process redesign.
Enterprise token consumption is divided into three stages. The first is personal productivity tooling, where employees use AI on their own for writing, summarizing, translation, information search, and coding assistance. The second is departmental workflow embedding, where customer service, sales, R&D, legal, HR, and finance teams connect models to specific systems. The third is organization-level intelligence, where the company redesigns workflows and breaks tasks into human judgment, model generation, tool invocation, data retrieval, system execution, and human review. The article notes that these stages are not strictly linear. Different companies may move through them in parallel or remain in one stage for a long time. By the third stage, tokens become a new input into organizational operations and enter budgets, audits, ROI calculations, and risk management.
The article says the biggest difference between enterprise and individual use is controllability. If an individual gets a poor answer, they can ask again. If a company inserts a wrong output into a contract, credit decision, codebase, customer communication, or medical recommendation, the result can be a real loss. For that reason, enterprise token demand is not driven simply by the idea that cheaper models are always better. Low-cost models fit low-risk tasks. High-value tasks require stronger models, better data, tighter permissions, and more complete review.
System software and agents: automated token consumers
The third category is system software and agents. In early large-model applications, token consumption was usually triggered directly by humans. As APIs, plugins, tool use, and agent frameworks have developed, more token consumption is now triggered by software. When developers embed model capabilities into products and workflows, a single software system connected to a model API can indirectly generate token usage for thousands of users. An enterprise system integrated with a model can create ongoing token demand across multiple departments.
Programming is presented as one of the clearest high-frequency token consumption scenarios. The article cites GitHub Copilot-related experimental evidence showing that in a controlled test where developers were asked to implement an HTTP server, the group using an AI coding assistant completed the task 55.8% faster than the control group. The author says that result should not be generalized to every software development scenario, but it does show that once models are embedded into developer tools, tokens are not just generating text. They are participating in software production.
Agents amplify that trend. An agent does not answer one question and stop. It repeatedly calls models and tools around a goal: understanding the task, making a plan, searching for information, reading files, invoking a coding environment, checking results, and revising outputs. The article says later Anthropic research on Claude usage found that the share of tasks delegated to Claude rose over several months, while enterprise API scenarios showed stronger automation and specialization. In that view, token demand grows not only because chat frequency rises, but because systems hand more tasks to models for continuous execution.
The common logic across individuals, enterprises, and agents is that token consumption is not really about using an AI tool. It is about invoking intelligent capability. Individuals use models as capability extensions. Enterprises embed models into workflows. Agents turn models into task-execution components. Together, they push token demand from low-frequency Q&A to high-frequency workflows, from active human input to automated system triggers, and from content generation to task completion.
The article concludes that the demand side of the token economy is not a single market. It is a composite market made up of individual capability extension, enterprise efficiency restructuring, and agent-driven automation. Broadly speaking, individual demand affects the speed of adoption, enterprise demand affects the depth of value creation, and automated agent calls may shape future consumption intensity. Public-sector demand from government, education, and healthcare is also described as significant.
Where token value shows up: five paths
The article insists that tokens themselves are not value. Enterprise bills can show input tokens, output tokens, cached tokens, and tool calls, but those figures do not directly equal economic value. A department may consume many tokens because its workflow has become more intelligent, or because prompts are inefficient, rework is frequent, the wrong model was chosen, or an agent is stuck in an unproductive loop. To judge whether token economics works, the author says, one has to look at the mechanism of value conversion rather than raw consumption.
From the demand side, the article identifies five broad paths: efficiency gains, revenue growth, capability expansion, organizational change, and knowledge discovery. Efficiency gains answer what was saved. Revenue growth answers what was added. Capability expansion asks whether tasks that were previously out of reach can now be done. Organizational change asks how work is re-divided. Knowledge discovery asks whether AI can help uncover things that were previously hard to find.
Efficiency gains
The most visible form of value is efficiency. In many knowledge jobs, the biggest time sink is not creative inspiration but reading, sorting, summarizing, rewriting, searching, classifying, and formatting. Meeting notes, customer service replies, first-pass contract review, code completion, and test generation all contain large amounts of repetitive, semi-structured cognitive labor. When generative AI enters those workflows, tokens first compress those task fragments.
The article cites an experimental study by Noy and Zhang published in Science. In that study, 453 college-educated professionals completed occupation-related writing tasks, and some were randomly allowed to use ChatGPT. The group using ChatGPT completed tasks 40% faster on average and produced output with 18% higher quality. Customer service shows a similar pattern. Brynjolfsson, Li, and Raymond, using data from 5,179 customer service agents, found that an AI assistant increased the average number of issues resolved per hour by 14%, with larger gains for new and lower-skilled workers.
Still, the article says efficiency gains are not automatic. It references work by Dell’Acqua and colleagues with Boston Consulting Group, which introduced the idea of a “jagged technological frontier.” For tasks within AI’s capability boundary, consultants using GPT-4 completed more work, faster, and at higher quality. For complex management tasks designed to sit beyond that boundary, people using AI were actually less likely to arrive at the correct solution. The implication is that the key is not to use AI for everything, but to identify which tasks fall within the model’s capability frontier and which still require human judgment. Outside that frontier, token consumption may create error and rework rather than value.
Revenue growth
The second path is revenue growth. If efficiency gains are about spending less money and less time, revenue growth is about building new products, serving new customers, and opening new markets. The article says many AI applications matter not because they make existing workflows faster, but because they make services scalable that were previously too labor-intensive to deliver at scale.
Examples include education providers generating personalized explanations and exercises, tourism companies creating routes and guide content based on user preferences, financial institutions offering basic investment education and product explanations to long-tail customers, design platforms helping ordinary users generate visual materials quickly, and software companies integrating code generation, test generation, and documentation generation into development workflows. In these cases, tokens break highly manual services into tasks that models can participate in, allowing broader coverage at lower marginal cost.
The article also says revenue growth comes from changes in product form. Traditional software sells functions. AI-native products often sell outcomes. Users are not buying a text editor but “help me write a good email,” not a search box but “help me complete research,” not a customer service system but “help me solve customer problems.” When products move from function-oriented to task-oriented, tokens become both a cost unit and a value-realization unit underneath the product. The author adds that in actual pricing, most AI products still rely on subscriptions, feature bundles, or API usage. Pure outcome-based pricing remains limited to some services.
Capability expansion
The third path is capability expansion. Many professional capabilities used to be tied to specific groups, institutions, and software systems. People who could code built tools. Designers created visual plans. Lawyers reviewed contracts. Finance professionals read statements. Generative AI has not erased those professional differences, but it has lowered the threshold for initial access to those capabilities.
An ordinary employee can ask a model to explain financial metrics. A small business owner can ask it to draft contract clauses. A student can ask it to break down a difficult concept. A solo founder can ask it to generate a marketing plan. The output may not be ready to use as a final answer, but it can serve as a draft, framework, explainer, or sparring partner. The customer service research cited earlier found that AI assistants helped new and lower-skilled workers more, which the article interprets as evidence that AI can act as an “experience diffuser,” passing some of the practices of high-performing workers to less experienced ones.
The article distinguishes between horizontal and vertical expansion. Horizontal expansion means entering unfamiliar domains and completing initial exploration. Vertical expansion means professionals using models to amplify their own capabilities, handing lower-value steps to the model and focusing their time on judgment, responsibility, and creative problems. Tokens can lower the barrier to entry, the author says, but they do not remove the barrier of responsibility. Once work reaches the level of professional decision-making, professionals still need to verify and own the result.
Organizational change
The fourth path is organizational change. When tokens are used only occasionally by individuals for writing or Q&A, they remain a tool. When they are embedded continuously into enterprise workflows, organizational structure begins to shift. Companies traditionally run on role-based division of labor: customer service answers questions, legal reviews contracts, R&D writes code, management makes decisions. Once large models enter the picture, many jobs can be broken into task fragments such as retrieval, summarization, generation, verification, judgment, and execution.
That can push companies from role-based division toward task orchestration. In contract review, for example, a system can read the contract, extract clauses, match templates, flag risks, and generate revision suggestions, while legal staff decide whether the risks are real, whether the suggestions are workable, and how negotiation should proceed. In customer service, a model can identify intent, retrieve knowledge-base content, and generate a reply, while human agents handle complex emotions, special permissions, and high-risk issues. In that structure, people move from being pure executors to becoming task designers, model users, result reviewers, and responsibility holders.
The article also cites a 2025 field experiment involving 776 professionals at Procter & Gamble. It says AI affected not only individual efficiency but also team collaboration: individuals using AI could perform close to two-person teams that did not use AI, and AI helped break down functional barriers between R&D and commercial staff. The author uses that result to argue that AI may change how knowledge flows inside teams, how specialties complement one another, and how collaboration is organized.
Knowledge discovery
The fifth path is knowledge discovery. The first four paths are mainly about doing existing human work faster, cheaper, or at broader scale. Knowledge discovery points somewhere else: using AI to find things that were previously hard to discover. In scientific research, models can propose hypotheses, screen options, and accelerate experiment design using large volumes of literature, experimental data, and molecular structures. The article places this under the banner of “AI for science,” especially in materials, biomedicine, and chemistry.
In these cases, the value of token consumption is not measured by labor hours saved. It depends on whether the process can unlock new discoveries. The potential return per token may be very high, but it also depends heavily on data quality, professional judgment, and repeated validation. The article stresses that none of the five paths happens automatically. Whether tokens turn into value depends on task fit, quality control, human-machine division of labor, data quality, system integration, organizational capability, and budget governance.
Token budgets and operations inside enterprises
The article says the pressure of demand-side cost management falls mainly on enterprises. Individual usage is small, and agents are ultimately deployed and paid for by companies, so this section focuses on enterprise practice. It distinguishes this from the supply-side discussion in an earlier chapter. There, the question was how prices are formed. Here, the question is how buyers plan, attribute, and control token spending.
When companies are only experimenting with AI tools, token consumption often appears as a small expense inside a technical or innovation budget. Once AI enters customer service, sales, R&D, legal, finance, knowledge management, and agent workflows, token spending stops being a trial expense and becomes a new cost category in operations. At that point, the article says, companies cannot stop at asking how much AI they used. They need to ask who used the tokens, which tasks they were used for, whether the results had value, whether calls were duplicated, whether sensitive data was entered into external models, whether agents were running without limits in the background, and whether low-value tasks were occupying expensive models. In short, model integration is not enough. Enterprises need token operations.
From API bills to token budgets
Many companies first encounter token costs through model API bills. Developers see charges for input tokens, output tokens, cached tokens, and tool calls. Departments buying AI products see account counts, quotas, packages, and overage fees. During pilot phases, those costs are often small and covered by innovation budgets. But once customer service systems, development platforms, knowledge-base systems, and agents run continuously, token costs become frequent, distributed, and fast-growing. The article compares them to cloud computing costs that rise automatically with usage intensity.
It then points to FinOps in cloud computing. The FinOps Foundation defines FinOps as an operating framework and cultural practice that brings engineering, finance, and business teams together to maximize business value from technology, support timely data-driven decisions, and create financial accountability. The article says token cost management can borrow from that logic, but it also differs from it. Cloud costs map to compute, storage, and network resources. Token costs map to cognitive tasks, model capability, and output results. Companies need to control consumption, but they also need to judge whether that consumption created value.
The first step in token budgeting, the article says, is to break the total bill down by department, project, and task. The department dimension answers who is using tokens. The project dimension answers which business objective they support. The task dimension answers what they are actually being used to do. Without that attribution, the bill remains a single total that looks manageable but cannot really be governed.
Budgeting is not about minimizing use
The article says token budgeting is often misunderstood as a way to use less AI. That is not the goal. The goal is to plan investment rationally: which tasks should use AI, what class of model they should use, and how quotas should be allocated across departments and projects. If a task consumes many tokens but saves labor, shortens delivery cycles, improves conversion, or reduces risk, the spending may be justified. If a task consumes few tokens but produces unusable output, requires repeated revision, or introduces errors, even a low bill may be wasteful.
That leads to task grading. Low-risk, low-value tasks such as ordinary rewriting, formatting, and simple summarization fit low-cost models. High-frequency efficiency tasks such as customer service assistance, meeting notes, knowledge-base Q&A, and code completion require attention to total cost and stable returns. High-value, complex tasks such as financial research, legal review, and industrial fault diagnosis may justify stronger models, longer context windows, and more tools, but they must come with human review. High-risk restricted tasks such as medical diagnosis advice, major financial decisions, and production control instructions must be placed inside compliance, accountability, and approval processes.
The article says Microsoft documentation on Azure AI Foundry cost management reflects a similar logic: enterprises should estimate costs before deployment, track spending during use, and set budgets and alerts to avoid overruns, while recognizing that model service costs are only one part of the total cost of an application or solution. In the author’s view, enterprise AI cost management has already moved from reading bills to full-process management that includes planning before deployment, monitoring during use, and warnings when spending exceeds expectations.
ROI, auditing, and an operating loop
Token budgets answer how much was spent. Token ROI answers whether it was worth it. The article says companies should at minimum build a task-level evaluation framework covering four categories: efficiency, quality, business, and risk. Efficiency metrics include task completion time, throughput per unit of time, and human review time. Quality metrics include usability rate, first-pass rate, error rate, rework rate, and human adoption rate. Business metrics include customer satisfaction, conversion rate, complaint rate, and risk detection rate. Risk metrics include sensitive data leakage, wrong recommendations, compliance issues, and misuse in high-risk decisions.
Token auditing answers another set of questions: what the model read, what it said, and what it affected. Traditional software auditing focuses on who logged in and what data was changed. In token economics, the article says, auditing also needs to record what data entered the model, which model and version were called, what prompts were used, what outputs were produced, whether those outputs were adopted, and whether they entered contracts, reports, code repositories, approval workflows, or customer replies.
The article references the U.S. National Institute of Standards and Technology’s AI Risk Management Framework 1.0, which organizes AI risk management around governance, mapping, measurement, and management, and emphasizes identifying, assessing, managing, and communicating AI risks. It adds that the term “token audit” in the article is an analytical label borrowed from the logic of governance frameworks such as NIST’s, not a term used by NIST itself.
When budgets, ROI, and auditing are combined, the article says, enterprises form what it calls “token operations.” This is not something owned only by the technical team, nor is it just a finance function reading bills. It is an operating system involving business, technology, finance, security, legal, and management. The concept borrows from FinOps, but the managed object is not compute or storage. It is cognitive tasks, model capability, and output results.
The section’s conclusion is clear: once tokens become a new enterprise cost category, the goal is not to use as few tokens as possible. The goal is to use them on the right tasks, produce verifiable value, and keep risk within an acceptable range.
High-value and low-value tasks
Not all tokens carry the same value, the article says. A model bill can show how many tokens were consumed, but it cannot tell a company how much value those tokens created. The same 1 million tokens may be used for casual chat, entertainment, and simple rewriting, producing little more than a better user experience. The same volume used for customer service triage, code generation, and contract review may save large amounts of labor. Used for financial risk control, industrial diagnosis, or drug R&D, it may affect major decisions and high-value output. Equal quantity does not mean equal value density.
The article defines value density as the economic value created, cost reduced, risk lowered, or capability expanded by a unit of tokens in a specific task. A task that consumes more tokens is not automatically more valuable. A task that consumes relatively few tokens may still create large value if it sits in a critical workflow. The author says value density is a relative, qualitative framework for ranking and prioritizing tasks rather than a precise metric on a single scale, because different tasks produce different kinds of returns that are hard to normalize.
Low-value and mid-value tasks
Low-value tasks are not worthless. They simply have limited unit value, lower error costs, and weaker willingness to pay. Typical examples include casual chat, entertainment dialogue, simple Q&A, ordinary rewriting, low-risk copy, routine summarization, light translation, and novelty image generation. These tasks are low-threshold, high-frequency, and highly substitutable. Their role is often to drive adoption and habit formation by familiarizing users with AI interaction and model limits. The article says they should not occupy high-end model resources for long periods, because the cost-return match may be poor. It also notes that the labels are contextual. Translation or summarization can become high-value in settings such as important contracts or medical materials.
Mid-value tasks are described as the easiest to scale today and the easiest for enterprises to perceive. Examples include meeting notes, document summaries, knowledge-base Q&A, customer service assistance, sales scripts, marketing content, translation polishing, code completion, test generation, data explanation, first-draft reports, and initial screening of contract clauses. These tasks occur frequently, produce clear work outputs, and have manageable error costs because humans can review and correct them. The writing, customer service, and developer studies cited earlier mostly fall into this category.
The article says the key metrics for mid-value tasks are volume and adoption rate. A single call may be cheap, but very high frequency can still create a large bill. If a customer service assistance system generates 10 suggestions and only two are adopted, value density is low. If eight are adopted and response time falls sharply, value density is higher. Companies should care about how many tokens produced adopted results, not just how many tokens were consumed.
High-value tasks and restricted high-risk scenarios
High-value tasks are where token economics has the most potential and where management is hardest, according to the article. Examples include financial research, credit risk control, anti-fraud, legal review, drug R&D, medical assistance, industrial fault diagnosis, complex code generation, cybersecurity analysis, enterprise strategy analysis, and supply chain optimization. These tasks are highly specialized, information-dense, costly to get wrong, and capable of producing high-value outcomes.
They do not always consume the most tokens, but they may generate the highest value per token. A summary of a financial research report that helps an analyst identify a key risk earlier, a contract review that catches a major liability clause, an industrial fault analysis that reduces downtime, or a security analysis that finds a vulnerability in advance can all create far more economic value than ordinary text generation.
Still, the article warns against equating high-value tasks with simply using the most expensive model. High-value tasks usually require a combination of model capability, industry data, knowledge bases, tool use, human review, and accountability mechanisms. A high-performance model without reliable data may produce fluent but wrong judgments. An outdated industry knowledge base may provide stale grounds. An agent without permission controls may carry a wrong action into a production workflow.
Restricted high-risk scenarios carry even stronger accountability constraints. Medical diagnosis, major financial decisions, production control, and final legal opinions may have high potential value, but the cost of error is extremely high. They cannot be judged only by efficiency and cost. They require strict permissions, expert review, audit trails, and clear responsibility boundaries.
From consumption management to value-density management
The article says value density depends first on task position. A strong model used for casual chat may still produce low-value output. A low-cost model used for high-frequency customer service triage may create stable commercial value. Model capability determines the upper bound of possible quality, but task position determines whether that quality has a path to value.
At least six factors shape value density, according to the article: task importance, output usability, the value of the labor being replaced, error cost, scalability, and the depth of data and workflow integration. Companies should not look only at model price or token volume. They need to look at which tasks the tokens are placed into. In general, the more important the task, the more usable the output, and the more scalable the reuse, the higher the value per token. On the other hand, higher error costs and review costs make value realization harder.
The section concludes that growth in token economics is not only about rising token volume. It is also about more tokens moving into high-value, high-complexity, high-trust tasks and creating stable value under controlled risk.
Demand-side risks: hallucinations, leakage, dependence, and accountability
The final major section turns to risk. The deeper tokens move into personal life and enterprise workflows, the less the problem can be reduced to “the model got something wrong.” When tokens are used only for casual chat, the cost of error is relatively low. When they enter customer service, contracts, code, finance, healthcare, industry, and government workflows, errors can lead to customer losses, compliance problems, system vulnerabilities, business disruption, and liability disputes.
For that reason, the article says growth in token demand must be accompanied by risk governance. Enterprises and individuals need to answer whether model outputs are reliable, whether input data is secure, whether people are becoming overly dependent on models, whether outputs contain systematic bias, whether AI-assisted decisions meet fairness requirements, and who bears responsibility if model outputs cause losses. Those questions determine whether tokens can move from low-risk experimentation into high-value business processes.
Hallucination risk
The most common and most underestimated risk in generative AI, the article says, is hallucination. This is not just the model “making things up” in a casual sense. It refers to content that looks reasonable, sounds confident, and appears complete in form, but is factually wrong, weakly grounded, or logically unsound. In enterprise settings, hallucinations can become wrong summaries, wrong contract judgments, wrong code, wrong customer replies, or wrong investment research conclusions.
The article cites NIST’s AI Risk Management Framework: Generative AI Profile, which identifies risks related to information integrity and confabulation and stresses that organizations need to identify and manage the distinctive risks of generative AI in design, development, deployment, and use. The author’s point is that hallucination is not a single technical flaw. It interacts with organizational process, data sources, user judgment, and accountability mechanisms.
Managing hallucination on the demand side cannot rely only on switching to a stronger model, the article says. Stronger models may reduce error rates, but they do not eliminate errors. Low-risk tasks can use lighter self-checking. Mid-risk tasks need retrieval augmentation, source citation, human review, and version records. High-risk tasks require expert review, cross-validation, output traceability, and clear responsibility boundaries.
Data leakage, overreliance, and unclear responsibility
The article says many users naturally feed files, code, contracts, customer information, and business materials into models. For enterprises, that may involve business plans, customer lists, financial statements, source code, R&D materials, contract files, transaction data, and internal meeting notes. A seemingly ordinary model call may mean sensitive data enters external systems, logs, third-party services, or cross-border data flows.
It references the Open Worldwide Application Security Project’s LLM application security work, which lists sensitive information disclosure as a major risk in large language model applications. The article says this matters especially on the demand side because many problems do not originate inside the foundation model itself. They arise from how enterprises connect models, open permissions, process outputs, and design plugins and toolchains.
Overreliance is another concern. AI can lower task barriers, improve efficiency, and expand capability, but it can also weaken judgment. Users who rely on models for writing over long periods may lose some ability to organize expression independently. Developers who rely heavily on code generation may become less sensitive to underlying logic and security flaws. Managers who depend on summaries may spend less time reading source materials in depth. The article says the answer is to redesign human-machine division of labor: low-risk tasks can be automated, mid-risk tasks can use model generation with human review, and high-risk tasks must retain expert judgment.
Responsibility is also harder to assign once model outputs enter business processes. If an AI customer service system makes a wrong promise to a customer, who is responsible? If a coding assistant generates vulnerable code, who is responsible? If an agent updates a database incorrectly, who is responsible? If a financial analysis model produces a misleading judgment, who is responsible? The article says these questions ultimately require institutionalized accountability rules and compliance frameworks. It notes that the EU AI Act has established rules around high-risk AI systems, transparency, and governance, while adding that the book discusses those regulatory frameworks in later chapters rather than in this excerpt.
The article also mentions fairness risk. If model outputs contain bias related to gender, race, or region and are used in screening, scoring, or recommendation systems, they may create systematic discrimination, damage social trust, and even trigger regulatory penalties. On the demand side, the proposed responses include bias testing, fairness evaluation, diverse datasets, and human spot checks.
Cost risk appears here as well. Agents stuck in ineffective loops and low-value tasks occupying expensive models for long periods can push token bills out of control. The article says enterprises need budget controls, call limits, anomaly monitoring, and model routing to keep costs within acceptable bounds.
Bringing AI use into organizational rules
The article says hallucination, leakage, dependence, and unclear responsibility may look like four separate risks, but they point to the same underlying issue: token consumption cannot be governed only through individual habits and tool experience. It has to be built into organizational systems. The author outlines five elements of demand-side management: task grading, data grading, model grading, role allocation, and continuous monitoring.
Task grading determines which tasks can be automated, which require review, which require expert approval, and which should not be automated at all. Data grading defines which data can enter external models, which can only be used in private environments, which must be desensitized, and which must not be entered. Model grading assigns different models and permissions to different tasks. Role allocation clarifies who uses the system, who reviews outputs, who approves decisions, who maintains the technology, and who owns risk. Continuous monitoring uses logs, spot checks, red-team testing, user feedback, and error reviews to improve models, prompts, knowledge bases, and workflows.
The section’s conclusion is that the deeper token economics enters business processes, the less risk governance can be treated as an afterthought. A mature demand side is not defined by everyone knowing how to use AI. It is defined by an organization knowing which tasks are suitable for AI, which data can be entered, which outputs can be adopted, which results must be reviewed, and who is responsible when something goes wrong.
The article’s closing argument
The excerpt closes by saying that the essence of token demand is the conversion of intelligent capability. It summarizes the chapter in three points. First, token demand comes from three kinds of actors: individuals, enterprises, and agents. The first two are final demand-side actors, while the third is a triggering actor. Individuals consume tokens to extend capability, enterprises consume them to restructure efficiency, and agents consume them as machine workflows begin to use intelligent capability automatically.
Second, token value is realized through five paths: efficiency gains, revenue growth, capability expansion, organizational change, and knowledge discovery. Tokens are not value in themselves. They become economic value only when they enter concrete tasks, produce usable results, and fit into workable processes.
Third, growth in token demand must be accompanied by risk governance. Hallucinations, leakage, dependence, and accountability all shape whether tokens can enter high-value, high-risk, high-trust scenarios.
The article says this chapter completes the explanation from “who uses tokens” to “how tokens become value.” The next part of the book will move into industry-specific settings, including manufacturing, tourism and culture, finance, and cross-border services, to examine how tokens are consumed in practice and how they change cost structures, workflows, and industrial logic.
The excerpt is from Understanding the Token Economy and was published via the WeChat account of Tencent Research Institute (ID: cyberlawrc). The author is Du Ning.
