Enterprise Brain Scrum Invited Attachments Meeting records Summary Codebase review confirmed an operational agent structure utilizing mock data for efficient LLM strategy and pipeline validation. Codebase Structure and Agent Status The codebase is contained in the chanaka folder with four operational agents, 2 data sources, 1 real-time, and 1 user-aware, running on dedicated ports 8001 through 8003. All agents currently function exclusively with mock data, including emails, Jira tickets, and user preferences, which are filtered to create a "fake snapshot" for testing. LLM Strategy and Pipeline A small local LLM, quen 3.5, is employed for debugging to conserve tokens, ensuring the code pipeline functions before switching to Gemini Flash 3.0. The core Agent-to-Agent pipeline is operational, enabling the real-time agent to query data agents and synthesize generic responses. Frontend and Infrastructure A user-aware agent facilitates testing through an admin feature that allows faking users like Manisha, enabling personalized mock responses for queries such as 'Who am I'. Future development decided on integrating a single React application via the exposed websockets endpoint at /ws to the Real-Time agent, moving away from the current pylog interface.  Details Codebase Components and Agent Structure: The main code is located in the `chanaka` folder, and running `make UI` launches the agents. The current setup includes four agents: two data source agents (Gmail and Jira), one real-time agent, and one user-aware agent (00:00:00). Both Gmail and Jira agents are currently functioning with mock data, and each requires an `agent.py` file and a Docker file for manual deployment if needed (00:07:17). Agent Accessibility and Mock Data Implementation: Each agent has its own dedicated port, with Jira and Gmail agents running on ports 8001 and 8002, respectively, and the user-aware agent on port 8003 (00:07:17). Mock data for emails, Jira tickets, and user preferences (including projects and dashboard settings) is located in a specific directory, and a "fake snapshot" is created by filtering this mock data based on demand and specific dates (00:08:47). LLM Strategy and Constraints: The current setup uses a small, local model (quen 3.5) instead of Gemini Flash for debugging purposes, which helps conserve tokens and encourages efficient coding practices (00:10:16). The strategy is that if the code pipeline works efficiently with a smaller model, it is highly likely to function well when they eventually switch to Gemini Flash 3.0. This approach requires highly accurate LLM tool calls and instructions to compensate for the smaller model's limitations (00:11:40). Faking User Context for Testing: Although a user can log in with Google, they can utilize an administrative feature at `localhost:8010/admin` to fake a user, such as "Manisha," which subsequently reflects in the user-aware agent's responses (00:12:51). This capability allows them to test user-specific functionalities, like asking "Who am I" or "What is my briefing today," and receiving personalized (albeit mocked) responses (00:14:05). Agent-to-Agent Communication Pipeline: The core agent-to-agent (A2A) pipeline is operational, enabling the real-time agent to ask questions of the data source agents (Gmail and Jira) and synthesize the responses, making it capable of handling generic queries. Currently, this pipeline supports the ability to send metadata, such as which user is asking the question, but controls for "training mode" or "ad hoc mode" are pending (00:18:20). Data Source and Snapshot Status: Currently, both data agents and the user-aware agent fetch information from the mock data folder. The ability for the real-time intelligence agent to update the organization snapshot based on information from data agents is currently missing because they are still working exclusively with mock data (00:20:24). All agents are currently working on the pylog interface (00:21:51). Implementation Details for Agent Infrastructure: The base agent model is defined in `base.py` as `enterprise_agent`, which subclasses a pydantic responder to enable history retention and compatibility with the pylog UI (00:26:32). The `A2A_context` component is responsible for sending contextual information—such as the active user, company tenant details, and whether the user is a trainer—along with the question when a real-time agent communicates with a data agent (00:28:03). Next Steps for Development and Deployment: New agents can be created by following the `new_agent_guide` documentation, and deployment is managed through Docker commands, allowing for individual control over each agent's deployment (00:32:01). Configuration, including agent URLs and ports, is config-driven, and downstream data source agents must be launched before the main `chanaka` agent (00:33:31). Frontend Integration with React: Although the current development version uses pylog, which mounts the application on `/chat`, the application also exposes a necessary websockets endpoint at `/ws` that can be used for integration with a React front end (00:36:48). They agreed that future development should aim to use a single React application linked to the real-time (RT) agent, which will manage the data source agents in the backend (00:35:40) (00:47:25). The working branch is `chanaka/alpha`, and the model loading logic is designed to use an MLX model if environment variables are set, otherwise, it falls back to a light LLM (00:39:32). Team Assignments and Immediate Tasks: Rajasekar G will coordinate follow-up discussions and set up the next call for 11:00 AM (00:42:14) (00:46:12). They need to set up the environment and run the `make UI` command, which is expected to start the agents (00:42:14). Pavhan Saii Gajjalakonda's task is to go through the provided vasa link and drive files to understand the data structures and then dump the data into a SQL database (00:45:05). Assignments for UI and Dashboards: Abhilash Adunuri and Amulya Maggidi will work on the UI part, exploring how to integrate the system with a React application. Kalakonda Harshith Rao is tasked with getting the knowledge transfer from Ganesh regarding the dashboards package and how to integrate it into their system (00:45:05). The immediate goal is to connect the data to the system and ensure it is responding to questions in pylog by the end of the day (00:46:12).  Suggested next steps [Yeshwanth Reddy Yerraguntla] Push Code: Commit necessary code pushes to the chanaka folder repository. [Yeshwanth Reddy Yerraguntla] Schedule Follow-up: Set up one more call by getting everyone's timings and availability. [Phawhan Saii Gajjalakonda] Review Vasa File: Go through the shared Vasa link and drive containing Excel files by end of day today. Understand the required data structures and DB schema. [Phawhan Saii Gajjalakonda] Dump Data: Dump the entire data into a SQL database based on the understood Vasa file structure. [Amulya Maggidi] Explore Repository: Explore the new repository structure. Determine how to integrate the React application and work on the UI part. [Kalakonda Harshith Rao] Get Dashboards KT: Get knowledge transfer from Ganesh on the dashboards package functionality. Determine how to integrate that package with the current system. [Rajashekar G] Schedule Meeting: Set up the next internal meeting call for 11:00 AM.  You should review Gemini's notes to make sure they're accurate. Get tips and learn how Gemini takes notes Please provide feedback about using Gemini to take notes in a short survey.