--- meeting: Enterprise Brain Scrum - Technical Knowledge Transfer date: 2026-03-26 participants: - Yeshwanth Reddy Yerraguntla (Lead/Presenter) - Rajashekar G - Satyasri Prabhakar Mantripragada - Kalakonda Harshith Rao - Amulya Maggidi - Phawhan Saii Gajjalakonda - Vara Kumar Jagarapu - Abhilash Adunuri duration: 50:00 transcript: 20260327.txt --- # Enterprise Brain Technical KT — March 26, 2026 A comprehensive technical knowledge transfer session where Yeshwanth walked the team through the multi-agent architecture codebase, demonstrated the working A2A (Agent-to-Agent) communication pipeline, explained the strategic decision to use smaller local models during development, and provided detailed implementation guidance for deployment and React integration. The session ended with urgent task assignments, including a hard 11 AM JIRA deadline for the following day. ## Act I - Architecture Overview and Agent Launch (~00:00:00 - ~00:08:47) Yeshwanth began the KT by sharing his screen and establishing the session's agenda: walking through the code components so the team could start building immediately. The foundation of the system is the `chanakya` folder, launched via `make ui`, which stands up four agents across distinct ports. > _"the main code is present in chanaka folder um after this call I'll try to make some pushes but um you can see uh that there are four agents two data source agents one realtime agent and one u user aware agent"_ > — Yeshwanth Reddy Yerraguntla _(~00:07:17)_ The architecture consists of: - **Two data source agents**: Gmail (port 8002) and Jira (port 8001) — both currently working with mock data - **One realtime agent**: Chanakya (port 8010) - **One user aware agent**: (port 8003) Yeshwanth emphasized a critical design principle: in the worst-case scenario, each agent must function independently. If you want to test only the Jira agent, you should be able to do so without dependencies on other components. Each agent has its own `agent.py` file and a Dockerfile for manual launching if needed. The ports expose different endpoints: - `8002/chat` for Jira agent - Individual agents serve PyLog interfaces at `/chat` - Each agent maintains its own dedicated conversation history Mock data lives in `data/mock_data/`: separate modules for emails, Jira tickets, and users (including dashboard preferences and project assignments). A `snapshot.py` module pulls this mock data and builds fake snapshots on demand—not true mock data itself, but a dynamic filter over the static mocks for specific dates. ## Act II - Mock Data and Local Model Strategy (~00:08:47 - ~00:14:05) After demonstrating the login flow through port 8010, Yeshwanth revealed a strategic architectural decision that surprised the team: the current setup doesn't use Gemini Flash. Instead, it runs Qwen 3.5 locally via MLX. > _"I'm not using geminy flash um in our uh in this setup I'm using something locally I'm using some quen 3.5 model why because for the sake of debugging uh generally I feel we don't need to waste a lot of tokens and to use a small model will help will force us to think uh uh in a smart way."_ > — Yeshwanth Reddy Yerraguntla _(~00:10:16)_ The reasoning is profound: using a very heavy model like Gemini Flash can mask inefficient code. The LLM's power compensates for poor pipeline design, inefficient data passing, inaccurate tool calls, and vague instructions. But if your code works with a small 9-billion-parameter model like Qwen 3.5, it means: - Your code is efficient - You're not sending too much data to the LLM - Your tool calls are accurate - Your instructions are precise > _"If you make your code work on quen 3.5 that basically means when you actually switch to geminy flash 3.0 it will anyway work there is a very good chance that it will work right. So uh this is one uh AI lesson that I also I think I learned over the last one week that try to make your pipeline work with a small model."_ > — Yeshwanth Reddy Yerraguntla _(~00:11:40)_ Rajashekar confirmed the setup: MLX via Hugging Face, specifically the 4-bit quantized version of Qwen 3.5. Yeshwanth noted that the community consensus is that models below 9 billion parameters are generally too weak for general-purpose programming tasks, but Qwen 3.5 at that size hits the sweet spot for forcing disciplined development. Yeshwanth also demonstrated the admin panel at `localhost:8010/admin`, where you can fake a user. Setting a user there (e.g., Manisha) propagates across agents—when Chanakya asks "who am I?", it correctly identifies the impersonated user and their preferences, though team data plumbing is still incomplete. ## Act III - A2A Communication Pipeline Demonstration (~00:14:05 - ~00:21:51) Yeshwanth moved into live demonstrations to prove the A2A pipeline is operational. At the system level: - Data agents (Gmail, Jira) are available - Realtime agent can query data agents and synthesize responses - User aware agent is available and respects user-specific filtering He encountered a minor surprise during the demo: when logged in with his actual Gmail account, the system was fetching real emails instead of mock data. Investigation revealed the Gmail agent was using actual GWS (Google Workspace) services rather than mock data. > _"I thought it was using mock data."_ > — Yeshwanth Reddy Yerraguntla _(~00:18:20)_ He immediately created a backup (`agent.py.backup`) and switched to mock data from `data/mock_data`. The key takeaway: the pipeline works. The realtime agent at 8010 can ask questions to downstream agents (Gmail, Jira) and synthesize answers. If you ask a generic question, it might query both agents and combine their responses. The A2A protocol includes metadata capabilities: - **Currently implemented**: which user is asking the question - **Pending but feasible**: training mode vs. normal mode, ad hoc mode, refresh mode > _"These two are pending. I mean we can always do them on uh when necessity comes right. It's just that you have to add a specific uh uh key in your JSON and it should work."_ > — Yeshwanth Reddy Yerraguntla _(~00:20:24)_ Right now, data agents connect to mock data, and the user aware agent filters responses based on user identity. What's missing: the realtime intelligence agent's ability to update the organization snapshot based on information from data agents. Mock data currently serves as a proxy for both data source agents and the user aware agent. All agents currently run PyLog interfaces. The agent-to-agent communication (the arrows in the architecture diagram) is functional, but only through the realtime agent's PyLog interface. ## Act IV - Implementation Deep Dive (~00:21:51 - ~00:33:31) Harshit asked the critical question: how do we replace mock data with real data—database connections, API calls? > _"How we replace mock data with real data like DB connections or something or any row creations"_ > — Kalakonda Harshith Rao _(~00:23:13)_ Yeshwanth showed them the `.backup` files he'd just created. The `agent.py.backup` for Gmail and Jira contain the actual real agent source code that connects to live Jira and Gmail systems. Switching to real data sources is a matter of swapping back to those implementations. Currently, with mock data enabled, even the admin is a mock admin, the user is a mock user, and data is mock data—everything stays within the mock boundary. The conversation shifted to Harshit's email-sending microservice (port 8020), which can trigger alert emails via API. The question: if it's a parallel service, will it use mock data for recipients? Yeshwanth clarified it's an implementation question—if the email service receives user information from the user aware agent, it will send to the active user only. The implementation determines behavior. Yeshwanth then dove into the code architecture, starting with `base.py`: > _"the base uh um model is present in base.py. Maybe this will be changed into a different folder but just keep a look on base.py uh where the key class is called as enterprise agent."_ > — Yeshwanth Reddy Yerraguntla _(~00:26:32)_ **`base.py`**: Contains the `EnterpriseAgent` class, which subclasses `PydanticAIResponder`. The inheritance from Pydantic AI provides message history management and PyLog UI compatibility. The `run` method is essentially a wrapper around Pydantic AI's run, with message history tracking. Most of the code is boilerplate wrappers around actual agent functionality. **A2A Protocol**: When `make ui` launches, all agents reserve their own ports. On those ports, the A2A protocol listens for new messages. This is the inter-agent communication backbone. **`a2a_context.py`**: Defines the `RequestContext` structure for passing metadata between agents. When the realtime agent talks to a downstream agent (e.g., Jira), it must send context along with the question: - Who is asking? - Which company/tenant? - Is the user a trainer? - Any other relevant keys > _"this request context is now creating all these uh uh keys for us. Um sorry it's not creating you just defining that this is how I am going to send between A2A agents."_ > — Yeshwanth Reddy Yerraguntla _(~00:28:03)_ During `agent.run()`, the system internally attaches dependencies on the message packet—adding context to the raw question before forwarding to the agent. **`chanakya.py`**: Contains Chanakya's world model instructions. Ideally, this should pull from a Postgres connection string to fetch instructions, skills, and runbooks dynamically from a database rather than being hardcoded. Chanakya is a normal agent with A2A capability. **Downstream agent registration**: Each downstream data source agent (Gmail, Jira, future agents) is registered as a tool call. The wrapper function takes a URL, a question, and context, then does A2A message sending with a wait loop to receive the response. **Deployment architecture**: Yeshwanth pointed to the new agent guide in the docs folder, which covers how to create, update, and deploy agents. Docker commands are provided—individual agents can be brought up separately via `docker compose up `, or all agents can be launched together via the main docker-compose file. ## Act V - React Integration and Deployment Details (~00:33:31 - ~00:40:46) Rajashekar raised a critical frontend integration question: right now, PyLog connects to individual agent ports (8001, 8010, etc.). When they switch to a single React frontend application, how do they avoid exposing multiple endpoints? > _"If you connect with a single front end application react application there will be endpoints only one endpoint we can write right one front end application. So, how can we"_ > — Rajashekar G _(~00:36:48)_ Yeshwanth clarified the architecture: the PyLog interface is just one consumer of the agent. When you call `create_core_app()` on a Pydantic AI agent object, it returns a FastAPI application that mounts on `/chat` for PyLog. But critically, it also exposes WebSocket endpoints. > _"the moment you create this create core app, it will give you a pylo endpoint. Well, and good. But it is also giving you in this one thing, it is also giving you the websockets endpoint API charts."_ > — Yeshwanth Reddy Yerraguntla _(~00:37:51)_ The PyLog UI is already calling a WebSocket endpoint (base path `/ws`). If the React frontend can locate that WebSocket endpoint and connect to it, the hard work is already done—no need to reinvent the protocol. Configuration is entirely environment-driven. All services read their ports from config files or environment variables. For example, the Gmail agent port comes from a specific variable. Ideally, these should live in `.env` files. Each agent can specify its own port, the downstream agents it connects to, and its database paths. **Deployment strategy**: - Data source agents launch first - Then Chanakya launches, configured with the ports of downstream agents - PyLog listens on `/chat` - The root path is where FastAPI listens **Branch strategy**: The working branch is `chanakya/alpha`. Yeshwanth will share the latest `.env` file for deployment. Rajashekar asked about the Qwen model being hardcoded. Yeshwanth clarified: `base.py` checks for an MLX model environment variable. If present, it uses MLX; if missing, it falls back to LiteLLM (which would connect to Gemini Flash or other remote models). The system gracefully degrades. > _"it will work only if you have MLX model in one of your environment variables if this is missing it will skip and come to light LLM"_ > — Yeshwanth Reddy Yerraguntla _(~00:40:46)_ ## Act VI - Team Assignments and Immediate Action Items (~00:40:46 - ~00:50:00) As the call ran long and another meeting loomed, the team pivoted to concrete assignments. Phawhan, attending only his second call, asked for high-level context and documentation. Yeshwanth pointed him to the docs folder, which contains all ongoing discussion artifacts. Phawhan asked who owns requirements—Rajashekar confirmed he would coordinate and link people as needed. Yeshwanth committed to setting up another call after checking everyone's availability. Rajashekar then delivered urgent marching orders for the team, starting with a hard deadline: > _"we need to close your jas by 11 a.m. first thing"_ > — Rajashekar G _(~00:43:29)_ **Immediate priorities**: 1. **JIRA ticket closure**: Must close by 11 AM tomorrow (March 27)—non-negotiable 2. **Local setup**: Everyone needs to check out `chanakya/alpha`, get the `.env` file from Yeshwanth, initialize `uv` in the root folder, and run `make ui` to verify agents start correctly 3. **Data pipeline**: Pavan received a Vasa link and Excel files. By end of day, he must understand the data structures and dump the entire dataset into a SQL database. Yeshwanth confirmed the Vasa file can directly provide the DB schema. 4. **UI work**: Amulya (or Abhilash) will explore the new repository and figure out React integration with the agent system 5. **Dashboard KT**: Harshit must get knowledge transfer from Ganesh on the dashboards package and how to integrate it with the current system 6. **Office attendance**: Everyone must come to office early and attend the 10 AM scrum in person Rajashekar emphasized the development vs. production split: for development, PyLog needs multiple endpoints (one per agent for individual testing). But for the production React platform, only one endpoint is needed—the RT agent at the top. The frontend talks to the RT agent; backend orchestration of data sources is invisible to the frontend. > _"we will be communicating with the RT agent. Our front end application will be communicating with RT agent in the back end. The data source will be enabled or not that back end will figure it out. No need to have the dependent front end."_ > — Rajashekar G _(~00:48:00)_ He floated the idea of a flag-based system: enable one flag to run with PyLog for debugging, enable another to link with React. This would accelerate development by allowing quick context switching between debugging and integration modes. The urgency was palpable—JIRA tickets by 11 AM tomorrow, database work by end of day, everyone in office early, and a follow-up call at 11 AM to assess progress. ## Todos - [ ] Close all pending JIRA tickets (hard deadline, non-negotiable) | author: Rajashekar G, Team | deadline: 2026-03-27 (11:00 AM) - [ ] Set up local environment with chanakya/alpha branch and verify `make ui` launches all agents | author: All developers | deadline: 2026-03-27 - [ ] Study Vasa file and Excel data, extract DB schema, and dump entire dataset into SQL database | author: Pavan | deadline: 2026-03-26 (EOD) - [ ] Get KT from Ganesh on dashboards package and integration strategy | author: Harshit | deadline: 2026-03-27 - [ ] Explore new repository and research React-to-agent WebSocket integration approach | author: Amulya, Abhilash | deadline: 2026-03-27 - [ ] Audit PyLog WebSocket implementation to derive React integration strategy | author: Team | deadline: TBD - [ ] Attend 10 AM scrum in office (everyone must be present in person) | author: All team members | deadline: 2026-03-27 (10:00 AM)