Friday, 16 October 2026

The New AI Stack in 2026

Standard


In 2023, the stack was simple: pick a Large Language Model (LLM), wrap it in a chat User Interface (UI), ship. In 2026, production artificial intelligence (AI) looks like a five-layer cake:

Model → Agent → MCP → Tools → Infrastructure

The model reasons. The agent plans, remembers, and enforces policy. Model Context Protocol (MCP) standardizes how the agent reaches the outside world. Tools are the actual systems of record: GitHub, Jira, Customer Relationship Management (CRM), databases, browsers. Infrastructure is where it all runs: gateways, identity, sandboxes, Kubernetes (K8s), observability, and horizontally scaled MCP servers (Model Context Protocol, n.d.; TrueFoundry, 2026; Microsoft, 2026).

Teams that treat "we use GPT" as the whole architecture build demos. Teams that map all five layers build systems that survive contact with enterprise reality.

Key Abbreviations in This Post

  • LLM (Large Language Model): A neural network trained on text for language understanding and generation.
  • SLM (Small Language Model): A compact model optimized for on-device or low-cost inference.
  • MCP (Model Context Protocol): Open standard connecting AI hosts to tools, resources, and prompts (Model Context Protocol, n.d.).
  • API (Application Programming Interface): Programmatic access to software systems.
  • JSON-RPC (JSON Remote Procedure Call): Protocol MCP uses for host-server communication.
  • A2A (Agent-to-Agent): Google's protocol for agent discovery and delegation (Google, n.d.).
  • CRM (Customer Relationship Management): Software for customer records and sales workflows.
  • IAM (Identity and Access Management): Systems governing who or what can access resources.
  • NHI (Non-Human Identity): Credentials used by service accounts, agents, and automation.
  • K8s (Kubernetes): Container orchestration platform for scaling services.
  • SEP (Specification Enhancement Proposal): Formal MCP spec change document.

The One-Minute Version

  • Model: The reasoning engine. Increasingly swappable and partially commoditized.
  • Agent: The product layer. Harness, memory, orchestration, discovery, governance.
  • MCP: The standard wire format between agents and capabilities. Stateless as of July 2026 (Model Context Protocol, 2026).
  • Tools: Real integrations that mutate state in your organization.
  • Infrastructure: Identity, scaling, audit, sandboxes, and policy enforcement outside the model.
  • Moat in 2026: Layers 2 through 5, not layer 1 (TrueFoundry, 2026; Knowlee, 2026).

Old Stack vs New Stack

Era Stack What broke
2023 chatbot Model + UI Human copy-paste integration, no memory, no audit
2024 copilot Model + plugins/RAG Custom glue per integration, tool sprawl in prompt
2026 agent platform Model + Agent + MCP + Tools + Infra Complex, but composable and governable
The New AI Stack (2026) Model → Agent → MCP → Tools → Infrastructure 5. Infrastructure K8s, gateways, identity, sandboxes, observability, stateless MCP scale-out You own this 4. Tools GitHub, Jira, CRM, databases, browsers, file systems, internal APIs Your systems 3. MCP Host / client / server, JSON-RPC, discovery, auth, tool schemas Standard wire 2. Agent Harness, memory, orchestration, discovery, policy, human gates Your product 1. Model GPT, Claude, Gemini, Phi, local SLMs: reasoning engine, swappable Commodity ↓ ↓ ↓ ↓ ↓ Value and risk accumulate as you move down the stack

Layer 1: Model (The Engine, Not the Product)

The model is where most conversations start and where least durable advantage lives in 2026. GPT-6 Astra, Claude Opus-class, Gemini, Phi-4-reasoning, local Small Language Models (SLMs) on laptop Neural Processing Units (NPUs): all are interchangeable inputs to the same agent harness (OpenAI, 2026; Microsoft Research, 2025; Chandra & Krishnamoorthi, 2026).

What the model provides:

  • Language understanding and generation.
  • Reasoning over context (quality varies by tier).
  • Tool-call intent: which function to invoke with what arguments.

What the model does not provide:

  • Persistent memory across sessions (unless the agent layer adds it).
  • Reliable multi-step workflow execution.
  • Authentication, authorization, or audit trails.
  • Guaranteed correct tool selection from 400 similar schemas.

Smart teams pick models by task routing: frontier cloud for hard reasoning, local SLM for high-volume classification, mid-tier for cost-sensitive agent loops (Chandra & Krishnamoorthi, 2026). The model is the engine. You do not sell the engine. You sell the car.

Layer 2: Agent (Where the Product Lives)

An agent is not a model with a system prompt. It is a runtime that wraps the model in a loop:

  1. Observe context (user message, memory, tool results).
  2. Reason and plan next action.
  3. Call tools or delegate to sub-agents.
  4. Update state, retry on failure, escalate to humans.
  5. Repeat until done or bounded.

The agent layer includes components that separate demos from production (MindStudio, n.d.; Agent Operating System, 2026):

  • Harness: Retry logic, context management, subagent spawning, evaluators (OpenAI, 2026).
  • Memory: Session, user, and org knowledge that survives turns and tabs.
  • Orchestration: LangGraph-style workflows with explicit state, not hidden prompt chains (TrueFoundry, 2026).
  • Tool discovery: Progressive loading, semantic routing, MCP-Zero-style catalogs instead of dumping 2,800 schemas into context (Xu et al., 2025; Spring AI, n.d.).
  • Governance: Human approval gates, policy checks, misalignment monitoring (OpenAI, 2026; OWASP GenAI Security Project, 2025).

Microsoft's Windows agent runtime, OpenAI Codex, and Amazon Bedrock AgentCore all sit at this layer. The model inside can change. The harness is what users and enterprises actually depend on (Microsoft, 2026; Eluna, 2026).

Layer 3: MCP (The Standard Wire)

Before MCP, every agent platform invented its own plugin format. Salesforce had one shape. GitHub Copilot another. Internal platforms a third. MCP replaces that fragmentation with a shared protocol (Model Context Protocol, n.d.).

Three roles:

  • Host: The AI application (Cursor, Claude Desktop, Copilot, your agent platform).
  • Client: One JSON-RPC client per server connection, inside the host.
  • Server: Your integration exposing tools, resources, and prompts.

MCP servers expose:

  • Tools: Callable functions (create_ticket, run_query).
  • Resources: Readable data (files, database views).
  • Prompts: Reusable templates.

The July 2026 spec made remote MCP stateless: no session handshake, no sticky pods. Each HTTP request carries client identity in _meta. Gateways read Mcp-Method and Mcp-Name headers for routing (Model Context Protocol, 2026). That turns MCP from a local dev trick into production infrastructure behind load balancers.

MCP is not the only protocol. Google's Agent-to-Agent (A2A) handles delegation between agents. Many teams use both: MCP for tools, A2A for multi-agent handoffs (Google, n.d.). Think of MCP as USB-C for capabilities. A2A is the office phone system between departments.

Layer 4: Tools (Where State Actually Changes)

Tools are the reason agents matter. A tool call creates a Jira ticket, charges a card, deletes a file, merges a pull request. This is where blast radius lives (Cloud Security Alliance, 2026).

Tools arrive through several patterns in 2026:

  • MCP servers: Packaged integrations (official GitHub MCP, internal CRM MCP).
  • Agent Connectors: Microsoft Windows on-device registry for File Explorer, Settings, and third-party connectors (Dave R, 2026).
  • Native computer use: GPT-6 Astra driving browser and desktop directly, bypassing formal tool schemas for some tasks (OpenAI, 2026).
  • Legacy APIs: Wrapped behind MCP servers so agents never touch raw REST (Representational State Transfer) diversity.

Tool design principles that survive production:

  • Small surface area. Prefer search_issues and update_issue over one mega-tool that does everything.
  • Explicit schemas. Clear names reduce wrong-tool errors when catalogs grow (Spring AI, n.d.).
  • Idempotent where possible. Agents retry. Non-idempotent tools need guardrails.
  • Backend enforcement. Never rely on the model to respect "do not delete" in the system prompt (Cloud Security Alliance, 2026).

MCPTox showed 72.8% success poisoning tool metadata on real MCP servers. Tool definitions are part of your attack surface, not documentation (MCPTox, 2026).

Layer 5: Infrastructure (Where Trust Is Enforced)

Infrastructure is everything that must work even when the model is wrong. It sits below MCP and tools and enforces reality (Agent Operating System, 2026; Microsoft, 2026):

  • Identity and access. Dedicated Non-Human Identity (NHI) per agent, just-in-time credentials, tested revocation (Cloud Security Alliance, 2026; IDC, 2026).
  • API gateways. Rate limits, auth, routing for stateless MCP replicas on Kubernetes, Cloud Run, or Lambda.
  • Sandboxing. Microsoft Execution Containers (MXC), agent workspaces, cloud PCs for isolated execution (Microsoft, 2026).
  • Observability. Tool-call logging with principal, arguments, and outcome to a sink the agent cannot modify (Cloud Security Alliance, 2026).
  • Policy engines. Block destructive actions outside declared scope regardless of model intent.
  • Data plane. Databases, queues, and secrets stores where tool side effects land.

Eluna runs production warehouse agents on Amazon Bedrock AgentCore with graph-guided Standard Operating Procedure (SOP) execution. The model reasons. The infrastructure guarantees procedural compliance and auditability (Eluna, 2026). That split is the whole point of the five-layer model.

How a Request Flows Through the Stack

Example: "Refund order 4821 and notify the customer."

  1. Model parses intent and proposes a plan: lookup order, validate policy, issue refund, send email.
  2. Agent loads memory (prior interactions with this customer), checks approval policy (refunds over $500 need human gate), selects tools via discovery (not all 200 schemas).
  3. MCP routes tools/call to the Stripe MCP server and the email MCP server with authenticated client identity in _meta.
  4. Tools execute: Stripe API refund, CRM status update, SendGrid message.
  5. Infrastructure logs each call, enforces OAuth scopes, rate-limits the agent identity, and stores audit records for compliance.

If the model hallucinates a refund amount, infrastructure and tool backends catch it. If MCP metadata is poisoned, gateway inspection and schema pinning catch it. If the agent loops, orchestration checkpoints and budgets stop it. No single layer carries the full burden.

What Breaks When You Skip a Layer

Missing layer Symptom
No agent layer Chatbot that cannot sustain multi-step work or recover from failures
No MCP (ad-hoc plugins) N integrations = N custom wire formats, no shared discovery or audit
No real tools Agent generates text about actions but nothing in systems of record changes
No infrastructure Prompt injection becomes data breach; no identity, scale, or kill switch
Model-only focus Benchmark wins, production losses when tool catalog exceeds context

Real-World Use Cases (Problem → Cause → Effect)

1. IDE assistant that only swapped models

Problem: Team upgraded from GPT-5.6 Sol to GPT-6 Astra expecting 2x productivity. Gains were marginal.

Cause: Harness was unchanged: no parallel sessions, no git worktree isolation, no context notes across windows. Model swap without agent layer investment (OpenAI, 2026; Microsoft, 2026).

Effect: GitHub Copilot app with agent-native harness (parallel sessions, CI babysitting) captured the value. Model was necessary; harness was sufficient.

2. Enterprise MCP behind a load balancer

Problem: Remote MCP worked on localhost, failed in Kubernetes with session errors on the second request.

Cause: Pre-2026 stateful MCP pinned clients to pods. Sticky sessions were fragile (Model Context Protocol, 2026).

Effect: Stateless MCP (July 2026 spec) let any replica serve any request. Infrastructure layer finally matched REST-style deployment patterns.

3. Support agent with 400 tools in prompt

Problem: Agent picked wrong Jira action 30% of the time. Context window half-consumed before user spoke.

Cause: No discovery layer. Model layer alone cannot navigate large catalogs (Spring AI, n.d.; Xu et al., 2025).

Effect: Progressive MCP discovery cut initial context 70 to 90% and improved selection accuracy. Agent layer fix, not model fix.

4. "Local AI" app that synced everything to cloud

Problem: Marketing claimed on-device inference. Security review found customer data leaving the device.

Cause: Model ran locally; agent layer still posted outputs to a cloud analytics endpoint (Beagle, 2026).

Effect: Stack audit required tracing all five layers. Privacy lives in infrastructure and agent design, not model location alone.

Build Order for Teams Starting Today

  1. Pick one bounded workflow. Refund processing, ticket triage, code review. Not "general assistant."
  2. Wrap it in an agent harness. Explicit state, retries, human gates, memory scope.
  3. Expose tools via MCP. One server per domain (billing, CRM, email). Stateless HTTP for production.
  4. Implement backend enforcement on tools. Scopes, idempotency keys, rate limits.
  5. Add infrastructure before scale. Agent identity, gateway, logging, sandbox. OWASP ASI Top 10 as checklist (OWASP GenAI Security Project, 2025).
  6. Choose model last and route by task. Swap freely once layers 2 through 5 are solid.

The new AI stack is not a model picker. It is an architecture:

Model → Agent → MCP → Tools → Infrastructure

The model thinks. The agent acts with memory and policy. MCP connects. Tools mutate real state. Infrastructure enforces trust when the model is wrong, the tool is poisoned, or the agent loops too far.

In 2023, buying GPT access was the strategy. In 2026, the strategy is building layers 2 through 5 so well that the model becomes a replaceable part. The teams winning on agents are not winning on parameters. They are winning on stack discipline.

Map your system against all five layers. Fix the missing floor before you upgrade the engine.

References

  • Agent Operating System. (2026). The agent operating system (AOS): A reference operating architecture for distributed agentic systems. arXiv. https://arxiv.org/abs/2608.03214
  • Beagle. (2026). Understand Microsoft Aion 1.0 before you plan your deployment. https://www.heybeagle.com/blog/understand-microsoft-aion-1-0-before-you-plan-your-deployment
  • Chandra, V., & Krishnamoorthi, R. (2026). On-device LLMs: State of the union, 2026. Meta. https://v-chandra.github.io/on-device-llms/
  • Cloud Security Alliance. (2026). Autonomous by design, uncontrolled by default. https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/09/CSA_whitepaper_agentic_ai_loss_of_control_20260908-csa-styled.pdf
  • Dave R. (2026). Inside the Windows agent platform. ITNEXT. https://itnext.io/inside-the-windows-agent-platform-how-microsoft-turned-the-os-into-a-secure-runtime-for-1-3-a980ac1d58b0
  • Eluna. (2026). Eluna: An agentic LLM system for automating warehouse operations. arXiv. https://arxiv.org/html/2607.08960v2
  • Google. (n.d.). Agent2Agent (A2A) protocol. https://google.github.io/A2A/
  • IDC. (2026). IDC research finds AI agents outpacing security teams. https://ittech-pulse.com/news/idc-research-finds-ai-agents-outpacing-security-teams-sponsored-by-guidepoint-security/
  • Knowlee. (2026). The agentic operating system. https://www.knowlee.ai/blog/agentic-operating-system-business
  • MCPTox. (2026). MCPTox: A benchmark for tool poisoning on real-world MCP servers. AAAI. https://ojs.aaai.org/index.php/AAAI/article/view/40895
  • Microsoft. (2026). Microsoft Build 2026: Be yourself at work. https://blogs.microsoft.com/blog/2026/06/02/microsoft-build-2026-be-yourself-at-work/
  • MindStudio. (n.d.). What is an agentic operating system? https://www.mindstudio.ai/blog/what-is-agentic-operating-system
  • Model Context Protocol. (2026). Specification (2026-07-28 stateless update). https://modelcontextprotocol.io/
  • Model Context Protocol. (n.d.). Architecture overview. https://modelcontextprotocol.io/docs/concepts/architecture
  • OpenAI. (2026). GPT-6 Astra: A new generation of intelligence. https://openai.com/index/gpt-6-astra/
  • OWASP GenAI Security Project. (2025). OWASP Top 10 for agentic applications 2026. https://genai.owasp.org/download/52117
  • Microsoft Research. (2025). Phi-4-reasoning technical report. https://www.microsoft.com/en-us/research/publication/phi-4-reasoning-technical-report/
  • Spring AI. (n.d.). Tool calling and MCP integration. https://docs.spring.io/spring-ai/reference/api/tools.html
  • TrueFoundry. (2026). Agent orchestration in production. Referenced via industry deployment patterns.
  • Xu, Y., et al. (2025). MCP-Zero: Proactive tool discovery for LLM agents. arXiv. https://arxiv.org/abs/2505.07874

Sunday, 27 September 2026

UWB Devices Explained: The Radio That Knows Exactly Where Things Are

Standard

 

Before we start talking about UWB let me share some real life examples: Your phone points an arrow at a lost AirTag under the sofa cushion. Your car unlocks as you walk up, but stays locked when a thief tries to relay your key signal from the café next door. A forklift in a warehouse slows down automatically because a worker is standing two meters behind a rack it cannot see around.

All three use the same technology: Ultra-Wideband (UWB) radio. Wi-Fi and Bluetooth were built to move data. UWB was built to measure time very precisely, and that makes it the most accurate short-range positioning radio in mass production today. It can locate a device to within roughly 10 centimeters, indoors, in real time, and securely (Institute of Electrical and Electronics Engineers [IEEE], 2020; ABI Research, 2025).

This post covers what UWB is, who invented it and where, what problem it solves, how a UWB device works inside, where it is used today, and why companies build it into their products.

Key Abbreviations in This Post

  • UWB (Ultra-Wideband): Radio that spreads very short pulses over a very wide frequency band (at least 500 MHz).
  • ToF (Time of Flight): How long a radio signal takes to travel between two devices. Distance is calculated from it.
  • TWR (Two-Way Ranging): Two devices exchange messages to measure distance without needing synchronized clocks.
  • TDoA (Time Difference of Arrival): Several fixed anchors hear one tag and compare arrival times to compute its position.
  • AoA (Angle of Arrival): Using multiple antennas to measure the direction a signal came from.
  • RTLS (Real-Time Locating System): Infrastructure that tracks people or assets indoors continuously.
  • STS (Scrambled Timestamp Sequence): Cryptographic pulse pattern in IEEE 802.15.4z that stops distance spoofing and relay attacks.
  • BLE (Bluetooth Low Energy): Low-power radio often paired with UWB for discovery and wake-up.
  • CIR (Channel Impulse Response): The receiver's view of the direct signal plus all its echoes.
  • FCC (Federal Communications Commission): U.S. regulator that legalized commercial UWB in 2002.
  • CCC (Car Connectivity Consortium): Industry group behind the Digital Key standard for phone-as-car-key.

The One-Minute Version

  • What it is: A radio that sends billions of tiny, extremely short pulses across a wide band (3.1 to 10.6 GHz) at very low power, and measures their travel time to calculate distance (FCC, 2002).
  • Who invented it: Modern UWB grew out of time-domain research led by Dr. Gerald F. Ross at the Sperry Research Center in Sudbury, Massachusetts, USA, in the 1960s and 1970s. Sperry received the first UWB communications patent in 1973 (Fontana, 2004; IEEE MTT-S, n.d.).
  • When it went mainstream: The FCC authorized unlicensed commercial UWB on February 14, 2002. Apple put a UWB chip in the iPhone 11 in 2019, and the AirTag followed in 2021.
  • Problem it solves: GPS does not work indoors, and Bluetooth or Wi-Fi signal strength can only guess distance to within a few meters. UWB measures it to about 10 cm and can prove the device is really that close.
  • Where it is used: Digital car keys, item trackers, smart locks, factory and warehouse RTLS, worker safety, hospitals, sports tracking, and in-car child presence radar.
  • What is next: IEEE 802.15.4ab (expected 2026) extends range by an order of magnitude and adds stronger radar sensing (Ceva, 2026; STMicroelectronics, 2026).

What Is UWB?

Most radios work like a singer holding one note: a steady carrier wave at a single frequency, with data hidden in small changes to that wave. UWB works more like a drummer. It sends extremely short pulses, each about 2 nanoseconds long, and because the pulses are so short, their energy spreads across a very wide slice of spectrum.

Regulators define a signal as ultra-wideband if it uses at least 500 MHz of bandwidth, or more than 20% of its center frequency (FCC, 2002). For comparison, a Bluetooth channel is 1 to 2 MHz wide and a typical Wi-Fi channel is 20 to 160 MHz wide.

Two properties follow from that design:

  1. Precise timing. Short, sharp pulses have crisp edges, so a receiver can timestamp their arrival very accurately. Radio travels about 30 cm per nanosecond, so timing to a fraction of a nanosecond means distance to a few centimeters.
  2. Low interference. Power is spread so thinly (limited to -41.3 dBm/MHz in the U.S.) that to other radios UWB looks like background noise. That is why it can share spectrum with Wi-Fi, cellular, and satellite services without a license (FCC, 2002).

UWB can carry data too, but its real value is not speed. It is knowing exactly how far away something is, and in which direction.

Who Invented UWB, When, and Where?

UWB has no single "eureka" moment. It has a long lineage:

Year Who / Where Milestone
1890s Guglielmo Marconi, Europe Spark-gap transmitters produce impulse, wideband signals. Radio literally began as UWB, then moved to narrowband carriers (FCC, 2004).
1960s to 1970s Dr. Gerald F. Ross, Sperry Research Center, Sudbury, Massachusetts, USA Pioneers time-domain electromagnetics: studying circuits and antennas by their response to short impulses. Most early UWB concepts and patents come from his team (Fontana, 2004; Intechopen, 2012).
1970s Dr. Henning F. Harmuth, Catholic University of America, Washington, D.C. Publishes foundational work on non-sinusoidal (carrier-free) radio waves (FCC, 2004).
April 17, 1973 Sperry Rand U.S. Patent 3,728,632: the earliest UWB communications patent (Fontana, 2004).
1987 Ross and Dr. Robert Fontana, USA Field a low-probability-of-intercept military communications system. For decades UWB stayed mostly military and radar (Fontana, 2004).
Feb 14, 2002 FCC, Washington, D.C. First Report and Order (FCC 02-48) legalizes unlicensed commercial UWB in 3.1 to 10.6 GHz (FCC, 2002).
2007 IEEE IEEE 802.15.4a standardizes impulse-radio UWB for low-rate data and ranging. Industrial RTLS adoption begins (ABI Research, 2025).
2019 Apple; FiRa Consortium iPhone 11 ships with the U1 UWB chip. The FiRa Consortium forms to drive interoperability.
2020 to 2021 IEEE; CCC; Apple IEEE 802.15.4z adds secure ranging. CCC Digital Key 3.0 uses it for phone-as-car-key. AirTag launches (IEEE, 2020; Ceva, 2025).
2026 IEEE; chip vendors IEEE 802.15.4ab (next-generation UWB) arrives with longer range and radar. STMicroelectronics announces ST64UWB chips (STMicroelectronics, 2026).

The short answer: UWB as we know it was invented by Gerald F. Ross and his team at Sperry Research Center in Sudbury, Massachusetts, starting in the 1960s, and it became a consumer technology after the FCC opened the spectrum in 2002.

What Problem Does UWB Solve?

Location technology has a gap. GPS works outdoors to a few meters but fails inside buildings, parking garages, and warehouses. Indoors, most systems estimate distance from signal strength (RSSI): the weaker the Bluetooth or Wi-Fi signal, the farther away the device probably is.

"Probably" is the problem. Signal strength changes when you put the phone in your pocket, turn your body, or walk past a metal shelf. Reflections from walls add echoes. The result is error of several meters, which is fine for "you are near the store" and useless for "the pallet is on shelf B3, level 2."

UWB closes that gap in three ways:

Problem Older approach What UWB does
Accuracy BLE/Wi-Fi signal strength: 1 to 5 m error Time of flight: about 10 cm, plus direction with AoA
Multipath (echoes) Echoes blur the signal and distort estimates Pulses are so short that the direct path arrives separately from reflections, so the receiver picks the first one
Security Keyless car entry can be fooled by relay attacks that amplify the fob signal Physics-based distance bounding: a relay adds delay, so the key looks farther away and the car stays locked (Wi-Fi NOW, 2026)
Interference Crowded 2.4 GHz band shared by Wi-Fi, BLE, microwaves Low-power spread spectrum in 6 to 9 GHz, largely invisible to other radios

The security point deserves emphasis. A relay attacker can copy and forward a Bluetooth signal, but nobody can make a radio wave travel faster than light. Relaying always adds time, and UWB measures time. The IEEE 802.15.4z Scrambled Timestamp Sequence also prevents attackers from predicting and faking the pulse pattern (IEEE, 2020).

How a UWB Device Works (Block Diagram)

How a UWB Device Works A. Inside one UWB transceiver TX Host MCU / app → Packet + STS (secure timestamp code) → Pulse generator ~2 ns pulses, 500+ MHz → PA + filter → Antenna (1 or more for AoA) 3.1-10.6 GHz very low power RX Ranging engine distance / angle ← Timestamp first path, ~15 ps ticks ← Correlator + CIR separates echoes ← LNA + ADC ← B. Two-way ranging: distance from time of flight Device A phone, key fob, worker badge Device B car, door lock, ceiling anchor 1. Poll (A notes send time) ▶ 2. Response (B reports its reply delay) ◀ 3. Final (cancels clock drift) ▶ Distance = speed of light × time of flight (1 ns ≈ 30 cm) C. From distance to action Tags + anchors TWR, TDoA, AoA measurements → Location engine trilateration + filtering (x, y, z) → Security check STS verifies the signal is not relayed → Application action unlock car, find tag, stop forklift, route robot, log asset position

Here is the same flow in words.

A. Inside the chip

Transmit side: the host microcontroller asks the UWB chip to send a ranging packet. The chip adds a Scrambled Timestamp Sequence (a cryptographic pulse pattern only the two devices can predict), turns it into a train of nanosecond pulses, amplifies and filters them to stay inside regulatory limits, and radiates them from the antenna.

Receive side: a low-noise amplifier and analog-to-digital converter capture the incoming energy. A correlator builds the Channel Impulse Response, which shows the direct pulse and every echo as separate spikes. The chip timestamps the first spike (the direct path) using a clock with ticks of about 15 picoseconds, then hands the timestamps to the ranging engine.

B. Measuring distance

The two devices do not share a clock, so they use Two-Way Ranging. Device A sends a poll and records the time. Device B replies and reports how long it took to respond. A third "final" message cancels out small clock drift between the two chips. Subtract the reply delay from the round-trip time, halve it, multiply by the speed of light, and you have the distance.

With two or more antennas, the device also measures the tiny phase difference between antennas to get Angle of Arrival. That is how an iPhone draws an arrow toward an AirTag rather than just saying "2.4 m away."

C. From distance to position to action

For indoor tracking, fixed anchors on the ceiling measure distances to a tag (or compare arrival times using TDoA). A location engine combines at least three measurements through trilateration and smoothing filters into x, y, z coordinates. The application then acts: unlock the door, stop the forklift, update the asset map.

Most real products pair UWB with Bluetooth Low Energy. BLE is cheap to keep listening, so it discovers nearby devices and wakes the UWB radio only when precise ranging is needed. That saves battery.

Applications Today

  • Digital car keys: CCC Digital Key 3.0 lets a phone or watch act as a hands-free, relay-proof car key. Adopted by BMW, Audi, Hyundai, Kia, Genesis, Mercedes-Benz, Volvo and others (Ceva, 2025).
  • Item finders: Apple AirTag and Samsung Galaxy SmartTag2 use UWB for precise "point me to it" finding.
  • Smart home and access: Door locks that open when you approach from outside but not when you walk past from inside. Media that follows you from room to room.
  • Industrial RTLS: Tracking tools, pallets, work-in-progress, and vehicles in factories and warehouses to tens of centimeters (ABI Research, 2025).
  • Worker safety: Proximity alerts between workers and forklifts, cranes, or robots; geofenced danger zones.
  • Healthcare: Locating infusion pumps and wheelchairs, tracking patient flow, protecting infants and dementia patients.
  • Sports and broadcasting: Player tracking for performance analytics and live graphics.
  • Radar sensing: The same chip can work as a tiny radar for child presence detection in cars, breathing detection, and gesture sensing, without a camera (STMicroelectronics, 2026).

Real Use Cases (Problem → Cause → Effect)

1. Relay theft of keyless cars

Problem: Thieves steal keyless-entry cars from driveways at night without touching the owner's key.

Cause: Older passive entry systems only check that the key's signal is present. One thief holds a relay device near the house, a second holds one near the car, and the car hears the key as if it were next to the door.

Effect with UWB: The car measures time of flight using IEEE 802.15.4z secure ranging. The relay adds delay, so the key appears far away and the car refuses to unlock. BMW introduced UWB-based Digital Key Plus in 2021, and Digital Key 3.0 is now standard across many brands (Ceva, 2025).

2. Lost items in the last few meters

Problem: A Bluetooth tracker says your keys are "nearby," but you still spend ten minutes searching the living room.

Cause: Signal strength cannot tell you direction, and its distance estimate jumps around by meters.

Effect with UWB: Apple's Precision Finding uses UWB distance plus angle to show an on-screen arrow and a countdown in meters. The last-meter search becomes a few seconds.

3. Forklift and pedestrian collisions in a warehouse

Problem: Forklift drivers cannot see workers behind racks or around blind corners.

Cause: Cameras and mirrors need line of sight. Bluetooth proximity alarms trigger too early or too late because their distance estimates are unreliable, so workers learn to ignore them.

Effect with UWB: Workers wear UWB badges and forklifts carry UWB anchors. The system knows the real distance to within tens of centimeters and slows the forklift automatically inside a defined safety zone. Fewer false alarms means workers trust the system.

4. Searching for tools on an assembly line

Problem: On an aircraft or automotive line, technicians lose time hunting for calibrated torque tools, and a tool left inside a product is a serious safety risk.

Cause: Barcodes and RFID only record where a tool was last scanned, not where it is now.

Effect with UWB: UWB tags on each tool report live positions to an RTLS map. The system can also confirm that a smart tool is at the correct station before it is allowed to operate, and flag any tool not returned before a product moves on.

5. Children left in hot cars

Problem: Children are sometimes forgotten in parked cars, where heat can quickly become fatal.

Cause: Seat-weight sensors miss a sleeping child in a footwell or an infant seat, and cameras raise privacy concerns.

Effect with UWB: The same UWB chip used for the digital key runs in radar mode, detecting the tiny chest movement of a breathing child. Euro NCAP recommends child presence detection, and new chips like the ST64UWB add edge AI for exactly this (STMicroelectronics, 2026).

Benefits for Industries That Build UWB Into Their Products

Industry How UWB is used Business benefit
Automotive Digital keys, child presence radar, kick-to-open trunks Lower theft claims, premium features, one chip serving several functions
Consumer electronics Item finding, device handoff, spatial awareness Ecosystem lock-in, new accessory revenue, differentiated user experience
Manufacturing Tool and WIP tracking, process verification Less search time, fewer quality escapes, digital-twin data
Logistics and warehousing Pallet and vehicle location, forklift safety, robot navigation Higher throughput, fewer accidents, lower insurance costs
Healthcare Equipment tracking, patient and staff flow Fewer lost devices, better use of equipment, faster response
Smart buildings and retail Hands-free access, occupancy, precise indoor navigation Frictionless entry, space optimization, location-based services

Across all of them, the common advantages are:

  1. Accuracy that enables automation. Ten-centimeter precision is good enough for a machine to act on, not just for a human to glance at.
  2. Security built into the physics. Distance bounding makes UWB suitable for access control and payments where relay attacks matter.
  3. Standards and interoperability. IEEE 802.15.4z, FiRa, and CCC Digital Key mean products from different vendors work together.
  4. Existing install base. Hundreds of millions of flagship phones and watches already carry UWB, so a product can use the customer's phone instead of shipping a dedicated fob.
  5. One radio, many jobs. Ranging, direction finding, data, and radar sensing can share the same chip, which lowers bill-of-materials cost.
  6. Privacy-friendly sensing. Presence and motion detection without cameras.

Limitations to Plan For

  • Short range today. 802.15.4z works best within about 10 to 50 meters and prefers line of sight. Concrete, metal, and the human body weaken it.
  • Infrastructure cost. Indoor RTLS needs anchors installed and surveyed, and the calibration effort is real.
  • Power. UWB uses more energy than BLE, which is why products pair the two.
  • Regional rules. Allowed channels and power limits differ between the U.S., Europe, Japan, China, and India. Channel 9 (about 8 GHz) is the most widely usable worldwide.
  • Not a data pipe. Throughput is modest (6.8 Mbps is common). Use Wi-Fi for bulk data.

The Future of UWB

Next-generation UWB (IEEE 802.15.4ab). Expected in 2026 and backward compatible with 802.15.4z. It adds multi-millisecond ranging, which accumulates many measurements to gain signal strength, and narrowband assistance, which uses a 5 to 6 GHz helper channel for coordination. Vendors report link-budget gains of around 20 dB and range improvements up to 30 times (ABI Research, 2025; Ceva, 2026; imec, 2026). That moves UWB from "is the user next to the door?" to "where on this floor are they?"

UWB radar everywhere. Wider 1.3 GHz channels roughly double radar accuracy compared with 500 MHz channels (STMicroelectronics, 2026). Expect breathing monitors, fall detection for elderly care, gesture control, and intrusion sensing using the same chip already in phones and cars.

Robots and physical AI. Warehouse robots and drones need precise, low-latency relative positioning indoors where GPS fails. UWB gives robot-to-robot and robot-to-human distance with safety-grade reliability (imec, 2026).

Payments and ticketing. Walk-through transit gates and hands-free checkout, where the system knows you are really at the gate and not three meters behind.

Augmented reality and spatial computing. Headsets that know exactly where your phone, controller, or smart speaker sits in the room.

Market growth. ABI Research forecasts UWB to be one of the fastest-growing wireless technologies from 2025 to 2030, at around 21% compound annual growth (ABI Research, 2025).

UWB started as a spark-gap curiosity, became a Cold War research program under Gerald F. Ross at Sperry in Massachusetts, spent decades as military radar, and was opened to everyone by the FCC in 2002. Nearly twenty years later, the iPhone 11 turned it into a mass-market radio.

Its job is narrow and important: measure time so precisely that distance becomes trustworthy. That single capability fixes indoor location, blocks relay theft, lets machines react safely to people, and now doubles as a privacy-friendly radar.

For companies building products, the question is shifting from "should we add UWB?" to "which UWB features will our customers expect first?" Your customers' phones already have the radio. The next generation will reach across whole floors instead of just across a doorway.

References

  • ABI Research. (2025). How IEEE 802.15.4ab is set to unlock the true potential of UWB. https://www.abiresearch.com/market-research/insight/7787184-how-ieee-802154ab-is-set-to-unlock-the-tru
  • Ceva. (2025). UWB, digital keys, and the quest for greater range. https://www.ceva-ip.com/blog/uwb-digital-keys-and-the-quest-for-greater-range/
  • Ceva. (2026). Ceva announces IEEE 802.15.4ab-compliant UWB IP. Referenced via Wi-Fi NOW (2026).
  • Federal Communications Commission. (2002). New public safety applications and broadband internet access among uses envisioned by FCC authorization of ultra-wideband technology (First Report and Order, FCC 02-48). https://transition.fcc.gov/Bureaus/Engineering_Technology/News_Releases/2002/nret0203.html
  • Federal Communications Commission. (2004). Ultra-wideband (UWB) [TCB workshop presentation]. https://transition.fcc.gov/oet/ea/presentations/files/may04/May_04-Ultra-Wideband-AL.pdf
  • Fontana, R. J. (2004). A brief history of UWB communications. Multispectral Solutions. https://www.scribd.com/document/92157802/A-Brief-History-of-UWB-Communications
  • IEEE. (2020). IEEE 802.15.4z-2020: Standard for low-rate wireless networks, amendment: Enhanced ultra wideband physical layers and associated ranging techniques. IEEE Standards Association.
  • IEEE Microwave Theory and Technology Society. (n.d.). Gerald F. Ross. https://mtt.org/profile/gerald-f-ross/
  • imec. (2026). Imec unveils world's first IEEE 802.15.4ab UWB receiver. IoT Insider. https://www.iotinsider.com/industries/communications/imec-unveils-worlds-first-ieee-802-15-4ab-uwb-receiver/
  • Intechopen. (2012). Ultra wide band positioning systems for advanced construction site management. https://www.intechopen.com/chapters/39775
  • STMicroelectronics. (2026, March 10). STMicroelectronics propels new era of ultra-wideband technology for automotive and smart device applications [Press release]. GlobeNewswire.
  • Wi-Fi NOW. (2026). UWB beyond ranging: What IEEE 802.15.4ab means for your firmware. https://syndicated.wifinowglobal.com/resource/uwb-beyond-ranging-what-ieee-802-15-4ab-means-for-your-firmware/

Sunday, 20 September 2026

Carbon-Aware Computing: What If Software Could Choose the Cleanest Time to Run?

Standard


Your batch job starts the moment you click Submit. The Kubernetes pod spins up at 6 p.m. The model training run kicks off during the evening demand spike. Nobody asked whether the grid was burning coal or soaking up midday solar. The software treated every kilowatt-hour as identical.

It is not. On the California Independent System Operator (CAISO) grid, average life-cycle emissions intensity can swing from roughly 484 grams CO₂ equivalent per kilowatt-hour (gCO₂e/kWh) overnight to about 292 gCO₂e/kWh at midday, driven by solar availability (Meyer et al., 2025). In Germany, hourly factors have ranged from 37% to 141% of the annual average within a single year (Kannan et al., 2017). The same compute job, same code, same hardware, can produce very different carbon outcomes depending on when and where it runs.

Carbon-aware computing is the idea that software should know that difference and act on it: defer flexible workloads to cleaner hours, route batch jobs to greener regions, or throttle capacity when the grid is dirty. Not as a sustainability brochure. As scheduling logic.

Key Abbreviations in This Post

  • CI (Carbon Intensity): Grams of CO₂ equivalent emitted per kWh of electricity consumed (gCO₂/kWh).
  • MOER (Marginal Operating Emissions Rate): Emissions from the next unit of generation dispatched when demand changes.
  • AEF (Average Emissions Factor): Annual or regional average CI; simpler but can misestimate avoided emissions.
  • VCC (Virtual Capacity Curve): Hourly compute capacity limits that reshape flexible load to greener times (Google, 2022).
  • SCI (Software Carbon Intensity): Green Software Foundation (GSF) rate metric for software emissions per functional unit.
  • SLA (Service Level Agreement): Deadline or latency contract a job must meet.
  • GSF (Green Software Foundation): Industry body behind the Carbon Aware SDK and SCI specification.
  • KEDA (Kubernetes Event-Driven Autoscaling): Scaler framework that can pause workloads on external signals.
  • CRD (Custom Resource Definition): Kubernetes extension for domain-specific scheduling policies.

The One-Minute Version

  • Grid carbon intensity changes by hour and region because generation mix shifts with demand, wind, and solar (Carbon Intensity, n.d.; Meyer et al., 2025).
  • Carbon-aware software uses live or forecast CI data to schedule deferrable work into lower-emission windows (Green Software Foundation [GSF], n.d.; Radovanovic et al., 2022).
  • Three levers: temporal shifting (when), spatial shifting (where), and load shaping (how much capacity per hour).
  • Google's Carbon-Intelligent Computing has run in production since 2020, using Virtual Capacity Curves to delay batch workloads to greener hours (Radovanovic et al., 2022).
  • Developers can start today with the GSF Carbon Aware SDK, Python tools like cleanshift, or Kubernetes controllers. Savings of 16 to 41% are reported on flexible pipelines (Bhat et al., 2026; GridWise AI, n.d.).
  • It only works for flexible workloads. User-facing latency-critical paths need different policies.

Why "A Kilowatt-Hour Is a Kilowatt-Hour" Is Wrong

Utility bills count energy, not emissions. Climate math needs both.

Electricity grids are dynamic systems. When demand rises at dusk, gas peaker plants often ramp up. When the sun is strong, solar displaces higher-carbon sources. Wind surges at night in some regions. Nuclear and hydro provide relatively steady low-carbon baseload. The result: carbon intensity curves that look nothing like flat lines.

Research on hourly accounting shows that using annual average emission factors can bias inventory estimates by up to 35% compared with hour-by-hour measurement in some regions (Lou et al., 2022). For load shifting specifically, marginal emission factors matter: they estimate what generator actually responds when you add or remove demand (Siler-Evans et al., 2012).

Carbon-aware computing treats electricity like a variable-price, variable-emissions commodity. The job is not just "use less power." It is "use power when the grid is cleaner, if you can."

Three Ways Software Can Shift Its Carbon Footprint

1. Temporal shifting (when)

Defer batch training, nightly ETL, report generation, or backup jobs to the lowest-carbon window before the deadline. A four-hour Spark pipeline due by 8 a.m. might sleep until 2 a.m. when wind output peaks instead of starting at 6 p.m. during a gas-heavy evening (GridWise AI, n.d.).

2. Spatial shifting (where)

Run the same container in a region with cleaner current or forecast CI. The GSF Carbon Aware SDK exposes endpoints like /emissions/bylocations/best to compare multiple cloud regions and pick the lowest-intensity location for a given time window (GSF, n.d.). Data gravity limits this: moving a 50 TB dataset across regions may cost more carbon than you save.

3. Load shaping (how much, each hour)

Instead of binary run-or-wait, cap hourly capacity for flexible workloads. Google's Carbon-Intelligent Computing System generates day-ahead Virtual Capacity Curves (VCCs): hourly CPU limits that preserve total daily capacity while starving dirty hours and filling green ones (Radovanovic et al., 2022). The same total work completes. The shape of demand changes.

Carbon-Aware Scheduling: Pick the Cleanest Window Grid carbon intensity (gCO2/kWh) over 24 hours High Low Dirty peak gas/coal ramp evening demand Green window solar + wind lowest CI slot Run now Defer job 00:00 06:00 12:00 18:00 24:00 How software decides 1. Carbon signal WattTime, Electricity Maps, grid APIs → 2. Forecast hourly CI curve + deadline window → 3. Policy flexible / batch / latency-critical → 4. Scheduler sleep, scale, or route to region → 5. Receipt kg CO2 avoided vs run-immediately

How Carbon-Aware Scheduling Works in Practice

The pattern is consistent across hyperscale internal systems and open-source tools:

  1. Ingest carbon signals. Providers like WattTime, Electricity Maps, UK Carbon Intensity API, and grid operator feeds supply historical, live, and forecast CI by region (Carbon Intensity, n.d.; GSF, n.d.).
  2. Normalize units. The GSF Carbon Aware SDK converts heterogeneous provider formats into standard gCO₂/kWh (GSF, n.d.).
  3. Define workload policy. Label jobs as latency-critical, flexible, or batch. Attach deadlines, duration, and acceptable delay.
  4. Optimize the window. Search all valid start times before the SLA and pick the lowest total emissions contiguous window (GridWise AI, n.d.; cleanshift, n.d.).
  5. Execute and receipt. Run the job, log kg CO₂ avoided versus an immediate baseline. Some tools sign receipts for audit (ebb-ai, n.d.).

Example Python policy with cleanshift:

from cleanshift import find_cleanest_window, MockProvider

best = find_cleanest_window(
    MockProvider(),
    duration_hours=2,
    max_delay_hours=24,
)
# Sleep until best.start_time, then run your training job

Policies can go further: halt_if_dirty pauses a long job mid-run if CI spikes above a threshold, then resumes when the grid cleans up (cleanshift, n.d.). That is carbon-aware computing as process control, not just queue management.

Who Is Already Doing This?

Google: Carbon-Intelligent Computing at fleet scale

Since 2020, Google has operated a production Carbon-Intelligent Computing System across its data center fleet. It forecasts next-day carbon intensity, predicts flexible load, and generates Virtual Capacity Curves that limit hourly batch capacity during dirty periods while preserving daily throughput (Radovanovic et al., 2022). The same infrastructure later supported demand response during grid emergencies in Oregon, Nebraska, the U.S. Southeast, and Europe (Utility Dive, 2023). Carbon awareness became grid reliability tooling.

Green Software Foundation: the open standard layer

The GSF Carbon Aware SDK provides CLI, Web API, and client libraries so developers do not rebuild provider integrations. It aligns with the Software Carbon Intensity (SCI) specification, which defines carbon-aware behavior as software that adjusts consumption in response to the carbon intensity of the energy it uses (GSF, n.d.). SCI scores operational emissions as energy times grid CI plus embodied hardware costs, per functional unit.

Kubernetes-native schedulers

Patterns include KEDA scalers that scale to zero when CI exceeds a threshold, custom controllers that hold "carbon-deferred" jobs until the SDK returns an optimal window, and research systems like Carbon-Kube, which reduced CO₂ emissions on Spark pipelines by 41% with only 1.1 to 1.7% latency overhead in AWS EKS experiments (Bhat et al., 2026; Tekko, n.d.).

Agent and batch API integration

Tools like ebb-ai route deferrable Large Language Model (LLM) agent tasks through batch APIs during off-peak grid hours, claiming 40 to 70% lower carbon and roughly 50% lower cost when deadlines allow (ebb-ai, n.d.). Carbon awareness meets inference economics.

When It Works, and When It Does Not

Workload type Carbon-aware fit Why
ML training, ETL, backups Excellent Hours of slack, high energy draw, clear deadlines
Overnight agent summaries Strong Deferrable, batch API compatible
Video rendering farms Strong Queue-based, deadline-driven
Interactive web APIs Poor Users expect sub-second response
Cross-region data pipelines Mixed Data gravity may erase spatial gains (Bhat et al., 2026)
Always-on inference at fixed SLA Limited Use right-sized models and clean-grid siting instead

Carbon-aware scheduling is not a substitute for using less energy. It is a multiplier on top of efficiency. A smaller model on a clean grid at the right hour beats a frontier model running immediately on a coal-heavy evening.

Real-World Examples (Problem → Cause → Effect)

1. Nightly ML fine-tune on CAISO

Problem: A team fine-tunes a model every night. Jobs auto-start at 6 p.m. when engineers leave the office.

Cause: Cron triggers ignore grid CI. Evening is often gas-heavy as solar drops and residential demand rises (Meyer et al., 2025).

Effect: Carbon-aware wrapper defers the 3-hour job to the 11 a.m. to 2 p.m. solar window. Same SLA (results by 7 a.m.). Estimated 30 to 40% lower operational CO₂ for that job versus immediate start.

2. Spark pipeline with hard deadline

Problem: A daily analytics DAG must finish before 9 a.m. for executives. Default Kubernetes scheduler runs it at midnight.

Cause: Standard schedulers optimize for cluster utilization, not marginal grid emissions.

Effect: Carbon-Kube uses forecast-based time planning with SLA envelopes. In published experiments, CO₂ fell 41% with under 2% latency penalty (Bhat et al., 2026).

3. Grid emergency demand response

Problem: A regional grid faces peak stress during a heat wave.

Cause: Fixed compute load adds to peak demand when peaker plants are most carbon-intensive.

Effect: Google reduced data center power during requested windows using the same carbon-intelligent platform, supporting grid reliability in Oregon, Nebraska, and Europe (Utility Dive, 2023). Carbon-aware load shaping doubles as demand response.

4. "Green" chatbot with no deferral policy

Problem: A product team markets an AI assistant as sustainable but serves every query synchronously on demand.

Cause: No workload classification. Every request is treated as latency-critical.

Effect: Peak-hour inference on dirty grids. Fix: separate interactive path from deferrable background tasks (summaries, eval runs, log analysis) and apply carbon policy only where slack exists.

Building Carbon-Aware Software: A Practical Checklist

  1. Classify workloads. Tag jobs with priority: latency-critical, flexible, batch. Only the latter two defer.
  2. Attach SLAs. Every deferrable job needs a deadline and duration estimate.
  3. Pick a signal source. Start with Electricity Maps, WattTime, or a regional grid API. Use the GSF SDK to normalize (GSF, n.d.).
  4. Choose marginal or average CI consciously. Marginal rates better reflect avoided emissions from shifting load; averages are simpler for reporting (Siler-Evans et al., 2012; Lou et al., 2022).
  5. Integrate at the scheduler. Cron replacement, Kubernetes controller, CI pipeline gate, or Python wrapper around your training script.
  6. Emit receipts. Log baseline (run now) versus optimized (deferred) kg CO₂. Auditable metrics beat vague "we care" pages.
  7. Watch for rebound. Cheaper off-peak compute can increase total usage. Track absolute emissions, not just intensity (GSF, n.d.).

The Bigger Picture: From Carbon-Aware to 24/7 Clean Energy

Carbon-aware scheduling is a bridge strategy. It reduces emissions today on grids that still mix fossil and renewable generation. The long-term goal for many hyperscalers, including Google, is 24/7 carbon-free energy: matching every hour of consumption with clean supply, not just buying annual renewable credits (Utility Dive, 2023; Google Cloud, n.d.).

Until every hour is clean everywhere, timing matters. Software that treats the grid as a live signal, not a static utility bill, is one of the lowest-friction climate levers developers actually control. You do not need a new model architecture. You need a scheduler that reads the atmosphere.

What if software could choose the cleanest time to run? It already can. The data exists. The SDKs exist. Production systems at Google scale have done it for years. Open-source tools now bring the same idea to Kubernetes clusters, Python batch jobs, and agent workflows.

The constraint is not technology. It is workload design. Carbon-aware computing works when you admit that not every job needs to run right now, that a kilowatt-hour at noon is not the same as a kilowatt-hour at dusk, and that schedulers are climate policy encoded in cron syntax.

Defer the batch job. Shape the load curve. Print the receipt. Same software, cleaner hour, measurably less carbon. That is not a thought experiment. It is an engineering ticket waiting in your backlog.

References

  • Bhat, S., Sirikonda, S. R., Katoch, V., & Jain, R. (2026). Carbon-Kube: A Kubernetes-native framework for multi-objective carbon-aware scheduling of big data pipelines. IEEE IEMECONTECH. https://doi.org/10.1109/iementech202669403.2026.11434192
  • Carbon Intensity. (n.d.). About the carbon intensity forecast. https://carbonintensity.org.uk/
  • cleanshift. (n.d.). Delay batch ML/AI jobs to the cleanest grid window. https://pypi.org/project/cleanshift/
  • ebb-ai. (n.d.). Carbon-aware MCP scheduler for agentic AI workflows. https://github.com/Vitalini/ebb-ai
  • Google Cloud. (n.d.). Google's approach to carbon-aware data center. https://cloud.google.com/blog/topics/sustainability/googles-approach-to-carbon-aware-data-center
  • Green Software Foundation. (n.d.). Carbon Aware SDK. https://carbon-aware-sdk.greensoftware.foundation/docs/overview
  • Green Software Foundation. (n.d.). Software Carbon Intensity (SCI) Specification. https://sci.greensoftware.foundation/
  • GridWise AI. (n.d.). Carbon-aware compute scheduling. https://www.grid-wise.us/
  • Kannan, R., Strunz, K., & Wiese, F. (2017). The trends of hourly carbon emission factors in Germany and investigation on relevant consumption patterns for its application. International Journal of Life Cycle Assessment, 22(4), 621-632. https://doi.org/10.1007/s11367-017-1277-z
  • Lou, X., Carley, K. M., & Azevedo, I. M. L. (2022). Hourly accounting of carbon emissions from electricity consumption. Environmental Research Letters, 17(4). https://doi.org/10.1088/1748-9326/ac6147
  • Meyer, J., et al. (2025). The dynamics of the California electric grid mix and electric vehicle emission factors. Energies, 18(4). https://doi.org/10.3390/en18040895
  • Radovanovic, A., et al. (2022). Carbon-aware computing for datacenters. IEEE Transactions on Power Systems. https://arxiv.org/pdf/2106.11750
  • Siler-Evans, K., Azevedo, I. M. L., & Morgan, M. G. (2012). Marginal emissions factors for the U.S. electricity system. Environmental Science & Technology, 46(9), 4742-4748. https://doi.org/10.1021/es300145v
  • Tekko. (n.d.). Carbon-aware scheduling using Kubernetes and the GSF SDK. https://tekko.id/en/blog/carbon-aware-scheduling-using-kubernetes-and-the-gsf-sdk
  • Utility Dive. (2023). Google taps carbon-intelligent computing platform to help maintain grid reliability in power crises. https://www.utilitydive.com/news/google-carbon-intelligent-computing-platform-system-reliability-demand-response-grid-emergency/698958/