--- meeting: Enterprise Brain Scrum date: 2026-04-01 participants: - Yeshwanth Reddy Yerraguntla - Rajashekar G - Vara Kumar Jagarapu duration: ~18:00 transcript: 20260401-1.txt --- # Enterprise Brain Scrum — April 1, 2026 A focused scrum addressing deployment status, UI agent architecture, LLM evaluation strategy, training lifecycle planning, and the design team's code generation workflow. The meeting established the responsibility separation between data source agents and UI agents for visualization decisions, discussed evaluation methodology with Navin's input on reliability testing, and planned the repository handoff to the design team. ## Act I - Deployment and UI Agent Architecture (~00:00:00 - ~00:09:01) Rajashekar reported successful deployment of enterprisebrain.zoomi.com and gomi.com. Testing with the data sheet is working well, with visualizations coming from Ganesh's experience center package. However, the actual designs haven't been PM-reviewed yet—the design team is still revamping and showed yesterday's work to PM. The critical architectural discussion centered on the UI agent's role. Navin's suggestion from yesterday: the team could branch their repository and hand it to the design team for them to work on top of, avoiding the friction of consuming poorly structured design team code. > _"we can give our repository to them by pulling a branch out of it. So Tim tinker on top of this."_ > — Rajashekar G _(~00:11:33)_ Rajashekar then raised the UI agent question. Yeshwanth confirmed it sits in the backend (same Enterprise Brain repo), receiving information about which user it's serving and their preferences, then deciding which visualizations to send to the UI. Rajashekar clarified the current limitation: they're not yet dealing with user preferences. The immediate scope is simpler but foundational: > _"right now data source agent itself taking the decision based on the question based on the answer like which kind of visualization it need to render and it is telling the client sending it type chart uh type pie chart type bar graph it is sending right now that responsibility should be removed from the data source agent that should be kept on the user interface agent."_ > — Rajashekar G _(~00:13:30)_ The architectural evolution: 1. **Current state**: Data source agent decides visualization type and sends it directly to client 2. **Target state (Phase 1)**: User asks question → RT agent queries data source agent → Data source returns raw data → RT agent passes question + answer to UI agent → UI agent decides visualization type 3. **Future state (Phase 2)**: Combine multiple widgets, add interactivity Yeshwanth validated the logic—this is the correct sequencing. First solve the responsibility separation, then layer in user preferences and advanced dashboard composition. ## Act II - Evaluation Strategy and Reliability Testing (~00:09:01 - ~00:14:30) The evaluation discussion began with LLM evaluation requirements. Yeshwanth emphasized that before worrying about evaluation methodology, the team must focus on the question dataset—what questions will be asked, and what are the expected answers. Vara Kumar brought up Navin's input from a recent discussion: reliability testing through consistency evaluation. The concept: ask the same question to three different LLMs. If all three agree on the answer, confidence increases that the underlying answer is correct. This is particularly critical for high-stakes domains like medical information where false positives are more dangerous than incomplete answers. > _"if there any contradiction between those answers then we can conclude something like there is something wrong uh from one of the agent Right? uh they taking an example for example uh uh the customers right so they're not worried about if they didn't get some I mean complete answer but they're worried about a wrong answer"_ > — Vara Kumar Jagarapu _(~00:08:26)_ Yeshwanth acknowledged consistency evaluation as a common paradigm in LLM evaluation but redirected focus: the critical unknown is the question set. Once they have the dataset, evaluating (via consistency or any other method) is only a few hours of work. Rajashekar's concern: the questions from Solv.it are generating correct answers now, but the business intent expectations from Navin and Prabhakar may differ from those test questions. Yeshwanth reframed the situation sharply: > _"You you evaluated it and it is working. It's just that what we evaluated against is not what they were expecting. So get a sign off from Prabhakar with the same questions. Simple. We'll escalate this saying this is what we tested on. This is what was the report. If there is a gap then the gap is uh in our understanding not in the execution."_ > — Yeshwanth Reddy Yerraguntla _(~00:11:40)_ This shifts accountability appropriately—if stakeholders didn't validate the test questions beforehand, any gap is a requirements clarification issue, not an execution failure. Rajashekar also flagged data quality gaps: many columns have null values, which affect query results. This needs investigation and discussion with stakeholders. ## Act III - Training Lifecycle and Design Team Collaboration (~00:14:30 - ~00:18:00) Rajashekar mentioned training lifecycle planning needs to happen today—no concrete design exists yet for this sprint's deliverable. Yeshwanth suggested minimum viable implementation: generate basic code demonstrating learning with mock data by end of day. The target outcome: launch a command, ask a question, see a change in the database (or system prompt) proving the system is learning. System prompt modification is acceptable for the POC. > _"aim for today just that you launch this command you ask this question this changes in the database because it is learning yeah system prompt is also fine"_ > — Yeshwanth Reddy Yerraguntla _(~00:10:40)_ The implementation path: extract system prompt into a text file, make Python load the text file, provide a mechanism to edit the text file, and demonstrate the learning workflow. If this can't be demonstrated today, there won't be time in the remaining four days to clean it up for Friday delivery. Rajashekar also reported a Saturday call about integrating the Infinithesim database with Enterprise Brain. Wernut requested the connection. The team created another data source agent, migrated everything from the previous repository (business context, etc.), hardcoded program IDs temporarily, and verified responses are coming through. He needs to understand requirements today to prioritize between Tata Steel and Infinithesim work—if needed, he'll assign a dedicated person. Yeshwanth acknowledged it's just one more connector. Rajashekar confirmed they're keeping it in a separate branch initially; if both need to be in the same deployment, they'll merge, otherwise separate deployments. The design team workflow: they're using Cursor or Claude to generate code. Previously their frontend repository structure wasn't production-ready, so Amulya sat with them, provided inputs, helped them set up Claude rules, and they refactored. Navin's suggestion to give them a branched repo eliminates that friction entirely. ## Todos - [ ] Remove visualization decision responsibility from data source agents and implement UI agent layer for visualization type decisions | author: Rajashekar G, Team | deadline: 2026-04-04 - [ ] Get stakeholder sign-off on evaluation question dataset (escalate gaps as requirements clarification, not execution failure) | author: Rajashekar G, Prabhakar | deadline: 2026-04-02 - [ ] Investigate and document data quality gaps (null values, missing columns) with stakeholders | author: Rajashekar G | deadline: 2026-04-02 - [ ] Demonstrate minimum viable training lifecycle POC (system prompt modification via text file) by EOD | author: Rajashekar G | deadline: 2026-04-01 - [ ] Clarify Infinithesim integration requirements and prioritize against Tata Steel work | author: Rajashekar G, Wernut | deadline: 2026-04-02 - [ ] Branch repository and provide to design team for direct development | author: Rajashekar G, Team | deadline: 2026-04-02