# Minutes of Meeting — Tata Steel: Use Cases Discussion **Date:** March 26, 2026 **Duration:** ~1h 22m **Source transcript:** [20260326.txt](20260326.txt) **Google Doc:** [Tata Steel: Use Cases Discussion — Notes by Gemini](https://docs.google.com/document/d/12sFgEi6RRHj05vzZ_jIpbznjOk9IRgmeTEQJHJjq6Wg/edit?tab=t.od431kymioa) **Attendees:** Naveen Puttagunta, Yeshwanth Reddy Yerraguntla, Satyasri Prabhakar Mantripragada, Vara Kumar Jagarapu --- ## Act I — Business framing and data agent skeleton readiness (~00:00 – ~00:12) Naveen opened the meeting by asking Yeshwanth to translate the technical delivery plan into business-level milestones. The first question was straightforward: what are we actually shipping? Yeshwanth walked through the current state of the data agent framework — the skeleton is mostly ready. It already allows creation of specific entity agents (e.g., for Invictus or Cautilia), and manual training at the developer level is possible today. The ability for the agent to train itself is slated for the next sprint. One gap surfaced immediately: the "orange box" — the PostgreSQL database that stores system prompts and instructions flexibly — is missing. Right now those prompts are hardcoded into Python. The data source agent can limp along without it by using embedded strings, but it is not a clean delivery. The broader orchestration wiring is being stitched together but is not complete yet. The Real Time Decision Intelligence (RT) core agent is confirmed for M1. It currently functions as a hub — managing user identity, question mode (ad hoc, training, data refresh), and routing to user-aware and data source agents. Future responsibilities — synthesizing cross-source snapshots, respecting RBAC for daily org data storage, communicating with two additional red boxes and one pink box — are explicitly deferred. ## Act II — Reactive copilot defined: terminology, visuals, and multi-source framing (~00:12 – ~00:32) Naveen confirmed the M1 deliverable is enough to operate in what he called a "reactive UI" mode — user asks a question, system answers — similar to the manufacturing demos. The team adopted **"reactive copilot"** as the internal term for this mode. Two clarifications came quickly and both matter for how the doc is written: First, the reactive copilot must not be described as something that queries a single data source. Naveen was direct: > *"The description should not suggest we can only query one data source. It orchestrates multiple agents to synthesize an answer."* > — Naveen Puttagunta _(~00:15:13)_ Yeshwanth committed to updating the communication modes document accordingly. Second, the output is not text-only. Yeshwanth confirmed the reactive copilot will include visual elements — charts with interactions and drill-downs — not just prose responses. This too needs to be reflected in the doc. The team then settled a key terminology point: **dynamic workspace** is the output delivery method — the canvas through which results are communicated. It can be driven by either the reactive copilot (user-triggered) or the autonomous experience center (proactively). These are not competing concepts; one is a driver, the other is the surface. Yeshwanth raised a practical concern: how do domain-specific visualizations (like a manufacturing plant dashboard) connect to the enterprise brain framework? Naveen reframed this cleanly — visualizations are **patterns or widgets** (a pie chart, a heat map, a trend line) that carry metadata describing what they can show. The engine decides which pattern fits the context. The widgets don't need to know the domain; they describe themselves, and the UI agent picks. ## Act III — M1 / M2 / M3 milestones locked, visualization framework, priorities (~00:32 – ~00:57) The three milestones were defined explicitly and assigned priority labels. **M1 — P0 — Reactive Copilot (by Wednesday, ~April 1):** Deliver a reactive copilot with base patterns and the redesigned UI connected to the Invictus/Tata Steel data source. Two parallel workstreams: (1) integrate the redesigned UI code from the design team (code, not Figma), and (2) prepare the Invictus data and train the data agent. Architectural databases are not fully set up yet; the plumbing is what ships. **M2 — P1 — Dynamic Workspace + Agent Training (~April 10):** Deliver a rudimentary experience center demonstrating the AI layer driving the UI dynamically with rich patterns. Even without real-time data refresh, this can be simulated by linking and unlinking pre-prepared static snapshots — the point is to show the AI driving layout changes, not the freshness of data. Also in scope for M2: the capability to train data source agents on the fly. Complex trainer-role features (arbback) are deferred to M3. **M3 — P2 then P3 — Full Experience Center (end of April):** Multi-data source orchestration and a fully integrated experience center blending reactive and proactive modes. Naveen was explicit about priority order: full experience center (P2) first, then multi-data source orchestration (P3), then data refresh (P4). The goal for M3 is the core system working end-to-end as originally envisioned. On visualizations: before M2, Yeshwanth needs to analyze the patterns Nihar's design team has built and establish a UI framework where each rich pattern (built in Three.js and D3.js) can describe itself via metadata. This is what lets the UI agent dynamically choose the right visualization. Naveen and Yeshwanth agreed to keep data set flexibility open — the milestone framing is architecture-first, not data-source-specific. ## Act IV — Platform independence, Dakshi quality, agent skills, and operational gaps (~00:57 – ~01:22) The conversation shifted to process and tooling concerns that cut across all three milestones. **Platform independence:** DUX must not be tied to Copilot. It needs to work with Claude, Codex, and Gemini. Yeshwanth is working on treating project files as markdowns so they are accessible regardless of which LLM or tool is active. No formal solution exists yet, but the goal is DUX as a stable layer across all of them. **Designer workflow:** There is friction in how designers generate documentation and UIs through VS Code. The desired flow is either doc-first-then-UI or UI-first-then-extract-doc, with the ability to move between systems when tokens run out. Component structures need to be upfront and clean. This is unresolved. **Training session:** Sessions covered theory, MCP server concepts, and documentation references. Most participants gave themselves one week to build something. Prabhakar believes hands-on capstone projects will land the concepts better than videos. Yeshwanth deliberately delayed the coding phase — the intent is for trainees to hit walls first, so they appreciate the solutions when they arrive. Naveen will follow up with Rama to propagate the materials (five or six videos) to the next team batch. **Dakshi quality issues:** Multiple developers report Dakshi either info-dumps or over-questions because it lacks project context. Yeshwanth named the root cause clearly: > *"The core issue is a process limitation — the system doesn't have sufficient project context to understand intentions. We need a systematic way to capture all project activities on a daily basis."* > — Yeshwanth Reddy Yerraguntla _(~01:12:07)_ The fix is comprehensive context capture: full meeting transcripts, salient daily points, everything fed to the AI so it asks fewer questions and produces higher-quality output. Skills already created toward this: a Storytelling mode (ensures docs begin with context for cold readers), a Vasa skill (correct rendering for Vyasa), and a Retrospective skill (auto-identifies and fixes mistakes in previously used skills). **Operational gaps:** A continuous architecture council — Yeshwanth, Gopal, Wenut, and Prabhakar — is needed to translate DUX conversations into actual adoption. Naveen flagged apathy as a concrete symptom: users not resolving a simple VS Code integration issue after an update signals the changes are not becoming operational across the team. Project estimation also needs to shift from effort hours to complexity-based story points, with a standard mechanism at both scoping and development stages. --- ## Decisions | # | Decision | Rationale | |---|----------|-----------| | 1 | Term "reactive copilot" adopted internally for the user-triggered Q&A mode | Distinguishes from autonomous/proactive modes | | 2 | Reactive copilot description must reflect multi-agent orchestration and visual outputs, not single-source text answers | Naveen's explicit correction; doc update assigned to Yeshwanth | | 3 | Dynamic workspace = output delivery surface; driven by reactive copilot OR experience center | Resolves prior terminology confusion | | 4 | M3 priority order: P2 full experience center → P3 multi-data source → P4 data refresh | Experience center completeness over breadth | | 5 | M2 can simulate proactive mode with static snapshots — no real-time refresh required to demonstrate AI-driven UI | Avoids blocking M2 on data pipeline completeness | | 6 | DUX must be LLM-agnostic: Claude, Codex, Gemini, Copilot all supported | Architectural requirement; no formal solution yet | | 7 | Visualization patterns described via self-metadata; UI agent selects pattern based on context | Decouples domain knowledge from widget design | --- ## Todos Update the communication modes document: Reactive Copilot section must reflect (1) multi-agent orchestration, not single data source, and (2) visual outputs including interactive charts and drill-downs.
Yeshwanth Reddy Yerraguntla ASAP (pre-M1) Grant Yeshwanth access to the UI pattern code repository (Nihar's team output).
The group This week Ask Nihar's team to share the UI generation prompts with Yeshwanth for analysis and framework planning.
The group This week Analyze Nihar's design patterns and establish a self-describing UI widget framework so the UI agent can dynamically select visualizations (Three.js / D3.js).
Yeshwanth Reddy Yerraguntla Before M2 (~April 10) Deliver agent training on the fly capability as part of M2 sprint — data source agents trained without developer intervention.
Yeshwanth Reddy Yerraguntla M2 (~April 10) Connect with Watana to find a formal solution for LLM compatibility (Claude, Copilot, Gemini, Codex) within DUX.
Yeshwanth Reddy Yerraguntla Unset Follow up with Rama on propagating training materials (5–6 videos) to the next team batch.
Naveen Puttagunta This week Revisit the missed core training session video and attempt hands-on implementation of the concepts.
Satyasri Prabhakar Mantripragada This week Work with Gopal to drive operational rollout of DUX changes and shift project estimation from effort hours to complexity-based story points.
Yeshwanth Reddy Yerraguntla Ongoing