Buying a tool and building a productive capability are different events. The purchase can happen in a minute. The capability may require reliable records, a useful procedure, trained judgment, and several rounds of correction.
That difference matters when we call intelligence “capital.” Capital is an attractive word because it suggests something that continues to work after the initial effort. A subscription can support that kind of asset. It can also support a stream of disposable output that leaves the business no more capable than before.
Under what conditions is AI a productive asset rather than a recurring expense? The answer depends on what remains, what it can repeatedly do, who controls it, and how much it costs to maintain. This is an operating distinction, not a claim about how a particular item should be classified for accounting or tax purposes.
The asset is usually larger than the model
A model provides a capability the business can access. The productive asset may be the complete system built around that capability: instructions, records, integrations, evaluation cases, permissions, and a process for using the results.
Consider an assistant that helps prepare estimates. The model can draft language. The business’s asset includes its current service definitions, cost rules, accepted estimate format, exceptions that require review, and examples that demonstrate correct behavior. Those elements make the assistance repeatable.
If the business loses access to one model but retains the surrounding system, it may be able to move to another. If the entire process exists only as an undocumented conversation, much of the capability may disappear with the interface. The same monthly bill can therefore support very different degrees of control.
The asset also includes people who know how to use and inspect it. A process nobody understands can become a liability even if it works most of the time. The organization needs enough understanding to recognize a change, investigate a failure, and continue the work through a fallback.
Calling the system capital is useful when it directs attention toward these durable elements. It is less useful when it simply gives a grand name to paying for generated text.
Repetition is necessary but insufficient
A tool that performs a task repeatedly may appear to be an asset. But repetition alone does not establish value. A process can repeatedly produce something nobody needs, repeatedly impose review costs, or repeatedly make a damaging mistake.
The relevant repetition is accepted productive work. An estimate assistant should help create feasible estimates the business can stand behind. A research assistant should help answer questions that influence decisions. A support workflow should resolve supported customer problems while preserving a route for exceptions.
That means the asset needs a defined user and result. “We use AI every day” is a statement about activity. “We can prepare this accepted comparison with less total effort while preserving accuracy” is a statement about capability.
The capability should also survive ordinary variation. A system that works only on the demonstration input may be a prototype. A system that handles the expected range of real inputs, escalates unsupported cases, and remains inspectable is closer to an operating asset.
The earlier article on Executable Knowledge explains how a procedure crosses into action. Here we add the economic question: whether that procedure produces repeated value after all the associated costs are counted.
Complementary investment is part of the explanation
Brynjolfsson, Rock, and Syverson’s Productivity J-Curve research, published in 2021 after earlier working-paper versions, examines how general-purpose technologies require complementary intangible investments. Their model concerns measurement and historical technology adoption. It does not predict a guaranteed payoff for a particular AI project.
The useful connection is that new technology often requires changes in processes and skills before its benefits become visible. A business may spend time improving records, rewriting a procedure, or teaching staff to inspect outputs. Those efforts are part of adoption even if the software bill is small.
This is a reason to include setup work in the estimate. It is not a reason to excuse every disappointing project indefinitely. A complement must have a plausible job, an owner, and a testable contribution. Otherwise “we are building intangible capital” can become a story that protects a failing initiative from scrutiny.
A well-run project identifies which complement is missing and why it matters. Cleaning a product record can make generated descriptions checkable. Defining an approval rule can allow routine drafts to move forward. Training can reduce correction time. Each investment should connect to a specific obstacle.
The evidence for value then comes from the resulting workflow. The theory helps us know where to look; it does not supply the local result in advance.
A four-part test for productive AI capital
First, the capability must serve a recurring need. The organization should be able to name the work and the person or customer who benefits. A collection of clever demonstrations is not enough.
Second, the capability must retain useful structure. Instructions, records, rules, or evaluation cases should become easier to reuse. If every task begins from scratch, the system may be assistance rather than an accumulating asset. Assistance can still be worthwhile, but it should be described accurately.
Third, the capability must be economically maintainable. Corrections, software changes, review, and incident handling belong in the calculation. An impressive process that requires constant rescue may consume more capacity than it creates.
Fourth, the organization must have sufficient control. It needs the right to use the relevant inputs, an appropriate way to handle data, and a practical exit or fallback. Control does not require owning every component. It requires understanding the dependency and retaining the parts that matter to continued operation.
These four conditions are a proposed decision framework. They are not a financial reporting standard. Their value is that a business can inspect each condition and identify what evidence is still missing.
Worked example: an estimate-preparation system
Imagine a service business that prepares forty estimates each month. The existing process takes thirty minutes per estimate, including checking the current service list and drafting the document. That is twenty hours of monthly work.
A proposed AI-assisted system reduces total preparation and review to twenty minutes per estimate. It also requires two hours of monthly maintenance. Under these hypothetical assumptions, recurring work falls to about 15.3 hours. The gain is approximately 4.7 hours per month.
Suppose setup requires twelve hours to define templates, organize source records, and check representative cases. A simple time-based comparison suggests that the setup effort would be recovered in roughly three months if the recurring gain persists. That is an illustration, not an observed result, and it excludes any claim that saved hours automatically become revenue.
Now ask what the organization retains. If it keeps clear service definitions, validated templates, and evaluation cases, those materials may remain useful even if the model changes. If the process depends on an opaque chat history and the person who created it leaves, the retained capability is weaker.
Change the review assumption. If each estimate takes twenty-eight minutes rather than twenty minutes, preparation and review take eighteen hours and forty minutes. Adding the two maintenance hours brings monthly work to twenty hours and forty minutes—forty minutes more than the original process. The economic character of the system changes even though it still uses AI and still creates documents quickly.
This example shows why the asset question depends on complete work rather than draft speed. The business should measure accepted estimates, correction time, and whether commitments remain feasible.
Durability does not mean permanence
Physical equipment wears out. Software and procedures become obsolete. An AI-assisted capability can lose value when a source changes, a model behaves differently, a service is discontinued, or the business stops needing the task.
The relevant question is how the capability depreciates and how it can be renewed. A maintained service list may remain useful for years with ordinary updates. A prompt tied to one model’s peculiar behavior may need frequent revision. A rule built around a temporary interface may stop working abruptly.
This suggests separating stable business knowledge from replaceable technical components. The service definitions should not depend on the model’s format. The acceptance criteria should survive a vendor change. The record of completed actions should remain available outside the current conversational context.
Durability also requires periodic revalidation. The system should be checked when something material changes, not merely because a calendar says it is time to produce another report. Relevant changes include a new data source, a permission expansion, a model update, or a changed customer promise.
A capable organization can retire an asset as well as maintain it. Continuing to pay for a workflow after its purpose disappears is not evidence of commitment. It is a reason to review the portfolio.
Ownership and access need separate attention
A business can own its process while renting the computation that helps perform it. It can also believe it owns a capability while lacking the rights or practical ability to move essential records. The distinction deserves explicit examination.
Ask which elements are under the organization’s control: source records, prompts, code, templates, evaluation cases, output history, and integrations. Ask which are dependent on a vendor: model access, hosted functions, proprietary formats, and service-specific identity systems.
The purpose is not to eliminate every dependency. That would be unrealistic for most small organizations. The purpose is to identify dependencies that could make the business unable to serve customers or inspect its obligations if access changes.
An exit exercise can be simple. Can the organization export the records it needs? Can it explain the current procedure? Can it complete a representative case through a fallback? Can it identify outstanding commitments without relying on the assistant’s memory?
The later article Ownership Matters More as Intelligence Gets Cheaper examines these questions in greater depth. Here they help distinguish a durable capability from a convenient but fragile experience.
Capital can produce risk as well as output
A productive system can scale a mistake. An estimate assistant connected to sending tools might distribute an incorrect price before review. A document process might expose information that should remain restricted. A recurring classification error might quietly affect a large set of records.
These risks belong in the asset’s economics. A system’s expected benefit should not be assessed as though failures have no cost. Some consequences are rare but large. Others are small and frequent. Both can change whether the capability is worth maintaining.
The controls should target the actual risk. A price derived from authoritative rules can be checked mechanically. An unusual scope request can be handed to a person. External sending can remain a separate permission from internal drafting. A record can show which version produced the estimate.
The business should also define how to stop the system. If the current source is wrong, more throughput can worsen the problem. A pause mechanism and a way to identify affected work make the capability more manageable.
This is why capital is not synonymous with autonomy. A bounded assistant can be a productive asset. A broadly autonomous agent can be an expensive experiment. The level of authority should follow the demonstrated work and the consequences, not the marketing label.
Cash, capacity, and quality are different returns
A capability can generate value by increasing revenue, reducing actual expenditure, releasing capacity, improving quality, or making the business less fragile. Those returns should not be blended casually.
If an owner saves five hours, that is capacity. If the business stops paying for an outside service it no longer needs, that may be a cash saving. If better estimates reduce disputes, that is a quality or risk benefit requiring evidence about the disputes. If the owner uses the time for family, the benefit is real without being commercial income.
A business can choose among these returns. It may deliberately use automation to shorten working hours rather than expand output. It may accept a higher software bill because service becomes more dependable. The choice should be explicit so the evaluation measures the intended benefit.
The error is to count the same return several times. Saved time, additional sales made in that time, and a wage-equivalent value should not automatically be added together. Some represent alternative uses of the same capacity.
The AI Leverage Equation develops a practical way to keep these categories separate. The asset question becomes clearer when the owner can state what kind of return the capability is meant to produce.
When the capital metaphor should be resisted
Not every useful AI interaction needs to become a system. An occasional explanation can be worth its price without creating a retained asset. A creative draft can be helpful even if it is used once. It is unnecessary to turn every benefit into capital language.
The metaphor becomes harmful when it encourages accumulation without use. A business can collect prompts, integrations, and documents while failing to improve a single recurring task. The inventory looks substantial, but the productive capability remains unproven.
It can also hide the burden on staff. If maintaining the system requires constant unpaid effort, the apparent return may reflect a cost that the accounting failed to notice. A process should be evaluated with the people who do the checking and correction.
The most useful response is modest: call a capability productive when it has demonstrated a recurring benefit under defined conditions. Keep prototypes and speculative investments labelled as such. Retire what does not work. The terminology should make the decision clearer, not make the project sound inevitable.
AI Leverage in Practice
Choose one recurring workflow and write a short asset record. Include its purpose, accepted result, owner, retained materials, dependencies, permissions, setup effort, recurring cost, and fallback. This makes the proposed capability concrete enough to evaluate.
Measure the existing process before investing in a replacement. Use representative cases, including an exception. Count review and correction. Keep the initial scope reversible, and do not add external authority merely to demonstrate sophistication.
After the trial, identify what has actually improved and what remains reusable. A better source record or acceptance checklist may be worth retaining even if the AI component is rejected. That is a useful result because the experiment has strengthened the organization’s understanding.
Today’s tools can support productive assets built from bounded workflows and maintained knowledge. A future system may perform more work independently. That possibility should be tested when available rather than included as an assumed present return.
Review the asset when its inputs, model, permissions, or business purpose change. If maintaining it costs more than the supported benefit, narrow it, replace it, or stop. Capital discipline includes that decision.
The productive meaning of intelligence as capital
Intelligence becomes capital when it is embodied in a controlled, maintainable capability that repeatedly helps produce useful results. The model may be one component. The organization’s records, rules, judgment, and responsibility make the capability usable.
That definition leaves room for substantial optimism without promising automatic wealth. Cheaper cognition can make new assets possible. The work is to identify a recurring need, build the right surrounding system, and establish that the result remains worth its cost.
The next step in The Age of AI Leverage is to estimate that net value explicitly. A productive asset deserves a calculation that includes what it takes to make the work trustworthy.
Sources
- Erik Brynjolfsson, Daniel Rock, and Chad Syverson, The Productivity J-Curve: How Intangibles Complement General Purpose Technologies, revised working paper January 2020, published 2021; complementary-investment framework, not a forecast for a particular AI project.
Loading comments…