SCI for AI gives agent workflows a carbon denominator
It is easy to make an AI agent look efficient on paper. Count the final model call, divide by tokens, and leave out the retrievals, tool calls, retries, monitoring, and hardware that produced the result.
The number may be precise, but it answers the wrong question.
The Green Software Foundation's newly ratified Software Carbon Intensity for AI specification proposes a more useful denominator for agentic systems: one workflow execution. The specification extends ISO/IEC 21031:2024. When operations are material, it includes the whole runtime path inside the measurement boundary.
An agent is a small software system, not a single prompt. It decides, searches, calls tools, checks results, and sometimes starts again. Measurement should follow the work delivered to a user rather than the text passing through one model.
The formula is simple; choosing the boundary is harder
SCI for AI keeps the parent standard's formula:
SCI = (O + M) / R
O is operational emissions. M is allocated embodied emissions from the hardware. R is the functional unit, the useful work against which the emissions are normalized.
For an LLM service, the specification suggests tokens as a consumer functional unit. For agentic AI, it suggests a workflow execution. It also says that services with multiple model calls or integrations can include model executions, tool use, retrieval, model-to-model exchanges, and any other material operations.
An agent that uses fewer tokens per call can still consume more energy per completed task when it makes more calls, enters long tool loops, or retries failures. Measuring the workflow exposes those costs.
The specification divides responsibility into two boundaries. The provider boundary covers inception, design and development, deployment, and retirement. Its training calculation includes test runs, stopped jobs, hyperparameter searches, and discarded checkpoints. The consumer boundary covers operation and monitoring: inference, API infrastructure, orchestration, scaling, observability, storage, client software, and tool connectors.
If your product calls an external model API, you can measure the consumer boundary under your control. A complete provider score requires data from the provider.
Cheaper queries can coexist with rising electricity demand
The denominator has consequences beyond reporting. The International Energy Agency's April 2026 Key Questions on Energy and AI says energy use per AI task has fallen by at least an order of magnitude annually in recent years. Reasoning, video, and agentic tasks, however, can use hundreds or thousands of times more energy per query than simple text generation.
Better chips and software reduce the cost of a narrow task. More users and more elaborate workflows can still push total demand upward. The IEA estimates that global data-center electricity demand grew 17% in 2025, while electricity use at AI-focused data centers grew 50%. Its central projection rises from 485 TWh in 2025 to 950 TWh in 2030.
"Per query" hides too much variation to guide an engineering decision. A short answer, a video render, and a repository-wide code migration are different products. One token-based number cannot make them comparable.
Measure an outcome a user can recognize
Choose one outcome such as "one pull request reviewed," "one support case resolved," or "one invoice reconciled." That is more useful than "one prompt submitted." Define completion and decide how failed runs will appear in the report.
Measure a representative period instead of a polished demo:
- Set the workflow boundary. Include the application, orchestration layer, model calls, retrieval, tool services, storage, monitoring, and client-side work that materially contribute to the result.
- Record operational energy, or the closest defensible estimate, for each component. Separate measurements from estimates and document the source and time window.
- Apply location-based grid carbon intensity to the energy consumed. Allocate embodied hardware emissions across the same period and boundary.
- Count completed workflow executions. Report failures separately instead of deleting them from the numerator.
- Divide operational plus embodied emissions by completed workflows. Keep tokens, tool calls, wall time, retries, model route, and quality outcome as diagnostic fields.
Agent observability already captures much of the denominator. The same traces used to explain agent failures can count model invocations, tool loops, and retries. Teams can then test a context-budget policy against task quality and carbon intensity.
When a product can route the same workload across models, including through a multi-model endpoint such as api.ish.chat, keep the test fixture, completion rule, and quality threshold fixed. Compare models only under matching conditions. A lower score is not useful when the workflow fails more often or transfers work to a human reviewer.
Use the baseline to find wasted work
Long traces may show the same documents being retrieved repeatedly. Tool logs may reveal retries caused by brittle schemas. A large model may be handling steps that a smaller model or deterministic function can complete. Nightly batch work may be movable to a place or time with lower grid carbon intensity.
Change one variable, then rerun the same workload. Track quality beside SCI so the score cannot be improved by truncating answers, skipping checks, or tolerating more failures. Every result should state the functional unit, boundary, model version, region, measurement period, and assumptions.
The specification does not let offsets reduce the score. Carbon credits, renewable energy certificates, power purchase agreements, and similar market instruments do not lower SCI for AI. Only reductions in energy use, hardware footprint, or grid carbon intensity do. The rule makes the metric harder to polish with procurement claims and more useful for engineering.
Carbon is one part of the environmental bill
SCI for AI measures carbon intensity. It does not provide a complete environmental impact assessment. The OECD's AI footprint framework separates production, transport, operation, and end of life. It discusses energy, water, greenhouse gases, and material impacts. Lawrence Berkeley National Laboratory's US data-center energy report also examines electricity, water, and carbon at infrastructure scale.
A low SCI score does not establish low water use, responsible mineral sourcing, or acceptable effects on a local grid. Those limits belong in the report. Communities near data centers experience infrastructure through megawatts, water withdrawals, construction, and electricity bills, not tokens.
Start with one defined workflow, one measured week, separate provider and consumer boundaries, a quality threshold, and an assumptions table. Publish enough detail for another engineer to inspect the number and reproduce it.
