---
meeting: Enterprise Brain Scrum
date: 2026-04-12
participants:
  - Yeshwanth Reddy Yerraguntla
  - Rajashekar G
  - Vara Kumar Jagarapu
  - Satyasri Prabhakar Mantripragada
duration: ~25:27
transcript: 20260413.txt
---

# Enterprise Brain Scrum — April 12, 2026

A comprehensive scrum addressing critical UI agent history propagation bugs, widget rendering concerns, sprint planning with new Pydantic AI capabilities exploration, local LLM cost optimization strategies, and onboarding plans for a new team member. The meeting established architectural clarity on shared state management and prioritized reducing Gemini API costs through MLX and llama.cpp alternatives.

## Act I - UI Agent History Propagation Bug (~00:00:00 - ~00:04:53)

Rajashekar opened by checking if Yeshwanth had reviewed the beta design branch—he hadn't yet but committed to reviewing it immediately. The pressing issue: history propagation in the UI agent is broken.

The architecture uses session-based context persistence. When a user starts a conversation, the system creates a session in the database and continuously logs all chat messages. On each new question, the system fetches the last five questions and answers based on session ID and passes them as context to the agent.

> _"right now not into radius it's it's into database like session create it will create a session in my database and it will add all the charts messages in that database continuously when a new question arise [...] it will fetch the last five uh questions and answers based on that particular ID and pass it as a context"_
> — Rajashekar G _(~00:03:47)_

Yeshwanth validated the architecture as sound but probed for the root cause. Rajashekar explained the system worked perfectly when only the core agent and data steel agent existed. After introducing the UI agent, it worked on day one but broke during subsequent UI enhancement work.

The symptom: when users ask a question generating a chart, then request "convert this chart into another graph," the system doesn't respond. Log file inspection reveals no previous history in the context—the propagation mechanism failed.

> _"first we'll ask a question it will generate a chart again I ask like uh convert this chart into another graph it is not changing and whenever I go into log file and see I'm not able to see the previous uh history has a context there. That's where the issue we found it on Friday evening."_
> — Rajashekar G _(~00:04:53)_

The issue was discovered Friday evening and remains unfixed. Cache implementation, originally planned for last sprint, was put on hold—this becomes relevant context for the architectural discussion that follows.

## Act II - Widget Rendering Concerns and Sprint Priorities (~00:04:53 - ~00:07:27)

Rajashekar shifted to immediate priorities: getting the UI agent working properly with the widgets provided by the design team. Two specific concerns emerged around data visualization:

**Line Graph Horizontal Scrolling**: When line graphs render with many data rows, the design requires horizontal scrolling to show more data. Work is underway to implement this.

**Table Pagination**: The system currently fetches all data and renders it in tables, but the design team hasn't provided pagination components. Without pagination controls, large datasets become unwieldy.

> _"whenever we are rendering a table right now we are going and hitting and getting all the data right but representation it need to have a page nation and all that repentation they haven't provided us. So that also we need to take care."_
> — Rajashekar G _(~00:04:53)_

Yeshwanth confirmed pagination is critical. Rajashekar committed to discussing with the design team to obtain the table widget with pagination controls.

The immediate sprint priority: stabilize the UI agent with all widgets and deploy. This becomes task number one for the day.

Rajashekar then shared his sprint planning screen, showing comprehensive backlog organization with bandwidth for additional priority items. The planned work includes:

- Caching mechanism implementation
- WebSocket implementation (needed for interactive charts)
- Training lifecycle V1 completion
- Training lifecycle V2 (document upload as new instructions)
- UI layout intelligence
- Interactive charts

## Act III - UI Layout Intelligence and Exchange Format Architecture (~00:07:27 - ~00:10:13)

The conversation turned to a critical Friday discussion with Navin about UI layout intelligence. This ties directly to interactive charts—they're interdependent features.

Yeshwanth emphasized the need for architectural design work before committing to sprint timelines:

> _"We should we should spend some time first uh dedicating ourselves to architecture, right? What is that interchange uh exchange format? How will AI tell the user interface? What plots to put and how which order to plot them in? how to put them via interactions. These three are critical and we need to understand how to come up with the right JSON structure. Once we know the JSON structure, we'll be in a position to tell whether we can do it this uh sprint or next sprint."_
> — Yeshwanth Reddy Yerraguntla _(~00:08:42)_

The three critical questions for the JSON exchange format:

1. What plots to display
2. In what order to arrange them
3. How to wire interactions between widgets

Without clarity on this structure, sprint commitment is premature. Yeshwanth proposed a meeting before 11 PM Indian time to resolve this. Rajashekar scheduled it for 10:30 PM.

Additional sprint stories were outlined:

- Move all environment files to structured database
- Migrate to new React architecture
- Proper LLM error handling (currently retries on API failure but lacks architectural structure)
- Multi data source agent orchestration (handling new data sources as they appear)

Spillover work from previous sprint includes training lifecycle completion and fixes for the new agent.

## Act IV - Team Expansion and Onboarding Strategy (~00:10:13 - ~00:16:45)

Rajashekar raised a people question: Rama is joining the team. She's from Abhilash and Amulya's team, has React frontend and backend skills, and attended Pydantic training sessions in office. How should they onboard her effectively?

Yeshwanth proposed a self-directed learning approach with structured accountability:

> _"You have like two days to understand what is going on. Let her come back. [...] mainly she has to come back with uh a report of what is enterprise brain what are all the features [...] there is art agent there are data storage data source agents UI agent what is the role of each agent all these things she has to know it's not that I want you or one of us to sit her and explain to her she has to come up with that information by herself."_
> — Yeshwanth Reddy Yerraguntla _(~00:11:37)_

The resource: all daily meetings are captured as minutes of meeting documents. The phase-2 conversations folder contains both raw text transcripts and MOM markdown files. Rama should use co-pilot to explore these documents and answer a curated question set about the system architecture.

Timeline: after lunch, Rajashekar should spend 15 minutes assessing her learning, understanding her interests, and assigning her to either UI work or enterprise backend work based on preference.

The meeting scheduler then surfaced a conflict: 10-11 AM was already booked for an internal review meeting with GenRx and Prabhakar. The synthetic data architecture meeting was rescheduled to 10:30-11:00 PM.

## Act V - Pydantic AI Capabilities and Shared State Architecture (~00:16:45 - ~00:20:57)

Yeshwanth introduced a new Pydantic AI feature: capabilities. This architectural pattern could significantly clean up the Enterprise Brain codebase.

A capability bundles:

- Collection of tools
- Lifecycle hooks (before LLM call, after LLM call, before tool call, after tool call)
- Shared behaviors across agents

> _"A capability is uh nothing but a mix of tools hook uh hooks for uh agent when it is running before LLM call what to do after LLM call what to do before tool call what to do it's a collect hooks and a collection of tools"_
> — Yeshwanth Reddy Yerraguntla _(~00:19:44)_

When you attach capabilities to a Pydantic agent, all tools and behaviors automatically attach to the LLM. The example Yeshwanth demonstrated: a shared state capability providing Postgres visibility across microservices. Instead of repeating tool call definitions in every agent, define it once as a capability.

The concrete benefit: every agent can automatically fetch conversation history from Postgres and dump conversations to Postgres without duplicating code. The `after_run` hook demonstrated this—after every agent call, it appends the response to Postgres (Yeshwanth's example used fake Redis).

> _"This way you don't need to your the the kind of code that you'll have to use will come down."_
> — Yeshwanth Reddy Yerraguntla _(~00:20:57)_

Yeshwanth asked Rajashekar to explore this pattern for cleaner architecture. They could discuss it in the same 10:30 PM call after Rajashekar reads the documentation for 5-10 minutes.

## Act VI - Local LLM Cost Optimization (~00:20:57 - ~00:23:00)

Rajashekar raised cost concerns: the team is using Gemini for everything—internal development, deployed systems, and testing. Current usage: $124. There's tracking on who uses what and how much, but the MLX model hasn't been integrated yet, and costs continue climbing.

Yeshwanth agreed they should explore MLX models immediately. He also suggested llama.cpp as an alternative—it's extremely fast and has Pydantic integration completed.

> _"You guys can also try llama CPP. [...] Uh that is also supposed to be extremely cost [effective] [...] Mac OS. Uh yeah with identic closed. So this is this is done actually completed."_
> — Yeshwanth Reddy Yerraguntla _(~00:22:20)_

If llama.cpp doesn't work well, they'll explore other options. Rajashekar should report back if performance isn't acceptable.

The strategic escalation path: bring this up with Joshua, emphasizing token burn rate. If they can get internal LLM deployment, it would save substantial money.

## Act VII - Design Feedback and Client Demo Preparation (~00:23:00 - ~00:25:27)

Prabhakar joined briefly at the end. New designs are coming from the design team. He confirmed what's been done so far is acceptable and ready for client demonstration.

He emphasized continuity on database work and requested a feedback button be added to the interface.

The meeting closed with confirmation that all stakeholders are aligned on the demo-ready state and next priorities.

## Todos

- [ ] Fix UI agent history propagation bug preventing context from passing to UI agent | author: Rajashekar G, Team | deadline: 2026-04-13
- [ ] Implement horizontal scrolling for line graphs with large datasets | author: Team | deadline: 2026-04-13
- [ ] Obtain table widget with pagination controls from design team | author: Rajashekar G, Design Team | deadline: 2026-04-13
- [ ] Stabilize UI agent with all widgets and deploy | author: Team | deadline: 2026-04-13 (Priority 1)
- [ ] Hold architecture meeting to define JSON exchange format for UI layout intelligence (plots, order, interactions) | author: Yeshwanth, Rajashekar | deadline: 2026-04-12 10:30 PM
- [ ] Provide Rama with curated question set about Enterprise Brain architecture for self-directed learning | author: Rajashekar G | deadline: 2026-04-13 morning
- [ ] Assess Rama's learning progress after lunch and assign to UI or backend work based on preference | author: Rajashekar G | deadline: 2026-04-13 after lunch
- [ ] Explore Pydantic AI capabilities pattern for shared state management and code reduction | author: Rajashekar G | deadline: 2026-04-13
- [ ] Integrate MLX local model to reduce Gemini API costs | author: Team | deadline: 2026-04-15
- [ ] Test llama.cpp as cost-effective alternative to Gemini | author: Team | deadline: 2026-04-15
- [ ] Escalate token burn costs to Joshua with request for internal LLM deployment | author: Rajashekar G | deadline: 2026-04-14
- [ ] Add feedback button to interface | author: Team | deadline: 2026-04-15