--- date: 2026-04-27 meeting: Enterprise Brain Scrum (two sessions) sources: - Enterprise Brain Scrum - 2026_04_27 20_03 PDT - Notes by Gemini.txt # full transcript, session 1 (~99 min) - Enterprise Brain Scrum - 2026_04_27 22_10 PDT - Notes by Gemini.txt # full transcript, session 2 (~61 min) duration: session 1 ~99 min · session 2 ~61 min --- # Enterprise Brain Scrum — 27 Apr 2026 **Date:** 2026-04-27 | **Sessions:** 20:03 PDT (~99 min) + 22:10 PDT (~61 min) **Source:** Two full transcripts — combined into one MOM ## Participants **RG** — Rajashekar G Mannam **YR** — Yeshwanth Reddy Yerraguntla **SP** — Satyasri Prabhakar Mantripragada **PG** — Phawhan Saii Gajjalakonda **AB** — Abhilash Adunuri **NP** — Naveen Puttagunta --- ## Act I — Session 1 Open: Audio Issues and Project Status (~20:03 – ~20:15) The session opened with sustained network and audio problems — SP was dropping repeatedly (moving between Wi-Fi and mobile data). The first substantive exchange happened around the 13-minute mark when connectivity stabilised. SP opened with a project-level status check and an uncomfortable observation: the team should have been **starting M4 (training module / RB admin)** by now, but was still in **M3**. The delay was acknowledged without a detailed root-cause analysis at this point. SP's agenda items: 1. Current milestone status and gap to plan 2. Architecture diagram — is it up to date with current implementation? 3. Tata Steel data challenges — specifically Pawan's ability to understand the data independently --- ## Act II — Data Credibility: Static Figures on the Landing Page (~20:16 – ~20:26) SP surfaced a concern about the landing page static figures. The displayed "286 billion total project cost" (likely appearing as 28.6 in the UI) was suspected to be a design placeholder rather than a live query result. RG clarified: the UX design had provided a representative figure and the team had built queries around it (planned cost, actual cost, variance — queries running over ~14-day and ~13-day windows). The exact figure needed verification. SP pressed on the data accuracy gap: the demo audience was expert Tata Steel stakeholders who know their own data. If a question is answered with an incorrect or stale figure, the credibility of the entire system is undermined: > *"They are experts in that domain — they are familiar with the data — so they can ask more questions in depth. So that is where I think we need to upskill ourselves on how to understand the data."* > — SP _(~00:26)_ SP also noted the client feedback from the previous demo: "this is not the UI that I was expecting — we were expecting even better — but considering the time constraint, this is what we could deliver." --- ## Act III — Debug Mode Proposal: SQL Citations on the UI (~20:28 – ~20:30) YR proposed a practical short-term transparency feature: for every answer rendered, show the SQL query that produced it — similar to how Wikipedia shows citations. > *"Whenever something is getting calculated, debug mode — if we show on the UI which SQL was responsible for it — just like Wikipedia after everything it says citations — something like that if we can do, at least for the time being for debugging."* > — YR _(~00:28)_ RG extended this: also show which tables were referenced, not just the SQL text. This would let internal teams validate correctness without opening the database directly. AB joined and demonstrated a feature he had been working on: showing the SQL query and its description as a collapsible attribution panel under each visualisation — effectively what YR had just described. YR noted this was exactly right, and asked AB to extend it to include "what is being extracted, what are the assumptions behind the SQL query." --- ## Act IV — QA Gap: No Formal Testing Framework (~20:40 – ~20:44) SP raised a concern about testing. A question had come from the NSL sales team: "How are you testing your applications?" The answer was uncomfortable — formal QA was not happening. Only prompts were being tested informally. > *"We know what to be tested but we don't have the timelines. So — we know but we don't have the timelines."* > — SP _(~00:40)_ YR introduced LangSmith (referred to as "log fryer" / "log fire" in transcript) as a framework that supports capturing interactions and converting them into test cases with one click: > *"Framework like — literally once it collects a log, we can click on it and say 'make this a test case.' Someone can explore it — like firefighting — either this or they can explore this."* > — YR _(~00:43)_ The suggestion was to have Arshit (or another engineer not in firefighting mode) explore LangSmith / DeepEval as the automated testing foundation. AB demonstrated adding a query to a LangSmith dataset live: query → expected output (7 widgets generated, specific answer content) → save as a test case. YR asked AB to build out this dataset with more queries. --- ## Act V — Demo Process and Leadership Expectations (~20:45 – ~20:55) This section contained the most direct organisational friction of the meeting. YR described the pattern of being told about a demo at the last minute and having to improvise: > *"Now I'm realising — after speaking with you — that's not at all a good spot to put our engineers in."* > — YR _(~00:45)_ SP agreed, noting the team was exposing its most vulnerable state to clients: > *"You are exposing your most vulnerable spot there — which you never wanted to do. It also projects our capabilities in a wrong way."* > — SP _(~00:45)_ YR and SP agreed that either YR or SP needed to have a conversation with Navana (senior leadership) to establish a minimum demo notification window. The consensus: at least 2–3 days' notice was needed so the team could prepare a stable version rather than demo whatever was in progress. SP also described the ideal squad structure: **1–2 engineers on NSL, 1–2 on Tata Steel, 1–2 on core development** — all progressing in parallel rather than the whole team pivoting to whichever client is demanding attention at that moment. > *"We had to halt core development because we had to work on NSL or we had to work on data. Everybody jumped on to this. But the expectation is that one or two people are working on NSL, one or two people are working on data, one or two people are working on core."* > — SP _(~00:52)_ --- ## Act VI — Architecture Direction: LLM-Driven Layout, Prompts to DB (~20:38 – ~20:40) RG raised a deeper architectural concern: the frontend currently renders whatever the backend sends, but the backend decides layout as well as content. Multiple graph types were being emitted, and the frontend had no agency over layout composition. RG wanted the backend (specifically the UI agent) to also specify layout — how multiple graphs should be arranged. YR connected this to the broader issue he had been working on over the weekend: moving prompts from `.py` files to `.txt` or `.md` files, and introducing skills into the pipeline. Through that refactoring process he had discovered the static dashboard and other structural fragilities. He planned to continue code review on the branch PG had shared. --- ## Act VII — Session 2 (22:10): Confidence Scoring and Attribution Design (~22:10 – ~22:38) The second session opened with PG and YR reviewing the **confidence scoring and internet attribution** problems in more depth. Naveen Puttagunta also joined partway through. **Dashboard figure accuracy:** PG opened with concern about the 26.5 million off-plan figure. YR cut to the root issue quickly: > *"It's not just that the 26.5 is bad — the whole approach is fragile. The whole UI approach is fragile because design has hardcoded those figures and animations. We have to come up with a way to make it more generic and personalised and LLM-driven."* > — YR _(~00:19)_ **Confidence scoring — simplified approach confirmed:** YR proposed a concrete UI approach: wrap each rendered response packet in a border rectangle — **green border if from DB, orange border if from internet**. No numerical percentages at this stage; that comes after design weighs in. PG raised a complication: some responses blend DB data with internet data in the same section (key highlights, for example). YR's answer: don't ask the LLM for a confidence percentage — it's unreliable. Use a deterministic rule: > *"If it is from an SQL query directly — we'll simply make it 100%. If it is from internet search — somehow you have to figure out a way to put a number on it."* > — YR _(~00:28)_ Internet confidence was not to be left to the LLM's self-assessment. Instead, YR described a document that needs to be written — a **confidence and internet search strategy document** — covering: - What is the correct search strategy per question type? - Which domains are whitelisted / blacklisted? - What confidence level does each tier of source warrant? Until that document is written and agreed by Naveen and Rakkesh, the working default is **75% confidence for any internet-sourced content**. **Attribution — show all internet sources:** YR pushed hard on this: > *"Attribution is very important when it's searching so many websites and giving an answer — have a similar drop-down of all the links that it searched — ideally in the order of most important information — whatever information it surfaced I want those web pages at the very top that are most relevant."* > — YR _(~00:36)_ YR noted he had observed LangSmith do 20–30 searches to produce 2–3 paragraphs, which raised doubts about synthesis quality. Showing attribution would also build credibility — users can see the system didn't hallucinate. --- ## Act VIII — Session 2: Naveen on Answer Quality and Pilot Regression (~22:40 – ~22:44) NP joined and raised a qualitative concern that went beyond the confidence/attribution thread. In the earlier pilot version of Enterprise Brain (before the current structured-widget format was enforced), the system had given impressively rich, textual answers. As an example, NP recalled Vijay (a US-based stakeholder) asking about standard deviation on the visual defect analysis dataset, and the system had answered precisely and analytically without being told to format the response in any particular way. NP's hypothesis: the current format constraints (key highlights, key insights, specific widget sequence) were **over-prescribing the output** and producing dry, constrained answers that felt inferior to the earlier pilot. > *"I'm wondering whether we are restricting and prescribing the format too rigidly — that you have to stick with a key highlight, a key insight, then this, then that — and it is just very constrained and giving very dry results. I wonder if we can experiment a little — loosen it up where it has a little bit more freedom — then at display time say, if there is too much text, how do we convert it into a visual."* > — NP _(~00:40)_ YR agreed with the direction but wanted to start from a measured baseline: > *"We need to understand the baseline before attempting that. These are the questions. These are the answers currently answered. This is the baseline. Now, how can we improve it?"* > — YR _(~00:41)_ YR asked NP to contribute a set of questions he would ask the Coutilia (NSL Salesforce) system, along with expected answers, to seed the test dataset. --- ## Act IX — Session 2: Tata Steel Expertise and Deployment (~22:44 – ~22:51) NP noted that he had gotten stuck on the Tata Steel data because answers were inconsistent (e.g., variance always returned zero, only one project found). He had abandoned deeper exploration as a result. YR was direct with PG about the expectation going forward: > *"Pan — there is no other choice. Unfortunately you have to become the Tata Steel data expert. If it so happens that you have to offload coding activities to Amolya, Harshit, and Abhilash — so be it. I want you to take more responsibility from the business side."* > — YR _(~00:47)_ NP requested that the current Coutilia changes be deployed to **chanaka.com** (replacing the dummy Salesforce data that was currently there), so NP could do hands-on testing. PG confirmed deployment would happen within ~30–60 minutes and would notify NP when ready. The session closed with a 7:30 PM review meeting confirmed for that evening. --- ## Todos - [ ] Update architecture diagram to reflect current implementation | author: Rajashekar G | deadline: unspecified - [ ] Validate landing page figures (26.5M / 28.6B) against actual DB queries; confirm which are live vs design placeholders | author: Phawhan Saii Gajjalakonda | deadline: unspecified - [ ] Add SQL citation / attribution panel (collapsible) under each response widget — show SQL, tables referenced, and assumptions | author: Abhilash Adunuri | deadline: unspecified - [ ] Explore LangSmith / DeepEval as automated testing framework; build initial dataset of questions + expected outputs for Tata Steel | author: Abhilash Adunuri | deadline: unspecified - [ ] Write internet search strategy and confidence document: search strategy per question type, whitelisted/blacklisted domains, per-source confidence tiers — get approval from Naveen and Rakkesh | author: Phawhan Saii Gajjalakonda | deadline: unspecified - [ ] Implement confidence UI: green border (DB-sourced), orange border (internet-sourced) — placeholder until design provides final spec | author: Phawhan Saii Gajjalakonda | deadline: unspecified - [ ] Show internet attribution drop-down: all URLs searched, ranked by relevance to the answer | author: Phawhan Saii Gajjalakonda | deadline: unspecified - [ ] Build baseline test dataset from current Enterprise Brain queries for Tata Steel: questions, current answers, expected answers | author: Yeshwanth Reddy Yerraguntla | deadline: unspecified - [ ] Pawan to become Tata Steel domain expert: read EWC session recording, study data model document, understand entity-to-report mapping | author: Phawhan Saii Gajjalakonda | deadline: unspecified - [ ] Deploy Coutilia (NSL Salesforce) changes to chanaka.com — replace dummy Salesforce data | author: Phawhan Saii Gajjalakonda | deadline: 2026-04-27 (same day, within 1 hour) - [ ] NP to spend 1 hour on Coutilia — ask deep business questions, document where system goes wrong | author: Naveen Puttagunta | deadline: unspecified - [ ] Establish squad track structure: 1–2 engineers per track (NSL, Tata Steel, core dev) to avoid full-team context switching | author: Satyasri Prabhakar Mantripragada | deadline: unspecified - [ ] Talk with Navana about minimum demo notification window (at least 2–3 days) | author: Yeshwanth Reddy Yerraguntla | deadline: unspecified - [ ] Move agent prompts from .py files to .txt / .md; continue code review on PG's branch | author: Yeshwanth Reddy Yerraguntla | deadline: unspecified - [ ] Review evening session at 7:30 PM — Enterprise Brain progress review | author: Group | deadline: 2026-04-27 (same day)