Skip to content
Contact
Open menuClose menu
Contact

Environmental

Agentic AI: energy, carbon, and water behind the prompt

An agent uses far more tokens than a plain query, and every token costs energy, emissions, and cooling water

Published
Reading time
8 min
Author
Takter Insights
In this article

The agentic AI footprint is the energy, carbon, and water an AI agent consumes to complete a task. It grows quickly because the agent plans, calls tools, reviews its own work, and tries again, and each step sends the model a context that keeps getting longer. A study published in 2026 found that coding tasks performed by agents consume about a thousand times more tokens than a code question put to the same model.

Navveen Balani, executive director of the Green Software Foundation (GSF), the body behind the software carbon measurement standard adopted by ISO, wrote in June 2026 that agents are now the biggest efficiency problem in AI. In Balani's view, an organization that runs agents needs to measure each task along all three dimensions, kept apart, and design the agent to spend fewer tokens from the start.

How much does an AI agent task consume?

Far more than a single query, and with wide variation from one run to the next. In April 2026, Longju Bai and coauthors, among them Erik Brynjolfsson and Alex Pentland, analyzed coding tasks run by agents on several frontier models. The agentic tasks consumed about a thousand times more tokens than code reasoning and code chat, and input tokens, more than output tokens, accounted for most of the cost.

The weight of input tokens has a mechanical cause. At every step, the agent sends the model the task history, the instructions, and the output of every tool it has already called, and that context grows with each loop. Another 2026 study, AgencyBench, by Keyu Li and coauthors, built 138 tasks across 32 real work scenarios and measured, per scenario, an average of 90 tool calls, one million tokens, and hours of execution.

Variation matters as much as volume. In the Bai study, runs of the same task differed by up to 30 times in total tokens, and the models themselves underestimated their consumption when asked to predict it. Spending more tokens did not guarantee better results either: accuracy tended to peak at an intermediate cost and level off beyond it. A budget based on the average run comes up short on exactly the most expensive tasks.

What to do: log input and output tokens for every agent task, run by run, and track the spread across runs of the same task alongside the average.

Energy, carbon, and water: three separate accounts

The token is the unit on the invoice. The kilowatt-hour, the gram of CO2 equivalent, and the liter of water are the units of impact, and each depends on a different decision. Balani treats them as three connected but distinct dimensions, and warns that using one as a stand-in for the others leaves blind spots in the inventory.

Energy is the dimension architects control directly: fewer tokens mean fewer GPU-seconds and fewer kilowatt-hours. Carbon depends on where and when the agent runs. A kilowatt-hour from a solar-heavy grid at midday emits a fraction of what the same kilowatt-hour emits on a coal-heavy grid at night, and the GSF notes that embodied carbon, the emissions from manufacturing the hardware, is rising as AI data center capacity expands. Water is the local impact. According to the GSF, evaporative cooling at a data center can consume millions of liters of freshwater a day, and a liter drawn from a water-stressed basin weighs more than a liter drawn elsewhere.

The three accounts can move in opposite directions. Shifting a workload to a region rich in renewable power cuts emissions and can worsen water scarcity if the region is in drought. Replacing hardware with more efficient equipment lowers energy per token and adds the manufacturing emissions of the new machines.

What to do: in the emissions inventory, report AI along all three dimensions, broken down by cloud region, and ask the provider for energy, carbon, and water data for the region where each agent runs.

Measuring per task: the SCI and SCI for AI

The method already exists as an international standard. The Software Carbon Intensity (SCI) specification, created by the GSF, was published in 2024 as ISO/IEC 21031:2024. It calculates a software system's emissions rate with the formula SCI = ((E × I) + M) per R: the energy consumed (E), in kilowatt-hours, multiplied by the carbon intensity of the regional electricity (I), plus the embodied emissions of the hardware (M), divided by a functional unit (R), such as an API call, a user, or a minute of use.

The result is a rate, so it can compare two versions of the same system and track a target even as usage volume changes. For an agent, the most useful functional unit is usually the completed task: the document reviewed, the ticket closed, the order processed.

SCI for AI, ratified by the GSF community in late 2025, extends the method to the full lifecycle of an AI system, from inception to end of life, including data preparation, training, and operation. The GSF is also developing a dedicated standard for software energy efficiency, Software Energy Efficiency (SEE), with water usage planned as the next step, and a standard for cloud providers to publish hourly, region-by-region energy and carbon data.

What to do: choose the functional unit for each agent and calculate the SCI per unit before comparing models, vendors, or cloud regions.

Taiwan and the SCI in companies

Taiwan shows the SCI moving from government to business. The Taiwan Institute of Economic Research (TIER), an independent economic think tank founded in 1976, has run the green software initiatives of Taiwan's Ministry of Digital Affairs since 2024. In an interview with the GSF published in July 2026, researcher Mei-Lian Wei said the institute has developed carbon calculation tools for software and websites and is running 2026 pilots to help Taiwanese companies apply the SCI.

Wei described green software as the means to turn digital emissions, today abstract and hard to quantify, into metrics a company can act on. The Taiwanese program adopted the existing standard instead of creating a national metric, so companies measure with the method the ISO standard describes and can compare results with each other.

For a company in Brazil or anywhere else, the same path is open: the standard is published, and applying it takes two decisions, the software boundary (what goes into the calculation) and the functional unit.

What to do: start with a pilot on a digital service with known traffic, with the boundary written down (servers, network, storage, and the model the agent calls) and the SCI recalculated for every release of the service.

The token that is never generated

The lowest-impact token is the one the system never generates. Balani lists what is already available for that: routing simple steps to smaller models, caching responses and context, specialized models, retry limits, and human review checkpoints. None of these comes switched on by default in agent-building tools, and it falls to the team to turn them on.

The decision starts before the project. Not every problem needs an agent, not every agent needs a reasoning model, and not every step needs the full context. The question that decides whether an AI project pays off, which line of the income statement it moves (AI ROI), also decides whether the problem justifies what an agent consumes. Because accuracy levels off past an intermediate cost, cutting tokens usually reduces the energy bill without reducing accuracy, and the cloud bill falls with it.

What to do: set a token and retry budget per task for each agent, a smaller model as the default and the reasoning model only for the steps that require it, and revisit the budget when accuracy stops improving.

Conclusion

An AI agent's footprint is measured per task, in energy, carbon, and water, and each account responds to a different decision: how many tokens the agent spends, where and when it runs, and how it is cooled. The SCI, an ISO standard since 2024, provides the method for energy and carbon, and SCI for AI extends it across the AI lifecycle. The next step is to choose a functional unit for each agent, log consumption per run, and set a token budget before the next agent goes into production.

Sustenext Green IT® measures the IT footprint the same way as the rest of the inventory, with the source of every number traceable. In the software module, Green IT calculates the carbon intensity of each digital service per transaction, using the Green Software Foundation's SCI method, with a carbon budget per service; in the cloud module, it shows the footprint of each account with the grid carbon intensity of each region and simulates shifting workloads to lower-intensity time windows and regions. To measure the footprint of your organization's digital services and agents, talk to Takter.

Sources

Solutions

Sustenext Green IT®

Explore the solution Talk to a specialist

More insights

All insights