# Enterprise Brain Scrum MOM ## Context - Meeting: Enterprise Brain Scrum - Transcript date: Mar 18, 2026 - Transcript start: ~19:58 PDT - Source: [eb-scrum-doc3.txt](eb-scrum-doc3.txt) - Note: the transcript has a short noisy opening fragment, then resumes around ~00:13:10 for the main discussion. ## Act I - 00:13 to 00:19, repo standards and the toolchain baseline The evening scrum began with a short noisy opening and then moved into engineering hygiene. Yeshwanth laid out the repo baseline he wants the team to converge on: `uv` for package and environment management, Ruff for linting and formatting, and pytest for tests. The discussion was not philosophical; it was about making the repo behave predictably for every developer. > *"UV for both package management and environment management."* > — Yeshwanth Reddy Yerraguntla _(~00:13:10)_ Vara pressed on how the team should enforce those conventions. The answer was partly configuration and partly discipline, but the direction was clear: this repo should have repo-level guardrails rather than depending on each person's local habits. The team also discussed whether pre-commit should be part of that baseline so formatting and linting happen before changes reach review. ## Act II - 00:19 to 00:23, milestone one should prove the data path, not every source Once the toolchain question was parked, the meeting shifted back into product shape. The first milestone needs one source that proves the end-to-end path. Gmail was the strongest candidate, and the team agreed that if Gmail works properly, GDrive and GChat become much easier to reason about. > *"Which data source are we going to first fulfill in milestone one?"* > — Yeshwanth Reddy Yerraguntla _(~00:19:28)_ The harder question was how to collapse many user inboxes into something usable by the organization. Rajashekar pointed out the obvious scale problem: if ten users sync mail, the system must still understand which project each email belongs to and how those messages should contribute to the org snapshot. Yeshwanth answered by keeping the first version intentionally simple: bucket emails, summarize the bucket, and then let the RT agent consolidate the result. ## Act III - 00:23 to 00:31, snapshot design, structure, and the first privacy wall The long middle section focused on how to represent the org snapshot. Yeshwanth started from a plain-text model: one text file per project, with the latest information collected into a raw-text column or similar storage. The team can add structure later, but the v1 should be easy to reason about and easy to generate from the incoming data. > *"The snapshot could be one text file."* > — Yeshwanth Reddy Yerraguntla _(~00:23:07)_ The team then explored how much metadata should be carried along with each packet. Yeshwanth argued for source tags, people tags, and content-category tags so that future retrieval can be structured instead of arbitrary. The privacy discussion was equally direct: Gmail may need stricter access control, while Jira or Salesforce may be safe to open more broadly depending on the source and the customer context. ## Act IV - 00:31 to 00:40, buckets, tags, and the RBAC boundary The next step was to stop thinking about one giant inbox stream and start thinking in independent buckets. Each bucket can be processed on its own, which also means the work can be parallelized later if the scale demands it. Yeshwanth made the point 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:40 to 00:46, alerts are stories, not isolated flags The final topic was the alert path. The team clarified that data source agents should detect and summarize signals, but the RT agent must synthesize those signals into a coherent story before the user-aware layer decides where to route it. That means the alert output is not just "something happened"; it needs enough context to explain what changed and why the escalation matters. The meeting also left Copilot Kit unresolved. It may help the experience layer, especially for chat and chart components, but Ganesh and Manisha still needed to decide whether the dependency is worth it or whether the team should build the relevant pieces itself. The meeting ended without a final UI call, but with a much clearer split between data, snapshot, privacy, and experience responsibilities. ## Todos Standardize the repo toolchain around `uv`, Ruff, and pytest, and decide whether pre-commit or another guardrail should enforce it automatically.
Yeshwanth Reddy Yerraguntla / Vara Kumar Jagarapu Next repo setup pass Finalize the milestone-one source call, with Gmail as the primary candidate and GDrive / GChat as adjacent follow-ons once the Gmail path is stable.
Team leads Before milestone-one execution is locked Define the intermediate summary and bucketing flow for Gmail sync so high-volume inbox data can be grouped by project or topic before RT-agent consolidation.
Rajashekar G Next architecture iteration Clarify how item-level metadata, tags, provenance, and sensitivity markers should be stored so RBAC and source-specific privacy controls can be applied later.
Vara Kumar Jagarapu / Yeshwanth Reddy Yerraguntla Next org-snapshot design discussion Decide whether Copilot Kit stays in the UI stack or whether the team builds the chart and chat experience directly.
Ganesh / Manisha Next scrum