How I Built an AI Decision Copilot to Help India Prepare for the 2026 El Niño Crisis

A developer built an AI decision copilot to help India prepare for the 2026 El Niño crisis. The platform, developed during the Google Cloud Gen AI Academy APAC Hackathon, uses Gemini, Vertex AI, BigQuery, and Google Cloud to provide explainable recommendations for district administrators and farmers. The system integrates multiple public datasets and employs specialized AI agents for risk assessment, resource allocation, and personalized crop advice.

Building an explainable AI platform that helps district administrators allocate resources and farmers make better crop decisions using Gemini, Vertex AI, BigQuery, and Google Cloud. Climate disasters are not just weather events. They are decision problems. When forecasts predict a strong El Niño, governments do not simply need more data. They need answers to questions like: Existing dashboards provide plenty of charts. Very few provide decisions. That became the motivation behind El Niño 2026 Decision Copilot , an AI-powered decision intelligence platform built during the Google Cloud Gen AI Academy APAC Hackathon . India depends heavily on the monsoon. A severe El Niño can lead to: The information already exists across dozens of government portals, weather services, satellite datasets, and agricultural reports. The challenge is that it is scattered. District collectors do not have time to manually combine: Farmers face an even bigger challenge. Most need a simple answer: Given my district, should I plant the usual crop this season? Instead of building another dashboard, I wanted to build an AI system that reasons over multiple data sources and produces explainable recommendations. The platform serves two audiences through the same intelligence engine. They receive: Instead of simply showing that a district has high risk, the system explains why . Farmers interact with a conversational AI. They can ask questions such as: Should I grow paddy this season? or Which crop is safer in my district? The assistant retrieves official contingency plans, combines them with weather forecasts, and generates localized recommendations backed by citations. Rather than building one giant AI model, I designed the platform as a decision pipeline. Data Sources ↓ Data Ingestion ↓ BigQuery ↓ Risk Model ↓ AI Agents ↓ Explainable Decisions Everything flows through a single decision intelligence core. The platform runs entirely on Google Cloud. Multiple public datasets are collected continuously, including: All datasets are standardized before being stored in BigQuery. BigQuery stores district-level information including: Every downstream component reads from BigQuery instead of directly querying external APIs. This keeps the architecture modular, scalable, and reproducible. The first version uses BigQuery ML . Instead of training a black-box neural network, I intentionally chose an interpretable approach. The model combines features such as: The output is a district-level risk score. That score becomes the starting point for the AI agents. A single prompt quickly becomes difficult to maintain. Instead, I divided responsibilities into specialized agents using Google's Agent Development Kit ADK . Its responsibility is to answer: Which districts require attention first? It ranks districts and explains the factors influencing each score. Once priorities are known, this agent decides how available resources should be distributed. Examples include: Unlike pure LLM reasoning, resource allocation is deterministic so recommendations remain consistent and auditable. This agent combines: Farmers receive localized advice supported by official documents instead of hallucinated responses. The original hackathon prototype focused on 23 high-risk districts. Scaling nationwide turned out to be far more challenging than building the AI itself. The platform now covers: Expanding reliable public datasets was significantly harder than writing prompts. One principle guided every feature. Never ask users to trust the AI blindly. Every recommendation answers: For government decision-making, transparency is often more valuable than model complexity. Every source uses different schemas, update frequencies, and district identifiers. A significant portion of the project involved cleaning, validating, and reconciling datasets before any AI processing could begin. Government users need confidence in every recommendation. Every output had to include evidence rather than relying on confidence scores. District contingency plans vary significantly in formatting and quality. Building an automated indexing pipeline was necessary to move beyond a small proof of concept. There are several areas I would continue developing: Building AI for public-sector decision making is very different from building a chatbot. The hardest problems were not prompt engineering. They were: Large language models become far more useful when they serve as the reasoning layer instead of the entire application. 🌐 Live Demo https://climate-resilience-in.web.app https://climate-resilience-in.web.app 🎥 Demo Video If you are building AI systems for climate resilience, agriculture, disaster management, or public-sector decision intelligence, I would love to hear your thoughts and feedback. Happy building 🚀