# Minutes of Meeting: Enterprise Brain Scrum

**Date:** March 16, 2026  
**Participants:** Abhilash Adunuri, Rajashekar G, Amulya Maggidi, Yeshwanth Reddy Yerraguntla, Manisha Gundapuneedi, Mannam Sai Anitha, Kalakonda Harshith Rao  
**Transcript:** [Mar 16, 2026.txt](Mar%2016,%202026.txt)

## Act I - 00:00 to 00:08, sprint math, capacity, and branch hygiene

The meeting opened on plain sprint logistics. Rajashekar explained that the sprint is split into two parts and that the team is being measured against a weekly story-point target of about 74 points by March 27, with an expectation of roughly seven hours of effort per person per day. That set the tone: this is a capacity-managed sprint, not an open-ended architecture discussion.

> *"We need to come around 74 story points."*
> — Rajashekar G _(~00:06:53)_

Updates then moved quickly across the board. Ganesh stayed on his current work, Anitha was validating dashboard and chart integration, and the docs were being moved into the `chanaka/alpha` branch via PRs so the documentation surface stays centralized. Yeshwanth reinforced that document changes should flow through a normal PR process, not ad hoc edits in isolated branches.

## Act II - 00:08 to 00:15, separate the real-time agent from the data source agents

The next stretch was about repo discipline and knowledge-base structure. Yeshwanth kept repeating that the RT agent and data source agents should not share the same schema, even if they live in the same database. Each data source agent gets its own schema and its own tables for world model, concepts, runbooks, and skills.

> *"Data source agents will have their own schema."*
> — Yeshwanth Reddy Yerraguntla _(~00:13:11)_

That distinction led to a useful clarification: concepts are the technical side of the world, while the world model is the business interpretation. For Jira or Salesforce, concepts capture the technical schema, while the world model captures what Diwami, the projects, and the people actually mean in business terms. For the RT agent, the concept layer may start empty, because the first thing it needs is a usable understanding of the organization rather than source-specific technical detail.

## Act III - 00:15 to 00:29, snapshot design and the decision to stay text-first

The meeting then shifted to the org snapshot. The team debated whether the snapshot should be a graph, a structured table, or a simple text artifact. Yeshwanth chose the simplest possible starting point: one text file per project, with the latest information written into a raw-text column or equivalent storage, and more structure added only after the v1 proves useful.

> *"The snapshot could be one text file."*
> — Yeshwanth Reddy Yerraguntla _(~00:23:07)_

The key point was not the storage format itself, but the habit of thinking in terms of purpose and examples. The LLD should state what the snapshot is for, what questions it should answer, and how it will be tested. The team agreed that this document also needs functional and non-functional requirements near the top, plus a testing section at the end, so the business side can sanity-check the design instead of reading raw implementation notes.

## Act IV - 00:29 to 00:39, alerts, enrichment, and the role of the source agent

The middle of the meeting moved from static design into runtime behavior. Amulya asked why alert handling appears in both the core agent work and the data source agent work, and Yeshwanth explained that data source agents detect and summarize signals, while the RT agent synthesizes them into a coherent story before the user-aware layer routes it to the right person.

> *"The alert should be all about like what was happening since 2 days?"*
> — Yeshwanth Reddy Yerraguntla _(~00:39:09)_

That same logic drove the privacy discussion. Gmail is sensitive enough that access may need toggles and role-aware restrictions, while Jira or Salesforce can be treated more openly if the source does not require the same controls. The data source agent should enrich records at sync time, but the RT layer should still be the thing that decides how to present the story to the user.

## Act V - 00:39 to 00:46, UI dependency and close

On the UI side, the group was still undecided about Copilot Kit: it may speed up the chart and chat experience, but the team wanted Ganesh and Manisha to confirm whether the dependency is worth it before they commit to it. The meeting ended without a final UI call, but with a much clearer split between data, snapshot, privacy, and experience responsibilities.

## Todos

<todo>
  Move all documentation into the `chanaka/alpha` branch via PRs instead of leaving it scattered across custom branches.<br/>
  <span class="owner">Team</span>
  <span class="deadline">Immediate</span>
</todo>

<todo>
  Roll out Gmail integration to the internal demo users Pratam, Naveen, and Gopal for the Friday demo.<br/>
  <span class="owner">Pawan / rollout owner</span>
  <span class="deadline">March 20, 2026</span>
</todo>

<todo>
  Update the Alert Lifecycle LLD with functional and non-functional requirements plus testing criteria at the top and bottom of the document.<br/>
  <span class="owner">Amulya / Harshith</span>
  <span class="deadline">Next scrum</span>
</todo>

<todo>
  Decide whether Copilot Kit should stay in the UI stack after Ganesh and Manisha consult with Gopal or Prabhu.<br/>
  <span class="owner">Ganesh / Manisha</span>
  <span class="deadline">Next scrum</span>
</todo>

<todo>
  Implement separate Postgres schemas for each data source agent's knowledge base, including world model, concepts, runbooks, and skills.<br/>
  <span class="owner">Abhilash</span>
  <span class="deadline">End of sprint</span>
</todo>

<todo>
  Define escalation rules and payload formats for data source agents so the RT agent can synthesize alerts and route them cleanly.<br/>
  <span class="owner">Amulya</span>
  <span class="deadline">Next scrum</span>
</todo>