Part 3: Next-Gen Personal Running and Health Coach: Smarter AI, Deeper Insights, and Context-Aware Analytics

 Part 1 — https://medium.com/@bhattshailendra/extracting-running-data-out-of-nrc-nike-nike-run-club-using-apis-bcee76a714c3

Part 2 — https://medium.com/@bhattshailendra/from-extracting-running-data-to-transforming-it-into-ai-powered-insights-with-nike-nrc-strava-0f19742b2f11

Building on Part 2’s foundation of extracting, embedding, and querying running data from Nike NRC, Strava, Garmin, and OpenAI-powered vector search, in this part I have expanded the application to incorporate multimodal data, contextual external knowledge, and agentic tooling for more accurate AI insights.

My architecture now does the following:

Press enter or click to view image in full size

Step 1 — Multiple running, knowledge based and health data sources are ingested and normalized into the back-end.

Step 2 — Data — including multi-modal records are embedded and stored in the vector database.

Step 3 — User queries are routed through the chat app initiate vector-based similarity searches for pertinent personal data.

Step4 — The OpenAI GPT-5 LLM synthesizes responses, enhanced by injected external knowledge and agentic tool outputs.

Step 5 — Insights and predictions are returned in conversational form, evolving with feedback and new data.

Part 2 - From Extracting Running Data to transforming it into AI-Powered Insights with Nike NRC, Strava, Garmin and OpenAI

Few years back in my earlier article (https://www.shailendrabhatt.com/2020/11/extracting-running-data-out-of-nrcnike.html), I explained how to extract running data from Nike NRC using public endpoints and basic API scripts. At that time, this was a step up from manual tracking, a way to view runs, pace, and totals using dashboards and exported files. Seeing progress week-to-week and analyzing simple trends locally felt empowering and encouraging to go back to do the next run. Also, back then running api's were publically available, which they no longer are and that was another reason to store this information locally for future references. 

Part 1 - Feeding Historical data to Open AI

In this article, I am trying to move beyond static tracking to an autonomous coach that suggests plans in real-time based on historical data. Instead of just visualizing past metrics in dashboards, I have tried using OpenAI’s models (GPT-5) and vector search databases to analyze my performance. The idea was to use the tools to correlate training variables and create predictions for upcoming runs, all based on my own historical data.

Part 2 - Storing run data into Vector Database

Leveraging OpenAI’s LLMs, I added chat-based analysis—so the app answers training questions  in natural language instead of just showing numbers. 

Step 1: The first step was bringing together Nike NRC, Strava data into a unified dataset. After several manually exporting activity logs, I finally automated the pipeline for both Nike NRC and Strava using API's. The updated codebase is present here --> https://github.com/shailendrabhatt/runanalysis-usingopenai 

Step 2: The next step was feeding the data into a Vector database. All summary of runs are sent to the Open AI's embedding endpoint.

var embeddingPayload = new { input = runSummary, model = "" };var response = await httpClient.PostAsJsonAsync("https://api.openai.com/v1/embeddings", embeddingPayload);var embedding = await response.Content.ReadFromJsonAsync<EmbeddingResponse>();

For semantic analysis, runs and embeddings are indexed using a vector database

Step 3: The application features a chat window. When prompted about my running trends or wanting any advice, the chat backend sends context data with the query to the OpenAI endpoint:

var gptRequest = new {    model = "gpt-4-turbo", messages = new[] { new { role = "system", content = "You are a running coach." },      new { role = "user", content = "Analyze my last four days of training and suggest improvements." }  } };var resp = await httpClient.PostAsJsonAsync("https://api.openai.com/v1/chat/completions", gptRequest);

By integrating OpenAI’s GPT-based models as a chat interface on top of my fitness vector database, I can now do more than just browse charts:

I ask, “When did I last have a similar training block to this month?”, and the LLM summarizes and compares periods—even if I don’t remember the dates or specific workouts.

Even questions like, “Did my pace improve after switching shoes?” or “Which kind of recovery week led to my highest VO2max gains?” The LLM pulls contextually relevant vectors (embeddings) from the DB that has almost 10 years of my running information, draws parallels and trends, and gives coherent, actionable feedback.

I have now started to actually trigger the query just before a workout to evaluate how long I should do that specific run. The next step is to fetch the Garmin data, which seems to be a tricky case and then integrate the heart rate, stress levels to get more accurate feedback. 

Reshaping Development Team Dynamics and ROI

 I’ve always been skeptical that small, agile teams could consistently deliver robust, production-ready applications. The complexities of modern software development have long seemed to require a roster of specialized professionals to successfully execute an entire SDLC project.

The skeptical veteran in me has had to confront the reality that irrespective of skills even individual developers are now equipped to drive initiatives that once demanded large, collaborative groups. My recent experience with an AI-powered development environment has been a true paradigm shift. Only recently have I come to fully appreciate the ground-level impact of these tools.

While having previously tested tools like GitHub Copilot and observed incremental gains in productivity. I still felt dependence on the expertise of specialists for nuanced or highly complex tasks. Those tools never completely changed that equation for me.

Now, even from a business perspective, the ROI is equally game-changing. Rather than investing heavily in consultants or maintaining large, narrowly focused teams, AI powered platforms like cursor.com streamline the entire delivery cycle. I am now absolutely convinced that by adopting these technologies, small-high-output agile teams are becoming an achievable standard.

Looking into Azure AI Foundry: Building a Smart Response System

Over the past few weeks, I had the opportunity to dive deep into Azure AI Foundry and work on poc that combined prompt flow, large language models (LLMs), and database indexing. The idea was to build a system that evaluates different LLMs, retrieves relevant information from a database, selects the right email template, and generates a personalized email response. 

Azure AI Foundry

Azure AI Foundry is a powerful platform designed to simplify the development of AI applications by orchestrating flows involving LLMs, prompts, and Python tools. The best thing about the AI foundry is the visualized graph-based interface for creating flows and its ability to test and debug seamlessly. After setting up my project in the Azure AI Foundry portal, the major part was the setting of Prompt flows.

Designing the Prompt Flow

The first step was to create a Prompt Flow that could evaluate multiple LLMs based on specific input parameters. Here’s how I structured it:

Input Parameters: The flow began by taking user inputs such as query type, historical data context, and additional metadata.

LLM Evaluation: Using Azure OpenAI GPT models, I evaluated several LLMs for their performance on these inputs. This step involved crafting multiple prompt variants using Jinja templating and comparing their outputs.

Index Lookup: Once the best-performing model was selected, I integrated an Index Lookup tool to query a vector database for relevant historical data.

Template Selection: Based on the retrieved data, the system dynamically chose one of several pre-uploaded email templates.

Database Indexing & Retrieval

The Index Lookup tool in Azure AI Foundry made it easy to search through my vector database for relevant results. This tool uses embeddings generated by LLMs to find the most contextually appropriate matches for a given query.

For example:

If the input query was related to customer feedback, the system would retrieve historical feedback records.

For support-related queries, it would fetch relevant support ticket summaries.

This indexing mechanism ensured that every email response was grounded in accurate and relevant data.

Generating the Response

Once the right template was selected, I used the chosen LLM to fill in placeholders in the template with dynamic content. The final email response was not only accurate but also personalized based on historical interactions.

For instance:

A customer asking about delayed shipping would receive an email referencing their previous order details.

A user requesting technical support would get an email tailored to their issue history.

This seamless integration of templates with real-time data retrieval made the system highly effective.

There main areas to look into when turning the POC into a proper use case.. 

1. LLM Evaluation: Comparing multiple LLMs required careful tuning of prompts and iterative testing. What was frustrating at times was that different LLM gave different results for the same query.

2. Data Integration: Ensuring that database indexing worked smoothly with diverse datasets took some effort.

3. Template Management: Designing flexible templates that could adapt to various contexts required creativity. Since I had limited data this impacted the output result.

Final Thoughts

Azure AI Foundry I think can revolutionize workflows by combining retrieval-augmented generation (RAG) techniques with powerful LLMs. The ability to evaluate models dynamically, retrieve relevant data efficiently, and generate personalized outputs has immense potential across different industries —from customer support to marketing automation.

In search of a cost effective strategy for modernizing a monolithic - Part 3

It's been a while since I last updated on the modernization journey of the monolithic Java application.

As I highlighted in Part 2, the initial domain identification process is proving to be more time-consuming than anticipated. The lack of readily available stakeholders and domain experts presented a significant hurdle, making it challenging to gain a comprehensive understanding of the application's intricate workings. Moreover, the discovery of hidden interdependencies between seemingly distinct domains further is complicating the decomposition strategy.

Budget constraints continued to be a major factor shaping our decisions. With the initial plan of migrating to the cloud no longer feasible, we had to explore alternative approaches that would deliver substantial value without breaking the bank. The strangler fig pattern is emerging as a promising solution, offering a way to incrementally modernize the monolith by gradually replacing specific functionalities with microservices built using the same technology stack.

To mitigate risk and ensuring business continuity, we identified a few non-critical modules as our initial targets for strangulation. These modules, while not directly impacting core business operations, would provide valuable insights and experience as we refined our modernization approach.

The Next Steps

With a clearer understanding of the challenges and a viable modernization strategy in place, the next crucial step is to develop a detailed roadmap that will guide our efforts moving forward. This roadmap will prioritize modules for decomposition based on three key factors:

●

Business value: Modules that deliver significant business value and have a high potential for improvement will be prioritized.

●

Technical complexity: Modules with lower technical complexity will be targeted first to minimize risk and accelerate the modernization process.

●

Potential for immediate impact: Modules that can demonstrate tangible benefits quickly will be given preference to showcase the value of the modernization initiative.

Creating a comprehensive business capability matrix is essential for effectively mapping out the modernization journey. This matrix will provide a clear overview of the application's functionalities and their relationships to business processes.

Looking Ahead

The road ahead is undoubtedly long and complex, but I'm a bit optimistic about the progress we've made so far. By embracing an iterative approach and focusing on delivering value incrementally, I'm feel that we can successfully modernize this application and unlock its full potential.

The Hidden Carbon Cost when Working Remote

As part of an Organization that has sustainability as one of its top agenda, I've been closely examining the environmental impact of remote work, and the results are not as straightforward as many might assume. While initial studies painted a rosy picture of reduced emissions due to eliminated commutes, a more nuanced personal analysis reveals that working from home may, in a lot of cases, lead to higher CO2 emissions than traditional office work. 

Since I live in Sweden, a cold country, this analysis seems even more true, considering the high number of dark and cold months in a calendar year. Let me try to break this down into real-world numbers. Let me try to take an example of how sustainable I am as an Architect when it comes to working from the office or from home.

Carbon Emission Numbers when working from the office

For a day when I am working from the office with proper sustainable practices (walking commute, single screen use, no overtime, reusable coffee mug, no printing), I calculated my daily CO2 emissions of 14.3 kg.

This includes approximately 6 kg from office energy use, 2.4 kg from computer usage, and other small contributions from digital activities and shared resources like sending emails, taking video calls, etc.

My reference for the data is from articles that support how remote working reduces CO2 footprint.

 Also, for the fact that like most modern offices, the office I work at also offers green building technologies, and energy-efficient workspaces leading to sustainable corporate facilities.

 

https://www.sciencedaily.com/releases/2023/09/230918153242.htm  

https://allwork.space/2023/09/digest-remote-works-green-potential-can-working-from-home-slash-carbon-emissions/  

https://www.anthropocenemagazine.org/2023/09/remote-work-is-better-for-the-climate-but-mainly-in-large-doses/

Carbon Emission Numbers when Working Remote

In contrast, when I work from home initially it appeared to have lower emissions at 10.7 kg CO2 per day based on the above factors. However, when I factor in the limitations and long-term impacts of remote work, the numbers change dramatically. Let me detail out

1. Basic home energy use: Electricity for computer and multiple screens: 2.0 kWh/day, CO2 emissions: 0.512 kg CO2/day

2. Heating/Cooling (year-round average, Sweden is a cold country still keeping the numbers low): 50 kWh/day (assuming less efficient home HVAC) CO2 emissions: 9.2 kg CO2/day

3. Additional residential energy use: Cooking, appliances, increased device usage. Estimated additional 2 kWh/day, CO2 emissions: 0.512 kg CO2/day

4. Inefficiencies due to work-from-home disadvantages:

• Communication delays (1.5 hours/day lost): CO2 emissions: 0.0576 kg CO2/day
• Reduced collaboration efficiency (Appx 1.5 hours/day lost): CO2 emissions: 0.0576 kg CO2/day
• Misunderstandings in digital communication (Appx 1 hour/day): CO2 emissions: 0.0384 kg CO2/day 
• Limited access to physical resources (1 hour/day of inefficiency): CO2 emissions: 0.0384 kg CO2/day

5. Longer working hours due to blurred boundaries:

Extra energy use: 0.3 kWh with CO2 emissions: 0.0768 kg CO2/day

6. Increased use of digital tools for team bonding: Video calls, and virtual social events: 0.5 kWh/day

CO2 emissions: 0.128 kg CO2/day

7. Additional lighting needs for home office:

0.5 kWh/day CO2 emissions: 0.128 kg CO2/day

8. Increased non-work energy use during breaks:

TV, Mobile, additional cooking: 2 kWh/day

CO2 emissions: 0.512 kg CO2/day

9. Less efficient home office equipment:

Additional 1 kWh/day

CO2 emissions: 0.256 kg CO2/day

10. Frequent additional trips during work hours:

CO2 emissions: 4.04 kg CO2/day (using 0.404 kg CO2/mile)

Some of these additional factors bring the total daily emissions for our remote worker to 15.7 kg CO2, surpassing the office-based scenario by 1.4 kg, and I have gone easy with the numbers for point 4 --> Inefficiencies due to work-from-home disadvantages.

Conclusion

In conclusion, this data may differ from case to case and for different working models. But just in my case, I feel working from the office isn't just a traditional approach, it's, turning out to be a strategic environmental choice. By centralizing my work, optimizing shared resources, and fostering collaborative environments, I think I am being more sustainable than when I am working from home.

What I am still missing is a spontaneous innovative environment that fosters, immediate problem-solving, people-to-people knowledge transfers, and most importantly, enhanced mental health through social interactions.

Imagine how these sustainable numbers will improve if all my colleagues were also working from the office.

Session Management: B2C vs B2B Customer Facing Applications

As I was thinking about a good topic to write about this week, I couldn’t help but reflect on the subject of user session management. It is a critical topic that plays a pivotal role in shaping user experiences on customer-facing websites. Since being part of both B2C and B2B applications, I have noticed how different approaches to session management can either enhance or hinder user engagement.

In B2C applications, we have used a browser-level cookie with a 30-minute timeout, while the B2B applications employ server pinging every few minutes. Both approaches have their merits and challenges.

When designing a session management system, these are the architecture abilities considered:

Scalability: Our solution must handle varying user loads efficiently.

Security: Protecting user data and preventing unauthorized access.

User Experience: The system should balance security with ease of use. 

Flexibility: How flexible does the session management solution cater to different timeouts?

Performance: We must minimize the impact on server resources and network traffic.

Compliance: Our implementation should adhere to relevant data protection regulations.

Based on these considerations, our ideal implementation was 

For B2C

Since the number of users accessing the application is very high and requires high concurrency, there was a requirement for better user experience and performance. Hence, using secure HTTP-only cookies for session tokens was more suited. 

Also, since the application had several public pages, security was achieved by storing limited data in cookies and ensuring all secured information was on the server side. 

A distributed session could have been achieved, as there was a Redis cache layer. However, we wanted to keep the session stateless, and using a sticky session was available, and scalability was not an issue.

For B2B

Since concurrency was not an issue, server-side session management with client-side pinging periodically was a more apt solution. It did not hamper user experience SLAs and was more secure. 

Also, different b2b functionalities required different session timeouts. Keeping the logic on the server side made it more flexible and more controlled in terms of monitoring.

In conclusion, this is a good topic to revisit continuously, considering how the application security landscape is evolving, and so will our session management approach.