# Enterprise Brain Scrum MOM

## Context

- Meeting: Enterprise Brain Scrum
- Transcript date: Mar 17, 2026
- Transcript start: ~19:56 PDT
- Source: [eb-scrum-doc1.txt](eb-scrum-doc1.txt)

## Act I - 00:00 to 00:07, access friction and sprint-board orientation

The meeting opened with access noise and screen-sharing checks. Yeshwanth and Vara were making sure the right people could see the board and that the team was not blocked by something as basic as permissions. Once that was settled, the conversation quickly moved from setup issues to the sprint board and the question of how the current work should actually be grouped.

> *"Let me share my screen."*
> — Yeshwanth Reddy Yerraguntla _(~00:00:00)_

Rajashekar then walked the team through the current sprint structure and the current work items. The important point was not just who was doing what, but whether the team was still trying to solve too many unconnected things in parallel. Yeshwanth wanted the team to treat the board as a shared operating surface rather than a passive status list.

## Act II - 00:07 to 00:17, close the clarity gaps before opening more work

The next stretch focused on the knowledge-base work and the open design questions around org snapshot and knowledge graph. Rajashekar noted that Abhilash had already completed the knowledge-base setup and CRUD work, and the next move was to finish the LLD for the next slice rather than blurring design and implementation together.

> *"What is the name of the current sprint?"*
> — Yeshwanth Reddy Yerraguntla _(~00:05:39)_

The discussion made the team stop and separate the exploration story from the implementation story. The current ticket should be the place where the clarity is created, and only after that should the team break into the next layer of tickets.

## Act III - 00:17 to 00:29, org snapshot becomes the central design question

The longest part of the meeting centered on how to represent the org snapshot. Rajashekar explained the need for project-level summaries, CEO-level views, and the ability to pull different slices for sales, engineering, or design. Yeshwanth steered the team toward separation by bucket rather than a single mixed inbox dump.

> *"You have to put them in separate buckets."*
> — Yeshwanth Reddy Yerraguntla _(~00:21:16)_

That led to the simpler working idea that a project should have its own text file and that the team can think about date and topic as the first organizing dimensions. It is intentionally crude, but it gives the team something to generate and something to reason over before they move toward a more structured representation.

## Act IV - 00:29 to 00:39, structure, metadata, and RBAC

The discussion then moved from plain text to what metadata should ride along with each bucket. The team explored tags, provenance, sender/receiver information, and whether the snapshot should remain fully open or be filtered by role and sensitivity later. Yeshwanth pushed hard on the idea that the snapshot itself should not be the place where filtering happens.

> *"We will not put any filter at the snapshot level."*
> — Yeshwanth Reddy Yerraguntla _(~00:39:09)_

Instead, the snapshot should hold everything needed for later routing, and the user-aware layer should decide what each person is allowed to see. That lets the system preserve enough context to tell a story while still keeping RBAC and source-specific privacy controls in a later stage of the pipeline.

## Act V - 00:39 to 00:58, alerts, sentiment, and the next control point

The final stretch covered alert life cycle and how Gmail should be treated as a source with its own analysis needs. The team discussed sentiment scoring, escalation signals, and the possibility of a natural-language analysis module that runs during sync and tags incoming data with the right indicators. The core idea was that data source agents should enrich data, but the RT agent should still decide how to synthesize that information into a user-facing story.

The meeting closed with a reminder that the real goal of the snapshot is to let each bucket read like a coherent story and remain independent of the others. That gave the team a workable direction for the next iteration: keep the snapshot text-first, attach metadata and sensitivity markers, and let the later routing layer enforce visibility.

## Todos

<todo>
  Complete the org snapshot and knowledge-base LLD before starting implementation so the team can close the design story first.<br/>
  <span class="owner">Abhilash Adunuri / Rajashekar G</span>
  <span class="deadline">Next working session</span>
</todo>

<todo>
  Define the source-agent schema separation cleanly for RT agent vs data source agents so the same database is not reused as one shared schema.<br/>
  <span class="owner">Yeshwanth Reddy Yerraguntla</span>
  <span class="deadline">Next architecture update</span>
</todo>

<todo>
  Finish the scaffold logic that creates source-specific schemas, prompt references, and supporting folders when a new data source agent is launched.<br/>
  <span class="owner">Rajashekar G / Abhilash Adunuri</span>
  <span class="deadline">Next implementation pass</span>
</todo>

<todo>
  Decide which enrichment signals the data source agent should own at sync time, including labels, sentiment, and source-specific metadata.<br/>
  <span class="owner">Amulya Maggidi / Rajashekar G</span>
  <span class="deadline">Next sprint planning</span>
</todo>