Forem: Arpit Pandey

Build ElectIQ: Turning Election Complexity into an Interactive AI Experience

Arpit Pandey — Wed, 29 Apr 2026 23:04:13 +0000

Elections are one of the most important pillars of any democracy — yet for many people, especially first-time voters, the process feels confusing, fragmented, and intimidating.

What if understanding elections felt less like reading a rulebook and more like having a conversation?

That question led me to build ElectIQ — an AI-powered, interactive platform designed to simplify the election process and make citizens more informed, confident, and engaged.

The Problem: Information Exists, But It’s Not Accessible

Election-related information is everywhere — government websites, news articles, PDFs — but it’s rarely:

Personalized
Interactive
Easy to explore

Most people don’t need more information.
They need better ways to understand it.

The Idea: Make Learning Elections Conversational

ElectIQ approaches this problem differently.

Instead of forcing users to search, scroll, and decode complex content, it creates a guided, interactive experience where users can:

Ask questions naturally
Explore timelines visually
Simulate real-world scenarios
Test their understanding through quizzes

The goal is simple:
👉 Make every user walk in confused and walk out informed.

What ElectIQ Actually Does

At its core, ElectIQ combines AI, structured data, and a clean UI to deliver multiple learning modes.

🧠 AI Chat Assistant

Users can ask election-related questions and receive context-aware, role-specific answers powered by Google Gemini.

This isn’t just a chatbot — it adapts responses based on who the user is:

First-time voter
Candidate
Journalist
Student

🗓️ Interactive Timeline

Instead of reading static articles, users can explore the election process step-by-step through:

Animated milestones
Expandable details
Contextual explanations

🧩 Scenario Simulator

One of the most practical features.

Users can explore “what if” situations like:

What happens if your name is missing from the voter list?
What should a candidate do during nomination?

This makes learning actionable — not just theoretical.

🏆 Gamified Quiz System

To reinforce learning, ElectIQ includes:

Topic-based quizzes
Progressive scoring
Badge rewards

Because passive learning doesn’t stick — interaction does.

🌙 UX That Actually Respects Users

Small things matter:

Dark mode support
Multilingual interface (English + Hindi)
Clean, distraction-free UI

Architecture: Simple, Fast, and Scalable

ElectIQ follows a lightweight, practical architecture:

Frontend: Vanilla JS (fast, no unnecessary bloat)
Backend: FastAPI (clean APIs, async support)
AI Layer: Google Gemini API
Deployment: Google Cloud Run (serverless, scalable)

Instead of overengineering, the focus was:

Build something that works reliably and scales when needed.

Why I Didn’t Overcomplicate the Stack

It’s easy to fall into the trap of using:

React + Redux + Tailwind + Microservices + Kubernetes

But for this project, that would be unnecessary.

ElectIQ proves that:

You don’t need a complex stack to build a powerful product — you need clarity.

Deployment: From Local to Cloud

The app is fully containerized and deployed using Google Cloud Run.

A single command can:

Build the container
Push it
Deploy it
Generate a public URL

This keeps infrastructure simple and cost-efficient.

Key Takeaways From Building This

1. Start Simple, Then Scale

Trying to implement CI/CD, automation, and optimization too early only slows you down.

Get it working first.

2. UX Matters More Than Features

You can have powerful functionality, but if it’s not intuitive, users won’t engage.

3. AI Is a Tool, Not the Product

The real value comes from:

How you structure information
How you guide users
How you design the experience

4. Practical > Perfect

A working system with clear value beats a “perfect” system that never ships.

What’s Next

ElectIQ is just the starting point.

Future improvements could include:

More regional languages
Real-time election data integration
Voice-based interaction
Mobile-first optimization

Final Thoughts

Elections shouldn’t feel complicated or inaccessible.

With the right combination of AI, design, and structured content, we can make civic education:

engaging
understandable
and actually useful

ElectIQ is a step in that direction.

If you’re building something similar or exploring AI-powered education tools, I’d love to hear your thoughts.

BiasLens: A Plug-and-Play Fairness Auditor for AI Systems

Arpit Pandey — Fri, 24 Apr 2026 18:25:35 +0000

Detect AI Bias Without Being a Machine Learning Expert

Artificial intelligence is increasingly making decisions that impact people's lives - hiring, lending, healthcare, and more. But what happens when those decisions are biased?
Amazon had to scrap an AI recruiting tool that discriminated against women. Apple Card faced backlash for offering lower credit limits to women. Healthcare systems have shown bias against Black patients compared to white patients with identical conditions.
The pattern is clear:
Bias is often discovered too late.
And here's the real issue - most tools designed to detect AI bias are built for machine learning engineers, not the people responsible for decisions.
That's the gap I wanted to close.

What is BiasLens?
BiasLens is a web application that helps non-technical users detect and understand bias in AI systems.
Instead of requiring expertise in machine learning, it allows users to simply upload a dataset and receive fairness insights instantly.
What it does:
Upload a CSV file
Automatically detect sensitive attributes (like gender or race)
Compute fairness metrics
Visualize results clearly
Export a compliance-ready report

Why This Matters
Most organizations don't intentionally deploy biased systems.
They just don't have the tools - or visibility - to detect bias early.
BiasLens shifts fairness auditing from:

"reactive damage control"
to
"proactive evaluation"

The Stack (and Why It Matters)
Frontend
React 18
TypeScript
Tailwind CSS
Recharts

Backend
Python
FastAPI
Pandas & NumPy
IBM AI Fairness 360
ReportLab

Key decisions:
FastAPI for speed, validation, and clean APIs
AIF360 for proven fairness metrics
TypeScript to catch errors early
React for scalable UI

Nothing fancy for the sake of it - just practical, reliable choices.

How It Works
Frontend → FastAPI → Metrics Engine
| | |
Upload Validate Compute
| | |
Preview Schema Visualize
| | |
Confirm Analyze Export
Flow:
Upload dataset
System validates and suggests schema
User confirms inputs
Metrics are computed
Results are visualized
Report is exported

Simple, fast, and intentional.

The Core: 4 Fairness Metrics
BiasLens focuses on four widely accepted fairness metrics.

Statistical Parity Difference Do different groups receive outcomes at the same rate? Fair range: -0.1 to 0.1 Example: 70% men hired vs 50% women → Fail

Disparate Impact Based on the "four-fifths rule" in employment law. Fair range: 0.8 to 1.25 Example: 60% vs 80% → Fail

Equal Opportunity Difference Are qualified individuals treated equally? Fair range: -0.1 to 0.1 Example: 90% vs 70% → Fail

Predictive Parity Difference Are predictions equally accurate across groups? Fair range: -0.1 to 0.1 Example: 85% vs 65% → Fail

Making It Understandable
Each metric is labeled as:
Pass → acceptable
Warning → borderline
Fail → problematic

Because raw numbers don't help non-technical users - decisions do.

Key Engineering Decisions

No Login System BiasLens uses session-based storage instead of accounts. No authentication No database overhead Sessions expire automatically

This keeps friction low and usability high.

Smart Attribute Detection The system suggests protected attributes automatically based on: Column names Number of unique values

Users don't need to "know what to select" - the system guides them.

Strict Validation One mistake users kept making: Selecting non-binary outcome columns (like age). Fix: Only allow binary outcome columns Filter UI options Show clear errors

Simple constraint, huge improvement.

Performance Trade-offs Large datasets (>500k rows) slowed things down. Instead of over-engineering: Added progress indicators Warned users Suggested sampling

Sometimes the right solution isn't optimization - it's expectation management.

Real Example: Adult Income Dataset
~48K rows
Attribute: gender
Outcome: income >50K

Results:
Statistical Parity: 0.197 → Fail
Disparate Impact: 0.27 → Fail
Equal Opportunity: 0.098 → Pass
Predictive Parity: -0.053 → Pass

Insight:
The model is biased in overall outcomes
- but fair in evaluating qualified candidates.
That distinction matters.

What You Should Take Away
If you're a developer:
Don't reinvent fairness metrics - use proven libraries
Validate early
Build for the actual user, not yourself

If you're an organization:
Audit before deployment, not after controversy
Bias isn't rare - it's expected
Documentation matters

If you're a researcher:
Your work needs usable interfaces
Theory without accessibility doesn't scale

Getting Started
git clone https://github.com/arpitpandey0307/bias-lens.git
cd biaslens
docker-compose up
Or run manually using FastAPI + React.
Then:
Open localhost
Upload dataset
Analyze fairness
Export report

Final Thoughts
Bias in AI isn't going away.
But ignorance about it can.
BiasLens isn't about solving fairness completely -
it's about making it visible, understandable, and actionable.
And that's where real progress starts.

Resources
IBM AI Fairness 360
Microsoft Fairlearn
UCI ML Repository

About the Author
[Arpit Pandey]
[Full Stack and AI/ML Developer]

StadiumOS — A Multi-Agent Coordination Engine!

Arpit Pandey — Wed, 15 Apr 2026 21:08:54 +0000

Building StadiumOS: A Real-Time Multi-Agent AI System for Crowd Management

Have you ever wondered how megastructures like sports stadiums handle tens of thousands of people moving around simultaneously? Between food court rushes, security bottlenecks, and exit gate stampedes, stadium operations are incredibly complex to manage.

I set out to tackle this problem by building StadiumOS — a multi-agent coordination engine capable of simulating and optimizing stadium operations in real time.

The Architecture: A Brain for the Stadium

This wasn’t just a simple web app. I wanted to build a true system-level intelligence platform. Here is the stack that powered it:

Backend: Node.js and Express (Simulation Engine and REST API)
Database: In-memory caching with optional Firebase Firestore mirroring
Frontend: Next.js 16 with Tailwind CSS and Leaflet.js
Brain: A custom Multi-Agent Architecture

How the Multi-Agent System Works

Instead of one monolithic AI trying to figure everything out, I decentralized the logic. StadiumOS runs a live simulation (ticking every 2 seconds) passing data to four independent AI Agents, each handling a specific domain:

Crowd Agent: Monitors zone densities to prevent overcrowding.

Write on Medium

Vendor Agent: Analyzes food court queues against stall service rates to predict wait times.
Security Agent: Keeps a rolling history of crowd spikes to detect anomalies and flag zones.
Transport Agent: Calculates net flow rates at gates to estimate clearance times during egress.

These four agents don’t make final decisions. Instead, they produce structured reports and pass them up to the Coordinator Engine.

The Decision Coordinator

The Coordinator acts as the central brain. It ingests the agent reports, runs them through priority-based rules, and outputs actionable recommendations.

For example: if the Crowd Agent reports the South Stand is highly dense, and the Security Agent flags an unusual spike, the Coordinator immediately generates a Critical Priority Decision: “RESTRICT_ZONE — Halt ingress to South Stand temporarily.”

The Dashboard

To bring this all to life, I built a dark-mode Next.js dashboard. It features an interactive Leaflet map that dynamically changes marker sizes and colors based on zone loads. A polling hook fetches the latest agent reports and coordinator decisions every 2 seconds, displaying a real-time, priority-sorted feed of actions.

Deployment and Takeaways

To cap it off, I containerized the entire monorepo using a multi-stage Docker build, allowing the Express backend to serve the Next.js static build from a single container, and deployed it serverlessly to Google Cloud Run.

Building a multi-agent architecture from scratch was an incredible challenge. It taught me how to decouple complex state, manage real-time tick-based simulations, and build prioritizing rule engines.

Check out the code on my GitHub!

GitHub Repo : https://github.com/arpitpandey0307/Stadium-OS.git

Link to Live Deployment : https://stadium-os-795750315067.us-central1.run.app/

Built SmartDesk, a multi-agent AI system using Google ADK to automate tasks, scheduling, notes, and research end-to-end.

Arpit Pandey — Wed, 15 Apr 2026 11:16:26 +0000

When I signed up for the Google Cloud Gen AI Academy APAC 2026 Hackathon, the problem statement was clear:

"Build a multi-agent AI system that helps users manage tasks, schedules, and information by interacting with multiple tools and data sources."

Simple enough on paper. But building it taught me more about real-world AI systems than anything I'd done before. This is the full story — what I built, how I built it, the mistakes I made, and what I learned.

The Problem I Chose to Solve

Here's a stat that hit me hard when I was planning this project:

The average knowledge worker spends 2.5 hours every day just organizing their work — not doing it. Switching between Notion for tasks, Google Calendar for scheduling, a notes app for summaries, and a browser tab for research.

Every tool is smart on its own. But none of them talk to each other intelligently. You're the human glue between them.

I wanted to build something that eliminates that. One conversational interface that handles everything end-to-end. You describe what you need in plain English — and a team of AI agents handles the rest.

That's SmartDesk — your personal AI Chief of Staff.

The Idea: One Prompt, Four Agents

Instead of building a single AI assistant, I designed SmartDesk as a team of specialist agents, each owning one responsibility:

✅ Task Agent — creates and manages tasks with priorities and deadlines
📅 Calendar Agent — schedules events and blocks focus time with conflict detection
📝 Notes Agent — captures summaries and action items automatically
🔍 Research Agent — answers knowledge questions via Wikipedia

A single prompt like this:

"I have a product launch deadline this Friday. Block 2 hours of focus time daily, create tasks for design, development, and testing milestones, and save a project summary note."

…triggers all four agents to execute their jobs in sequence, passing context to each other, and returns one clean consolidated response.

No app switching. No manual entry. Just results.

How It Works — The Architecture

SmartDesk is built on Google ADK (Agent Development Kit) using a SequentialAgent pattern.

Here's the full flow:

User Input (natural language)
↓
Root Agent (smartdesk_root)
→ saves prompt to shared state
↓
Sequential Workflow (smartdesk_workflow)
→ Task Agent writes task_output to state
→ Calendar Agent reads task_output, writes calendar_output
→ Notes Agent reads all outputs, writes notes_output
→ Research Agent checks if knowledge lookup needed
→ Response Formatter synthesizes everything
↓
Final Response to User

The key insight is shared state. Every agent reads from and writes to tool_context.state — a shared memory dictionary that flows through the entire pipeline. This is what makes true multi-agent coordination possible. Each agent builds on the work of the one before it.

The Database

All data is persisted in SQLite across four tables:

tasks → title, priority, deadline, status

events → title, start_time, end_time

notes → content, tags, created_at

agent_logs → agent_name, action, timestamp ← my favorite

That last table — agent_logs — logs every single agent action with a timestamp. During demos, watching it fill up in real-time is the most compelling way to show judges that genuine multi-agent coordination is happening.

The Tech Stack
Layer Technology Why I chose it
Agent Framework Google ADK 1.14.0 Native Google Cloud integration, built-in Cloud Run deployment
LLM Gemini 2.5 Flash (Vertex AI) Fast inference for multi-step pipelines, no API key needed with ADK
Database SQLite Zero configuration, perfect for hackathon demos
External Knowledge LangChain + Wikipedia Bridges ADK with the LangChain tool ecosystem
Deployment Google Cloud Run Serverless, one-command deploy via adk deploy cloud_run
Auth Google IAM Service Account Least-privilege security
Building It — Step by Step
Setting Up the Environment

I used Google Cloud Shell — a browser-based development environment with everything pre-installed. No local setup required.

cd && mkdir smartdesk && cd smartdesk
uv venv && source .venv/bin/activate
uv pip install -r requirements.txt

The requirements.txt was simple:

google-adk==1.14.0
langchain-community==0.3.27
wikipedia

One thing I learned the hard way: wikipedia==1.4.8 doesn't exist. The version pin breaks the install. Remove the version and let pip grab the latest.

Writing the Agents

Each agent in Google ADK is defined with a name, model, instruction, tools, and an output_key:

task_agent = Agent(
name="task_agent",
model=model_name,
description="Creates and manages tasks in the database.",
instruction="""
You are the Task Manager Agent for SmartDesk.
Based on the user's PROMPT, break it down into clear tasks.
Create each task using the create_task tool.
PROMPT: { PROMPT }
""",
tools=[create_task, get_all_tasks],
output_key="task_output"
)

The { PROMPT } syntax injects shared state values into agent instructions.

The SequentialAgent
smartdesk_workflow = SequentialAgent(
name="smartdesk_workflow",
sub_agents=[
task_agent,
calendar_agent,
notes_agent,
research_agent,
response_formatter
]
)

The SequentialAgent handles execution order automatically.

Key Challenges I Faced

SQLite Path on Cloud Run

Error:

"Fail to load 'smartdesk' module. unable to open database file"

Fix:

Before

DB_PATH = "smartdesk.db"

After

DB_PATH = "/tmp/smartdesk.db"

Service Account Name Too Short

Error:

ERROR: The account ID "lab2" does not have a length between 6 and 30.

Fix: renamed to smartdesk-agent.

Git Push Rejection

Error:

error: failed to push some refs — Updates were rejected because the remote contains work that you do not have locally.

Fix:

git pull --rebase origin main
git push
The Demo — What Judges See

Prompt:

"I have a product launch deadline this Friday. Block 2 hours daily, create tasks for design, dev, and testing, and save a project summary note."

Execution trace:

smartdesk_root → task_agent → calendar_agent → notes_agent → research_agent → response_formatter

Then showing agent_logs filling in real time — proof of real multi-agent coordination.

What I Learned
Shared state is the backbone of multi-agent systems.
Observability matters more than output.
Google ADK makes deployment trivially easy.
Start with the demo, work backward.
SQLite is underrated for AI demos.
What's Next for SmartDesk
🔌 Real MCP integrations — Google Calendar API, Notion, Slack
🧠 Long-term memory — ChromaDB
🗣️ Voice interface — faster-whisper
📊 Analytics dashboard — agent_logs insights
🤝 Team mode — multi-user collaboration
Try It Yourself
GitHub: https://github.com/arpitpandey0307/smart-desk
Live Demo: https://smartdesk-agent-456703325610.us-central1.run.app
Demo Video: https://drive.google.com/file/d/17i04sEihCSWR1J7ioeOPM0dH4MoaxzQy/view
Final Thoughts

Building SmartDesk taught me that the real power of multi-agent AI isn't in any single agent — it's in the coordination layer between them.

The moment you design agents that pass context to each other, you stop building tools and start building systems.

Built with Google ADK, Gemini 2.5 Flash, Vertex AI, SQLite, and Google Cloud Run.