The Circular Economy of AI: Use Less to Do More

The waste is often in the repetition

Imagine an operator asking an AI system to review a supplier claim. The system loads a long conversation, several versions of the same report, copied web pages, old notes, and a high-capability model. It produces an answer, but nobody records which evidence was decisive. A week later, a similar question arrives and the system loads everything again.

This is not only a computing problem. It is a circularity problem. Useful knowledge was not preserved in a form that could be checked and reused. Raw material entered the workflow, a result came out, and much of the value in between was discarded.

A more circular AI system identifies the question, retrieves only relevant evidence, uses an appropriately capable tool, retains the verified conclusion with its source trail, and makes that result available for later work. If the evidence changes, the record shows what changed instead of silently duplicating the whole history.

That design may reduce computation, data transfer, storage, cost, and human rework. It may also improve consistency and resilience. None of those outcomes should be assumed. They should be tested against a defined baseline and a completed-task quality threshold.

What a circular economy of AI means in plain language

The circular economy moves away from a linear pattern of extraction, use, and disposal. In an AI workflow, scarce resources include chips and electricity, but also trustworthy data, network transfer, stored copies, model calls, human review time, and the attention required to verify a result.

A circular AI workflow tries to keep the value of those resources in use. It asks what the task actually requires, what work has already been verified, what tool is sufficient, and what must be retained so the next task does not begin from zero.

The International Energy Agency's 2026 analysis describes rising data-centre investment and electricity demand alongside uncertainty, physical bottlenecks, and rapidly changing efficiency. That is a reason to measure carefully. It is not a basis for attaching a fixed energy or emissions number to every token or request.

• Define the task and its acceptance threshold before choosing the model.
• Retrieve the smallest sufficient evidence set, not the smallest possible input.
• Reuse prior work only when its source, scope, date, and approval still hold.
• Measure one accepted outcome rather than one model response.

Principle 1: retrieve only the memory the task needs

Long context is convenient because it postpones the decision about relevance. The system can send everything. That convenience can increase repeated processing, latency, cost, and exposure of irrelevant or sensitive material. It can also make it harder to see which evidence shaped the answer.

Retrieval-augmented generation separates externally stored knowledge from the material selected for a generation step. The original RAG paper by Lewis and colleagues established a technical basis for combining parametric and retrieved non-parametric memory. It did not show that every RAG implementation uses less energy.

For an operator, retrieval should be selective, attributable, and testable. Too little context can create errors and rework, so the objective is the smallest sufficient evidence set, not the shortest possible prompt.

• Retrieve by task, entity, date, authority, permission, and access boundary.
• Limit retrieved passages unless a quality test shows that more evidence is needed.
• Record which passages were used so a reviewer can replay the decision.
• Measure retrieval misses and incorrect exclusions, not only context length.

Principle 2: retain verified evidence, not permanent duplication

Raw logs have legitimate uses in audit, incident review, safety investigation, and regulated retention. Keeping every intermediate copy as permanent working memory is different. It makes later retrieval noisier and can preserve sensitive or stale material without a clear operational reason.

A more durable working unit is a compact evidence record: the question or claim, source, relevant fact, date and scope, method, reviewer state, caveats, expiry condition, and a link back to retained raw material where retention is justified.

This does not authorize deletion of required source evidence. Raw files remain the source layer. The distilled record becomes the reusable working layer. Summaries without provenance should never replace originals.

W3C PROV-O provides a standard vocabulary for describing entities, activities, agents, and derivation. NIST's Generative AI Profile recommends attention to data origin, content lineage, transformations, and upstream dependencies. These sources support provenance and reviewability; they do not establish environmental savings from distillation.

• Keep source, date, method, owner, caveat, and expiry visible.
• Separate raw-record retention from reusable working memory.
• Provide a correction path when evidence changes or conflicts.
• Compare storage, transfer, retrieval, model processing, and review effort before making a savings claim.

Principle 3: set budgets for tokens, transfer, tools, and retries

Unlimited context and retries are easy defaults because the resource boundary is invisible to the person asking the question. A circular operating model makes that boundary explicit while preserving an escalation path for high-risk or evidence-heavy work.

A budget can cover retrieved passages or bytes, input and output tokens, model escalations, external requests, tool calls, and automatic retries. It should also include a stop condition when evidence is insufficient.

Token counts are useful operating metrics, but they are not carbon metrics. Energy per request can vary with model architecture, hardware, batching, utilization, software, location, provider operations, and result quality. A shorter request that fails repeatedly may create more total work than a longer request completed once.

• Set a first-attempt context and tool budget by task class.
• Require a reason for escalation rather than silently expanding every request.
• Include failed attempts, retries, and human correction inside the measurement boundary.
• Keep a wider evidence allowance for consequential work where completeness matters more than speed.

Principle 4: reuse prior verified work before generating again

Circular systems preserve value. For AI operations, that means checking whether a usable result already exists before recomputing it. Reusable work may include a verified calculation, an approved supplier explanation, a reviewed policy definition, a tested code transformation, or a validated data mapping.

Reuse requires more than similarity. The workflow should test scope, date, source authority, permissions, approval state, and whether the evidence has changed. When those conditions fail, reuse can spread an old mistake faster.

A practical pattern is reuse, verify the delta, and recompute only what changed. The output should show which part came from prior approved work and which part is new. Reuse without provenance is copying; reuse with provenance, expiry, and change tracking is retained operational value.

• Search approved evidence objects before starting a new generation step.
• Invalidate or refresh records whose source, policy, product, or owner has changed.
• Preserve disagreement and uncertainty instead of collapsing them into one reusable sentence.
• Log the delta so a reviewer can distinguish retained work from new inference.

Principle 5: route each step to the smallest sufficient capable tool

Classification, extraction, search, arithmetic, translation, drafting, and high-stakes synthesis do not need the same capability. A strong system can route each step to a deterministic tool, specialist model, smaller model, or stronger general model according to a tested acceptance threshold.

FrugalGPT studied prompt adaptation, approximation, and model cascades to reduce inference cost while maintaining or improving measured task performance in its experiments. RouteLLM studied learned routing between stronger and weaker models using preference data. These papers support the technical feasibility of routing; they do not prove universal energy or emissions savings.

Cost is not identical to energy or emissions. Benchmarks are not production workloads, and routers add computation and failure modes. The complete cascade therefore belongs inside the evaluation boundary. Sometimes the sufficient tool is not a language model at all: a database query, parser, calculator, or rules engine can be more accurate and easier to audit.

• Define the acceptance threshold before selecting the tool.
• Start with the least resource-intensive tool demonstrated to meet that threshold.
• Escalate when uncertainty, evidence complexity, or consequence requires it.
• Record router overhead, wrong assignments, retries, and final acceptance.

Principle 6: stay resilient across providers without duplicating everything

Efficiency should not depend on one opaque service remaining available forever. If a provider, model, or API becomes unavailable, changes terms, or fails a quality test, the workflow should be able to move without rebuilding its evidence from zero.

Provider resilience can come from portable task and evidence schemas, provider-neutral source records, clean interfaces between retrieval and generation, exportable provenance, evaluation sets, and tested fallback paths for critical work.

Resilience has a resource cost. Multiple integrations, duplicated caches, and idle fallback capacity add engineering and infrastructure. The circular objective is not maximum redundancy. It is enough portability to avoid concentration and lock-in turning a provider change into wasteful rework.

NIST's AI Risk Management Framework connects resilience, transparency, measurement, third-party dependencies, and lifecycle governance. That supports this operating logic, but it does not prove that a multi-provider architecture lowers environmental impact.

• Keep source evidence and approval records in portable formats.
• Separate task definitions from provider-specific prompt wrappers.
• Test representative workloads across candidate tools before an emergency.
• Retain only the fallback capacity justified by continuity risk.

The operating loop: ask, retrieve, route, verify, retain, learn

A circular AI workflow can be organized as six connected steps. First, ask: define the task, risk level, acceptance criteria, and evidence boundary. Second, retrieve: find the smallest evidence set likely to answer the question, ranked by authority, relevance, date, permission, and prior approval.

Third, route: choose a deterministic tool, specialist model, smaller model, or stronger model based on demonstrated task performance. Fourth, verify: check the output against evidence and the quality gate, with named human review for consequential work.

Fifth, retain: store the approved result as a compact evidence object with provenance, caveats, owner, and expiry, while keeping raw source material according to legal, audit, privacy, and operational needs. Sixth, learn: update retrieval rules, routing thresholds, and reusable records from verified outcomes rather than treating every output as truth.

The loop is circular only when retained value reduces unnecessary future work without weakening evidence, quality, privacy, or human control.

• Ask: define the job and its acceptance test.
• Retrieve: select the evidence needed for this job.
• Route: choose a sufficient tool and justify escalation.
• Verify: replay sources, measure quality, and record uncertainty.
• Retain: preserve the approved result with provenance and expiry.
• Learn: update the workflow from verified outcomes and correction history.

A practical operating checklist

Begin with one task class rather than an organization-wide promise. Choose a functional unit such as one accepted supplier review, one resolved ticket, one verified report section, or one approved product-data update. Record the current workflow before changing it.

During operation, keep source and date visible, use deterministic tools for deterministic work, escalate when uncertainty requires it, and stop when evidence is insufficient. After completion, retain the approved result with provenance and compare the full accepted outcome with the baseline.

Review the system periodically. Routing thresholds, providers, evidence, access rights, electricity conditions, and workload can all change. A result measured once should not become a permanent environmental claim.

• Define one task class, one baseline, one quality threshold, and one evidence boundary.
• Record tokens, requests, transfer volume, latency, cost, human review, and rework.
• Limit automatic retries and explain each capability escalation.
• Store source, method, owner, caveat, approval, and refresh conditions with the result.
• Audit stale memory, duplicate evidence, routing quality, portability, privacy, and continuity risk.
• Publish no savings claim that cannot be replayed from measured records.

Measure the complete accepted outcome

The Green Software Foundation's Software Carbon Intensity specification offers a useful discipline: define a software boundary and a functional unit, then account for operational energy, location-based carbon intensity, and embodied hardware emissions. Its SCI for AI work extends the discussion toward AI systems. A valid calculation still requires system-specific data and disclosed assumptions.

For this operating thesis, the recommended functional unit is one accepted task outcome at a defined quality level. Compare the baseline and proposed workflow under the same workload, period, quality threshold, and boundary. Otherwise a lower number may simply reflect a smaller task, lower quality, or work moved outside the measured system.

Track both intensity per accepted outcome and absolute workload. Lower cost per task can increase total use, so an efficiency gain does not automatically produce a lower total footprint.

• Accepted outcomes per 100 tasks and the reasons for rejection.
• Input and output tokens, retrieved bytes, network transfer, tool calls, retries, and escalations per accepted outcome.
• Latency, monetary cost, and human review minutes.
• Stale-evidence, provenance, privacy, and quality failures.
• Measured energy where infrastructure access allows it, plus operational and embodied emissions with method and uncertainty stated.
• Absolute workload growth alongside per-outcome intensity.

Limits and trade-offs

Less context can reduce quality when retrieval misses the decisive document. Distillation can remove nuance or disagreement. Smaller models can consume more total resources if they fail repeatedly. Routers add overhead, monitoring, and new failure modes.

Reuse can preserve stale mistakes. Provider portability can require extra adapters, formats, tests, and retained capacity. Energy and emissions also vary with hardware, utilization, electricity mix, cooling, timing, and system boundaries, while public provider data may be too aggregated for precise task-level claims.

Efficiency can also produce rebound: when each task becomes cheaper, total usage may grow. This is why the operating record must preserve quality, absolute workload, uncertainty, and correction history alongside resource intensity.

The circular economy of AI is therefore not a campaign against capable models. It is a discipline for using capability with less avoidable repetition while keeping evidence and human judgment intact. The honest sustainability claim comes last, after the system boundary, functional unit, baseline, and measured result are visible.

• Widen retrieval for high-risk tasks when the evidence set is uncertain.
• Keep a route back to source records whenever a compact evidence object is reused.
• Evaluate the complete cascade, not only the model selected first.
• State measurement uncertainty and avoid converting tokens or cost directly into emissions.
• Track absolute growth so efficiency does not hide a larger total footprint.

Use less to do more is an operating question

Retrieve what the task needs. Preserve verified evidence instead of permanent duplication. Reuse work whose scope and sources still hold. Route each step to the smallest sufficient capable tool. Keep the system portable enough to survive provider change. Measure the accepted outcome, including failure and rework.

Use less to do more is not a promise that every shorter prompt is greener. It is an operating question: can the system deliver the same or better accepted outcome while using fewer material, computational, data, and human resources, and can another reviewer verify that result?