While finishing Forensic Capital Governance, I discovered roughly $300 in automatic credit-recharge charges on my card. I believed I had purchased approximately $20 in AI credits. I had not understood that the account would automatically purchase another $20 whenever the balance fell below a specified threshold. By the time I recognized what was happening, the charges had accumulated.
OpenAI responded responsibly. The charges were refunded, and the automatic-recharge feature was disabled. I was relieved, but the financial-control problem was only the visible part of the incident. The more consequential question was why my workflow had consumed enough tokens to trigger so many recharges in the first place.
The answer was uncomfortable because much of the consumption had been produced by practices I considered rigorous. AI had helped draft and revise a manuscript of approximately 275,000 words. It had inspected repository controls, compared versions, verified corrections, supported independent model reviews, reconciled findings, prepared publication materials, and tested whether accepted changes had been executed correctly. Much of that work improved the book.
Some of it, however, came from repeatedly reloading context, reprocessing documents, reverifying facts that had not changed, rebuilding handoffs that already existed, and verifying earlier verification work. The workflow was behaving exactly as instructed. It had permission to continue, and every additional control condition gave it another reason to run.
What it lacked was a reason to stop.
That distinction exposed a control problem that extends well beyond one credit setting or one publishing project. Most discussions of AI governance ask whether a system is authorized to perform an action, whether a human remains accountable, and whether the result can be traced to evidence. Those questions are necessary, but they are incomplete. An AI system may be authorized to continue and still be economically unjustified in doing so.
Authorization establishes what a system may do. It does not establish that another cycle remains worth its cost.
Two Reinforcing Loops
The incident involved two separate automation loops. The first was financial: when the credit balance crossed a threshold, the account purchased more credits. The second was operational: when a control condition identified another review, verification, or context requirement, the AI workflow performed more work.
Each loop was locally rational. Automatic recharge prevented an interrupted session. Additional verification reduced the possibility of an undetected error. Yet neither loop was required to reconsider the value of continuing. One converted a declining balance into another purchase; the other converted the possibility of additional assurance into another inference cycle.
Together, they created a system in which consumption could continue without renewed human judgment. The account did not know whether the next purchase was economically sensible, and the workflow did not know whether the next review would resolve an uncertainty material enough to justify its cost.
This is a familiar enterprise pattern. Organizations automate a decision rule because the rule is reasonable in isolation. A queue creates another ticket. A threshold triggers another review. A failed check launches another attempt. A new document causes an entire knowledge base to be reprocessed. An agent discovers an exception and invokes another agent to evaluate it. Every transition appears defensible, yet the combined system may continue consuming money, compute, time, and attention after the marginal value of another cycle has collapsed.
The problem is not simply that AI can be expensive. Human workflows are expensive as well. The deeper problem is that machine-speed work can conceal its own accumulation. A person assigned to repeat an analysis ten times will usually ask why. A system that can repeat it in seconds may reach the tenth cycle before anyone realizes that the first acceptable answer was already available.
Rigor Can Become Waste
Verification is valuable because AI systems can produce fluent errors, overlook exceptions, misread authority, or change something outside the intended scope. In consequential work, the answer is not to remove review and trust the model more. The answer is to govern assurance economically.
Every additional check has a cost and an expected contribution. Early review cycles often create substantial value because they expose major omissions, contradictions, or boundary failures. Later cycles tend to produce smaller refinements. Eventually, another run stops resolving material uncertainty and begins reproducing reassurance.
This is where rigor can become ritual.
An organization may believe it is being prudent because several agents independently inspect the same output, a judge model scores the result, an evaluator checks the judge, and a final agent summarizes the evaluation. If these steps address distinct failure modes, the architecture may be justified. If they merely restate the same judgment in different model-generated language, the organization is paying for the appearance of control.
The same danger exists in human governance. A decision can pass through numerous committees without becoming better. AI does not create that organizational habit, but it can accelerate and multiply it. Cheap analysis encourages more analysis. Fast review encourages more review. The technical ability to run another cycle can quietly become the operational assumption that another cycle should be run.
Consequently, a mature control environment must distinguish possible verification from necessary verification. The relevant question is not whether another check might discover something. Almost any additional review might. The relevant question is whether the unresolved risk, the consequence of error, and the expected information gain justify the next unit of expenditure.
The Workflow Needed an Economic Control Layer
After the incident, I stopped the book workflow and reviewed the guidance controlling how AI was being used. The existing instructions encouraged efficiency. They called for narrow reads, reuse of verified facts, and bounded work. Nevertheless, they expressed those practices as preferences rather than enforceable controls. They did not require the system to declare why another material run was necessary, how much it was expected to cost, or what condition would end the cycle.
We changed and committed the guidance. Every substantive run would now have to identify the uncertainty being resolved, the verified facts that could be reused, the smallest sufficient input set, the cost class, the retry limit, the accepted checkpoint, and the stop condition. The revised approach also favored delta-based review, deterministic checks where reasoning was unnecessary, recovery from accepted checkpoints instead of full restarts, and human approval before expensive reruns.
These controls did not weaken the governance model used to produce the book. They completed it. The previous architecture separated review, adjudication, authorization, execution, and verification so that no AI system could convert its own recommendation into permission to change the manuscript. The new controls addressed a different boundary: even authorized work could not continue indefinitely merely because further work was technically possible.
That is the difference between governing authority and governing consumption. The first asks whether the system has permission to act. The second asks whether the expected value of acting remains proportionate to the resources consumed and the risk being addressed. AI-native operations require both.
Start With the Uncertainty
The most important control is to define what the next run is intended to resolve. “Review this again” is not a sufficient purpose. Neither is “make sure nothing was missed.” Those instructions authorize open-ended scrutiny without identifying the decision that additional scrutiny will improve.
A disciplined run begins with a bounded uncertainty. For example, a team might need to determine whether a correction altered any manuscript component outside nine authorized files, whether a revised forecast still uses the assumptions approved by the steering committee, or whether a failed security test affects a pending release decision. Each question defines a specific information gap and connects the cost of analysis to a consequential use.
Once the uncertainty is explicit, the workflow can determine what evidence is necessary. If the question concerns a nine-file correction, the system should not reread an entire repository merely because it can. If the question can be answered by comparing file identities or running a deterministic test, a frontier reasoning model may be unnecessary. If the answer already exists in a verified record and the underlying evidence has not changed, the workflow should reuse the accepted fact rather than reconstruct it.
This moves cost control upstream. Rather than measuring token consumption after the work is complete, the system limits consumption by defining the smallest sufficient analytical problem before work begins.
Use Cost Classes Before Exact Estimates
AI costs are not always predictable enough to manage through precise estimates. The size of retrieved context can vary, an agent may call tools iteratively, and a difficult task may require more reasoning than expected. That uncertainty does not eliminate the need for control. It makes classification more useful.
A practical workflow can assign each proposed run to a simple cost class. A low-cost run might inspect a small, known set of files or perform a deterministic comparison. A medium-cost run might reconcile several artifacts, analyze a bounded history, or produce a substantive draft from established sources. A high-cost run might review an entire manuscript, traverse a large repository, compare independent model findings, or repeat an analysis with a frontier model.
The purpose of the class is not accounting precision. It is to change the authorization behavior. Low-cost, reversible tasks may proceed under standing authority. Medium-cost tasks may require a declared uncertainty and a defined checkpoint. High-cost tasks should require explicit human approval, an explanation of why lower-cost methods are insufficient, and a clear statement of what decision the work will support.
This is analogous to other risk-based controls. Organizations do not subject every purchase, change, or investment to the same approval path. They use thresholds because consequence and exposure differ. AI work should be governed in the same way. A two-file formatting check and a full independent review of 275,000 words are not the same class of action merely because both are initiated through prompts.
Retries Must Have Limits
Retries are another place where reasonable automation can become wasteful. A transient tool failure may justify trying again. A malformed output may justify one corrected prompt. An interrupted run may justify recovery. However, repeated failure often indicates that the task, context, tool, or model needs to change.
Without a retry limit, a system can spend resources reproducing the same failure under slightly different conditions. This is especially dangerous when agents can invoke tools, hand work to other agents, or reconstruct large contexts before each attempt. The visible error may be small, while the cost of reaching it repeatedly is substantial.
A retry policy should therefore identify both a maximum count and an escalation condition. After the limit is reached, the workflow should stop, preserve the evidence from the failed attempts, and return the problem for human judgment. The next decision may be to narrow the task, choose a different model, correct the source material, change the tool, accept a manual step, or conclude that the result is not worth pursuing.
The essential principle is that failure does not grant the system unlimited authority to consume resources in search of success. A retry is a new expenditure, not a continuation without consequence.
Checkpoints Prevent Full Restarts
The book project already used frozen commits, branches, decision records, and verified states to govern intellectual work. The cost incident revealed another benefit of that architecture: accepted checkpoints reduce the need to rebuild context.
When a workflow preserves the last verified state, a failed or interrupted run can resume from that point. It does not need to reread every source, reconstruct every decision, or revalidate every unchanged fact. The system can inspect the delta between the checkpoint and the current proposal.
This is one reason governed state matters economically, not only procedurally. Version control, accepted facts, evidence identities, and bounded handoffs are forms of reusable computational memory. They allow later AI work to depend on verified results without paying repeatedly to rediscover them.
By contrast, a workflow that stores its reasoning only inside transient conversations forces each new session to reconstruct the project. The organization pays again for orientation, context assembly, and historical explanation. What appears to be model consumption is often an operating-model failure: the work has no durable state from which the model can continue.
The principle is straightforward. Restart only what failed. Reopen only what changed. Reverify only the claims affected by the change.
Stop Conditions Must Be Explicit
Most workflows define how work starts and what it should produce. Far fewer define when further work is no longer justified.
An effective stop condition might be reached when the declared uncertainty has been resolved, the output satisfies an agreed acceptance threshold, the retry limit has been reached, the next cycle would repeat unchanged evidence, the estimated cost moves into a higher class, or the remaining uncertainty is too immaterial to affect the decision. A stop can also be triggered when new human authority is required or when additional evidence must come from a professional source rather than a model.
These conditions prevent the system from interpreting every imperfection as permission for another iteration. They also force the organization to state what “good enough” means before seeing an endlessly improvable result.
That phrase can make leaders uncomfortable. In consequential settings, “good enough” may sound like a retreat from quality. In fact, every governed process already uses sufficiency thresholds. Financial audits, engineering tests, security reviews, legal analyses, and investment decisions do not eliminate all uncertainty. They establish what evidence is sufficient for a defined purpose under a defined standard.
AI assurance should do the same. The objective is not maximum possible analysis. It is sufficient, traceable, decision-relevant analysis at a cost proportionate to consequence.
The Enterprise Version of the Problem
The implications become more significant as organizations deploy agents across enterprise workflows. Imagine an AI system maintaining a governed project record. It continuously reads meetings, schedules, tickets, financial data, test results, contracts, and technical telemetry. It identifies contradictions, updates proposed project state, prepares executive questions, and routes exceptions for review.
Such a system could create enormous value. It could also create enormous consumption if every new signal caused a full reanalysis of the project, every discrepancy invoked several specialist agents, and every unresolved exception triggered repeated attempts to reconcile the same evidence.
The operating model therefore needs an economic decision surface alongside the governance decision surface. Leaders should be able to see what uncertainty a run addresses, what evidence it will inspect, which prior results it will reuse, what cost class it occupies, how many attempts remain, what checkpoint protects completed work, and what condition will stop the process.
Those controls should not be buried in model infrastructure. They are management controls because they determine how organizational resources are converted into analysis. A technically successful agent that consumes more value than it creates is not an operational success.
This is particularly important because tokens are not the ultimate business metric. Low token consumption does not prove that a workflow is valuable, and high consumption may be entirely justified when a consequential decision is at stake. The economic question is comparative: did the work reduce enough uncertainty, avoid enough risk, improve enough quality, or accelerate a valuable decision sufficiently to justify its total cost?
That total cost includes more than the model bill. It includes retrieval and storage, tool calls, orchestration, monitoring, human review, exception handling, rework, delay, and the opportunity cost of attention. A workflow can be inexpensive per token and still be wasteful in operation.
Economic Governance Is Not Cost Cutting
It would be easy to draw the wrong conclusion from my experience and respond by minimizing AI use. That would sacrifice value without fixing the operating model. The independent reviews, bounded corrections, and verification cycles materially improved the book. The lesson is not that rigorous AI-assisted work costs too much. It is that rigor needs an economic architecture.
Cost control should protect valuable work by directing resources toward the uncertainties that matter most. It should make expensive review easier to justify because leaders can see what decision it supports. It should also make stopping defensible when another cycle would add little beyond reassurance.
This is the same fiduciary logic that applies to capital programs. The fact that an organization has authority to continue spending does not mean continued spending remains justified. Past investment does not create an entitlement to future investment, and technical momentum is not a business case.
AI workflows deserve the same scrutiny. Authorization must be renewed when cost, scope, or consequence changes. Continuation should be an affirmative decision supported by current evidence, not the automatic result of an agent, a threshold, or a process that has not yet encountered a hard stop.
The Larger Lesson
The automatic-recharge incident was jarring, but it revealed a weakness while the operating model was still small enough to correct. We did not hide the setback or abandon the workflow. We examined the evidence, separated the financial-control failure from the workflow-control failure, changed the governing instructions, and continued under better rules.
That response is itself a model for AI governance. A controlled system is not one that never produces an unpleasant outcome. It is one that makes the outcome visible, preserves enough evidence to explain it, assigns authority to respond, and changes the operating conditions before work resumes.
Part 5 of this series argued that an AI finding is not a decision, a decision is not authorization, authorization is not execution, and execution is not verification. Part 6 adds another boundary: authorization is not economic justification.
AI can be permitted to continue and still need a reason to do so. That reason should be explicit. It should identify the uncertainty being resolved, the decision being improved, the evidence required, the cost class, the retry limit, the checkpoint, and the condition under which the system will stop.
The question is no longer only, “Is the system authorized to continue?”
It is also, “Does continuing this way still make economic sense?”
Automation without cost awareness can turn rigor into waste. Governed correctly, however, the same automation can produce better evidence, stronger decisions, and more defensible use of resources.
The workflow may have permission to continue. It still has to earn the next cycle.
This is Part 6 of Building an AI-Native Intellectual Enterprise, a series exploring how GitHub, multiple AI systems, governed project state, evidence traceability, economic controls, and human decision authority may reshape project management and knowledge work.
Part 5 — AI Found the Problems. It Still Couldn’t Change the Book.
forensicgovernance.com/insights/ai-book-control
My first book, The Sentient PMO
https://a.co/d/0fNNpRGV
The broader work behind Forensic Capital Governance
https://forensicgovernance.com