DEV Community: Krushna Kodgirwar

I Boardroom OS: A Private Board of Directors That Runs on a 4GB GPU

Krushna Kodgirwar — Tue, 13 Oct 2026 11:38:49 +0000

What I Built

AI Boardroom OS is a multi-agent business decision simulator that runs on a local LLM. You describe a business decision, optionally upload supporting documents, and a virtual boardroom of 10+ executive personas (CFO, CTO, CMO, and others) analyzes it, debates it, and hands it to a CEO agent that synthesizes a final recommendation. A last validation stage checks that the decision is coherent.

Who would pay: solo founders, small agencies and consultancies who want a structured second opinion on pricing, hiring, or go-to-market calls but can't afford an advisory board or send confidential numbers to a third-party API. Everything runs on the user's own machine.

Side hustle angle: [your model, e.g. "sell it as a one-off 'decision review' service at ₹X per session", or "offer a self-hosted license to small consultancies". Fill in what you'd actually do.]

Code

krushnakodgirwar / AI-Boardroom

AI-powered multi-agent business decision simulator with executive agents and an AI CEO decision system.

🏛️ AI Boardroom OS

### Where AI Agents Think Together

A Multi-Agent AI Business Decision Simulator
Analyze business challenges through specialized AI executives, collaborative reasoning, and structured decision-making

🌐 Live Application

🔗 Live Website: https://ai-boardroom-xexp.onrender.com

🔗 GitHub Repository: https://github.com/krushnakodgirwar/AI-Boardroom

Deployment note: The frontend is hosted on Render. Full AI analysis requires the FastAPI backend to be running and the frontend to be configured with a reachable backend URL.

📑 Table of Contents

📖 Explore the README sections

✨ Introduction

AI Boardroom OS is a multi-agent AI business decision simulator that explores how specialized…

View on GitHub

How I Built It

Model: Qwen2.5-3B-Instruct (open weights), 4-bit NF4 quantized, running on an RTX 3050 with 4 GB VRAM. I started with TinyLlama-1.1B, moved to Qwen2.5-1.5B, then to 3B as I got better at working around small-model limits.
Pipeline: four stages: executive analysis → debate → CEO synthesis → decision validation.
Small-model tricks: JSON-schema-constrained outputs, role-specific grounding hints, and compressed "cards" passed between stages so context stays small. A truncation-retry function handles incomplete generations.
Retrieval: Sentence Transformers + ChromaDB for RAG over uploaded documents.
Stack: Python, PyTorch, Hugging Face transformers, FastAPI backend (/boardroom/analyze), Streamlit multipage frontend with a landing page and a "Command Center" page.
Modes: 2 intelligence modes, 3 response formats, and auto or manual agent selection.

Why Does Open Innovation Matter?

A closed API would have meant per-token costs on every multi-agent debate, which is a lot of calls for one decision, and my clients' business data leaving their machine. Open weights let me quantize the model to fit a 4 GB laptop GPU, constrain its output with schemas, and tune prompts per role. That is what makes a private, near-zero marginal cost advisory product possible for the small businesses I'd sell it to.

Trail Council: Four Tiny AI Agents on My Laptop That Decide If I Should Go Hiking

Krushna Kodgirwar — Wed, 07 Oct 2026 15:08:01 +0000

What I Built

I built Trail Council, a panel of four small AI agents that runs on my laptop with no internet and decides whether I should go on a hike today, and which route to take.

Four agents each look at the plan from one angle: Weather, Route, Gear and Safety. They debate, and a final "lead" agent gives one verdict: Go, Go with a shorter route, Gather more info, or Stay home. The output is a one-page printable plan with the route, turnaround time, gear checklist and the reasoning. I print it, close the laptop, and walk out the door.

The screen is the shortest part of the trip. I use it for about two minutes before I leave, and I can regenerate the plan at the trailhead with zero signal.

It's for anyone who plans outings in places with bad connectivity: hikers, trail runners, and weekend trekkers.

Code

I reused the architecture of an earlier project of mine (AI Boardroom, a multi-agent business decision simulator). Trail Council is a new repository with new agents, new data, new prompts and a new output format. Only the staged pipeline idea carries over.

How I Built It

Stack

Model: Qwen2.5-3B-Instruct, an open-weight model, loaded in 4-bit (NF4) with PyTorch and transformers
Hardware: a laptop with an RTX 3050 (4GB VRAM). No cloud GPU.
Backend: FastAPI + Uvicorn
Retrieval: all-MiniLM-L6-v2 embeddings + ChromaDB over a small local knowledge base ([YOUR DATA: e.g. my own route notes, sunrise/sunset table, gear checklists, local trail descriptions])
Frontend: [HTML/JS page or Streamlit]

The four-stage pipeline

Agent analysis: Weather, Route, Gear and Safety each read the same trip request plus their own retrieved notes and return structured JSON.
Debate: Agents flag disagreements, for example Safety objecting that the long loop finishes after sunset.
Lead decision: One agent weighs the analyses and picks a verdict.
Validation: A check confirms the verdict is one of the four allowed categories and that the next step actually follows from it. Otherwise it retries.

What was hard
A 3B model on 4GB of VRAM drops instructions, cuts off mid-answer and drifts from the format. Three things fixed most of it:

JSON-schema-constrained outputs
Short, role-specific prompts with grounding hints
Compact "cards" passed between stages instead of full text, plus a retry when output is truncated

[ADD 1-2 REAL NUMBERS FROM YOUR MACHINE: time to generate a full plan, VRAM used, how often validation had to retry.]

Field Test

I took it to [PLACE] on [DATE].

What worked: [e.g. it flagged that my planned loop would end after sunset and suggested a shorter one]
What didn't: [e.g. the Weather agent was confidently wrong about X, because my data was stale]
What I changed on the trail: [e.g. regenerated the plan at the trailhead with no signal, and it worked]
Did I follow its advice? [yes/no, and what happened]

Why Does Open Innovation Matter?

It worked with no signal. The model, the embeddings and the vector database all live on my laptop. A hosted-API version of this would be useless at exactly the place it's needed, a trailhead with no coverage.
My plans stay mine. Where I go, when I'll be alone, and when I'll be back are sensitive details. Nothing is sent to a server I don't control.
It costs nothing to run. No API key and no per-request bill. I regenerated plans [N] times while testing.
I could tune the behavior. I rewrote agent roles, swapped the model between sizes, and changed the validation rules. I couldn't have done that with a closed black box.
The honest tradeoff: A 3B model is less capable than a frontier model. I had to design around its limits with schemas, short prompts and validation. For this task I think that's a fair trade, but it is a trade.

Prize Categories

Best Use of Render: [ONLY IF you really host the demo frontend on Render; say what runs there and what runs locally]

Trail Council: Four Tiny AI Agents on My Laptop That Decide If I Should Go Hiking (No Signal Needed)

Krushna Kodgirwar — Wed, 07 Oct 2026 15:06:11 +0000

What I Built

I built Trail Council, a panel of four small AI agents that runs on my laptop with no internet and decides whether I should go on a hike today, and which route to take.

The screen is the shortest part of the trip. I use it for about two minutes before I leave, and I can regenerate the plan at the trailhead with zero signal.

It's for anyone who plans outings in places with bad connectivity: hikers, trail runners, and weekend trekkers.

How I Built It

Stack

Model: Qwen2.5-3B-Instruct, an open-weight model, loaded in 4-bit (NF4) with PyTorch and transformers
Hardware: a laptop with an RTX 3050 (4GB VRAM). No cloud GPU.
Backend: FastAPI + Uvicorn
Retrieval: all-MiniLM-L6-v2 embeddings + ChromaDB over a small local knowledge base ([YOUR DATA: e.g. my own route notes, sunrise/sunset table, gear checklists, local trail descriptions])
Frontend: [HTML/JS page or Streamlit]

The four-stage pipeline

Agent analysis: Weather, Route, Gear and Safety each read the same trip request plus their own retrieved notes and return structured JSON.
Debate: Agents flag disagreements, for example Safety objecting that the long loop finishes after sunset.
Lead decision: One agent weighs the analyses and picks a verdict.
Validation: A check confirms the verdict is one of the four allowed categories and that the next step actually follows from it. Otherwise it retries.

What was hard
A 3B model on 4GB of VRAM drops instructions, cuts off mid-answer and drifts from the format. Three things fixed most of it:

JSON-schema-constrained outputs
Short, role-specific prompts with grounding hints
Compact "cards" passed between stages instead of full text, plus a retry when output is truncated

Field Test

I took it to [PLACE] on [DATE].

What worked: [e.g. it flagged that my planned loop would end after sunset and suggested a shorter one]
What didn't: [e.g. the Weather agent was confidently wrong about X, because my data was stale]
What I changed on the trail: [e.g. regenerated the plan at the trailhead with no signal, and it worked]
Did I follow its advice? [yes/no, and what happened]

Why Does Open Innovation Matter?

It worked with no signal. The model, the embeddings and the vector database all live on my laptop. A hosted-API version of this would be useless at exactly the place it's needed, a trailhead with no coverage.
My plans stay mine. Where I go, when I'll be alone, and when I'll be back are sensitive details. Nothing is sent to a server I don't control.
It costs nothing to run. No API key and no per-request bill. I regenerated plans [N] times while testing.
I could tune the behavior. I rewrote agent roles, swapped the model between sizes, and changed the validation rules. I couldn't have done that with a closed black box.
The honest tradeoff: A 3B model is less capable than a frontier model. I had to design around its limits with schemas, short prompts and validation. For this task I think that's a fair trade, but it is a trade.

My Agent Session

Prize Categories

Best Use of Render: [ONLY IF you really host the demo frontend on Render; say what runs there and what runs locally]

ErrataGuard: AI Board Game Rules & Errata Resolution Agent

Krushna Kodgirwar — Sat, 03 Oct 2026 18:40:50 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

What I Built

Meet ErrataGuard, an AI-powered board game companion and rules agent designed to solve a problem every complex tabletop gamer faces: conflicting rulebooks, errata sheets, and developer FAQs.

Standard keyword search or generic RAG setups frequently blend rulebook text and errata updates together, resulting in hallucinated or outdated rulings. ErrataGuard uses structured Sanity schemas and Model Context Protocol (MCP) to guarantee absolute source attribution, ensuring that when an official errata overrides an original rule, both claims surface side-by-side with clear precedence ranks.

How I Used Sanity

I structured complex game components inside the Sanity Content Lake using custom schemas (ruleClause and errata), mapping out rulebook sections, version printings, and override priorities.

I then pointed Sanity Context at this structured dataset to build a navigable Knowledge Base exposed via an MCP endpoint.

Sanity Context & MCP: The AI agent uses the Model Context Protocol (MCP) stream to query the Knowledge Base dynamically during user chat sessions.
Structured Conflict Resolution: Rather than performing blind full-text vector searches, the agent reads structured reference documents. When an official errata updates a base rule, the agent evaluates the priority field in Sanity to surface both the original rule text and the official clarification side-by-side.

Sanity Project Details

Sanity Project ID: xyz12345 (Production Dataset)
Schema Model: Custom documents for ruleClause (tracking page numbers, text, version) linked via references to errata documents (tracking effective date and precedence levels).

AI Boardroom: Local Multi-Agent Business Decision Simulator

Krushna Kodgirwar — Fri, 02 Oct 2026 04:12:06 +0000

*This is a submission for the Hacktoberfest Weekend challenge: Build for a Friend*

AI Boardroom — A Multi-Agent AI Decision Simulator Built for a Friend

What I Built

I built AI Boardroom, an open-source multi-agent decision-making simulator designed specifically for a close friend who was struggling to evaluate complex business decisions.

Instead of asking a single AI model for advice and receiving a surface-level, biased response, AI Boardroom creates a virtual executive boardroom. It spins up specialized AI agents—such as a cautious CFO, a growth-focused CMO, a risk-averse Legal Advisor, and a Pragmatic Engineer—who analyze the exact same problem simultaneously, challenge each other's assumptions, and generate a balanced, multi-perspective recommendation.

When I ran his latest startup proposal through the local board in front of him, his initial reaction was:

"Seeing the CFO agent immediately call out my unit economics while the CMO agent argued for brand exposure gave me more clarity in 30 seconds than days of overthinking."

Key Features

Multi-Agent Simulation: Orchestrates multiple distinct personas with tailored prompts and temperature parameters.
Autonomous & Manual Collaboration: Observe agents analyze, critique, and build on each other's points in real-time.
Structured Final Synthesis: Generates an aggregated consensus, highlighted risks, and actionable next steps.
100% Local Open-Weight Execution: Operates completely offline with zero API costs using open-source LLMs.

Code

krushnakodgirwar / AI-Boardroom

AI-powered multi-agent business decision simulator with executive agents and an AI CEO decision system.

🏛️ AI Boardroom OS

### Where AI Agents Think Together

A Multi-Agent AI Business Decision Simulator
Analyze business challenges through specialized AI executives, collaborative reasoning, and structured decision-making

🌐 Live Application

🔗 Live Website: https://ai-boardroom-xexp.onrender.com

🔗 GitHub Repository: https://github.com/krushnakodgirwar/AI-Boardroom

Deployment note: The frontend is hosted on Render. Full AI analysis requires the FastAPI backend to be running and the frontend to be configured with a reachable backend URL.

📑 Table of Contents

📖 Explore the README sections

✨ Introduction

AI Boardroom OS is a multi-agent AI business decision simulator that explores how specialized…

View on GitHub

The repository contains the complete source code, including the FastAPI backend, prompt orchestration pipelines, agent persona configs, and interactive frontend interface.

How I Built It

I engineered the entire stack from scratch to run efficiently on consumer hardware without reliance on closed third-party APIs:

1. System Architecture & Tech Stack

Core Intelligence: Open-weight Qwen2.5-3B-Instruct model.
Model Optimization: Loaded via PyTorch using 4-bit NF4 quantization (bitsandbytes), drastically reducing GPU memory overhead so it runs smoothly on standard hardware.
Backend API: FastAPI & Uvicorn handling asynchronous multi-agent prompt pipelines and stream responses.
Frontend UI: Built with HTML5, CSS3, and modern JavaScript (ES6) for clear visual separation of agent discussions.
Tunneling & Testing: Integrated Cloudflare Tunnels for secure local-to-web testing and live previews.

                     USER INPUT
                         │
                         ▼
                Business Problem Context
                         │
                         ▼
              AI BOARDROOM ORCHESTRATOR
                         │
        ┌────────────────┼────────────────┐
        │                │                │
        ▼                ▼                ▼
   Agent 1: CFO     Agent 2: CMO    Agent 3: Tech Lead
(Financial Risk)  (User Growth)    (Feasibility)
        │                │                │
        └────────────────┼────────────────┘
                         │
                         ▼
              Agent Discussion & Review
                         │
                         ▼
             Structured Final Consensus

Why Does Open Innovation Matter?

Building AI Boardroom on open-source technology made critical features possible that closed proprietary APIs couldn't offer:

Unrestricted Persona Fine-Tuning & Prompt Depth: Proprietary APIs often apply heavy global system instruction layers that dull distinct agent personas. Using an open-weight model like Qwen2.5-3B-Instruct allowed me to fine-tune exact agent behavior, context lengths, and temperature parameters per role without safety filter over-triggering.
Absolute Confidentiality: Business ideas, pitch decks, and internal financials are highly sensitive. Keeping inference 100% local ensures zero data is logged or sent to cloud servers to train external models.
Zero Token Cost for Complex Multi-Turn Loops: Multi-agent discussions consume thousands of tokens in context-swapping per run. Running locally eliminated per-token API costs completely, enabling infinite iterations for free.

Challenges I Solved

Context Swapping Latency: Running multi-agent prompts sequentially on a single GPU can slow down response times. I optimized memory consumption with 4-bit NF4 quantization and streamlined prompt templates to keep response latency low.
Preventing Consensus Bias: Early iterations saw agents blindly agreeing with each other. I tuned the temperature settings individually per agent (e.g., lower temperature for CFO, higher for CMO) and added explicit counter-argument system constraints to force realistic boardroom debate.

Prize Categories

Best Use of Gemma / Open-Weight Models

Building AI Boardroom: A Multi-Agent Decision Engine for My Friend

Krushna Kodgirwar — Fri, 02 Oct 2026 04:10:13 +0000

*This is a submission for the Hacktoberfest Weekend challenge: Build for a Friend*

AI Boardroom — A Multi-Agent AI Decision Simulator Built for a Friend

What I Built

I built AI Boardroom, an open-source multi-agent decision-making simulator designed specifically for a close friend who was struggling to evaluate complex business decisions.

When I ran his latest startup proposal through the local board in front of him, his initial reaction was:

"Seeing the CFO agent immediately call out my unit economics while the CMO agent argued for brand exposure gave me more clarity in 30 seconds than days of overthinking."

Key Features

Multi-Agent Simulation: Orchestrates multiple distinct personas with tailored prompts and temperature parameters.
Autonomous & Manual Collaboration: Observe agents analyze, critique, and build on each other's points in real-time.
Structured Final Synthesis: Generates an aggregated consensus, highlighted risks, and actionable next steps.
100% Local Open-Weight Execution: Operates completely offline with zero API costs using open-source LLMs.

Code

krushnakodgirwar / AI-Boardroom

AI-powered multi-agent business decision simulator with executive agents and an AI CEO decision system.

🏛️ AI Boardroom OS

### Where AI Agents Think Together

A Multi-Agent AI Business Decision Simulator
Analyze business challenges through specialized AI executives, collaborative reasoning, and structured decision-making

🌐 Live Application

🔗 Live Website: https://ai-boardroom-xexp.onrender.com

🔗 GitHub Repository: https://github.com/krushnakodgirwar/AI-Boardroom

Deployment note: The frontend is hosted on Render. Full AI analysis requires the FastAPI backend to be running and the frontend to be configured with a reachable backend URL.

📑 Table of Contents

📖 Explore the README sections

✨ Introduction

AI Boardroom OS is a multi-agent AI business decision simulator that explores how specialized…

View on GitHub

The repository contains the complete source code, including the FastAPI backend, prompt orchestration pipelines, agent persona configs, and interactive frontend interface.

How I Built It

I engineered the entire stack from scratch to run efficiently on consumer hardware without reliance on closed third-party APIs:

1. System Architecture & Tech Stack

Core Intelligence: Open-weight Qwen2.5-3B-Instruct model.
Model Optimization: Loaded via PyTorch using 4-bit NF4 quantization (bitsandbytes), drastically reducing GPU memory overhead so it runs smoothly on standard hardware.
Backend API: FastAPI & Uvicorn handling asynchronous multi-agent prompt pipelines and stream responses.
Frontend UI: Built with HTML5, CSS3, and modern JavaScript (ES6) for clear visual separation of agent discussions.
Tunneling & Testing: Integrated Cloudflare Tunnels for secure local-to-web testing and live previews.

                     USER INPUT
                         │
                         ▼
                Business Problem Context
                         │
                         ▼
              AI BOARDROOM ORCHESTRATOR
                         │
        ┌────────────────┼────────────────┐
        │                │                │
        ▼                ▼                ▼
   Agent 1: CFO     Agent 2: CMO    Agent 3: Tech Lead
(Financial Risk)  (User Growth)    (Feasibility)
        │                │                │
        └────────────────┼────────────────┘
                         │
                         ▼
              Agent Discussion & Review
                         │
                         ▼
             Structured Final Consensus

Why Does Open Innovation Matter?

Building AI Boardroom on open-source technology made critical features possible that closed proprietary APIs couldn't offer:

Unrestricted Persona Fine-Tuning & Prompt Depth: Proprietary APIs often apply heavy global system instruction layers that dull distinct agent personas. Using an open-weight model like Qwen2.5-3B-Instruct allowed me to fine-tune exact agent behavior, context lengths, and temperature parameters per role without safety filter over-triggering.
Absolute Confidentiality: Business ideas, pitch decks, and internal financials are highly sensitive. Keeping inference 100% local ensures zero data is logged or sent to cloud servers to train external models.
Zero Token Cost for Complex Multi-Turn Loops: Multi-agent discussions consume thousands of tokens in context-swapping per run. Running locally eliminated per-token API costs completely, enabling infinite iterations for free.

Challenges I Solved

Context Swapping Latency: Running multi-agent prompts sequentially on a single GPU can slow down response times. I optimized memory consumption with 4-bit NF4 quantization and streamlined prompt templates to keep response latency low.
Preventing Consensus Bias: Early iterations saw agents blindly agreeing with each other. I tuned the temperature settings individually per agent (e.g., lower temperature for CFO, higher for CMO) and added explicit counter-argument system constraints to force realistic boardroom debate.

Prize Categories

Best Use of Gemma / Open-Weight Models