# Enterprise Brain Scrum MOM ## Context - **Meeting:** Enterprise Brain Scrum - **Date:** March 22, 2026 · 7:58 PM PDT - **Duration:** ~1 hr 4 min - **Attendees:** Yeshwanth Reddy Yerraguntla, Vara Kumar Jagarapu, Manisha Gundapuneedi, Satyasri Prabhakar Mantripragada (joined ~00:51) - **Transcript:** [20260322.txt](20260322.txt) - **Chat log:** Drive file `1-mNjVB6yeXGyI7-OFTKMO3IGW2hc2QRc` (Enterprise Brain Scrum - 2026/03/22 19:58 PDT - Chat) - **Notes doc (Gemini):** [Google Doc](https://docs.google.com/document/d/10s09gIBhTepMzwG78SoGUKgGY6FZrIYywPyOZm0Iiqw/edit) - **Source email:** [Gmail](https://mail.google.com/mail/u/0/#all/19d190398d86e0cd) · ID `19d190398d86e0cd` --- ## Act I — 00:07 to 00:22 · Data flow architecture, user scope, and the privacy constraint The session opened with Yeshwanth walking Vara through the proposed end-to-end data flow for email processing. The design is pipeline shaped: Gmail sync connects to per-user tables, a Data Source Agent consumes those tables to produce project-level summaries, and a Real-Time Agent (RTA) consumes those summaries to push a finalised snapshot to the organisation view. > *"Data sync connects to Gmail. Each user data is independently stored in Gmail tables. Data source agent processes the synced data and prepares… user produces unified project level snapshot… pushes finalized snapshot to organization."* > — Yeshwanth Reddy Yerraguntla _(~00:07:14)_ The core privacy rule was established early and repeated throughout: the full email body is never stored. What is stored per email is a structured summary containing bullet points, sentiment, project tags, type/category tags, participant list, and a short summary field. Vara confirmed this is also sufficient from an encryption standpoint since no raw content survives the ingestion step. > *"We will never store the full mail anyway."* > — Yeshwanth Reddy Yerraguntla _(~00:09:37)_ The team also disposed of the "what if it's Slack?" question quickly: email is fundamentally user-scoped in a way that Slack workspaces are not, so the per-user loop model is the correct primitive here and doesn't need to generalise further for v1. The chat transcript corroborated the design with pseudocode Yeshwanth posted to [DEB-345](https://divami.atlassian.net/browse/DEB-345?focusedCommentId=42216) during the meeting: ``` # Step 1 — collect all_mails = set() for user in org: all_mails.add(user.mails) # Step 2 — per-email summary with structured tags Email N → Summary( Bullets([point #finance, point #deadline, point #bug, …]), users=[…], project=proj_X, sentiment=…, tags=[…] ) # Step 3 — group by project Summary for proj_X → union of all email bullets for that project # Step 4 — store in DB, send row references to RT Agent ``` --- ## Act II — 00:22 to 00:28 · Multi-item emails and bullet-point structure A nuance arose around emails that carry more than one significant piece of information — for example a single client email that announces a go-live date, quotes a budget figure, and attaches a signed agreement. Yeshwanth argued that the per-email summary should model this explicitly by producing multiple tagged bullet points rather than a single text block. > *"In the form of bullet points, bullet one hashtag — you can start tracking for sensitive information. Finance, deadline — because a single event can have multiple things, or because we are aggregating we'll have multiple items."* > — Yeshwanth Reddy Yerraguntla _(~00:22:23)_ The tagging strategy (`#finance`, `#deadline`, `#bug`, etc.) serves two purposes: it lets the RTA group by category when it later reads the DB rows without re-reading every field, and it provides a lightweight signal for downstream notification and RBAC filtering. Vara confirmed the structure was clear. Privacy also follows naturally from the grouping step: when project-level summaries are assembled, the team already knows which email (and therefore which user) each bullet came from. The hashtag-based separation Yeshwanth proposed for approach-1 turns out to be redundant at step 3 because the recipient metadata already carries the separation needed. > *"You don't even need hashtags [at the project grouping stage]. Yes. So step one email, step two email, step [three] project — done."* > — Yeshwanth Reddy Yerraguntla _(~00:26:55 – 00:28:00)_ --- ## Act III — 00:28 to 00:40 · Token economy, DB references, and the inter-agent highway The heaviest part of the session was about how the Data Source Agent and the Real-Time Agent should exchange data without the token cost of passing a full email corpus in every cycle. Yeshwanth framed the problem clearly: passing summaries by value on every refresh cycle is wasteful and likely to exceed context windows at scale. The proposed solution is pass-by-reference: summaries are stored in the Data Source Agent's DB, and the RTA receives only the DB row-range references. The RTA can then use structured queries (group by hashtag, group by project) to read only the rows it needs. > *"Step four — store all summaries in a DB and send the DB row reference to the RT Agent. You will not send [the data] as in just do that."* > — Yeshwanth Reddy Yerraguntla _(~00:32:33)_ > *"If you send the DB reference to the real-time agent, you can inform the agent to first get the text summary of what is there — maybe group by bugs, group by hashtags — then read each at once and take more intelligent actions."* > — Yeshwanth Reddy Yerraguntla _(~00:34:36)_ Vara queried whether grouping by project makes more sense than grouping by user or team at this stage. Yeshwanth agreed and noted that project-level grouping is the minimum viable unit — finer-grained access control (by role, by tag) should live in the notification/delivery layer, not inside the snapshot itself. The shared DB tables also have a secondary benefit: they become a stable intermediate layer that other agents can access in the future, functioning like a "highway of communication" between autonomous services. > *"There has to be a highway of communication — almost like how organisations also work. Just now I created a bunch of comments for Abilash in Jira so he'll get a notification. This common place of storing information will help both of us to take it asynchronously."* > — Yeshwanth Reddy Yerraguntla _(~00:37:12 – 00:39:11)_ The tables should live inside the Data Source Agent's store but be treated as pseudo-public and accessible by the RTA. --- ## Act IV — 00:40 to 00:43 · Parallel ingestion and large-file skip policy Yeshwanth addressed scale directly: emails are independent by definition, so the ingestion step should spawn one process per email (or bounded batch) and process them in parallel. A cadenced run (e.g. every 5 minutes) that encounters a stuck task should not block — the next cadence will pick it up. > *"There are a thousand mails. Ideally we should spawn thousand processes to parallelly sync all of these things because each is by definition independent of everything else."* > — Yeshwanth Reddy Yerraguntla _(~00:41:01)_ For large attachments, the team agreed on a skip-first policy: if a PDF exceeds a practical page limit (the example used was 10,000 pages), the attachment is skipped entirely so the cadence is not exceeded. Vara raised Excel and password-protected files as additional edge cases. The resolution was: if the file size or description gives enough signal, take a skip-or-flag decision rather than attempting to process it; extraction from the subject/description line may be sufficient to record the existence of the attachment without reading its content. --- ## Act V — 00:43 to 00:51 · MLX Chat and GWS CLI — two tooling updates Yeshwanth shared two concrete tooling advances for the team. **MLX Chat (local LLM testing):** For Mac users, MLX Chat lets a developer run a quantised model locally. The benefit for this team is zero-cost test cycles — no API tokens consumed, no dependency on LiteLLM or any external provider during basic integration debugging. > *"So in a sense you don't need to rely on [any external provider] for doing basic testing. I write some code, I want to check that it is working or not — I open a fresh window and simply type. I don't want to waste tokens, so you can use MLX Chat."* > — Yeshwanth Reddy Yerraguntla _(~00:43:52)_ Setup is two steps: install the MLX server, set the environment variable, run the model. The existing Chanakya infrastructure will pick it up automatically via the `LITELLM_PROVIDER_BASE_URL` env. **GWS CLI (Gmail integration live):** Yeshwanth has completed a working Gmail integration using the `gws` CLI — a Google Workspace toolset built by Google developers and documented at `developers.google.com`. Chanakya can now query Yeshwanth's own inbox in real-time; basic queries and context propagation are confirmed working. > *"I made a few changes — I can use Chanakya to get to my own emails. If I ask 'what are my emails since 4 days' I'm getting [results]."* > — Yeshwanth Reddy Yerraguntla _(~00:46:56)_ The open question is organisation-wide access. The current GWS auth is OAuth for a single user. To cover the whole organisation, each user needs to individually consent to onboarding their inbox. Vara suggested this must be an explicit user-initiated step, not silent background auth. The team agreed the list of consented users will be maintained and only those users feed the pipeline. Vara noted that GWS CLI has some Gmail-specific issues but is the best available option in the current stack. --- ## Act VI — 00:51 to 01:04 · Sprint planning, demo prep, and Salesforce portal toggle Satyasri joined at approximately 00:51 and moved the meeting into sprint-management topics. **Connecting technical to functional deliverables:** Satyasri's primary ask was for Yeshwanth and Vara to help translate completed technical work into functional language that the product and business side can understand and validate. The velocity report (Palash to pull it) will be the starting point, but the framing must be functional. > *"I need both of your help in… connecting the technical deliverables to the functional deliverables, representing the technical deliverables in terms of functionality."* > — Satyasri Prabhakar Mantripragada _(~00:55:32)_ **Sprint discipline:** Mid-sprint tasks should be capped at 10–20% churn. Clarity on scope should arrive at the start of each sprint, not accumulate during it. **Team continuity:** Confirmation from "data series" (a related project) is expected early this week. If that confirmation comes, Rahul may be retained on the Enterprise Brain context rather than being reassigned. Satyasri will handle that coordination. **Documentation repo:** Yeshwanth committed to creating a GitHub repo with all project documents consolidated in one place by Thursday. **Salesforce / Experience Center portal merge:** Satyasri requested that the Salesforce-side experience centre and the Enterprise Brain portal be unified into one portal with a toggle — "classic view" for the existing experience and "intelligent dashboard" for Enterprise Brain behaviour. Vara noted that Venkat / Rajashekar is already working on this in the aging branch. **Validation standard:** For any feature declared done, the team must be able to point to a minimal, exhaustive list of test cases covering basic functionality. Jira tickets alone are not sufficient; actual test evidence is required before a team can claim confidence for customer delivery. > *"Whatever they are saying is done — we should be able to validate it. Have they taken care of all the cases? At least a minimal exhaustive list of basic functionality — as a team that should be good enough to give us confidence."* > — Satyasri Prabhakar Mantripragada _(~01:01:37)_ --- ## Todos Design and document the 4-step Gmail ingestion pipeline (fetch → per-email summary + tag → group by project → store in DB + send refs to RTA) as a formal architecture spec; attach to DEB-345.
Yeshwanth Reddy Yerraguntla This sprint Define the per-email DB schema: email-id, project, summary (bullets), hashtag list, sentiment, participants (to/from), timestamp. Confirm with Vara before implementation.
Vara Kumar Jagarapu This sprint Implement parallel email ingestion with cadence-aware skip logic: per-email independent workers, 5-min cadence, timeout-skip for stuck tasks, attachment skip for oversized files (>N pages).
Vara Kumar Jagarapu This sprint Research and document the org-wide Gmail access model: per-user OAuth consent flow, approved-user list, and whether a Google Workspace service account with domain-wide delegation is a viable alternative.
To be assigned — Manisha Gundapuneedi / Vara Kumar Jagarapu Next architecture review Create a GitHub repo and consolidate all Enterprise Brain project documentation in one place (applies to other active projects as well).
Yeshwanth Reddy Yerraguntla Thursday, March 26, 2026 Help Satyasri map completed technical deliverables to functional deliverables in product language, using the velocity report from Palash as a baseline.
Yeshwanth Reddy Yerraguntla, Vara Kumar Jagarapu Early next week (before next sprint planning) Confirm toggle / view-switcher status on aging branch with Venkat / Rajashekar and update Satyasri; ensure Jira ticket exists and test evidence is available before claiming done.
Vara Kumar Jagarapu This week Connect in the afternoon with the model (Vara's action item from the session).
Vara Kumar Jagarapu Today / Monday afternoon