DEV Community: Jagadeesh

Gemma SlideCast: A 4-Agent Autonomous Presentation & Document Engine

Jagadeesh — Sun, 24 May 2026 17:24:04 +0000

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

What I Built

GemmaSlide is an autonomous, multi-agent slide presentation & document generation engine. It turns long, unstructured prose into beautiful, print-ready visual slide decks (matching aesthetics like NotebookLM or Minimal Modern styles) in seconds.

Traditional document summaries are text-heavy and dull. GemmaSlide solves this by orchestrating four specialized, cooperative AI agents in a pipeline that handles structure, design, quality audit, and unified output formatting:

The Planner Node: Dissects raw prose and maps out a cohesive presentation storyboard.
The Designer Node: Translates visual style sheets directly into beautiful modular HTML layouts.
The Critic Node: Audits contrast ratios, margins, and readability, returning corrective styling scores.
The Assembler Node: Stitches pages together, inserting smart cover pages, tables of contents, and print pages under unified CSS templates.

Repo

Git Hub Repo Link: https://github.com/Jagadeesh961982/dynamicpdfgenerator

Code

Backend & Frontend Repository: [Insert Link to your GitHub Repository]
Core Stacks:
- Backend: Python + FastAPI (with server-sent events for streaming agent states)
- Frontend: React + TypeScript + Tailwind CSS (with Recharts for telemetry)
- Orchestration: Multi-Agent Pipeline utilizing the official Google GenAI SDK.

How I Used Gemma 4

Our application relies on a configurable pipeline topology where users choose the exact model for each of the four roles. This highlights model trade-offs between speed, reasoning accuracy, and styling compliance.

Here is how each model was choose to power our workspace:

🚀 Which Model is Right for Us? Our Topology Selection

Gemma 4 (9B - SOTA Instruct): Chosen for the Planner and Designer roles. Its state-of-the-art instruction tuning delivers 2.5x higher structural alignment than similar-tier models. It consistently produces raw JSON slide storyboards and clean HTML layouts without breaking or outputting markdown junk.
Gemma 2 (27B - Heavy Reasoning): Selected as our Critic. Reviewing contrast ratios, reading text configurations, and outputting highly specific design audits requires deep intelligence. Gemma 2's 27B parameter weight was the clear winner for safety assessment.
Gemma 2 (9B): Chosen as our super agile Assembler to quickly handle structural page-break compilation and unify final document styling at incredibly low latency.

📊 Latency Telemetry

Our frontend tracks precise diagnostic telemetry for every run on a dynamic Recharts bar chart. Running Gemma 4 (9B) for creative generation alongside Gemma 2 (27B) for critique creates an optimized blend of execution speed and human-quality structural design!

Beyond RAG: Architecting Local Long-Context Pipelines with Gemma 4's 31B Dense Model

Jagadeesh — Sun, 24 May 2026 07:53:33 +0000

Most AI document processing relies heavily on Retrieval-Augmented Generation (RAG). We chunk data into tiny pieces, vectorize it, and stitch the summaries together. RAG is excellent for finding a needle in a haystack, but it is fundamentally flawed when you need the model to understand the entire haystack at once.

With the release of Gemma 4, specifically the native 128K context window, we finally have the tools to move away from aggressive chunking.

In this post, I’ll break down why long-context local models change how we design AI pipelines, examine the architectural differences between the Gemma 4 variants, and share a case study of how I utilized the 31B Dense model to process massive, unbroken log files locally.

The Problem: Chunking Destroys Narrative Coherence

Imagine an Operational Command Center (OCC) monitoring a multi-tenant Kubernetes deployment. A massive cascading failure occurs, generating 200 interconnected infrastructure alerts—Kafka backlogs, CPU spikes, and database deadlocks.

If you feed these logs into a standard chunked AI pipeline, it:

Splits the logs into 2,000-token chunks.
Summarizes each chunk independently.
Merges those summaries into a final report.

The problem? Separation of concerns works in code, but not in narrative analysis. The Kafka backlog in chunk 1 is never contextually linked to the database deadlock in chunk 7. You get a sterile list of bullet points, missing the actual root cause that ties the event together.

To solve this, the model must read the entire event timeline in a single prompt.

Why the 31B Dense Model is the Right Tool

The Gemma 4 family offers three main architectures. When designing a system that relies on a 128K context window, intentional model selection is critical.

Model	Primary Strength	Best For
2B / 4B	Edge execution	Ultra-mobile, browser-based tasks
26B MoE	Throughput / Speed	Chatbots, high-volume fast inference
31B Dense	Deep Recall / Reasoning	Complex analysis across large contexts

A typical severe OCC incident log is roughly 80,000 to 100,000 tokens.

I explicitly chose the 31B Dense model over the 26B Mixture-of-Experts (MoE). While MoE models are undeniably faster at inference, Dense architectures traditionally exhibit superior long-context recall. When asking a model to evaluate 100,000 tokens of raw server metrics and deduce the single underlying failure thread, coherent reasoning across the full document is far more valuable than raw token generation speed.

The Local-First Advantage

Infrastructure alert data is confidential. By running ollama run gemma4:31b, the data never leaves the machine. No API keys, no data residency concerns, and no per-token cost at scale.

Case Study: The Long-Context "Fast-Path" Architecture

To demonstrate this, I built a 4-agent pipeline to generate analytical reports from raw data. Instead of forcing all data through a chunking mechanism, the architecture implements a Long-Context Fast-Path.

Here is how the routing logic cleanly separates the decision-making process:

def _use_full_document(self, document_text: str) -> bool:
    """
    Determines if the document can be processed in a single, unchunked pass.
    """
    provider = getattr(config, "PROVIDER", "ollama")
    use_long_ctx = getattr(config, "USE_LONG_CONTEXT", True)
    model = getattr(config, "OLLAMA_MODEL", "gemma4:31b")

    if not use_long_ctx:
        return False

    is_gemma4_local = (provider == "ollama" and "gemma4" in model.lower())
    is_gemma4_cloud = (
        provider == "openrouter" and 
        "gemma-4" in getattr(config, "MODEL_ALL", "").lower()
    )

    if not (is_gemma4_local or is_gemma4_cloud):
        return False

    # Gemma 4 supports 128K tokens. 
    max_chars = getattr(config, "GEMMA4_LONG_CONTEXT_CHARS", 400_000)
    return len(document_text) <= max_chars

When this returns True, the orchestrator bypasses all intermediate summarizing agents. The entire context is injected directly into the primary narrative agent.

Multimodal Processing

I also implemented a call_vision() gateway using Gemma 4's native multimodal input. Ops teams can drop a screenshot of a dashboard (.png, .jpg), and Gemma 4 inherently connects the visual spikes to the text-based logs, extracting the numbers to use in the slides without needing a separate vision model.

Code & Running It Yourself

You can find the complete code for the CLI pipeline, FastAPI backend, and React frontend here:

GitHub Repository: https://github.com/Jagadeesh961982/dynamicpdfgenerator

For local, private execution:

# Install Ollama and pull the model
ollama pull gemma4:31b

# Clone and install
git clone https://github.com/Jagadeesh961982/dynamicpdfgenerator
pip install -r requirements.txt
playwright install chromium

# Set provider
echo "PROVIDER=ollama" >> .env
echo "OLLAMA_MODEL=gemma4:31b" >> .env

# Run the orchestrator
python orchestrator.py --input your_alerts.txt

(Instructions for OpenRouter are also available in the repository README).

What I Learned

Long context is not free. Feeding 80,000+ tokens into a model requires real hardware — the 31B variant needs roughly ~32GB VRAM to run efficiently locally with quantization. For most developers, cloud APIs or Kaggle notebooks are the practical path.
Dense beats MoE for recall tasks. For reading hundreds of alerts and synthesizing a coherent narrative, the Dense architecture was significantly more reliable.
Multimodal is genuinely useful. Unlocking screenshot processing completely changed the workflow for teams who rely on visual dashboards.
Open weights = architecture freedom. Being able to run this pipeline entirely on-premise under Apache 2.0 is a legitimate business advantage for enterprise environments.

The shift toward capable, open-weight, large-context models like Gemma 4 means we no longer have to compromise our data architecture to fit the limitations of an AI. We can finally build systems that read our data the way we do.

# ✉️ SmartSupportAI – AI-Powered Email Support for OnlineStore

Jagadeesh — Sun, 08 Jun 2025 10:12:59 +0000

🧠 What I Built

SmartSupportAI is an intelligent customer support automation system for e-commerce platforms like OnlineStore, where users can send feedback or support queries via email — and receive a personalized, human-like AI response within seconds.

It uses Postmark's inbound email parsing feature to receive emails and triggers a webhook to:

Log the email into a database
Analyze the content with Gemini 2.0 Flash
Classify and respond using AI
Send a formal, contextual, and human-sounding reply using Nodemailer

✨ Demo

📬 Send a feedback email to:

feedbacksonlinestore@gmail.com

Example:

"I'm facing an issue placing a mobile order."

You'll get a smart reply like this:

🔧 How It Works

Here’s the flow architecture:

User sends feedback to feedbacksonlinestore@gmail.com
Email is auto-forwarded to Postmark Inbound
Postmark triggers a webhook to my Express server
Server logs the message in MongoDB
It checks if this message is a follow-up to a previous query
Sends the data to Gemini AI (2.0 Flash) for smart classification and response generation
The AI's response is sent back to the user using Nodemailer
All feedback and responses are stored for future context

📦 GitHub Repository

👉 https://github.com/Jagadeesh961982/postmark

🤖 AI Deep Dive

Uses Gemini 2.0 Flash for generating formal, empathetic, and context-aware replies
AI checks similarity with previous feedback (via prompt-based comparison)
Example: If a user sends "I’m still facing payment issues", Gemini picks up the thread from the earlier conversation

🧠 Postmark Integration

Inbound email goes to a Postmark inbound stream
Webhook forwards full structured data to Express
Handles attachments, raw text, and reply chains
Logs feedback in MongoDB for traceability

🔐 Tech Stack

Backend: Node.js + Express
Email Inbound: Postmark Webhooks
AI Engine: Gemini Flash via Google Generative AI API
Email Outbound: Nodemailer with Gmail App Password
Database: MongoDB with Mongoose

💡 Why I Built It

Many customers still prefer to send support requests via email — especially older users or those in low-connectivity areas. Instead of forcing users into live chat bots or apps, this project turns traditional support mail into a fully automated yet human-sounding experience.

This also:

Saves support time
Offers consistent and structured replies
Enables easy record-keeping for admins

📈 Potential Use Cases

E-commerce customer support
SaaS support inbox
HR feedback handling
Complaint resolution bots
Feedback-based AI analytics

📣 Want to Try It?

✅ Just send a feedback email to:

📨 feedbacksonlinestore@gmail.com

🧪 You’ll receive an AI-generated response like this:

Dear Customer,

We understand you're facing issues placing your mobile order...

Please provide the following details...

✅ AI decides if it’s a follow-up, and builds context-aware responses.

🙌 Shoutout to Postmark

Postmark's inbound email parsing made this flow clean and reliable. Setting up inbound streams and webhooks was painless. And the structured payload helped feed AI models directly.

Huge thanks for this challenge — it pushed me to explore how email + AI can reinvent everyday support workflows.

Stock Price Predictor

Jagadeesh — Sun, 26 Jan 2025 16:37:34 +0000

This is a submission for the Agent.ai Challenge: Productivity-Pro Agent (See Details)

What I Built

I developed a Stock Prediction Agent designed to empower traders with AI-driven insights. My agent, Stock Price Predictor, analyzes historical stock data, leverages technical indicators (Bollinger Bands, MACD, RSI), and predicts actionable trading signals (Buy/Sell/Hold) alongside next day price targets (Open, Close, Buy/Sell levels). Built with Flask and machine learning, it transforms complex market data into digestible, confidence-scored recommendations.

Demo

https://agent.ai/agent/stock-price-predictor

How It Works

Step 1: Enter a stock symbol (e.g., RVNL.NS).
Step 2: The Agent fetches historical data, calculates technical indicators, and runs ML models.
Output:

Action: Buy/Sell/Hold recommendation with confidence score.
Price Forecasts: Predicted Buy (Low), Sell (High), Open, and Close prices for the next trading session.

Challenge Experience

Building this agent with Flask, XGBoost, and Random Forest was a rewarding deep dive into Stock Price Prediction. Key learnings:

Balancing imbalanced classes with SMOTE drastically improved prediction accuracy.
Integrating Yahoo Finance data via yfinance streamlined real-time analysis.
Deploying the model as an API with error handling ensured scalability.
While hyperparameter tuning with GridSearchCV was computationally intense, the performance gains justified the effort.

Next step? Adding real-time news for sentiment analysis!
Disclaimer: Predictions are educational and not financial advice. Trade responsibly!

Agent.ai Experience

Agent.ai simplified building and deploying Stock Price Predictor, letting me focus on refining ML models instead of infrastructure. Its intuitive tools made API integration and scaling effortless.

A Smarter Stock Predictor

Jagadeesh — Sun, 26 Jan 2025 14:17:06 +0000

This is a submission for the Agent.ai Challenge: Full-Stack Agent (See Details)

What I Built

Demo

https://agent.ai/agent/stock-price-predictor

How It Works

Step 1: Enter a stock symbol (e.g., IRFC.NS).
Step 2: The Agent fetches historical data, calculates technical indicators, and runs ML models.
Output:

Action: Buy/Sell/Hold recommendation with confidence score.
Price Forecasts: Predicted Buy (Low), Sell (High), Open, and Close prices for the next trading session.

Challenge Experience

Building this agent with Flask, XGBoost, and Random Forest was a rewarding deep dive into Stock Price Prediction. Key learnings:

Balancing imbalanced classes with SMOTE drastically improved prediction accuracy.
Integrating Yahoo Finance data via yfinance streamlined real-time analysis.
Deploying the model as an API with error handling ensured scalability.
While hyperparameter tuning with GridSearchCV was computationally intense, the performance gains justified the effort.

Next step? Adding real-time news for sentiment analysis!
Disclaimer: Predictions are educational and not financial advice. Trade responsibly!

Agent.ai Experience

Agent.ai simplified building and deploying Stock Price Predictor, letting me focus on refining ML models instead of infrastructure. Its intuitive tools made API integration and scaling effortless.