DEV Community: Naazim Hussain

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

Naazim Hussain — Fri, 10 Jul 2026 06:36:56 +0000

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:

Which districts will be affected first?
Where should limited water resources be sent?
Which crops are likely to fail?
What should farmers sow instead?
Why is the AI recommending this action?

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.

The Problem

India depends heavily on the monsoon.

A severe El Niño can lead to:

Rainfall deficits
Reservoir depletion
Groundwater stress
Crop failures
Rising food prices
Rural employment challenges

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:

Weather forecasts
NDVI satellite imagery
Reservoir levels
Mandi prices
Contingency plans
Drought indicators

Farmers face an even bigger challenge.

Most need a simple answer:

Given my district, should I plant the usual crop this season?

The Goal

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.

District Administrators

They receive:

District risk scores
Interactive risk maps
Reservoir outlook
Crop stress indicators
Resource allocation recommendations
AI-generated explanations

Instead of simply showing that a district has high risk, the system explains why.

Farmers

Farmers interact with a conversational AI.

They can ask questions such as:

Should I grow paddy this season?

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.

The Core Idea

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.

Architecture

The platform runs entirely on Google Cloud.

Data Layer

Multiple public datasets are collected continuously, including:

Google Earth Engine
OpenWeatherMap
Agmarknet
CWC reservoir reports
CGWB groundwater data
NRSC datasets
ICAR-CRIDA contingency plans
MGNREGA employment data

All datasets are standardized before being stored in BigQuery.

BigQuery as the Source of Truth

BigQuery stores district-level information including:

Rainfall
Weather forecasts
Reservoir status
Satellite vegetation indices
Soil moisture
Mandi prices
Employment indicators

Every downstream component reads from BigQuery instead of directly querying external APIs.

This keeps the architecture modular, scalable, and reproducible.

Building the Risk Model

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:

Rainfall anomalies
Forecast deficit
NDVI
Soil moisture
Reservoir storage
Groundwater stress
Agricultural indicators

The output is a district-level risk score.

That score becomes the starting point for the AI agents.

Why Multiple AI Agents?

A single prompt quickly becomes difficult to maintain.

Instead, I divided responsibilities into specialized agents using Google's Agent Development Kit (ADK).

Triage Agent

Its responsibility is to answer:

Which districts require attention first?

It ranks districts and explains the factors influencing each score.

Allocation Agent

Once priorities are known, this agent decides how available resources should be distributed.

Examples include:

Water tankers
Emergency funds
Drought relief supplies

Unlike pure LLM reasoning, resource allocation is deterministic so recommendations remain consistent and auditable.

Farmer Advisory Agent

This agent combines:

District data
Weather forecasts
Official contingency plans
Retrieval-Augmented Generation (RAG)

Farmers receive localized advice supported by official documents instead of hallucinated responses.

Scaling Beyond a Prototype

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:

763 districts across India
Weather forecasts for every district
Nationwide satellite vegetation data
Reservoir coverage through regional aggregation
Hundreds of district contingency plans indexed for retrieval

Expanding reliable public datasets was significantly harder than writing prompts.

Explainability Was a Requirement

One principle guided every feature.

Never ask users to trust the AI blindly.

Every recommendation answers:

Why?
Which data was used?
Which document supports the recommendation?
Which factors increased the risk score?

For government decision-making, transparency is often more valuable than model complexity.

Technology Stack

Google Cloud

BigQuery
BigQuery ML
Vertex AI
Vertex AI Search
Cloud Run
Firebase Hosting
Cloud Storage

AI

Gemini 2.5 Flash
Vertex AI Search
Retrieval-Augmented Generation (RAG)
Agent Development Kit (ADK)

Backend

Python
FastAPI

Frontend

React
Vite
React Leaflet

Challenges

Public Data Is Not Standardized

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.

Explainability

Government users need confidence in every recommendation.

Every output had to include evidence rather than relying on confidence scores.

Scaling RAG

District contingency plans vary significantly in formatting and quality.

Building an automated indexing pipeline was necessary to move beyond a small proof of concept.

What I'd Improve Next

There are several areas I would continue developing:

Retrain the risk model using nationwide datasets
Automate ingestion using Cloud Scheduler and Cloud Functions
Add multilingual support for Indian regional languages
Strengthen authentication between administrator and farmer workflows
Expand the knowledge base with additional government guidelines

What I Learned

Building AI for public-sector decision making is very different from building a chatbot.

The hardest problems were not prompt engineering.

They were:

Data quality
Explainability
Deterministic reasoning
Trustworthy recommendations
Integrating multiple systems into one coherent workflow

Large language models become far more useful when they serve as the reasoning layer instead of the entire application.

Demo

🌐 Live Demo

https://climate-resilience-in.web.app

🎥 Demo Video

https://youtu.be/U0Voa4h71II

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! 🚀

What Building Anamnesis Taught Me About Giving AI a Memory

Naazim Hussain — Sat, 04 Jul 2026 10:53:29 +0000

How Cognee turned a pile of medical PDFs into a living clinical memory graph, and why "storage" and "memory" turned out to be completely different problems.

The problem that started it all

A patient walks into a clinic. Behind them: years of blood reports, prescriptions, discharge summaries, imaging scans. In front of them: a doctor who has maybe four minutes to reconstruct that entire history before making a decision that affects the next one.

That's not a data problem. Every one of those documents is sitting in some folder, some PDF, some scanned image. The information exists. What's missing is the connection between it: the fact that the kidney function flagged in March relates to the medication started in January, which was prescribed because of a diagnosis made the previous year. A filing cabinet doesn't know that. Neither does a database that just stores rows.

That distinction, between storing information and remembering it, is the whole thesis behind Anamnesis, the project I built for wemakedevs.org's Cognee hackathon ("The Hangover Part AI: Where's My Context?"). And it's the reason I built it on Cognee instead of a conventional RAG pipeline.

Why RAG wasn't enough

Most "AI over your documents" tools follow the same recipe: chunk the text, embed it, stuff the closest chunks into a prompt when someone asks a question. That works fine for FAQ bots. It falls apart for clinical history, because clinical facts aren't independent, they're relational. A lab value only means something in the context of the medication that might be causing it and the diagnosis that explains why the medication was prescribed in the first place. Flat vector similarity search doesn't reason about relationships; it just finds text that sounds related.

What Anamnesis actually needed was a memory: something that ingests new facts, connects them to what's already known, revises itself when new information contradicts old information, and lets old information decay or retire without being deleted outright. That's a different shape of problem than search, and it turns out Cognee had already built the primitives for exactly that shape.

Four verbs, one memory lifecycle

Cognee organizes memory around four operations, and mapping Anamnesis onto them was the core design exercise of the whole build:

remember(): A clinician uploads a blood report, a prescription, a discharge summary. Anamnesis runs it through Gemini's vision-based OCR to pull out structured entities (diagnoses, medications, precise lab values with units), then commits those entities to the patient's Cognee graph. This isn't "save the file," it's "extract the facts and let them become nodes and edges that connect to everything already known about this patient."

recall(): When a doctor asks "why is kidney function declining?", Anamnesis doesn't search documents, it traverses the graph. The answer comes back with a traceable evidence chain: which document, which date, which exact snippet supports each claim. This traceability mattered more than almost anything else in the build. A clinician will never trust an answer they can't audit down to the source.

improve() (Cognee's memify()): Medicine is not append-only. When a clinician marks a condition as "ruled out" or a medication as "discontinued," that correction has to propagate through the graph, not just get logged as a new fact sitting next to the old, now-wrong one. improve() restructures the relationships so the graph reflects the corrected understanding. This is the operation that makes the memory feel less like a log and more like an evolving belief system.

forget(): When the same blood report type gets uploaded twice for the same date, Anamnesis doesn't want two contradictory copies of the same fact living in the graph forever. forget() intelligently retires the duplicate or superseded information while preserving the historical record: memory that can prune itself without becoming amnesia.

Building around these four verbs, instead of hand-rolling my own retrieval and update logic, is what let a solo hackathon build produce something that behaves less like a chatbot wrapper and more like an actual second brain for a patient's chart.

The architecture decision that mattered most

Patient data is PHI. Anamnesis runs entirely on self-hosted, open-source Cognee: a GCP VM running the open-source stack behind Caddy/TLS, backed by Postgres+pgvector for vectors and an embedded Kuzu graph store, with every API call authenticated and every byte of patient data staying inside infrastructure I control. Nothing patient-related ever touches a third-party managed data store. That constraint is also why the hackathon track fit: "Best Use of Open Source" isn't a checkbox here, it's the actual architecture.

(Yes, all data used anywhere in the build is synthetic. Real PHI doesn't touch this system until compliance work, signed BAAs, a security review, a real retention/deletion policy, is actually done. That's a gate, not a formality, and it's true in the code, not just in this post.)

What "memory" actually bought me

The unlock, in practice, showed up in small moments during testing. Ask "what changed since the last consultation?" and the answer isn't a document dump, it's a diff over the graph, phrased the way a colleague would phrase it. Correct a diagnosis and the next query about that diagnosis already reflects the correction, without re-ingesting anything. Upload a duplicate report and the system quietly resolves the conflict instead of presenting two contradictory truths side by side.

None of that requires cleverness on my part. It requires trusting the memory primitives to do their job, and designing the product to expose them rather than hide them. Anamnesis has a live operations panel showing every remember/recall/improve/forget call as it happens, because the whole point was to prove the memory is real, not a black box.

Where this goes next

The hackathon build (Phases 0 to 4: infra, Remember, Recall, Improve, Forget against a single demo patient) is done and live. It's now becoming a real product: multi-tenant clinics, real clinician rosters, hardened security, because the underlying bet held up under a week of building. Clinical software should behave like a memory, not a filing cabinet. Every upload should make the system more useful, not just bigger.

That's the difference between storing a patient's story and remembering it. Cognee is what made the second one possible.

Live app: anamnesisai.vercel.app
Demo video: youtu.be/IH7V3kgMxo8
Code: github.com/Naazimsnh02/Anamnesis
Built with: Cognee (self-hosted), Next.js, Clerk, Gemini, Postgres/Kuzu