DEV Community: Praveen Raj Thulasi S

🌱 GrassRoute: I Built an AI That Wants You to Stop Using It

Praveen Raj Thulasi S — Sat, 10 Oct 2026 18:59:51 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

GrassRoute is an open-source, AI-powered outdoor companion that transforms your available time, mood, interests, and surroundings into personalized real-world missions.

Think about the last time you felt bored, mentally exhausted, or stuck in front of your laptop.

You probably opened another app, watched another video, or asked an AI chatbot what to do next.

And the result? More screen time.

I wanted to explore the opposite idea.

What if an AI assistant's goal wasn't to keep you engaged, but to help you leave the screen altogether?

That's the idea behind GrassRoute.

Instead of recommending more digital content, GrassRoute helps you discover something meaningful to do in the physical world.

🌳 How does it work?

Imagine telling GrassRoute:

"I'm tired, I have 40 minutes, and I want to get outside without spending money."

GrassRoute uses your preferences and available context to generate a personalized outdoor mission.

Your mission: The 40-Minute Green Reset

🚶 Take a relaxing walk in a suitable nearby outdoor space.

🌿 Find three interesting things you would normally overlook.

📵 Spend five minutes observing your surroundings without your phone.

🌱 Return when you're ready and reflect on the experience.

The mission is designed around your available time, energy, preferences, and practical constraints.

No expensive equipment. No complicated workout plans. No endless chatbot conversation.

Just a reason to step outside.

🧠 More than an AI chatbot

GrassRoute is designed around an agentic workflow rather than a simple prompt-and-response interface.

The planned agent workflow includes:

Intent Agent: Understands what the user wants and extracts constraints such as available time, energy, and activity preferences.

Explorer Agent: Discovers relevant outdoor locations and activities using available search tools.

Environment Agent: Considers weather and environmental conditions when reliable data is available.

Mission Agent: Converts the gathered context into an actionable outdoor experience.

Safety and Feasibility Layer: Checks duration, budget, travel requirements, and relevant safety constraints.

Memory and Reflection Agent: Uses mission feedback and activity history to improve future recommendations.

The long-term goal is to make each mission more relevant without requiring the user to spend more time interacting with the application.

🌱 The feature I'm most excited about: Screen Exit

Most applications measure success through engagement, session duration, and repeated visits.

GrassRoute explores a different metric: meaningful time spent away from the application.

Once a mission is ready, the experience becomes intentionally minimal:

"Your mission is ready. Now put your phone away."

The user can complete the activity, return later, and optionally share feedback.

The application is there when needed, but it shouldn't demand attention throughout the experience.

Demo

Deployed Link - https://drive.google.com/file/d/1yS3QHnBi9zMXsEscAgvh2jzDs152pZ6T/view?usp=sharing

How I Built It

The architecture is designed around a modular frontend, backend, and AI tool layer.

Technology stack

Frontend: React, Vite, and Tailwind CSS.

Backend: Node.js and Express.

Database and memory: MongoDB Atlas.

AI: [Insert the open-weight model and inference runtime actually used.]

Agent tools: MCP-compatible tools for connecting the agent to external capabilities.

Observability: Sentry for error monitoring and agent execution visibility.

Outdoor discovery: SerpApi, where enabled, for finding relevant real-world places and activities.

The partner services are selected for their usefulness to the product, with free-tier-compatible usage as a development constraint.

🧩 Why an agentic architecture?

A conventional chatbot could generate an outdoor activity from a single prompt. However, recommending a real-world activity involves more than generating plausible text.

The system needs to consider multiple constraints:

How much time does the user actually have?

Is the activity suitable for their preferences and energy level?

Does it require travel, equipment, or money?

Is the location information reliable?

Are environmental conditions suitable?

What has the user enjoyed or rejected previously?

GrassRoute separates these responsibilities into modular services and agent capabilities.

MCP provides a standardized way for compatible AI clients and agents to discover and invoke tools. The application can use this approach to connect its agent to search, weather, profile, and mission-management capabilities.

The backend remains responsible for business rules, validation, persistence, and API access rather than placing all application logic inside the MCP server.

🧠 Personalization through memory

A useful outdoor companion should improve with experience.

For example, if a user repeatedly completes nature walks and photography missions but consistently rejects running activities, GrassRoute can use that feedback to adjust future recommendations.

MongoDB Atlas provides the proposed persistence layer for user preferences, missions, completion history, and reflections.

This allows personalization to be based on observed behavior instead of treating every conversation as an entirely new interaction.

Why Does Open Innovation Matter?

For GrassRoute, open innovation isn't just about making the source code public.

It's about giving users and developers control over how the AI works.

Freedom to choose the model

An open-weight model can provide an alternative to depending entirely on a proprietary AI API. Depending on hardware and model requirements, inference can run locally or through a compatible provider.

This creates room for experimentation with different models, inference runtimes, and prompting strategies.

Privacy and user control

Outdoor preferences, activity history, and location context can be personal.

A local-inference configuration can keep model processing on the user's device, subject to the application's actual data flows. External search, weather, and hosting services may still receive the information necessary for their requests, so these integrations need to be designed carefully.

The goal is to make privacy a design consideration rather than an afterthought.

A system developers can extend

Developers should be able to add new outdoor activities, replace a search provider, integrate another weather source, or experiment with a different model without rewriting the entire application.

A modular architecture and standardized tool interfaces make these experiments more practical.

AI that doesn't depend on a closed ecosystem

An application like GrassRoute shouldn't need a single proprietary provider to define its future.

Open models and replaceable integrations make it easier to experiment, self-host where practical, and contribute improvements back to the community.

For this project, open innovation makes a particularly interesting idea possible: building an AI assistant whose purpose is to help people spend less time using AI.

🛡️ DecisionShield: An AI That Audits Your Decision Before You Make It

Praveen Raj Thulasi S — Thu, 08 Oct 2026 11:26:32 +0000

Don't ask AI what to choose. Ask AI if you're ready to choose.

We use AI every day to make decisions.

Which technology should we use?

Should we migrate our database?

Which cloud platform should we choose?

Which vendor is better?

Should we build or buy?

The problem is that AI assistants are often very good at giving us an answer — even when the information behind the decision is incomplete.

That led us to a different question:

What if AI didn't immediately tell us what to choose, but first checked whether we actually had enough evidence to make the decision?

That's the idea behind DecisionShield.

🔗 Project Links

Resource	Link
💻 GitHub Repository	https://github.com/Praveen-Raj-Thulasi/DecisionAI
🎥 Demo Video	https://drive.google.com/file/d/1WADhxrbvxrPhcrXLVeSE0215SyG1gwe5/view?usp=sharing

🤔 The Problem

Imagine asking an AI:

"Should our startup migrate from PostgreSQL to MongoDB?"

A conventional AI assistant might respond:

"MongoDB could be a better choice because it provides flexibility and horizontal scalability."

Sounds convincing.

But what if we don't know:

What our query patterns look like?
How many transactions require strong consistency?
Whether complex joins are important?
What the migration downtime tolerance is?
What the three-year cost looks like?
Whether our team has the required expertise?

The AI may have given us a reasonable answer.

But we still weren't ready to make the decision.

This is the problem DecisionShield tries to solve.

💡 The Idea

DecisionShield is an AI-powered Decision Readiness & Risk Audit Platform.

Instead of immediately recommending an option, DecisionShield analyzes the decision itself.

It separates the information into:

✅ Facts
⚠️ Assumptions
❓ Unknowns
📌 Claims
🚨 Risks
🔍 Missing Evidence
🧪 Stress-Test Scenarios

Then a deterministic decision engine calculates a Decision Readiness Score.

The result isn't simply:

"Choose Option A."

Instead, it might say:

Decision Readiness: 64/100 — NOT READY

Three critical pieces of evidence are missing before this decision should be finalized.

That's a very different approach to AI-assisted decision making.

🔄 How DecisionShield Works

The complete workflow is:

                USER DECISION
                     │
                     ▼
             Decision Context
                     │
                     ▼
              ┌─────────────┐
              │   Gemma 4   │
              │  Reasoning  │
              └──────┬──────┘
                     │
                     ▼
          Structured AI Analysis
                     │
        ┌────────────┼────────────┐
        ▼            ▼            ▼
      Facts     Assumptions      Risks
        │            │            │
        └────────────┼────────────┘
                     │
                     ▼
             Missing Evidence
                     │
                     ▼
          Deterministic Scoring
                     │
                     ▼
          Decision Readiness Score
                     │
                     ▼
             Stress Testing
                     │
                     ▼
           Decision Stability
                     │
                     ▼
             Decision Audit

🧠 Why Not Just Build Another AI Chatbot?

This was one of the most important design decisions behind the project.

A traditional AI assistant looks like:

User Question
      ↓
     LLM
      ↓
Text Recommendation

DecisionShield looks like:

Decision
   ↓
Evidence Extraction
   ↓
Classification
   ↓
Risk Analysis
   ↓
Missing Evidence
   ↓
Deterministic Scoring
   ↓
Stress Testing
   ↓
Decision Audit

The goal isn't to replace the human decision maker.

The goal is to improve the quality of the reasoning and evidence available to the human decision maker.

🧩 Core Features

1. Decision Workspace

The user starts by describing the decision.

They can provide:

Decision title
Decision description
Options
Context
Requirements
Constraints
Existing evidence

For example:

Decision:
Should our startup migrate from PostgreSQL to MongoDB?

Options:
• Stay with PostgreSQL
• Migrate to MongoDB

Context:
Our startup currently has approximately 2 TB of data
and expects significant growth over the next three years.

Constraints:
• Small engineering team
• Limited migration budget

2. AI Evidence Analysis

Gemma analyzes the decision context and separates information into different categories.

Facts

Information directly supported by the provided context.

✓ Current database is PostgreSQL
✓ Current data volume is approximately 2 TB
✓ Engineering team is small

Assumptions

Statements that may be true but aren't sufficiently supported.

⚠ MongoDB will automatically solve scalability problems.
⚠ Migration will reduce operational complexity.

Unknowns

Important information that wasn't provided.

? Query workload patterns
? Transaction requirements
? Data consistency requirements
? Peak traffic

Claims

Statements that require verification.

? "MongoDB will be cheaper over three years."

This classification becomes the foundation of the rest of the analysis.

3. Decision Readiness Score

DecisionShield calculates a score from 0–100.

The score considers multiple dimensions such as:

Evidence Quality
Requirement Coverage
Evidence Completeness
Risk Coverage
Assumption Load
Unknown Information
Decision Stability

The important architectural decision here is:

Gemma does not generate the final score.

Instead:

Gemma
  ↓
Semantic Analysis
  ↓
Structured JSON
  ↓
Pydantic Validation
  ↓
Python Decision Engine
  ↓
Readiness Score

This makes the scoring process deterministic and reproducible.

Example:

                 DECISION READINESS

                       64
                     /100

        ┌───────────────────────────┐
        │        NOT READY          │
        └───────────────────────────┘

Evidence Quality       72%
Requirements           80%
Risk Coverage          55%
Evidence Completeness  61%
Decision Stability     68%

4. Missing Evidence Detection

One of the most important features is asking:

"What information are we missing that could materially change this decision?"

For the PostgreSQL vs MongoDB example, DecisionShield might identify:

🔴 CRITICAL

1. Query workload analysis
2. Transaction requirements
3. Data consistency requirements

🟠 HIGH

4. Migration downtime tolerance
5. Three-year infrastructure cost

But it doesn't stop there.

For each missing piece of information, the system generates a verification action.

For example:

Missing Evidence:
Expected peak traffic

Verification Action:
Estimate current peak requests per second and project
expected traffic over the next three years.

This converts AI analysis into an actionable workflow.

5. Risk Analysis

DecisionShield identifies risks associated with the decision.

Each risk can include:

Severity
Likelihood
Impact
Confidence
Supporting evidence

Example:

🚨 HIGH RISK

Complex relational workloads

MongoDB may introduce additional complexity
if the application's workload depends heavily
on complex relational queries and joins.

The backend then incorporates risk information into the deterministic readiness calculation.

6. Decision Stress Testing

A decision shouldn't only be evaluated under today's conditions.

So DecisionShield allows users to ask:

"What happens if the assumptions change?"

Example scenarios:

Scenario 1

Traffic increases 10×.

Scenario 2

The infrastructure budget decreases by 50%.

Scenario 3

Strict data residency becomes mandatory.

Scenario 4

The engineering team loses its existing database expertise.

Scenario 5

Data volume doubles.

The system analyzes how these scenarios affect the decision.

📉 Decision Stability

Suppose the current readiness score is:

72 / 100

Stress testing might produce:

Current Decision       72
10× Traffic            68
50% Budget             65
New Compliance         43
Team Expertise Loss    61

The system can then identify:

⚠️ Decision Stability: LOW

because one plausible change significantly alters the decision's readiness.

This is important because a decision can have a high current score but still be fragile.

🧠 Why Gemma 4?

Gemma is not being used as a generic chatbot inside DecisionShield.

It is used as the semantic reasoning layer.

Gemma performs tasks such as:

Unstructured Decision Context
            ↓
      Gemma 4 E4B
            ↓
     Semantic Analysis
            ↓
 ┌──────────┼──────────┐
 ▼          ▼          ▼
Facts   Assumptions   Risks
 ▼          ▼          ▼
Unknowns  Claims  Missing Evidence

The backend then converts this structured analysis into measurable decision metrics.

Separation of responsibilities

Component	Responsibility
Gemma 4	Semantic reasoning
Pydantic	AI output validation
Python Decision Engine	Deterministic scoring
FastAPI	Backend orchestration
React	Visualization
User	Final decision

This separation was intentional.

⚙️ Technical Architecture

                         ┌─────────────────────┐
                         │   React + Vite UI   │
                         │                     │
                         │ Decision Workspace  │
                         │ Dashboard           │
                         │ Evidence Explorer   │
                         │ Stress Testing      │
                         │ Audit Report        │
                         └──────────┬──────────┘
                                    │
                                REST API
                                    │
                                    ▼
                         ┌─────────────────────┐
                         │       FastAPI       │
                         │      Backend        │
                         └──────────┬──────────┘
                                    │
                    ┌───────────────┴──────────────┐
                    │                              │
                    ▼                              ▼
          ┌──────────────────┐           ┌──────────────────┐
          │   Gemma 4 E4B    │           │ Decision Engine  │
          │                  │           │                  │
          │ AI Reasoning     │           │ Deterministic    │
          │ Classification   │           │ Scoring          │
          │ Risk Discovery   │           │ Stability        │
          └────────┬─────────┘           └────────┬─────────┘
                   │                              │
                   └──────────────┬───────────────┘
                                  ▼
                         ┌──────────────────┐
                         │ Decision Analysis│
                         │   Structured     │
                         │     Result       │
                         └────────┬─────────┘
                                  │
                                  ▼
                         ┌──────────────────┐
                         │ Decision Audit   │
                         │     Report       │
                         └──────────────────┘

🛠️ Tech Stack

Frontend

React
Vite
Tailwind CSS
Recharts
Framer Motion

Backend

Python
FastAPI
Pydantic
Uvicorn

AI

Gemma 4 E4B
4-bit quantization
Local inference

Architecture

REST API
Structured JSON
Deterministic scoring engine
In-memory decision store for the MVP

💻 Running Locally

Prerequisites

You will need:

Python 3.x
Node.js
npm
NVIDIA GPU recommended for local Gemma inference
Approximately 16 GB RAM
Approximately 6 GB VRAM for the target E4B Q4 setup

Clone the Repository

git clone https://github.com/Praveen-Raj-Thulasi/DecisionAI/
cd DecisionShield

Backend

cd backend

python -m venv .venv

Windows

.venv\Scripts\activate

Linux/macOS

source .venv/bin/activate

Install dependencies:

pip install -r requirements.txt

Create environment configuration:

cp .env.example .env

Configure the Gemma model path and other required settings.

Start the backend:

uvicorn app.main:app --reload

🎨 Frontend

cd frontend

npm install

npm run dev

🧪 Demo Scenario

For the first demonstration, we use:

Should our startup migrate from PostgreSQL to MongoDB?

The system begins with a simple decision.

It then progressively reveals why the decision isn't as straightforward as it initially appears.

Decision
   ↓
Facts
   ↓
Assumptions
   ↓
Unknowns
   ↓
Risks
   ↓
Missing Evidence
   ↓
Readiness
   ↓
Stress Test
   ↓
Decision Stability

This demonstrates the central philosophy of DecisionShield:

A confident decision isn't necessarily a well-supported decision.

🔬 Example Analysis

Input

Our startup has 2 TB of PostgreSQL data.

We expect rapid growth and believe MongoDB
will make scaling easier.

Our team is small and we want to reduce
operational complexity.

DecisionShield might identify:

Facts

✓ PostgreSQL is currently used
✓ Data volume is approximately 2 TB
✓ Team size is limited
✓ Growth is expected

Assumptions

⚠ MongoDB will automatically improve scalability
⚠ MongoDB will reduce operational complexity

Unknowns

? Query patterns
? Transaction requirements
? Consistency requirements
? Peak workload
? Migration downtime

Risks

🚨 Complex relational queries
🚨 Migration downtime
🚨 Learning curve

Missing Evidence

🔍 Query workload analysis
🔍 Transaction requirements
🔍 Three-year cost comparison

Result

Decision Readiness

64 / 100

⚠ NOT READY

Instead of blindly recommending a database, DecisionShield tells the user what they should investigate first.

🏗️ Project Structure

DecisionShield/
│
├── frontend/
│   ├── components/
│   ├── pages/
│   ├── services/
│   └── ...
│
├── backend/
│   ├── app/
│   │   ├── api/
│   │   ├── ai/
│   │   ├── engine/
│   │   ├── schemas/
│   │   ├── services/
│   │   └── ...
│   │
│   ├── tests/
│   └── requirements.txt
│
├── docs/
│
├── README.md
└── ...

🔐 Reliability by Design

A major design principle of DecisionShield is separating AI reasoning from numerical decision logic.

We don't want:

Gemma:
"I think the decision readiness is 87."

Instead:

Gemma
 ↓
Facts / Assumptions / Risks / Unknowns
 ↓
Validated JSON
 ↓
Python Decision Engine
 ↓
Readiness Score

This provides a more reproducible scoring process and makes the system easier to inspect and debug.

🧪 Demo Mode

Local AI models can sometimes introduce practical problems during a hackathon:

model loading
VRAM limitations
CUDA issues
inference failures
environment configuration

To keep the application demonstrable, DecisionShield includes a fallback/demo provider.

              AI Analysis
                   │
          ┌────────┴────────┐
          │                 │
       Gemma 4          Demo Provider
          │                 │
          └────────┬────────┘
                   ▼
            Same JSON Schema
                   ▼
          Same Decision Engine

This means the rest of the application doesn't depend on whether the local model happens to load successfully during a demonstration.

The application clearly identifies whether the result came from Gemma or demo mode.

🌍 Why This Could Matter

Decision making isn't only about having more information.

It's about knowing:

which information is reliable
which assumptions are untested
which information is missing
which risks matter
which scenarios could invalidate the decision

DecisionShield tries to turn those questions into a repeatable workflow.

The goal is not:

AI makes the decision.

The goal is:

AI helps humans understand whether their decision is ready to be made.

🚀 Future Roadmap

DecisionShield is currently an MVP.

Possible future improvements include:

📄 Evidence Ingestion

Upload:

PDFs
documents
spreadsheets
reports

and automatically extract evidence.

🔗 Evidence Provenance

Track where every fact came from.

Fact
 ↓
Source
 ↓
Document
 ↓
Page / Section

🧠 Advanced Decision Graphs

Represent relationships between:

Evidence
   ↓
Assumption
   ↓
Risk
   ↓
Requirement
   ↓
Decision

👥 Collaborative Decision Rooms

Allow teams to collaboratively audit a decision.

📚 Decision History

Track how decisions change over time.

🌐 External Knowledge

Use trusted external sources to verify missing evidence.

🧪 Advanced Simulations

Introduce more sophisticated scenario and sensitivity analysis.

🏢 Domain-Specific Audits

Create specialized templates for:

software architecture
business decisions
procurement
hiring
cloud infrastructure
product strategy

⚠️ Limitations

DecisionShield is a decision-support system.

It does not guarantee that a decision is correct.

AI-generated classifications may be imperfect.

Missing evidence suggestions may not be exhaustive.

Stress tests are scenarios, not predictions.

The Decision Readiness Score is an analytical indicator, not an objective measure of truth.

For high-stakes decisions, users should consult qualified professionals and verify important evidence independently.

🌱 Open Source

DecisionShield is being developed as an open-source project.

The goal is to make the architecture transparent and allow developers to experiment with:

local AI
Gemma
structured reasoning
deterministic scoring
decision intelligence
human-in-the-loop systems

Contributions

Contributions, ideas, issues and improvements are welcome.

Repository:

[ADD GITHUB REPOSITORY URL]

Issues:

[ADD GITHUB ISSUES URL]

Pull Requests:

[ADD CONTRIBUTION GUIDELINES / PR URL]

👥 Team

Team Name

[ADD TEAM NAME]

Members

[NAME] — [ROLE]
[NAME] — [ROLE]
[NAME] — [ROLE]
[NAME] — [ROLE]

Responsibilities

Member	Contribution
[NAME]	AI / Gemma Integration
[NAME]	Backend / FastAPI
[NAME]	Frontend / UI
[NAME]	Architecture / Testing

🏆 Hackathon

Built for:

Hacktoberfest Hack Day Coimbatore x (INIT Club & IDEA Club)

Additional Challenge:

Gemme 4

🎥 Demo

Watch the complete DecisionShield demonstration:

https://youtu.be/Y3VlhbDvYRg

The demo covers:

Create Decision
      ↓
AI Analysis
      ↓
Evidence Classification
      ↓
Readiness Score
      ↓
Missing Evidence
      ↓
Stress Testing
      ↓
Decision Stability
      ↓
Final Audit

🔗 Links

Team

Wakie Wakie

🙌 Final Thoughts

The most interesting part of building DecisionShield wasn't getting an AI model to generate a recommendation.

It was asking a different question:

What if the most useful thing AI can tell us isn't what to choose — but what we're missing before we choose?

That idea became DecisionShield.

Instead of:

"What should I choose?"

we ask:

"Do I have enough evidence to choose?"

And if the answer is no, the system tells us why.

Built with ❤️ using open-source AI and Gemma 4.

I Built an AI Pocket Nutritionist to Read Food Labels So My Friend Doesn't Have To

Praveen Raj Thulasi S — Sun, 04 Oct 2026 17:02:23 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

FoodLabelAI: (codenamed FriendOS) is an intelligent, AI-powered health companion that demystifies the back of food packaging. By simply scanning a nutrition label or ingredient list, the app uses OCR and Google's Gemma model to instantly break down what you're actually eating. It visualizes macronutrients, flags hidden additives or allergens, and even provides advanced insights like "protein reality" (how bioavailable the protein actually is).

Who I Built It For:
I built this for my girl bestie. Recently, she was advised by her doctor to closely monitor her intake of hidden sugars and inflammatory seed oils. While she wanted to eat healthier, standing in the grocery store aisle trying to decode complex chemical names and intentionally confusing serving sizes on nutrition labels was incredibly overwhelming and stressful for her.

The Problem It Solves:
Food companies often disguise unhealthy ingredients under complex aliases or manipulate serving sizes to make a product look healthier than it is. FoodLabelAI solves this by acting as a pocket nutritionist. Instead of requiring her to google 15 different ingredients while holding up the grocery line, she just snaps a photo. The AI immediately cuts through the marketing noise, alerts her if a product violates her dietary goals, and explains the ingredients in plain, accessible language. It turned a stressful chore into an empowering habit.

Demo

Deployed Link - https://food-label-ai.vercel.app

Code

Github Repository Link - https://github.com/Praveen-Raj-Thulasi/FoodLabelAI

How I Built It

To bring FoodLabelAI to life, I relied on a modern full-stack architecture powered entirely by open-source AI.

For the intelligence layer, I used Ollama to run local inference with Google's Gemma (2B) open-weight model. This model acts as the core brain of the application, parsing raw text extracted from food labels (via OCR) and analyzing it for nutritional value, bioavailability insights, and potential health warnings.

The application itself is built with:

Frontend: A responsive React app built with Vite, Tailwind CSS, and custom UI components for data visualization (like macronutrient charts and protein reality cards). Hosted on Vercel.
Backend: A robust Node.js/Express API that handles user authentication (JWT), file uploads, and orchestration between the OCR service and the local Gemma model. Hosted on Render.
Database: MongoDB for storing user profiles, scan histories, and a growing knowledge base of food data.

By decoupling the AI inference into an independent service using Ollama, the Node.js backend can asynchronously communicate with the Gemma model without blocking the main event loop, resulting in a smooth experience for the user.

Why Does Open Innovation Matter?

Open innovation was absolutely critical for FoodLabelAI. When building an application that analyzes sensitive personal health targets and dietary restrictions, privacy and data sovereignty are paramount.

Using an open-weight model like Gemma via Ollama made it possible to run complex natural language analysis without sending sensitive dietary or health data to a closed-source, third-party API. It gave me complete control over the inference pipeline, allowing me to tweak system prompts, eliminate API costs, and guarantee to users that their food scanning habits and health goals aren't being used to train a closed, proprietary system.

Closed APIs are great for prototyping, but open innovation makes it possible to build scalable, privacy-first tools for everyday consumers.

Prize Categories

Render

I Built an Agentic Analytics Platform — Here's What I Learned

Praveen Raj Thulasi S — Fri, 02 Oct 2026 09:34:56 +0000

I Built an Agentic Analytics Platform — Here's What I Learned

What if you could ask your analytics dashboard:

"Why did sales decrease last month?"

and instead of manually filtering charts and writing database queries, an AI system could investigate the data, generate a query, validate it, analyze the results, and explain what it found?

That's what I wanted to explore with AgentVerse, an agentic analytics platform I built using React, Node.js, MongoDB, Ollama, and MCP.

This project started as an experiment with multi-agent AI. Along the way, I learned that building an agentic application is much less about simply connecting an LLM to a database—and much more about controlling, validating, and observing what the AI does.

🚀 What is AgentVerse?

AgentVerse is a natural-language analytics platform.

Instead of manually writing MongoDB queries, users can ask questions such as:

Show monthly sales for the last 12 months.

or:

Show the top 5 products by revenue.

or:

Why did sales decrease last month?

The platform translates these questions into an analytics workflow.

At a high level:

User
  ↓
Orchestrator Agent
  ↓
Query Generation
  ↓
Query Guardian
  ↓
MCP Server
  ↓
MongoDB
  ↓
Evidence Analysis
  ↓
Insight Agent
  ↓
Visualization

The goal isn't just to generate an answer.

The goal is to make the entire analytical process controllable and observable.

🧠 Why Multi-Agent?

One approach would be:

User → LLM → Database → Answer

But that gives one model too many responsibilities.

It has to understand the question, understand the schema, generate a query, execute it, analyze the result, and produce a visualization.

Instead, I separated the workflow into specialized components.

                    User
                      │
                      ▼
               Orchestrator
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
       Intent       Schema     Session
       Planning    Discovery    State
          │
          ▼
    Query Generation
          │
          ▼
    Query Guardian
          │
          ▼
       MCP Server
          │
          ▼
       MongoDB
          │
          ▼
    Evidence Engine
          │
          ▼
     Insight Agent
          │
          ▼
    Visualization

Each component has a specific responsibility.

This makes the system easier to debug and gives me more control over what each part of the AI workflow is allowed to do.

🔌 MCP as the Data Boundary

One of the most interesting parts of the project was using Model Context Protocol (MCP) as a boundary between the AI agents and the database.

Instead of allowing the agent to directly access MongoDB:

Agent
  ↓
MongoDB

the architecture becomes:

Agent
  ↓
MCP Server
  ↓
MongoDB

The MCP layer exposes controlled tools such as:

get_schema
execute_query

This means the AI can request the tools it needs without having unrestricted access to the underlying database.

For me, MCP became more than just a way to connect an LLM to tools.

It became an architectural boundary between:

AI reasoning → Data access

🛡️ The Problem I Didn't Expect: AI-Generated Queries

Getting an LLM to generate a MongoDB aggregation pipeline isn't particularly difficult.

The difficult part is deciding:

Should I trust the generated query?

The answer is no.

LLMs can generate invalid queries, use incorrect fields, or potentially generate operations that shouldn't be allowed in an analytics application.

That's why I built a Query Guardian.

The flow is:

LLM generates query
        ↓
   Query Guardian
        ↓
     Validation
        ↓
   ┌────┴────┐
   │         │
 Valid     Invalid
   │         │
   ▼         ▼
Execute    Repair
             │
             ▼
        Validate Again

The Guardian checks things such as:

Allowed aggregation stages
Allowed operators
Collection names
Field names
Pipeline length
Result limits
Forbidden operations
Query structure

The analytics system is designed around read-only operations rather than allowing the AI to modify the database.

This was one of the biggest lessons from the project:

LLM output should be treated as untrusted input, not executable truth.

📊 A Real Example

Let's say a user asks:

"Why did sales decrease last month?"

The system doesn't simply send that sentence to an LLM and return whatever it says.

Instead, the request goes through several stages.

1. Understand the request

The Orchestrator identifies the request as a root-cause analysis task.

2. Discover the schema

The system retrieves the available database structure through MCP.

3. Generate a query

The Analytics Query Agent creates a MongoDB aggregation pipeline.

4. Validate it

Query Guardian checks the generated pipeline.

5. Execute it

The validated query is sent through the MCP server to MongoDB.

6. Analyze the evidence

The Evidence Engine calculates measurable changes in the returned data.

For example:

Overall Revenue:    -18.2%

South Region:       -31.4%
Electronics:        -24.7%
Product A:          -28.1%

7. Generate the insight

The Insight Agent receives the structured evidence and creates the explanation.

Rather than blindly claiming:

"The South region caused the decline."

the system can use more careful language such as:

"The South region recorded the largest observed regional decline and may represent a contributing factor."

This distinction matters.

A correlation in the data isn't automatically proof of causation.

📈 Dynamic Visualizations

The result isn't just text.

AgentVerse can determine an appropriate visualization based on the analytical result.

For example:

Trend over time
       ↓
   Line Chart

Category comparison
       ↓
    Bar Chart

Distribution
       ↓
    Pie Chart

Single metric
       ↓
    KPI Card

The React frontend uses Recharts to render these visualizations.

The workflow becomes:

Question
   ↓
Intent
   ↓
Query
   ↓
Data
   ↓
Evidence
   ↓
Insight
   ↓
Visualization

🔍 Making the AI Workflow Observable

One thing I didn't want was a black box that simply says:

"Here's your answer."

AgentVerse includes an execution trace showing the different stages of the workflow.

For example:

✓ Orchestrator Agent
  Intent Classification

✓ MCP Schema Discovery
  Database Schema

✓ Analytics Query Agent
  MQL Generation

✓ Query Guardian
  Security Validation

✓ MCP Execution
  MongoDB Query

✓ Insight Agent
  Evidence Synthesis

✓ Visualization
  Chart Selection

This makes the system easier to understand and debug.

If something goes wrong, I can investigate the intermediate steps instead of only looking at the final response.

📝 Audit Logging

Agentic applications can be difficult to debug because there are multiple intermediate operations.

So I also added an audit layer that can track information such as:

Request ID
User Question
Generated Pipeline
Validation Status
Rows Returned
Execution Time
Timestamp

This gives me a history of what the system actually did.

For example, if an insight looks incorrect, I can trace:

User Question
      ↓
Generated Query
      ↓
Guardian Validation
      ↓
Database Result
      ↓
Evidence
      ↓
Final Insight

That is much more useful than debugging only the final LLM response.

🧰 Tech Stack

Frontend

React
TypeScript
Vite
Tailwind CSS
Recharts
Axios

Backend

Node.js
Express
TypeScript
MongoDB
Mongoose

AI / Agent Layer

Ollama
LLM-based agents
MCP
Multi-agent orchestration
Structured JSON responses

💡 What I Learned

1. LLMs should not be trusted blindly

The model can generate something that looks valid but isn't.

Validation needs to happen outside the model.

2. Not everything needs AI

Things like query limits, security checks, percentage calculations, and schema validation are better handled deterministically.

Use AI where reasoning is useful.

Use traditional code where deterministic correctness matters.

3. More agents don't automatically mean a better system

Adding agents increases complexity.

The reason for separating components should be clear responsibilities—not simply having "more AI."

4. Observability matters

With a traditional API, debugging can be relatively straightforward.

With an agentic system, there may be several intermediate decisions.

Execution traces and audit logs become extremely valuable.

5. AI should not become a single point of failure

If the LLM is unavailable, the application shouldn't necessarily become completely unusable.

Fallback strategies and deterministic logic can make the system more resilient.

🚧 What's Next?

AgentVerse is still evolving.

Some areas I want to explore next are:

More MCP tools
Multiple data sources
Better agent evaluation
Streaming agent responses
Improved query validation
More advanced anomaly detection
Long-term agent memory
Cloud deployment
Production-grade observability
Automated evaluation of analytical accuracy

The biggest question I want to explore is:

How do we reliably evaluate an agentic analytics system?

A fluent AI response isn't necessarily a correct one.

That's where I think a lot of interesting engineering work remains.

🎯 Final Thoughts

Building AgentVerse changed how I think about AI applications.

Earlier, my main question was:

"Which LLM should I use?"

Now I think more about:

"What should the LLM be allowed to do?"

That shift completely changed how I approached the architecture.

The LLM is only one component.

The interesting engineering happens around it:

LLM
 ↓
Tools
 ↓
Validation
 ↓
Security
 ↓
Evidence
 ↓
Observability
 ↓
Reliable Application

That's what I've learned while building AgentVerse.

And I'm still learning.

What's your experience with Agentic AI?

If you're building an agentic application, what has been the hardest part for you?

Orchestration? Tool calling? Security? Reliability? Evaluation?

I'd love to hear your experience.

🛠️ Built With

React TypeScript Node.js Express MongoDB Ollama MCP Multi-Agent AI Tailwind CSS Recharts

AI #AgenticAI #MCP #LLM #MongoDB #React #NodeJS #TypeScript #WebDevelopment

DEV Community: Praveen Raj Thulasi S

🌱 GrassRoute: I Built an AI That Wants You to Stop Using It

What I Built

Demo

How I Built It

Why Does Open Innovation Matter?

🛡️ DecisionShield: An AI That Audits Your Decision Before You Make It

🔗 Project Links

🤔 The Problem

💡 The Idea

🔄 How DecisionShield Works

🧠 Why Not Just Build Another AI Chatbot?

🧩 Core Features

1. Decision Workspace

2. AI Evidence Analysis

Facts

Assumptions

Unknowns

Claims

3. Decision Readiness Score

4. Missing Evidence Detection

5. Risk Analysis

6. Decision Stress Testing

Scenario 1

Scenario 2

Scenario 3

Scenario 4

Scenario 5

📉 Decision Stability

🧠 Why Gemma 4?

Separation of responsibilities

⚙️ Technical Architecture

🛠️ Tech Stack

Frontend

Backend

AI

Architecture

💻 Running Locally

Prerequisites

Clone the Repository

Backend

Windows

Linux/macOS

🎨 Frontend

🧪 Demo Scenario

🔬 Example Analysis

Input

DecisionShield might identify:

Facts

Assumptions

Unknowns

Risks

Missing Evidence

Result

🏗️ Project Structure

🔐 Reliability by Design

🧪 Demo Mode

🌍 Why This Could Matter

🚀 Future Roadmap

📄 Evidence Ingestion

🔗 Evidence Provenance

🧠 Advanced Decision Graphs

👥 Collaborative Decision Rooms

📚 Decision History

🌐 External Knowledge

🧪 Advanced Simulations

🏢 Domain-Specific Audits

⚠️ Limitations

🌱 Open Source

Contributions

👥 Team

Team Name

Members

Responsibilities

🏆 Hackathon

🎥 Demo

🔗 Links

GitHub

Demo Video

Presentation