# Minutes of Meeting - Enterprise Brain
**Date:** February 26, 2026
**Source transcripts:** [Feb 26, 2026.txt](Feb%2026,%202026.txt), [Feb 26, 2026-2.txt](Feb%2026,%202026-2.txt)
The day had two linked threads: a product-demo discussion about whether the synthetic manufacturing data was credible enough, and a deeper architecture discussion about how Enterprise Brain should distinguish snapshots, learned behavior, runbooks, skills, and user preferences. The shared conclusion was that the system has to become more proactive without turning every fact into permanent memory.
**Recording note:** The source transcript is not continuous. The first captured segment ends around `00:06:56`, and the next captured segment resumes at `00:19:50`, so the gap in between reflects missing transcript coverage rather than omitted summary content. There are also smaller later timestamp jumps inside the same source file.
## Act I - Morning demo calibration (00:00 – 06:56)
The first session was a reality check on the manufacturing demo. The team agreed that a single trivial CSV would look too thin, so they explored combining multiple sources and adding richer dimensions like quality, reliability, safety, productivity, defect type, and machine context. The point was not just to show charts; it was to show a story that feels operational.
> *"We should pick up the easy ones."*
> — Yeshwanth Reddy Yerraguntla _(~00:00:00)_
> *"we will be showing something trivial only"*
> — Yeshwanth Reddy Yerraguntla _(~00:02:39)_
That led into a calibration of the business questions. The team kept circling back to efficiency, yield, defect rate, predictive maintenance, and plant utilization, with the understanding that some fields may need to be artificially added so the demo can tell a better business story without pretending to be a production dataset.
## Act II - Afternoon continuation and the risk of fake causality (19:50 – 26:20)
When the conversation resumed later in the day, the team got more serious about what the synthetic evidence could safely claim. Rajashekar pushed on whether the simulated root-cause logic could be mistaken for a real plant conclusion, and the discussion turned into a defense of what is safe to claim and what is only illustrative.
> *"the manufacturing people will say this is not the root cause"*
> — Rajashekar G _(~00:20:48)_
That led to a tighter business frame. The demo can answer questions about defect patterns, repeated errors, and machine IDs, but it should not overclaim on actual production causality. The transcript explicitly moved away from pretending that every simulated image and every root cause are literally true for a plant.
## Act III - Modeling choices and response styles (26:20 – 35:33)
The next stretch sharpened how the system should answer manufacturing questions. The team discussed whether the right answer format is static analysis, predictive explanation, or a layered model that chooses a different method based on the question.
Rajashekar pushed the point that some questions are just summarization, while others need correlation or prediction. Yeshwanth accepted that split and kept the model discussion grounded in the type of question being asked rather than assuming one ML model should handle everything.
## Act IV - Memory, preferences, and immutable updates (35:33 – 42:46)
The architecture discussion then got more precise about memory. The group separated transient snapshots from durable learning: runbooks, skills, and source-specific instructions are where the system should learn how to behave, while the knowledge graph should retain only useful, durable signal.
> *"The knowledge graph should not be permanent."*
> — Yeshwanth Reddy Yerraguntla _(~00:42:46)_
That distinction mattered because the system is supposed to evolve. Yeshwanth and Rajashekar kept returning to the idea that user preferences, alert routing, and sentiment are source-specific or user-specific signals, not generic facts the whole platform should treat equally. The database should be able to evolve, but not by naively replacing everything in place.
The team also worked through the idea of a refresh loop and a proactive agent. The agent should not just answer questions; it should periodically pull the latest state, compare it to the prior snapshot, and surface what changed, what regressed, and what is worth escalating.
## Act V - Source-agent design and environment boundaries (42:46 – end)
The final part of the discussion was about making the architecture testable in smaller pieces. The team agreed to start with the simplest source and then work outward, rather than trying to design the perfect dynamic system before any implementation exists. They also clarified the environment split so dev work can stay on staging before promotion to production.
> *"Enterprisebrain.dewami.com is the production environment."*
> — Satyasri Prabhakar Mantripragada _(~00:43:08)_
By the end of the call, the team had a sharper definition of what should be refreshed, what should be learned, and what should only be remembered as a snapshot. The open question is not whether the system can answer questions; it is how it should decide what is important enough to remember and what is just transient noise.
## Todos
Finalize the manufacturing demo scope with stronger multi-source data and clearer business questions
Yeshwanth / Rajashekar Next review
Separate snapshots, runbooks, skills, and learning signals in the architecture so only durable knowledge is retained
Yeshwanth / Rajashekar / Gopal Next architecture session
Decide the first small implementation slice for the realtime agent and validate it against a real source
Rajashekar / Manisha / Abhilash Next working session
Keep staging and production separated so new work lands on chanaka before promotion to enterprisebrain.dewami.com
Rajashekar / team leads Ongoing