DEV Community: Tanya Garg

🌿TraceBack: Step Outside, Capture Something, Trace It Back

Tanya Garg — Sat, 10 Oct 2026 05:51:00 +0000

🌿 TraceBack: Step Outside, Capture Something, Trace It Back

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

What I Built

What if discovering something interesting outside didn't end with taking a photo and forgetting about it?

I built TraceBack — Field Evidence Explorer, an open-source AI-powered project designed to turn real-world observations into evidence-backed discoveries.

Whether you're exploring a nature trail, spotting an unfamiliar bird, discovering a plant, or noticing an interesting landmark, TraceBack helps you investigate what you found and understand the evidence behind it.

Here's how it works:

🌿 Capture: Take a photo or record an observation while exploring the real world.

🧠 Analyze: An open-weight AI model analyzes the observation and suggests a possible identification or explanation.

🔎 Trace: SerpApi searches the web for relevant sources and information related to the observation.

📚 Explore the evidence: TraceBack organizes the results into an evidence trail, making it easier to understand supporting information, source disagreements, and what still needs verification.

🗂️ Save the discovery: Keep observations and their evidence in a personal field journal.

The idea is simple: use AI to make the real world more interesting, not to keep people glued to their screens.

Instead of endlessly scrolling through content, users can step outside, observe something meaningful, capture it, and return to their exploration while TraceBack helps them investigate their discovery.

Demo

🌐 Live Demo: https://traceback-field-evidence.onrender.com

🎥 Demo Video: https://drive.google.com/file/d/1CPMQ-E-DqqNOLaA-SBmad4srLdbtq8Lw/view?usp=drive_link

The demo walks through the journey from capturing a real-world observation to analyzing it with AI and discovering relevant evidence online.

Code

💻 GitHub Repository: TraceBack — Field Evidence Explorer

The project is designed around a modular architecture, separating AI analysis, web search, evidence processing, and field-journal functionality.

How I Built It

I designed TraceBack around two complementary technologies: open-weight AI for observation analysis and SerpApi for online evidence discovery.

🧠 Open-Weight AI

The project is designed to integrate with an open-weight model such as Gemma through Ollama.

The AI analysis layer helps interpret observations, extract useful characteristics, and generate search queries for further investigation.

Keeping the model integration modular makes it possible to experiment with different models rather than locking the entire project to a single proprietary AI provider.

🔎 SerpApi

SerpApi powers the online research component.

It helps retrieve relevant web results for AI-generated queries, allowing TraceBack to collect source links and organize discoverable information around an observation.

Rather than presenting an AI-generated answer as unquestionable truth, the goal is to connect the answer to accessible evidence and make uncertainty visible.

🌱 Local-First Exploration

The architecture also supports saving field observations locally and keeping them available when connectivity is limited. Online evidence searches require an internet connection.

The long-term goal is to make field capture as lightweight as possible, so users can spend more time exploring and less time interacting with the interface.

Tech Stack: React, TypeScript, Tailwind CSS, Express.js, Vite, Featherless API, Ollama (Gemma 3 open-weight AI model), and SerpApi.

Why Does Open Innovation Matter?

For TraceBack, open innovation is not just about using different tools. It's about giving developers more control over how AI-powered exploration works.

Open-weight models make it possible to experiment with local inference, evaluate alternative models, and adapt the analysis pipeline without depending entirely on a closed AI API.

A modular AI architecture also makes the system easier to extend and improve. Different models can be evaluated for different observations, and the project can evolve alongside the open-source ecosystem.

Privacy matters, too. A local-first approach can help keep observations on the user's device during initial processing, while web evidence discovery remains an explicit online step.

SerpApi complements this approach by connecting field observations with information available across the web.

My goal is to combine the flexibility of open AI with searchable evidence, creating a tool that encourages curiosity, supports investigation, and helps people reconnect with the world around them.

Prize Categories

Best Use of SerpApi: For the project's web evidence discovery and source retrieval.

The project should only be entered into partner categories whose technologies are actually integrated and demonstrated in the submitted version.

TraceBack is built around one simple belief: the best discoveries begin when we look up from our screens. 🌿

JUDGELAYER: Building a Hackathon Judging Platform You Can Actually Trust

Tanya Garg — Thu, 08 Oct 2026 17:29:51 +0000

JUDGELAYER: Building a Hackathon Judging Platform Where Trust Is Part of the Product

Hackathons are exciting.

Hundreds of people build projects, teams submit their ideas, judges review them, and eventually someone wins.

But there is a part of hackathons that doesn't get talked about enough:

Can we actually trust the judging process?

Who can see a submission?

Can one judge see another judge's score?

Can a participant access private judging data?

What happens when the event is over and organizers need to understand how a result was produced?

These questions became the starting point for our DOGFOOD 2026 project:

JUDGELAYER

Run the event. Protect the judging. Trust the results.

Instead of building another generic hackathon management dashboard, we wanted to build something around the trust layer behind judging.

💡 The Idea

Our goal was simple:

Create a self-hosted platform that manages the complete hackathon submission and judging workflow while keeping access controlled and auditable.

The workflow looks like this:

SUBMIT
  ↓
ASSIGN
  ↓
REVIEW
  ↓
PROTECT
  ↓
AUDIT
  ↓
EXPORT

There are four main types of users:

Visitor — explores public projects
Participant — submits and manages a project
Judge — reviews assigned projects
Organizer — manages the event, judging and results

The interesting part isn't just that each role has a different dashboard.

The important part is that the backend actually enforces what each role is allowed to access.

🎯 Why We Didn't Want a Normal Dashboard

While planning the project, it was tempting to build the usual hackathon platform:

Projects → Judges → Scores → Leaderboard

But that didn't feel enough.

A beautiful interface can hide a serious security problem.

For example, hiding a "View Score" button doesn't mean the score is protected.

If a participant can directly call an endpoint and retrieve judge data, the application isn't secure.

So we made role isolation one of the core architectural principles of JUDGELAYER.

The UI communicates the permissions.

The backend enforces them.

🧩 The Trust Layer

This became the main idea behind our product.

Inside the platform, we wanted users to understand the current security state without making the interface feel complicated.

For example, a judge can see:

TRUST LAYER

✓ Assigned projects only
✓ Peer scores hidden
✓ Participant judging data protected
✓ Review actions audited

This is not just decorative UI.

The actual authorization logic lives on the backend.

That distinction was important to us.

👀 The Public Experience

We started with the simplest role: a visitor.

No login should be required just to explore an event.

The public gallery lets visitors discover projects and open their public submission information.

A project can contain things like:

Project name
Description
Team
Repository
Demo
Presentation

The idea is to keep the public experience open while keeping private judging information behind the appropriate access controls.

📝 Participant Workflow

Next comes the participant.

A participant gets their own submission workspace where they can manage their project.

We also added a Submission Health Check concept.

Before submitting, the platform can show whether important fields are ready:

SUBMISSION HEALTH

✓ Project name
✓ Description
✓ Repository
✓ Demo
✓ Presentation

READY TO SUBMIT

This sounds like a small feature, but it improves the actual submission experience.

Instead of discovering a missing field after submitting, the participant gets feedback before the submission enters the judging pipeline.

⚖️ The Judge Experience

This is where JUDGELAYER really starts to become different.

When a judge logs in, they don't get access to every project's private judging information.

They get a controlled queue of their assigned projects.

A judge can:

Open an assigned project
Review the project evidence
Evaluate judging criteria
Add supporting notes
Submit the review

The interface also makes the judge's scope clear.

YOUR JUDGING SCOPE

Assigned projects only
Peer scores hidden
Private judging data protected
Actions audited

The goal was to make judging feel like a focused review workspace rather than another admin panel.

🔐 The Security Test

One of the most important things we wanted to demonstrate wasn't a UI animation.

It was an actual access-control test.

Imagine Judge A is reviewing Project 42.

Judge B has also reviewed Project 42.

Judge A should not be able to retrieve Judge B's private score.

So we test it.

Judge A
   ↓
Request Judge B's score
   ↓
ACCESS DENIED

The important part is that this isn't simply:

"We removed the button."

The backend rejects unauthorized access.

The same principle applies to participants attempting to access private judging information.

This is what we mean when we say:

Role isolation is enforced by the backend, not just represented by the UI.

🧑‍💼 Organizer Command Center

Organizers need a completely different view.

They need to understand what is happening across the event.

The organizer dashboard brings together:

Submission tracking
Judge management
Project assignments
Review progress
Results
Audit information
CSV exports

One feature we particularly liked was the Judge Coverage view.

For example:

PROJECT #042

Judge 01     ✓ Reviewed
Judge 04     ✓ Reviewed
Judge 07     ◐ Pending

Coverage: 2 / 3

This gives organizers an immediate understanding of which projects still need attention.

🕵️ Auditability

Security isn't only about blocking something.

It is also about being able to explain what happened.

That's why JUDGELAYER includes an audit trail.

Instead of showing a completely raw log, we wanted the events to be understandable:

18:42:09
JUDGE-07
Opened Project #042

18:44:31
JUDGE-07
Submitted Review

18:44:32
SYSTEM
Score recorded

18:44:33
ACCESS CONTROL
Unauthorized score access blocked

This creates a timeline of the judging process.

After the event, organizers don't just see the final result.

They can understand the important actions that happened along the way.

🏗️ How We Built It

We kept the architecture intentionally simple and self-hostable.

Frontend

React
TypeScript
Vite
Tailwind CSS
shadcn/ui

Backend

FastAPI
Python
SQLAlchemy
Pydantic

Database

SQLite

Deployment

Docker
Docker Compose

The goal was to make the entire platform runnable locally without depending on external cloud services.

That also made the project easier to test with seeded fixture data.

🔄 Architecture

At a high level, the system looks like:

                ┌─────────────────┐
                │     FRONTEND    │
                │    React + TS   │
                └────────┬────────┘
                         │
                         ▼
                ┌─────────────────┐
                │      API        │
                │    FastAPI      │
                └────────┬────────┘
                         │
              ┌──────────┼──────────┐
              ▼          ▼          ▼
        AUTH / RBAC    JUDGING     AUDIT
              │          │          │
              └──────────┼──────────┘
                         ▼
                  ┌─────────────┐
                  │   SQLite    │
                  └─────────────┘

The key design principle is:

Authorization happens before sensitive data is returned.

🎨 Designing the Interface

We also didn't want JUDGELAYER to look like a generic hackathon admin panel.

So we created a visual concept around a Trust Command Center.

Instead of filling the screen with dozens of cards, the interface uses:

Strong typography
Thin borders
Compact system metadata
Status indicators
Clean data tables
Focused dashboards
A central Trust Layer concept

The UI should communicate:

Security. Control. Transparency.

Not just:

"Here are some statistics."

🧪 Testing the Important Flows

We focused our testing around the workflows that matter most.

For example:

  Public Gallery
      ✓

Fixture Project Visible
      ✓

Closed Event Rejects Submission
      ✓

Judge Reads Own Score
      ✓

Judge Cannot Read Peer Score
      ✓

Participant Cannot Read Judge Score
      ✓

Organizer Can Export CSV
      ✓

These aren't just visual features.

They represent actual acceptance scenarios for the platform.

🤖 AI Helped Us Build Faster — But the Product Had to Work

Like many modern development projects, we used AI-assisted development during the build.

But we didn't want the result to be:

"AI generated a dashboard."

The real test was whether the application could actually perform the workflows we designed.

So we treated AI as a development accelerator — helping with implementation, debugging, UI iteration and documentation — while the final product still had to be tested through the actual application.

That's why our demo focuses on real screens and real interactions, rather than only showing mockups.

🚧 What We Learned

The biggest lesson from building JUDGELAYER was that security is not a page you add at the end.

It affects the entire application.

The moment you introduce multiple roles, you have to think about:

What data can this user see?
What actions can they perform?
What happens if they directly call an API?
What should be recorded?
What should remain private?

Thinking about these questions early changed the way we designed both the backend and the interface.

🚀 What's Next?

JUDGELAYER could eventually grow beyond a DOGFOOD submission.

Some directions we'd like to explore include:

More advanced judge conflict management
Better review analytics
Custom judging criteria
Multi-stage judging
Review calibration
More detailed audit exploration
Organization-level event management

But the foundation would remain the same:

Keep the judging process controlled, transparent and trustworthy.

🏁 Final Thoughts

Building JUDGELAYER made us look at hackathons from a slightly different perspective.

We usually focus on:

Who built the best project?

But before we can answer that question, we need to trust the process that produces the answer.

That's what JUDGELAYER is about.

Not just collecting submissions.

Not just assigning judges.

Not just calculating scores.

But creating a system where every role has the right access, every important action can be traced, and the final results can be trusted.

Submit.
Assign.
Review.
Protect.
Audit.
Export.

That's JUDGELAYER.

Run the event. Protect the judging. Trust the results.

🔗 Project

GitHub: https://github.com/Tanya-garg10/JUDGELAYER-Self-Hosted-Hackathon-Submission-Judging-Platform.git

Live Demo: https://judgelayer-self-hosted-hackathon.onrender.com/

Demo Video: https://drive.google.com/file/d/1ThHje2t4vV-GU83m-5o8wF9sB3_hbNaF/view

If you're building hackathon infrastructure or working on systems where access control and auditability matter, we'd love to hear what you think.

VaultLog: Building a Persistent Key-Value Store with Zero Dependencies

Tanya Garg — Wed, 02 Sep 2026 11:38:34 +0000

What if you had to build a useful storage engine without installing a single third-party package?

That was the challenge behind VaultLog, my submission for the Zero Dependency 72-Hour Hackathon by Hackathon Raptors.

The rule was simple:

Use only the standard library. No third-party runtime dependencies.

At first, this sounds like a restriction on what you can import.

In practice, it changes how you think about software.

Instead of asking "Which package should I use?", you start asking:

"What is actually happening underneath that package?"

That question became the foundation of VaultLog.

The Idea

VaultLog is a persistent embedded key-value store written entirely in Go 1.27.

It supports the fundamental operations you would expect from a small key-value database:

Set a value
Get a value
Delete a value
List stored keys
Inspect storage statistics

The important part is that VaultLog doesn't wrap an existing database engine.

There is no SQLite driver.

There is no BadgerDB.

There is no BoltDB.

There is no external storage library.

The storage layer itself is implemented in the project.

Why Build a Storage Engine?

For most applications, using an existing database is obviously the right decision.

If I were building a normal production application, I wouldn't recommend writing a database from scratch just because I could.

But the Zero Dependency Hackathon created a different engineering question:

How much of a practical storage system can be built using only the language's standard library?

That made a key-value store a particularly interesting problem.

A database package normally hides a lot of complexity:

How records are persisted
How data is indexed
How writes are represented
How deleted records are handled
How data is recovered after restart
How corrupted data is detected
How concurrent access is synchronized

VaultLog makes those layers explicit.

The Architecture

The core architecture is intentionally simple:

                 VaultLog
                    │
          ┌─────────┴─────────┐
          │                   │
   In-Memory Index       Append-Only Log
          │                   │
          │                   ▼
          │             Persistent File
          │
          ▼
     Fast Lookups

The system has two important components:

1. Append-Only Log

Every write is represented as a record and appended to the storage file.

Instead of modifying existing records in place, VaultLog keeps adding new records.

For example:

SET user:name Tanya
SET user:role Developer
DELETE user:role

The log becomes the historical sequence of operations.

This approach makes persistence straightforward and gives us a natural source from which the database can reconstruct its state.

2. In-Memory Index

Scanning the entire file every time someone asks for a value would be inefficient.

So VaultLog maintains an in-memory index.

Conceptually:

Key                Record Location
-----------------------------------
user:name          → offset 0x120
user:role          → deleted

The index allows VaultLog to locate the latest record associated with a key without scanning the entire log.

This provides average O(1) hash-map lookup for key access, while persistence remains on disk.

Writing Data

A Set operation follows a simple process:

  Set(key, value)
      │
      ▼
  Encode Record
      │
      ▼
Append Record to Log
      │
      ▼
Update In-Memory Index

The important design decision is that the persistent log is updated before the in-memory state becomes authoritative.

This gives the log a durable representation of the operation.

Deleting Data

Deletes are interesting in an append-only system.

We don't physically remove the old record from the file.

Instead, VaultLog writes a delete record.

SET username → Tanya
DELETE username

During recovery, the replay engine sees both operations and knows that the latest operation means the key no longer exists.

This is one of the trade-offs of append-only storage:

Deletes are cheap, but the log grows over time.

A future version could introduce log compaction to remove obsolete records.

Restart Recovery

Persistence isn't particularly useful if the database forgets its state after restarting.

VaultLog therefore reconstructs its in-memory index from the storage log.

The recovery process looks like this:


  Persistent Log
      │
      ▼
Read Records Sequentially
      │
      ▼
   Validate Record
      │
      ▼
  Replay Operation
      │
      ▼
  Rebuild Index

Suppose the log contains:

SET name Tanya
SET role Developer
DELETE role
SET city Meerut

After replaying these records, the reconstructed state becomes:

name → Tanya
city → Meerut

The deleted key doesn't return because its latest operation was a deletion.

This means the in-memory index doesn't need to be persisted separately.

The log is enough to rebuild it.

Data Integrity

Persistent storage introduces another problem:

How do we know that a record hasn't been corrupted?

VaultLog uses the Go standard library's:

hash/crc32

A checksum is stored alongside record data.

During recovery, the checksum can be calculated again and compared with the stored value.

Conceptually:

Record
  │
  ├── Header
  ├── Key
  ├── Value
  └── Checksum

If the calculated checksum doesn't match the stored checksum, the record cannot be trusted.

This gives the storage layer a basic integrity mechanism without importing an external package.

Concurrency

Another feature normally handled by database libraries is concurrent access.

VaultLog uses Go's standard synchronization primitives from:

sync

The storage engine protects shared state so that multiple operations don't modify the in-memory index unsafely.

Again, no external concurrency framework was necessary.

Go already provides the building blocks.

The Packages I Would Normally Use

This is where the challenge became interesting.

In a normal project, I might reach for external packages for several pieces of functionality.

Instead, VaultLog uses standard-library alternatives.

Normally Used	VaultLog Uses
Database package	Custom append-only storage engine
`testify`	`testing`
`logrus` / `zap`	`log` / `log/slog`
External binary encoding library	`encoding/binary`
External hashing utility	`hash/crc32`
External filesystem utilities	`os` / `io`
External path utilities	`path/filepath`
External CLI parser	`flag`

The biggest replacement wasn't a small utility.

It was the database layer itself.

Instead of importing a storage engine, VaultLog implements one.

The Hardest Part

The hardest part wasn't writing Put() or Get().

Those operations are relatively straightforward.

The difficult part was defining what should happen when things go wrong.

Questions appeared everywhere:

What happens after a restart?

The index has to be reconstructed from the log.

What happens if a record is invalid?

The recovery process needs to detect it instead of silently producing incorrect state.

What happens when a key is deleted?

The delete needs to become part of the persistent history.

What happens with concurrent access?

The in-memory index and file operations need appropriate synchronization.

What happens as the log gets larger?

Append-only storage naturally creates a need for compaction.

These are the kinds of problems that existing database libraries normally solve for you.

Building VaultLog made those hidden engineering decisions visible.

What I Learned

The biggest lesson from this hackathon wasn't simply that you can build software without dependencies.

It was understanding why those dependencies exist in the first place.

A package like a database library isn't magic.

Underneath the API are decisions about:

Storage layout
Indexing
Serialization
Durability
Recovery
Concurrency
Integrity

When you remove the package, those decisions become your responsibility.

That is what made the Zero Dependency constraint valuable.

What VaultLog Does Not Try to Be

VaultLog is deliberately small.

It is not intended to replace:

PostgreSQL
SQLite
Distributed databases
Production-scale storage systems

It currently has important limitations:

The index is held in memory.
The log grows until compaction is implemented.
It is designed for embedded/single-process use.
There is no distributed replication.
There is no SQL query engine.

These aren't hidden.

Understanding the limitations is part of understanding the design.

Why Zero Dependencies?

Zero dependencies doesn't mean third-party packages are bad.

Libraries save enormous amounts of engineering time and are essential for many real-world systems.

The value of this challenge is different.

It forces you to understand the layer underneath the abstraction.

For VaultLog, that meant going from:

"Use a database package."

to:

"How does a database actually store a record?"

And then building that layer ourselves.

Final Thoughts

VaultLog started with a constraint:

No third-party runtime dependencies.

It ended up becoming an exploration of how a small storage engine actually works.

The result is a persistent key-value store with:

Append-only storage
In-memory indexing
Restart recovery
Integrity validation
Concurrent access protection
CLI operations
Standard-library-only implementation

The most interesting part wasn't removing dependencies.

It was discovering what those dependencies were doing for us.

And that's probably the biggest takeaway from Zero Dependency:

Don't just use the abstraction. Understand the layer underneath it.

Built With

Go 1.27

Standard library only.

Third-party runtime dependencies: 0.

Project: VaultLog
Track: Data & Storage

ScholarAgent: Don’t Just Read Research. Reproduce It.

Tanya Garg — Sun, 30 Aug 2026 18:28:49 +0000

What if an AI agent could actually reproduce a research paper?

Research papers are full of impressive results.

94% accuracy.
95% F1 score.
30% improvement over previous methods.

But there is a problem: reading a result is easy. Reproducing it is not.

Reproducing research often means understanding dozens of pages, finding datasets, implementing algorithms, configuring dependencies, matching preprocessing steps, running experiments, debugging failures, and finally comparing your results with the original paper.

We built ScholarAgent to automate that journey.

Don’t just read research. Reproduce it.

🔬 What is ScholarAgent?

ScholarAgent is an autonomous AI research reproduction agent.

The idea is simple:

Give it a research paper, and let the agent attempt to reproduce its experiments.

Instead of acting like a traditional PDF chatbot that answers questions about a paper, ScholarAgent actually takes action.

Its workflow looks like this:

  Research Paper
      ↓
Methodology Extraction
      ↓
Research Subagents
      ↓
Experiment Planning
      ↓
Implementation Generation
      ↓
TrueForge Sandbox
      ↓
Experiment Execution
      ↓
Result Comparison
      ↓
Discrepancy Investigation
      ↓
  Human Approval
      ↓
Final Reproduction Report

🧠 Why we built it

One of the biggest challenges in machine learning research is reproducibility.

A paper may describe the model clearly but leave important details unclear:

Which preprocessing configuration was used?
What random seed was selected?
What exact training settings were used?
Which dependency versions were used?
How were edge cases handled?
Why does the reported metric differ from an independently implemented version?

These small differences can produce significantly different results.

We wanted to build something that doesn't simply say:

“Here is how you could reproduce this paper.”

We wanted an agent that says:

“I attempted the reproduction. Here is what happened.”

🤖 From Paper to Experiment

When a paper is uploaded, ScholarAgent first extracts the experimental methodology.

It identifies things such as:

Dataset
Model / Algorithm
Preprocessing
Hyperparameters
Training procedure
Evaluation metric
Reported results

The main agent can then delegate parts of the analysis to specialized subagents.

Methodology Analyst

Focuses on understanding the algorithm and experimental procedure.

Dataset Analyst

Identifies dataset requirements, preprocessing, splits, and availability.

Experiment Analyst

Extracts hyperparameters, evaluation metrics, baselines, and reported results.

These findings are combined into an executable reproduction plan.

🔥 Why TrueForge Matters

TrueForge is not just sitting underneath ScholarAgent as a backend.

It is where the agent actually acts.

The agent can use tools to work with project resources, generate experiment files, and execute the resulting research code inside a sandbox.

The workflow becomes:

Agent decides what to do
        ↓
     Tool call
        ↓
Generate / modify experiment
        ↓
   TrueForge sandbox
        ↓
    Execute code
        ↓
   Inspect output
        ↓
  Reason about result
        ↓
   Next action

This is fundamentally different from a normal chatbot.

A chatbot might tell you:

“Run python train.py.”

ScholarAgent can actually run the experiment in its controlled execution environment and inspect what happened.

🧪 When the Experiment Fails

This is where the agent becomes particularly useful.

Suppose the paper reports:

Reported Accuracy: 94.2%

ScholarAgent runs the reproduction and gets:

Our Accuracy: 92.8%

Instead of immediately declaring failure, the agent investigates.

It may identify:

⚠ Random seed not specified
⚠ Preprocessing details incomplete
⚠ Training configuration differs

The agent can then formulate hypotheses and propose additional experiments.

For example:

“I found two plausible causes for the accuracy gap. Running both configurations will require additional compute. Would you like me to continue?”

And this is where human approval becomes important.

⛔ Human in the Loop

Autonomous does not mean uncontrolled.

ScholarAgent is designed to stop before consequential or resource-intensive actions.

For example:

┌──────────────────────────────────────┐
│       APPROVAL REQUIRED              │
│                                      │
│ Two alternative configurations       │
│ could explain the result gap.        │
│                                      │
│ Estimated additional computation:    │
│ 2 experiment runs                    │
│                                      │
│ [ Reject ]             [ Approve ]   │
└──────────────────────────────────────┘

The researcher remains in control.

Once approved, the agent can continue the experiment.

This creates a useful balance:

Autonomous investigation + controlled execution + human oversight.

📊 Reproduction Report

At the end of the workflow, ScholarAgent generates a structured reproduction report.

For example:

Paper: Image Classification using XYZ

Reported Accuracy: 94.2%
Reproduced Accuracy: 92.8%

Difference: -1.4%

Reproduction Status: PARTIAL

Detected Differences:
• Dataset preprocessing differs
• Training epochs unavailable
• Random seed unspecified

Additional Experiments:
• Configuration A → 93.7%
• Configuration B → 94.0%

Conclusion:
The published result is approximately reproducible,
but the exact experimental configuration could not
be completely reconstructed from the paper.

The goal is not to artificially produce a high score.

The goal is to provide an honest, evidence-backed assessment.

🏗️ Architecture

The project uses a modern agent-based architecture:

                 ┌───────────────────┐
                 │    React + Vite   │
                 │   ScholarAgent UI │
                 └─────────┬─────────┘
                           │
                           ▼
                 ┌───────────────────┐
                 │      FastAPI      │
                 │   Agent Backend   │
                 └─────────┬─────────┘
                           │
                           ▼
                 ┌───────────────────┐
                 │     TrueForge     │
                 │    Agent Runtime  │
                 └─────────┬─────────┘
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
       Methodology     Dataset       Experiment
        Analyst        Analyst         Analyst
             │             │             │
             └─────────────┼─────────────┘
                           ▼
                    ┌─────────────┐
                    │ MCP Tools   │
                    └──────┬──────┘
                           ▼
                    ┌─────────────┐
                    │  Sandbox    │
                    │ Experiments │
                    └──────┬──────┘
                           ▼
                    ┌─────────────┐
                    │   Result    │
                    │  Analyzer   │
                    └──────┬──────┘
                           ▼
                    Reproduction
                       Report

🛠️ Technology Stack

Frontend

React
Vite
Tailwind CSS
TypeScript

Backend

Python
FastAPI

Agent Infrastructure

TrueForge
Specialized research subagents
MCP tools

Experiment Layer

TrueForge sandbox
Python research environments
Experiment logging
Result comparison

Development & Code Quality

GitHub
Pull-request workflow
Qodo Code Review

🔍 Qodo and Engineering Quality

Building an autonomous agent means reliability matters.

Generated code, sandbox execution, error handling, and tool orchestration can introduce subtle bugs.

We therefore incorporated Qodo into our development workflow through GitHub pull requests.

The workflow was:

Feature Branch
      ↓
Pull Request
      ↓
Qodo Review
      ↓
Fix Valid Findings
      ↓
Follow-up Review
      ↓
Human Merge

Qodo helped us identify issues and improve areas such as error handling, maintainability, and reliability.

This was especially important because ScholarAgent isn't just displaying AI-generated text—it is generating and executing real experiment workflows.

💡 What We Learned

The biggest lesson from building ScholarAgent was that building an agent is very different from building a chatbot.

A chatbot mostly needs to produce a useful response.

An agent needs to:

Decide what action to take.
Use the correct tool.
Observe the result.
Reason about what happened.
Recover from failures.
Decide what to do next.
Know when it should stop.
Ask a human when approval is required.

That feedback loop is where the real engineering challenge lies.

We also learned that sandboxing is not an optional feature when an agent can generate and execute code.

🚀 What's Next?

ScholarAgent is currently focused on making research reproduction easier and more transparent.

Future versions could support:

More research domains
Larger experiment libraries
Automated dataset discovery
More sophisticated statistical comparison
Reproduction across different hardware environments
Experiment lineage and provenance tracking
Reproduction benchmarks across multiple papers
Collaborative researcher workflows

Eventually, we imagine ScholarAgent becoming a kind of automated research lab assistant.

Not one that blindly trusts a paper.

Not one that blindly trusts its own output.

But one that tests, measures, investigates, and reports evidence.

🎯 Final Thought

Research becomes more valuable when its results can be independently verified.

AI can help us read papers faster.

But we believe the next step is much more interesting:

AI that can actually attempt the experiment.

That's why we built ScholarAgent.

Don't just read research. Reproduce it.

🎙️ Building BillBhasha AI: A Voice-First Assistant for Bills, GST & Everyday Commerce

Tanya Garg — Sat, 15 Aug 2026 18:07:56 +0000

From a simple voice agent to a multilingual AI assistant with memory, tools, outbound calls, human escalation, analytics, and specialist handoffs.

Introduction

What if understanding a bill was as simple as asking a friend?

For many users, invoices, GST charges, convenience fees, payment details, and other commerce-related information can be confusing. Reading through a long bill and figuring out what each charge means isn't always easy.

That's the problem I wanted to address with BillBhasha AI — a voice-first AI assistant that helps users understand bills, GST, invoices, fees, and payment-related information through natural conversations.

I built BillBhasha AI as part of 10 Days of Voice Agents — VoiceForBharat Edition, using Murf Falcon for text-to-speech.

The interesting part wasn't just making an AI that could talk.

The real challenge was making it behave like a useful assistant.

Over ten days, I gradually added personality, safety, memory, tools, outbound calling, human escalation, analytics, and specialist-agent handoffs.

💡 What is BillBhasha AI?

BillBhasha AI is a multilingual voice assistant designed for commerce-related queries.

A user can simply speak to the agent and ask questions such as:

"Mere bill mein GST kitna laga hai?"

"Convenience fee kya hoti hai?"

"Can you explain this charge?"

"Mujhe ye bill Hindi mein samjha do."

Instead of forcing users to navigate complicated interfaces or read technical terminology, BillBhasha focuses on simple, conversational explanations.

It can also handle code-mixed conversations, such as Hindi + English, which is common in everyday communication.

🎯 Why Voice?

I chose a voice-first approach because not every user wants to type a detailed query or understand a complicated dashboard.

Voice makes the interaction more natural:

User speaks → AI understands → AI processes → AI responds

This becomes especially useful when the user wants a quick explanation rather than searching through documentation.

For BillBhasha, the goal was not just:

"Build a chatbot that speaks."

It was:

"Build a voice assistant that can actually help."

🏗️ How BillBhasha AI Works

At a high level, the system follows this flow:

    User
     ↓
Microphone / Phone Call
     ↓
Speech-to-Text
     ↓
LLM / Agent Logic
     ↓
 ┌───────────────┐
 │ Memory        │
 │ Tools         │
 │ Guardrails    │
 │ Escalation    │
 │ Specialist    │
 └───────────────┘
     ↓
Text-to-Speech
     ↓
  Murf Falcon
     ↓
   User

The agent uses real-time voice infrastructure to receive and process speech, while the LLM handles reasoning and conversation.

Murf Falcon generates the agent's voice response.

🚀 What I Built During the Challenge

The project evolved significantly throughout the challenge.

1. 🎙️ Voice Conversation

The first milestone was getting BillBhasha to actually talk.

The user could start a conversation, speak naturally, and receive a spoken response.

This became the foundation for everything that followed.

2. 🧠 Personality & Guardrails

An AI assistant needs to know not only what it can do, but also what it should not do.

I defined:

Its identity
Its main objectives
Its communication style
Language behaviour
Things it must refuse
Situations requiring human help

For example, BillBhasha should not invent a GST amount or confidently claim information that it doesn't have.

It should explain uncertainty instead of hallucinating an answer.

🌐 3. Multilingual & Code-Mixed Conversations

One important part of BillBhasha is language flexibility.

A user might say:

"Mere bill mein GST kitna hai?"

and then switch to:

"Can you explain the convenience fee?"

The agent should be able to understand this naturally and respond in an appropriate language/register.

I also configured the agent to respect the correct native script when generating multilingual text.

🎨 4. Personalised Voice-Agent Frontend

I didn't want the interface to look like a generic chatbot.

The frontend was redesigned around the voice experience and clearly communicates different agent states:

Ready → Connecting → Listening → Speaking → Call Ended

This makes it immediately clear to the user whether the agent is waiting, listening, or responding.

Microphone permission errors are also handled with clear feedback rather than leaving the user wondering why the call isn't starting.

🧠 5. Giving BillBhasha Memory

One of the biggest improvements was adding memory.

Initially:

Call ends → Everything is forgotten.

After adding persistent storage:

Call ends → User information can be stored → Next call can retrieve it.

For example, during one conversation a user may say:

"I prefer speaking in Hindi."

After receiving permission, that preference can be saved.

During the next conversation, BillBhasha can recognise the returning user and continue more naturally.

Importantly, the agent asks for permission before saving information.

This makes memory an intentional feature rather than silent data collection.

🔧 6. Adding Tools

An AI model shouldn't have to guess information that can be obtained through a function or external data source.

I added tool-based functionality so the agent can retrieve or calculate relevant commerce information when needed.

The important design principle was:

If reliable data is available through a tool, use the tool instead of inventing an answer.

I also added a failure path so that if a data source is unavailable, the agent can communicate the issue instead of silently failing or making up information.

📞 7. Outbound Voice Calls

Next, I moved beyond browser-based conversations.

BillBhasha was extended to support outbound calling.

This changes the interaction completely.

When an agent calls someone, the user didn't necessarily request the conversation.

So the opening needs to be transparent:

Who is calling?
Why are they calling?
What can the user do if they don't want to continue?

This taught me that outbound voice agents need a different conversational design from inbound agents.

👩‍💻 8. Human Escalation

Another important lesson was that an AI agent shouldn't try to solve everything.

For certain situations, BillBhasha can decide that a human should take over.

The flow is:

User Request
     ↓
AI Understands Problem
     ↓
Does AI Need Human Help?
     ↓
    Yes
     ↓
Ask User Permission
     ↓
Create Escalation Request
     ↓
Provide Reference ID

The agent doesn't simply say:

"I'll contact a human."

It creates a structured escalation request containing only useful information.

Privacy is also important here.

The system should never send sensitive information such as:

OTPs
PINs
Passwords
Account numbers

to the human escalation flow.

📊 9. Call Analytics Dashboard

Once an agent starts handling multiple conversations, another question appears:

How well is it actually performing?

So I added a call analytics dashboard.

The dashboard tracks key metrics such as:

Total Calls
Successful Calls
Failed Calls

The data is based on actual calls rather than hardcoded numbers.

I also redesigned the UI to make the dashboard more visually engaging and easier to understand.

This helped turn BillBhasha from simply a voice demo into something closer to a complete voice-agent product.

🤝 10. Specialist Agent Handoff

One of the final improvements was introducing a specialist agent.

The main agent doesn't need to be an expert at everything.

For example:

User
 ↓
BillBhasha AI
 ↓
Does this require specialist help?
 ↓
Yes
 ↓
Specialist Agent
 ↓
Continues the conversation

The main agent informs the user before transferring the conversation.

The specialist then receives the context and continues from there instead of asking the user to repeat everything.

This made the architecture more modular and showed me how multiple specialised agents can work together.

🧩 The Technology Behind It

The project combines several technologies and services to create the complete experience.

Core components

Frontend: HTML / CSS / JavaScript and voice-agent UI
Voice orchestration: LiveKit
LLM: Google Gemini
Speech-to-Text: Deepgram
Text-to-Speech: Murf Falcon
Database: SQLite / persistent storage
Telephony: Twilio / outbound calling setup
Tools: Function-based integrations
Analytics: Call data + dashboard
Specialist agents: Agent handoff architecture

The most important thing I learned is that a voice agent isn't a single model.

It's a system of multiple components working together in real time.

⚙️ Challenges I Faced

Building the project wasn't always straightforward.

1. Multilingual voice behaviour

One challenge was getting the agent to understand Hindi/code-mixed speech while maintaining the appropriate language and voice behaviour.

This required careful configuration of speech recognition, language handling, and prompting.

2. Memory shouldn't become automatic data collection

Adding memory sounds simple:

"Just save the user's information."

But that isn't enough.

The agent needs to ask:

"Would you like me to remember this?"

Only after confirmation should the information be saved.

This changed the way I thought about AI memory.

3. Voice responses need different prompting

A response that looks good on a screen doesn't always sound good when spoken.

Long explanations, complicated formatting, and overly technical sentences can feel unnatural in a voice conversation.

I learned to keep responses:

Short
Clear
Conversational
Easy to understand when heard rather than read

4. APIs can fail

Real-world voice agents depend on multiple external services.

A tool may fail.

An API may timeout.

A call may disconnect.

A microphone permission may be denied.

The agent therefore needs a failure path, not just a success path.

That was one of the biggest lessons from this challenge.

🔐 Privacy & Safety

Because BillBhasha deals with commerce and payment-related conversations, privacy cannot be an afterthought.

The agent is designed not to request or expose sensitive information such as:

OTP, PIN, passwords, or account numbers.

Memory also requires user consent.

Similarly, human escalation requires permission before sharing information with another person.

The goal is to make the assistant useful without making it careless.

📂 Project Repository

The complete project is available on GitHub:

BillBhasha AI

https://github.com/Tanya-garg10/BillBhasha-AI

The repository contains the implementation and setup required to explore the project.

Important: API keys and other secrets should always be stored in environment variables and should never be committed to GitHub.

🛠️ How to Start Building Your Own Voice Agent

If you're starting your own voice-agent project, think about it as these building blocks:

Step 1 — Speech-to-Text

Convert the user's voice into text.

Step 2 — LLM

Send the text to your language model and decide what the agent should do.

Step 3 — Tools & Memory

Give the agent access to reliable data and persistent information when necessary.

Step 4 — Text-to-Speech

Convert the response back into natural speech.

Step 5 — Real-Time Transport

Connect everything through a real-time voice layer.

Step 6 — Guardrails

Define what the agent can and cannot do.

Step 7 — Test Failure Cases

Don't test only:

"Hello, how are you?"

Also test:

API failures
Silence
Wrong requests
Language switching
Permission denial
Human escalation
Call disconnects

That's where the real engineering begins.

🌱 What I Would Build Next

BillBhasha is still a work in progress.

Some improvements I'd like to explore next are:

Better bill/invoice document understanding
OCR-based bill analysis
More Indian language support
Better GST explanation workflows
More advanced analytics
Improved specialist-agent routing
Stronger privacy controls
Real-world user testing
Better accessibility for first-time technology users

The long-term goal would be to make BillBhasha useful beyond a hackathon or challenge demo.

🎓 What I Learned

The biggest takeaway from these 10 days is simple:

Building a voice agent is much more than connecting an LLM to a microphone.

A useful voice agent needs:

Voice + Intelligence + Memory + Tools + Safety + Human Support + Observability

The challenge pushed me to think about the complete user experience rather than just the AI model.

I learned how small things — such as a clear greeting, a permission request, a fallback message, or a handoff explanation — can make a huge difference in how trustworthy an AI system feels.

🚀 Final Thoughts

BillBhasha AI started as a simple idea:

"What if users could simply ask an AI to explain their bills?"

Over the course of 10 Days of Voice Agents — VoiceForBharat Edition, that idea evolved into a much more complete voice-agent system.

It can now:

✅ Hold natural voice conversations
✅ Handle code-mixed language
✅ Follow safety guardrails
✅ Remember users with permission
✅ Use tools for useful information
✅ Make outbound calls
✅ Escalate problems to humans
✅ Track call outcomes
✅ Provide analytics
✅ Hand conversations to specialist agents

And throughout the journey, Murf Falcon powered the voice experience.

This challenge wasn't just about building an AI that can speak.

It was about learning how to build an AI system that can listen, understand, remember, act, and know when it shouldn't act alone.

10 Days. One voice agent. A lot of learning. 🎙️🚀

Project: BillBhasha AI
Track: Local Commerce
Challenge: 10 Days of Voice Agents — VoiceForBharat Edition
TTS: Murf Falcon

From Python to Rust: Rewriting a Real Open Source Project for Port Mortem 2026

Tanya Garg — Fri, 07 Aug 2026 11:31:14 +0000

Modern AI can translate code between programming languages in seconds.

But one question still remains:

Does the translated program actually behave like the original?

That question is exactly what Code Resurrection 2026 – Port Mortem challenged participants to answer.

Instead of building a new application, the challenge was to take an existing open-source project and rewrite it in another language while preserving its behavior.

I participated in Track D (Python → Rust).

Why I Chose Rust

Rust has become one of the most exciting systems programming languages because it offers:

Memory safety without a garbage collector
Excellent performance
Strong compile-time guarantees
Modern tooling through Cargo
Reliable error handling

Rather than creating a simple syntax translation, I wanted to understand how Python concepts map to idiomatic Rust.

The Goal

The objective wasn't simply to make the project compile.

The real objective was to preserve the original behavior while redesigning the implementation using Rust best practices.

That meant focusing on:

Functional equivalence
Clean project architecture
Better memory safety
Idiomatic Rust patterns
Maintainability

Repository Structure

The project follows the structure recommended by the hackathon.

README.md
DECISIONS.md
Dockerfile
Cargo.toml
src/
tests/
fuzz/
bench/
.port-mortem.toml

This organization makes the project easier to evaluate, build, and extend.

Migration Decisions

Several design choices changed during the migration.

Instead of Python's exception-based workflow, I adopted Rust's Result<T, E> error handling.

Dynamic Python collections were replaced with Rust's strongly typed collections.

The application was reorganized into Cargo modules to improve maintainability.

Every important design decision was documented in DECISIONS.md.

Biggest Challenge

The hardest part wasn't writing Rust.

It was making sure the Rust implementation behaved exactly like the original Python project.

Language features differ significantly.

Error handling, ownership, borrowing, collections, and type safety required a completely different mindset.

Writing equivalent logic often meant redesigning the implementation instead of translating it line by line.

What I Learned

This project taught me that software migration is much more than language translation.

A good migration should:

Preserve behavior
Improve maintainability
Follow target-language best practices
Be easy to build and test
Document architectural decisions

Rust encouraged writing code that is explicit, predictable, and easier to reason about.

Final Thoughts

Port Mortem was one of the most unique hackathons I've participated in.

Instead of rewarding quick prototypes, it encouraged participants to think like software engineers—focusing on correctness, maintainability, and engineering discipline.

Whether or not this project wins, it gave me a much deeper appreciation for systems programming, open-source software, and Rust's design philosophy.

Huge thanks to Hackathon Raptors for organizing such an interesting event.

If you're interested in systems programming or language migration, I'd definitely recommend trying a project like this yourself.

GitHub Repository: https://github.com/Tanya-garg10/croniter-.git

Building SentinelAI: How I Used SigNoz & OpenTelemetry to Make AI Agents Observable

Tanya Garg — Sun, 26 Jul 2026 18:13:50 +0000

Building SentinelAI: How I Used SigNoz & OpenTelemetry to Make AI Agents Observable

From black-box AI workflows to real-time traces, logs, metrics, security monitoring, and AI-powered root cause analysis.

Hook

AI agents are becoming increasingly capable—they can reason, call tools, retrieve knowledge, and automate complex workflows. But when an agent fails in production, the biggest challenge isn't fixing the bug—it's understanding why it happened.

During the Agents of SigNoz Hackathon by WeMakeDevs, I wanted to solve exactly this problem. Instead of building another AI chatbot, I built SentinelAI, an observability platform that gives developers complete visibility into AI agents using SigNoz and OpenTelemetry.

The Problem

While experimenting with AI applications, I realized that traditional logging wasn't enough.

Some common questions remained unanswered:

Which tool call caused the failure?
Why did latency suddenly increase?
Which prompt consumed the most tokens?
Why did the agent hallucinate?
Which API became the bottleneck?

Without proper observability, AI systems become difficult to debug as they grow in complexity.

Why SigNoz?

I wanted an observability platform that could collect multiple signals in one place.

SigNoz stood out because it supports:

OpenTelemetry-native instrumentation
Distributed tracing
Metrics
Logs
Dashboards
Alerts

Instead of jumping between different monitoring tools, I could inspect an entire AI workflow from a single interface.

Project Architecture

Include architecture diagram here.

Explain:

       User
        ↓
  Frontend (React)
        ↓
   FastAPI Backend
        ↓
  OpenTelemetry SDK
        ↓
    SigNoz Cloud
        ↓
     Traces
    Metrics
      Logs
     Alerts
        ↓
SentinelAI Dashboard

Building SentinelAI

Instead of only monitoring servers, I wanted to monitor AI reasoning itself.

The application contains multiple modules.

Dashboard

The dashboard provides a quick overview of the system.

It displays:

Agent Health Score
Active Requests
Average Latency
Token Usage
Estimated Cost
Error Rate
Live Alerts

The health score combines multiple signals into a single indicator, making it easier to identify unhealthy AI agents.

Live Agent Monitoring

Every AI request is tracked individually.

For each request I record:

Prompt
Response
Execution time
Token usage
Model used
Tool calls
Status

Instead of manually searching logs, developers can inspect an individual execution from start to finish.

OpenTelemetry Integration

One of the most interesting parts of this project was instrumenting AI requests.

Every request generates telemetry that can later be visualized inside SigNoz.

This made it possible to understand where time was being spent:

Prompt processing
Retrieval
LLM generation
External API calls
Database operations

Using SigNoz

SigNoz became the observability backbone of SentinelAI.

I used it for:

Distributed Traces

To visualize every stage of an AI request.

Metrics

To monitor:

Request latency
Error rate
Token consumption

Logs

To inspect failures and debug issues.

Dashboards

To create an overview of system performance.

Alerts

To identify abnormal latency and failures quickly.

Security Monitoring

One feature I particularly enjoyed building was the Security Monitor.

It detects:

Prompt Injection attempts
Jailbreak prompts
Suspicious tool calls
High-risk requests

Each request receives a Security Risk Score, helping developers prioritize investigation.

AI Root Cause Analysis

Raw logs can still be difficult to understand.

So I added an AI-powered analysis engine.

Whenever an anomaly occurs, SentinelAI automatically generates:

Incident summary
Root cause
Severity
Suggested resolution
Recommended next steps

This significantly reduces debugging time.

Analytics & Audit Export

To make the platform useful beyond debugging, I also implemented:

Latency analytics
Token usage trends
Cost estimation
JSON export
CSV export

These exports make it easier to share telemetry with engineering teams and support compliance workflows.

Challenges I Faced

The biggest challenge wasn't building the UI.

The real challenge was understanding how observability works.

Initially, I assumed logs alone would be enough.

While integrating SigNoz, I realized that combining traces, metrics, and logs provides much richer context than relying on any single signal.

Another challenge was organizing AI telemetry in a way that remained easy to understand for developers.

What I Learned

This hackathon completely changed how I think about production AI.

Some key takeaways:

Observability is as important as the AI model itself.
Distributed tracing makes debugging much easier.
Metrics help identify trends before users notice problems.
AI applications require security monitoring in addition to performance monitoring.
OpenTelemetry provides a flexible standard that works across different services.

Future Improvements

If I continue working on SentinelAI, I would like to add:

Multi-agent workflow visualization
Kubernetes monitoring
Real-time anomaly detection
Predictive incident alerts
Slack & Microsoft Teams notifications
Multi-tenant dashboards

Conclusion

Building SentinelAI taught me that successful AI applications need more than accurate responses—they need visibility, reliability, and security.

By combining OpenTelemetry with SigNoz, I was able to build a platform that helps developers understand every stage of an AI agent's execution instead of treating it as a black box.

This hackathon was a great opportunity to explore modern observability practices while building something practical for real-world AI systems.

Beyond Logs: Building Reliable AI Agents with SigNoz LLM Observability

Tanya Garg — Fri, 17 Jul 2026 15:56:38 +0000

How exploring SigNoz changed the way I think about monitoring AI applications.

Introduction

While preparing for the Agents of SigNoz Hackathon, I wanted to do more than just register and wait for the event to begin. Since the organizers encouraged participants to explore SigNoz before the hackathon, I decided to spend some time understanding what the platform actually offers and why observability has become such an important topic for modern AI applications.

Before this, my understanding of monitoring was fairly basic. I associated it with checking CPU usage, memory consumption, application logs, or server uptime. Those metrics are useful, but as I started learning more about AI systems, I realized they don't explain what is happening inside an AI workflow.

Think about an AI assistant that uses a Large Language Model (LLM). A single user request doesn't just go to the model and return a response. It may pass through authentication, a vector database, prompt construction, multiple API calls, external tools, memory retrieval, and finally the LLM before generating an answer. If something goes wrong in between, traditional monitoring often isn't enough to identify the exact cause.

This is where I discovered the concept of AI Observability, and that's what led me to SigNoz.

As I explored the platform, one thing immediately stood out—it isn't just another monitoring dashboard. SigNoz brings together logs, metrics, traces, dashboards, alerts, and AI observability into a single platform built on OpenTelemetry, making it much easier to understand what is happening inside an application.

In this blog, I'll share what I learned while exploring SigNoz, the features that impressed me the most, and why I believe observability is becoming an essential part of building reliable AI applications.

Why Traditional Monitoring Isn't Enough Anymore

Most developers, including me, usually begin debugging by checking logs or looking at CPU and memory graphs. That approach works reasonably well for traditional applications, but AI systems introduce an entirely different level of complexity.

Imagine asking an AI assistant:

"Summarize yesterday's meeting and create a follow-up email."

Behind the scenes, several operations happen almost instantly:

The request is authenticated.
Previous conversation history is retrieved.
Relevant documents are fetched from a vector database.
A prompt is generated.
The LLM processes the request.
External tools may be called.
The final response is formatted and returned.

If the response suddenly takes 12 seconds instead of 2, simply checking application logs doesn't immediately reveal the problem.

During my exploration of SigNoz, this became much clearer. Instead of showing only the final response time, observability helps break an entire request into smaller steps, making it easier to understand where time is being spent and which component is responsible for delays.

That shift in perspective was probably the biggest takeaway for me.

Understanding AI Observability

Before exploring SigNoz, I had heard the term observability many times but never really understood how different it was from monitoring.

The easiest way I can explain it now is this:

Monitoring tells you that something is wrong. Observability helps you understand why it went wrong.

For AI applications, that difference is extremely important.

Instead of tracking only infrastructure metrics, AI observability allows developers to understand what's happening throughout the complete lifecycle of an AI request.

Some examples include:

Model response latency
Prompt execution time
Token usage
Tool calls
API failures
Retrieval performance
Distributed traces
Error propagation

Seeing these capabilities helped me understand why observability has become such an important topic as AI applications continue to grow in complexity.

My First Impression of SigNoz

The feature that impressed me the most while exploring SigNoz was its ability to bring different types of telemetry into one place.

Rather than jumping between separate tools for logs, metrics, and traces, everything is available through a single interface.

For someone trying to understand how an application behaves internally, this makes debugging feel much more organized and intuitive.

Another thing I appreciated was that SigNoz is OpenTelemetry-native. Since OpenTelemetry has become the standard for collecting telemetry data, building on open standards instead of proprietary solutions makes the platform much more flexible for developers and organizations.

At this point, I started understanding that observability isn't just about fixing bugs—it's about building software with enough visibility that problems can be identified and solved before they affect users.

In the next section, I'll walk through the SigNoz platform, explain its core features, and share why Distributed Tracing became my favorite feature while exploring the platform.

Exploring SigNoz: Features That Stood Out

After understanding why observability matters, I wanted to see what SigNoz actually offers beyond the buzzwords.

As I explored the platform and its documentation, I realized that SigNoz isn't focused on just one aspect of monitoring. Instead, it combines everything needed to understand an application's health in a single place.

Some of the features that immediately caught my attention were:

Application Performance Monitoring (APM) for tracking application performance.
Distributed Tracing to follow requests across multiple services.
Centralized Log Management for debugging issues quickly.
Custom Dashboards for visualizing important metrics.
Real-time Alerts to detect problems before users report them.
LLM & AI Observability for monitoring AI-powered applications.

What impressed me the most was that these features are available within one platform rather than requiring multiple tools working together.

Understanding OpenTelemetry

While exploring SigNoz, I also learned why it emphasizes being OpenTelemetry-native.

Initially, I thought OpenTelemetry was simply another monitoring library. After reading more about it, I realized it has become the industry standard for collecting telemetry data.

Instead of using vendor-specific agents, developers instrument their applications once with OpenTelemetry and can send the collected data to compatible platforms like SigNoz.

This approach offers several benefits:

No vendor lock-in
Standardized telemetry collection
Support for multiple programming languages
Easier migration between observability platforms

For AI applications, this becomes even more valuable because a single request often travels through multiple services before generating a response.

OpenTelemetry captures each of these interactions, while SigNoz visualizes them in an easy-to-understand format.

Setting Up SigNoz

One thing I liked was that getting started with SigNoz is relatively straightforward.

The recommended approach is to run it locally using Docker.

The installation involves cloning the repository and starting the required services.

git clone https://github.com/SigNoz/signoz.git

cd signoz/deploy

docker compose up -d

After the services start, the dashboard becomes accessible through the browser.

Although the setup itself isn't complicated, I would still recommend checking the official documentation because it provides clear instructions for different operating systems and deployment options.

Figure 1: SigNoz Dashboard after completing the local setup.

The Feature I Found Most Interesting: Distributed Tracing

Among all the capabilities, Distributed Tracing was the feature that interested me the most.

When we build AI applications, a single request rarely consists of just one API call.

Instead, it usually looks something like this:

User Request
      │
      ▼
Authentication
      │
      ▼
Retrieve Context
      │
      ▼
Vector Database
      │
      ▼
     LLM
      │
      ▼
External Tool
      │
      ▼
Final Response

Without tracing, developers only know the total response time.

With distributed tracing, every step appears as an individual span.

For example, imagine an AI assistant takes 10 seconds to answer.

Tracing could reveal something like this:

Component	Time
Authentication	40 ms
Vector Search	320 ms
LLM Processing	6.2 s
External API	2.8 s
Response Formatting	120 ms

Instead of guessing where the slowdown happened, developers immediately know which component needs attention.

This made me appreciate why distributed tracing is considered one of the most powerful debugging tools for modern applications.

AI Observability: More Than Traditional Monitoring

Traditional monitoring tells us whether servers are healthy.

AI observability answers a different question:

"How well is my AI application actually performing?"

While exploring SigNoz, I found it interesting that AI-specific metrics can also be monitored.

These include:

Prompt execution time
LLM response latency
Token usage
Error rates
Tool invocation
Request success rate

These metrics become especially useful when building AI agents because performance depends on much more than server resources.

A perfectly healthy server can still produce a slow AI application if prompt execution, vector retrieval, or external APIs become bottlenecks.

Having visibility into these components makes troubleshooting significantly easier.

A Key Takeaway

The biggest lesson I learned while exploring SigNoz is that observability is not just about collecting logs.

It is about understanding the complete story behind every request.

Logs tell you what happened.

Metrics tell you how often it happens.

Distributed traces show exactly where it happened.

When all three are available together, debugging becomes much faster and more reliable.

That, in my opinion, is what makes SigNoz particularly valuable for developers building modern AI-powered applications.

In the final section, I'll share how LLM observability helps monitor token usage and costs, discuss dashboards and alerts, compare SigNoz with other observability platforms, and conclude with my overall thoughts after exploring the platform.

LLM Observability: A Feature Every AI Developer Should Understand

As AI applications continue to evolve, one thing became very clear to me while exploring SigNoz—monitoring an AI application is very different from monitoring a traditional web application.

For a normal application, checking CPU usage, memory utilization, request count, or response time is often enough.

But AI applications introduce completely new variables.

Questions like these become much more important:

Why is one prompt taking twice as long as another?
Which model is consuming the most tokens?
Which tool call failed?
Why did today's AI cost suddenly increase?
Which step in the workflow is creating the biggest delay?

These are questions that traditional monitoring tools simply weren't designed to answer.

This is where LLM Observability becomes incredibly valuable.

Instead of treating an LLM call as just another API request, SigNoz provides visibility into AI-specific metrics that actually matter.

Some examples include:

Prompt execution time
Response generation latency
Token usage
Model response time
Request failures
Tool invocation
End-to-end request traces

These insights make it much easier to understand how an AI application behaves in production.

Why Token Monitoring Matters

One topic I hadn't thought much about before exploring AI observability was token usage.

Every interaction with a language model consumes tokens.

A longer prompt or response means higher inference cost.

As an application scales, even small increases in token usage can have a noticeable impact on monthly expenses.

Instead of waiting for billing reports, developers can monitor token trends in real time and identify inefficient prompts or unusually expensive requests.

For teams deploying AI products in production, this kind of visibility can be just as important as monitoring latency.

Dashboards That Make Monitoring Easier

Another feature I liked was the flexibility of dashboards.

Instead of displaying only infrastructure metrics, dashboards can combine application health, traces, AI metrics, and performance graphs in one place.

For an AI application, a useful dashboard might include:

Average response latency
Request throughput
Error rate
Token consumption
Slowest endpoints
LLM latency
Tool execution time

Having all of these metrics together makes it much easier to understand the overall health of an application.

Figure 2: Dashboard showing request latency, throughput, traces, and application metrics.

Real-Time Alerts

Monitoring dashboards are helpful, but someone has to be looking at them.

This is where alerts become useful.

With SigNoz, developers can configure alerts for situations such as:

High response latency
Increased error rate
Unexpected token spikes
Database failures
Slow external APIs
Service downtime

Rather than discovering problems through user complaints, teams can identify issues much earlier and respond before they become major incidents.

Comparing SigNoz with Other Platforms

While researching observability tools, I also came across platforms like Datadog, New Relic, and Grafana.

Each has its own strengths, but one aspect that stood out about SigNoz is its focus on open standards.

Feature	SigNoz	Typical Proprietary Platform
Open Source	✅	Usually No
OpenTelemetry Native	✅	Partial
Self-hosting	✅	Limited
Unified Logs, Metrics & Traces	✅	✅
AI Observability	✅	Depends on Plan

For developers who value transparency, flexibility, and avoiding vendor lock-in, this is a significant advantage.

My Overall Takeaway

Exploring SigNoz changed how I think about monitoring modern software.

Earlier, I viewed monitoring as something you check only after an application breaks.

Now I understand that observability is about continuously understanding how an application behaves and why something goes wrong.

The feature I found most useful was Distributed Tracing, because it makes debugging much more visual and intuitive.

I also found AI observability particularly interesting since AI applications introduce challenges—like token usage, prompt performance, and model latency—that traditional monitoring tools were never designed to solve.

Although I explored SigNoz as part of preparing for the Agents of SigNoz Hackathon, it gave me a much better understanding of why observability is becoming an essential part of building production-ready AI applications.

Conclusion

Artificial Intelligence is changing how we build software, but it also introduces new debugging and monitoring challenges.

After spending time exploring SigNoz, I now have a much clearer understanding of why observability is more than just logs and dashboards. Being able to view metrics, traces, logs, alerts, and AI telemetry together provides a much deeper understanding of application behavior.

If you're planning to build AI agents, chatbots, or any LLM-powered application, I believe learning observability early is just as important as learning the AI frameworks themselves.

For me, exploring SigNoz wasn't just preparation for a hackathon—it was an opportunity to better understand how production AI systems are monitored, optimized, and maintained.

I'm excited to apply these learnings while building projects during the Agents of SigNoz Hackathon, and I hope this article helps other developers who are beginning their own observability journey.

References

SigNoz Documentation
SigNoz GitHub Repository
OpenTelemetry Documentation
CNCF OpenTelemetry Project

Thanks for reading! If you're participating in the Agents of SigNoz Hackathon, I highly recommend exploring SigNoz yourself. Even a short hands-on session provides a much better understanding of observability than reading documentation alone, and it's a great way to prepare before building AI applications in the hackathon.

🚀 Building Two AI-Powered Solutions at HACKHAZARDS '26: VeritasFlow & PermitFlow

Tanya Garg — Wed, 15 Jul 2026 14:43:18 +0000

🚀 Building Two AI-Powered Solutions at HACKHAZARDS '26: VeritasFlow & PermitFlow

How our team built two AI-powered solutions—VeritasFlow and PermitFlow—during one of the world's largest community-driven hackathons.

Introduction

Innovation begins with identifying real-world problems and building technology that creates meaningful impact.

That belief guided our team throughout HACKHAZARDS '26, a global community-driven buildathon organized by NAMESPACE. Unlike traditional 24- or 48-hour hackathons, HACKHAZARDS gave participants nearly two months to research, design, develop, and refine production-ready solutions instead of rushed prototypes.

With over 30,000 participants from more than 75 countries, the event brought together developers, designers, and innovators to solve meaningful challenges using modern technologies.

As a team, we challenged ourselves to build solutions for two completely different problem domains.

One focused on improving digital wellbeing and responsible information consumption.

The other focused on transforming construction permit approvals through AI-powered compliance automation.

That journey resulted in two projects:

🧠 VeritasFlow – AI-Powered Information Diet Coach
🏗️ PermitFlow – The Construction Compliance Autopilot

Although they solve different problems, both projects share the same vision:

Building AI that solves real-world problems, not just showcases technology.

🧠 Project 1: VeritasFlow – AI-Powered Information Diet Coach

The Problem

The internet gives us unlimited access to information, but not all information is beneficial.

Every day people are exposed to endless news articles, social media feeds, videos, and recommendations that often prioritize engagement over quality. This results in information overload, echo chambers, misinformation, and unhealthy digital habits.

We wanted to build a platform that helps users become more mindful of what they consume online.

Our Solution

VeritasFlow is an AI-powered Information Diet Coach that analyzes users' content consumption patterns and recommends healthier, more balanced, and more informative content.

Rather than maximizing screen time, VeritasFlow focuses on improving digital wellbeing through intelligent recommendations and personalized insights.

Users can understand how they consume information and gradually build healthier digital habits.

Key Features

AI-powered content analysis
Sentiment analysis
Personalized recommendations
Article summarization
Digital wellbeing dashboard
Information diversity score
Reading insights
AI-powered recommendation engine

Technology Stack

React
FastAPI
Python
MongoDB
Natural Language Processing (NLP)
Sentiment Analysis
Recommendation Engine

Implementation

The platform processes user content using NLP techniques to identify topics, sentiment, and reading patterns. Based on this analysis, the recommendation engine suggests educational and balanced content while providing personalized insights into users' digital habits.

Our goal was not to encourage users to spend more time online but to help them spend their time more meaningfully.

🏗️ Project 2: PermitFlow – The Construction Compliance Autopilot

The Problem

Construction permits remain one of the biggest bottlenecks in urban development.

Contractors often spend weeks navigating complicated zoning regulations, submitting repetitive paperwork, correcting applications, and waiting for approvals.

Even a single missing document can delay an entire construction project.

We wanted to simplify this complex process using Artificial Intelligence.

Our Solution

PermitFlow is an AI-powered construction compliance platform that streamlines the permit approval workflow for contractors, architects, municipal officers, and administrators.

Users upload project documents, and the platform automatically analyzes compliance requirements, detects missing information, assists with documentation, and guides applicants throughout the approval process.

Key Features

AI Blueprint Analysis
OCR-based document extraction
Compliance Gap Detection
Government Form Autofill
Permit Status Tracking
Municipal Officer Dashboard
Admin Analytics Dashboard
AI Compliance Assistant
Multilingual Support

Technology Stack

React
FastAPI
Python
MongoDB
OCR
JWT Authentication
Sarvam AI

How We Used Sarvam AI

PermitFlow was also built for the Sarvam AI Track, where Sarvam AI became a key part of our solution.

We integrated Sarvam AI to:

Build a multilingual AI compliance assistant.
Answer user queries related to zoning rules, FAR limits, setbacks, Fire NOCs, and municipal regulations.
Translate compliance guidance into multiple Indian languages.
Enable voice-based interactions for easier accessibility.
Simplify complex legal and technical regulations into easy-to-understand explanations.

By integrating Sarvam AI, PermitFlow became more accessible, user-friendly, and practical for contractors, architects, and government officials across India.

Challenges We Faced

Although both projects belonged to different industries, they presented equally interesting engineering challenges.

For VeritasFlow, designing recommendations that promote healthier information consumption rather than maximizing engagement required careful planning and experimentation.

For PermitFlow, understanding complex construction regulations and transforming them into a simple AI-assisted workflow required thoughtful product design and user-centric development.

Throughout the hackathon, we continuously refined our UI, backend architecture, and AI workflows to create solutions that were both practical and intuitive.

What We Learned

HACKHAZARDS '26 taught us that successful AI applications begin with understanding real user problems.

Beyond writing code, we learned the importance of product thinking, collaboration, user experience, and responsible AI implementation.

Working on two completely different projects also strengthened our understanding of full-stack development, document intelligence, recommendation systems, workflow automation, and AI integration.

Looking Ahead

Both projects have exciting possibilities for future development.

VeritasFlow

Browser Extension
Fake News Detection
AI Wellness Score
Social Media Feed Analysis
Mobile Application
Advanced Recommendation Models

PermitFlow

GIS-based Zoning Verification
BIM/CAD Blueprint Support
Real-time Municipal API Integration
Predictive Approval Analytics
Digital Signature Support
Inspection Scheduling
Mobile App for Field Officers

Final Thoughts

HACKHAZARDS '26 was much more than a hackathon—it was an incredible learning journey.

It gave us the opportunity to transform ideas into working products, collaborate as a team, and explore how AI can solve meaningful problems across entirely different industries.

From promoting healthier digital habits with VeritasFlow to simplifying construction compliance through PermitFlow and Sarvam AI, this journey reinforced one important belief:

Technology creates the greatest impact when it solves real problems for real people.

A heartfelt thank you to NAMESPACE, the mentors, organizers, and partner communities for creating such an amazing platform for builders around the world.

We are excited to continue improving both projects beyond the hackathon and turn them into solutions that create real-world impact.

👥 Team

Prerna — Team Lead
Tanya Garg — AI & Backend Developer
Kritika Maurya — Frontend & Design Lead

Thanks for reading! If you'd like to connect, share feedback, or discuss these projects, feel free to reach out. Happy building! 🚀

Building DetectiveAI: Giving Crime Investigation an AI That Never Forgets with Cognee

Tanya Garg — Sun, 05 Jul 2026 17:47:08 +0000

Introduction

One of the biggest limitations of modern AI assistants is memory. Every new conversation starts almost from scratch, making it difficult to work on long-running investigations or complex cases.

For my hackathon project, I wanted to solve exactly this problem.

I built DetectiveAI, an AI-powered crime investigation assistant that uses Cognee Cloud as its persistent memory layer. Instead of forgetting evidence after every session, DetectiveAI stores, organizes, and recalls investigation data whenever it is needed.

The Problem

Imagine a detective investigating a case over several days.

New evidence keeps arriving:

Witness statements
CCTV footage
Crime scene observations
Timelines
Suspect information

Traditional AI can summarize information, but it doesn't naturally remember and connect all of these details across sessions.

This is where persistent memory becomes essential.

My Solution

DetectiveAI combines a simple investigation workflow with Cognee Cloud.

The investigator can:

Create a crime case
Add evidence
Store investigation details
Search previous information
Ask natural language questions
Generate investigation summaries

Because the information is stored inside Cognee, the AI can retrieve relevant context instead of depending only on the current prompt.

How Cognee Powers DetectiveAI

Cognee acts as the memory layer for my application.

Each investigation is stored as structured knowledge rather than temporary chat history.

When the investigator asks questions like:

Who is the suspect?
Summarize this investigation.
What relationships exist between the evidence?
Explain the timeline.

Cognee retrieves the most relevant information from the stored investigation memory.

Features

Create Case

Start a new investigation with:

Case name
Location
Date
Officer name
Initial description

Add Evidence

Store investigation evidence including:

Witness statements
CCTV observations
Timeline events
Physical evidence

Investigation Chat

Interact with the investigation using natural language instead of manually searching documents.

Persistent Memory

Unlike traditional AI assistants, DetectiveAI remembers previously stored information and can reuse it across future sessions.

Investigation Reports

Generate structured summaries of the investigation for quick review.

Tech Stack

Cognee Cloud
Python
AI Language Model
Modern Web Interface

What I Learned

This project taught me that AI memory is much more than saving chat history.

Persistent memory allows AI systems to continuously build knowledge, connect related information, and provide more reliable answers over time.

Cognee made it easy to explore this concept while building a practical real-world application.

Future Improvements

Multi-case investigations
Image and PDF evidence analysis
Voice-based investigation assistant
Collaborative investigations for multiple officers
Automatic contradiction detection
Risk scoring for suspects

Conclusion

DetectiveAI demonstrates how persistent memory can transform AI assistants from simple chatbots into long-term intelligent investigation systems.

With Cognee Cloud, our AI doesn't just answer questions—it remembers the investigation.

CrisisIQ – AI-Powered Business Risk Intelligence using Gemma 4

Tanya Garg — Fri, 22 May 2026 18:01:53 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

CrisisIQ – AI-Powered Crisis Intelligence & Business Risk Analysis Dashboard

What I Built

CrisisIQ is an AI-powered business intelligence dashboard that analyzes how global crises impact companies, industries, and supply chains in real time.

Modern companies operate in highly interconnected ecosystems where geopolitical conflicts, cyberattacks, economic instability, sanctions, natural disasters, and trade disruptions can rapidly affect operations worldwide. CrisisIQ helps users understand these impacts using AI-driven analysis and contextual reasoning.

The platform allows users to:

analyze company exposure during crises
understand operational and financial risks
simulate business disruption scenarios
generate AI-powered mitigation strategies
summarize complex global events into actionable insights

Instead of manually reading lengthy reports and news articles, users receive structured AI-generated intelligence instantly.

Demo

Features Demonstrated

Company risk analysis dashboard
Crisis impact summarization
AI-generated mitigation strategies
Scenario simulation
Industry-wise risk comparison
Supply chain disruption analysis

Demo Video

https://drive.google.com/file/d/1kMt-lclhDu2YvFDQi1mgjPbBoagkEouq/view?usp=drive_link

Live Project

https://crisisiq-ai-business-risk-intelligence-using-gemma-4-edaputmky.streamlit.app/

Screenshots

Code

GitHub Repository

https://github.com/Tanya-garg10/CrisisIQ-AI-Business-Risk-Intelligence-using-Gemma-4.git

Tech Stack

Python
Streamlit
Gemma 4
Pandas
Plotly
OpenRouter / Google AI Studio API
News APIs

How I Used Gemma 4

Gemma 4 powers the core reasoning engine of CrisisIQ.

The application collects company data, industry context, and crisis-related information, then uses Gemma 4 to generate intelligent business impact analysis.

Model Used

Gemma 4 31B Dense

Why I Chose the 31B Dense Model

I intentionally selected the 31B Dense model because the project depends heavily on:

long-context understanding
analytical reasoning
structured business analysis
multi-factor risk interpretation

The larger context window allowed the model to process:

lengthy crisis reports
multiple company profiles
supply chain dependencies
geopolitical developments

This made the 31B Dense model the ideal choice for generating detailed and reliable business intelligence insights.

How Gemma 4 Powers the System

Gemma 4 analyzes:

crisis events
company operations
industry dependencies
supply chain vulnerabilities
financial exposure

The model then generates:

risk assessments
operational impact summaries
mitigation recommendations
scenario-based predictions
executive-level insights

Example Output

“The ongoing geopolitical conflict may significantly disrupt semiconductor supply chains affecting manufacturing timelines and increasing operational costs for automotive companies dependent on Asian suppliers.”

The system transforms raw crisis information into understandable strategic intelligence.

Key Features

AI Risk Scoring

Generates dynamic company risk scores based on current events.

Crisis Summarization

Converts complex news and reports into concise business insights.

Scenario Simulation

Allows users to test hypothetical crisis situations and predict business outcomes.

Supply Chain Intelligence

Identifies vulnerable operational dependencies and potential disruption points.

Executive Insights

Produces human-readable strategic recommendations for decision-making.

Challenges I Faced

One of the main challenges was designing prompts that produced structured, analytical responses instead of generic summaries.

Another challenge was handling large volumes of contextual information while maintaining coherent reasoning and fast response times.

Balancing accuracy, readability, and practical usefulness required significant prompt engineering and response optimization.

What I Learned

Through this project, I gained deeper experience in:

AI-powered reasoning systems
long-context prompt engineering
business intelligence workflows
risk analysis pipelines
dashboard development
integrating LLMs into analytical applications

I also learned how powerful open models like Gemma 4 can be for enterprise-style AI applications.

Future Improvements

Planned future enhancements include:

real-time live news integration
predictive trend forecasting
interactive crisis maps
AI-generated financial impact estimation
multilingual analysis support
collaborative enterprise dashboards

Final Thoughts

CrisisIQ demonstrates how AI can transform overwhelming global information into actionable strategic intelligence.

By combining real-world crisis data with the reasoning capabilities of Gemma 4, the platform helps businesses better understand risks, prepare for disruptions, and make informed decisions faster.

This project highlights the growing potential of open AI models in enterprise intelligence and decision-support systems.

Building a Smart Environmental Monitoring System with Google Cloud (Inspired by NEXT ‘26)

Tanya Garg — Thu, 23 Apr 2026 05:13:43 +0000

Building a Smart Environmental Monitoring System with Google Cloud (Inspired by NEXT ‘26)

This is a submission for the Google Cloud NEXT Writing Challenge

🌍 Why Google Cloud NEXT ‘26 Caught My Attention

Every year, Google Cloud NEXT brings new ideas, but this time what stood out to me was the strong push toward real-time data processing, AI integration, and scalable cloud-native systems.

As someone working on IoT + web-based systems, I was especially interested in how cloud tools can handle live sensor data efficiently and make it useful.

💡 The Idea: Smart Environmental Monitoring System

Inspired by the announcements around cloud scalability and developer tools, I decided to explore a simple but practical use case:

A system that monitors temperature, CO₂ levels, and soil moisture in real time.

This kind of system can be useful for:

Smart agriculture 🌱
Indoor air quality monitoring 🏠
Climate-aware applications 🌍

🛠️ Tech Stack I Used

Raspberry Pi → Collect sensor data
Django (Backend) → Handle APIs & data processing
React.js (Frontend) → Display real-time dashboard
HTTP Protocol → Send live sensor data
Google Cloud (Conceptual Integration):
- Cloud Run / App Engine (deployment ideas)
- Cloud Storage / Firestore (data handling)
- AI/ML possibilities for predictions

⚙️ How It Works

Sensors connected to Raspberry Pi collect data
Data is sent via HTTP to a Django backend
Backend processes and stores the data
React dashboard displays it in real time

🔍 What I Learned from NEXT ‘26

1. Cloud Makes Real-Time Systems Scalable

Before cloud integration, systems like this are limited locally.
With Google Cloud, this can scale to:

Thousands of devices
Multiple locations
Real-time analytics

2. AI Integration is the Next Step

The real power is not just collecting data, but:

Predicting trends
Detecting anomalies
Automating alerts

For example:

Predict soil dryness before it happens
Alert when CO₂ levels become unsafe

3. Developer Experience is Improving

One key takeaway from NEXT ‘26 is how tools are becoming:

Easier to deploy
More integrated
Faster to build with

This reduces the gap between idea → prototype → production.

🤔 My Honest Take

While Google Cloud offers powerful tools, beginners might still face:

Initial setup complexity
Understanding pricing
Choosing the right service

However, once you get past that, the ecosystem is incredibly powerful.

🚀 What I’d Do Next

If I extend this project using Google Cloud:

Deploy backend on Cloud Run
Store real-time data in Firestore
Use AI models for prediction
Add alerts using cloud functions

📌 Final Thoughts

Google Cloud NEXT ‘26 reinforced one thing for me:

The future is not just about building apps — it’s about building intelligent, scalable systems.

Even a simple IoT project can become powerful when combined with cloud + AI.

💬 What About You?

Did you explore anything from Google Cloud NEXT ‘26?
What feature excited you the most?

Let’s discuss 👇