# Minutes of Meeting — Enterprise Brain Pricing and Architecture Follow-up
**Date:** March 4, 2026  
**Source transcripts:** [Mar 4, 2026.txt](Mar 4, 2026.txt), [Mar 4, 2026-2.txt](Mar 4, 2026-2.txt)

**Attendees:** Yeshwanth Reddy Yerraguntla, Naveen Puttagunta, Diya Elizabeth, Rajashekar G, Vara Kumar Jagarapu, Manisha Gundapuneedi

## Act I — 00:00 to 00:06, infrastructure first

The morning started with a pricing calibration. Naveen separated infrastructure, interactive LLM usage, and background processing so the team could explain what a tiny proof of concept costs versus a real platform.

> *"One hour usage for one user is $1."*
> — Naveen Puttagunta _(~00:07:41)_

> *"For the simplest of use cases, it's anywhere between $100 to $300."*
> — Naveen Puttagunta _(~00:09:57)_

That set the baseline: a simple connector is not the same thing as the full Enterprise Brain system, and the economics should make that obvious.

## Act II — 00:06 to 00:11, usage and always-on cost

Naveen then walked the group through the difference between user-driven analysis and system-driven refreshes. One is charged per session or per hour of use; the other is a background cost that exists even when nobody is actively asking questions.

> *"For the simplest of use cases, it's anywhere between $100 to $300."*
> — Naveen Puttagunta _(~00:09:57)_

The team needed that split because the full platform vision includes ongoing refreshes, correlations, and alerts. Those are not priced like a single Excel upload.

## Act III — 00:11 to 00:16, implementation cost and sales framing

Diya kept pushing on how to explain implementation cost without making the team sound evasive. Naveen answered by separating the smallest proof-of-concept from the broader platform story.

> *"If you're trying to do a proof of concept, I could do it in like 15 $20,000 maybe even less."*
> — Naveen Puttagunta _(~00:14:31)_

> *"Don't hesitate answering, right?"*
> — Naveen Puttagunta _(~00:23:56)_

That brought the discussion into the same shape the product team has been using everywhere else: explain the small thing clearly, but don’t let the small thing define the platform.

## Act IV — 00:16 to 00:17, handoff to Pratima

By the end of the pricing segment, Naveen explicitly asked for Pratima to be involved before the number gets socialized further. The team did not want the implementation estimate and the platform estimate getting mixed together in the wrong room.

That is the point where the first session ended: the economics were clear enough to discuss, but still needed the right owner before they could be turned into a customer-ready narrative.

## Act V — later the same day, architecture follow-up opens

The second conversation on the same day shifted from pricing into product scope. The team talked through login, onboarding, dashboard landing, streaming responses, session history, and the role model before any polished demo could be considered real.

> *"There is no trainer mode user mode though."*
> — Yeshwanth Reddy Yerraguntla _(~00:25:43)_

That clarification mattered because the system should not blur user, admin, and trainer into one overloaded bucket. The architecture needs to make those concerns distinct even if one person can occupy more than one role.

## Act VI — scope stays smaller than the vision

The day ended with a pragmatic backlog shape: stabilize request/response flow, keep the role model explicit, and only then expand into richer interaction patterns. The team did not pretend the architecture was finished; they just made sure the scope for the next step was honest.

## Todos

<todo>
  Finalize the pricing narrative that separates the simple proof-of-concept cost from the amortized platform cost.<br/>
  <span class="owner">Diya / Naveen / Pratima</span>
  <span class="deadline">Before the client pricing review</span>
</todo>

<todo>
  Define the login, onboarding, session history, and user/admin/trainer data model for the V2 follow-up.<br/>
  <span class="owner">Architecture team</span>
  <span class="deadline">Next implementation pass</span>
</todo>

<todo>
  Lock the P0/P1 scope for dashboard landing, streaming chat, and follow-up question handling.<br/>
  <span class="owner">Yeshwanth / Rajashekar / Vara</span>
  <span class="deadline">Before the next sprint breakdown</span>
</todo>