Inspiration
AI and data-centre workloads are becoming more energy-intensive. Many carbon-aware schedulers optimize for the cleanest electricity window, but they often miss another critical factor: grid stress.
The project is inspired by Google’s leadership in carbon-aware computing, cloud sustainability, and the Google Cloud Rapid Agent Hackathon’s vision of building agents that do more than answer questions — agents that reason, use tools, and help people take action.
The cleanest electricity window is not always the safest grid window.
GridCarbon Guardian was inspired by this gap. A low-carbon time slot can still coincide with very high grid load. If many AI workloads shift to the same “green” window, they may unintentionally create a new demand spike. I call this the Green Herd Effect.
GridCarbon Guardian addresses this by treating AI workload scheduling as a carbon, grid-resilience, governance, and auditability problem.
What it does
GridCarbon Guardian is a Gemini-powered scheduling agent for AI and data-centre workloads.
Given a workload, it:
- evaluates carbon intensity, grid load, deadline risk, and latency/cost proxy
- compares multiple scheduling options
- rejects low-carbon options when they are grid-stressed
- recommends a safer schedule
- uses Gemini to generate an audit-ready explanation
- escalates high-risk schedules for human approval
- creates a Compute Carbon Liability Record
- stores the decision in MongoDB decision memory
- allows operators to download and review JSON audit logs
The app demonstrates two key scenarios:
- A flexible AI batch inference workload is shifted away from the lowest-carbon window because that window has 94% grid load.
- An urgent AI model retraining workload is escalated for human approval because it must meet a tight deadline under high grid stress.
How we built it
The project is built as a Cloud Run-hosted Streamlit operator console with a Gemini-powered agentic workflow.
The scheduling engine uses a transparent weighted scoring model:
40% carbon intensity
+ 30% grid stress
+ 20% deadline risk
+ 10% latency/cost proxy
Lower score means a safer scheduling option.
Gemini generates the explanation layer, while MongoDB Atlas stores the decision-memory layer. Each decision record includes workload details, selected region, selected time, carbon intensity, grid load, emissions estimate, approval status, and audit metadata.
The project also includes a Google ADK-style agent definition. The agent exposes tools to schedule workloads, retrieve recent MongoDB memory, save new carbon-accounting decisions, and view the audit ledger.
Use of Google Cloud
GridCarbon Guardian uses Google Cloud in three ways:
- Gemini API / Google Gen AI SDK for reasoning and audit-ready explanations
- Cloud Run for hosting the web application
- Google ADK / Agent Builder-aligned structure for agentic orchestration
The live app is deployed on Cloud Run and is accessible through the hosted project URL.
Use of MongoDB
GridCarbon Guardian is submitted to the MongoDB track.
MongoDB Atlas is used as persistent decision memory. The app stores audit logs and Compute Carbon Liability Records in the gridcarbon_guardian.audit_logs collection.
MongoDB memory allows the agent to avoid treating every scheduling decision as isolated. It can retrieve prior workload decisions, approval history, and carbon-grid trade-offs.
The project also includes MCP-aligned MongoDB tool wrappers that expose memory functions such as:
- test MongoDB memory
- load recent decisions
- save carbon decisions
- load audit ledger
The current MVP uses MongoDB Atlas through PyMongo and MCP-aligned tools. Full official MongoDB MCP Server runtime deployment is a future extension.
Challenges we ran into
The hardest challenge was balancing carbon optimization with grid resilience. A simple carbon-only scheduler would choose the cleanest electricity window, but that can be unsafe when the grid is already stressed.
Another challenge was making the system understandable to non-technical operators. To address this, the app includes Gemini explanations, visual risk scoring, human approval controls, and downloadable audit logs.
A third challenge was creating a responsible MVP within the hackathon timeline. The current version uses deterministic synthetic carbon and grid-load data so judges can reproduce the workflow reliably. The data layer is modular, so live carbon-intensity and grid-load APIs can be added later.
What we learned
We learned that carbon-aware AI scheduling should not be treated only as an optimization problem. It also needs governance, memory, human oversight, and auditability.
We also learned that MongoDB is useful not just as storage, but as decision memory for agents. By storing prior decisions, approval outcomes, and carbon-liability records, the agent can build institutional memory over time.
What is next
Future improvements include:
- official MongoDB MCP Server deployment
- live Electricity Maps API integration
- real grid-load API integration
- fuller Agent Builder orchestration
- game-theoretic workload routing to avoid the Green Herd Effect
- adaptive thresholds for extreme grid stress
- downloadable PDF compliance reports
- stronger observability for agent decisions
GridCarbon Guardian shows how AI agents can help make digital infrastructure greener, safer, and more accountable.
Log in or sign up for Devpost to join the conversation.