Our Executive Function series features perspectives from leaders driving transformation through AI.
JioStar operates entertainment and live-sports platforms used by more than 500 million consumers and has supported as many as 72.5 million concurrent live-sports viewers. At that scale, AI has to be fast, reliable, and ready for production.
Using the OpenAI API, JioStar built a conversational video and cricket-stat discovery assistant into JioHotstar. Viewers can speak naturally to find movies and shows, historical highlights, live-match moments, or cricket statistics, with results returned through a visual, conversational experience.
At OpenAI’s Executive Summit in Singapore, Sidharth Sharma, OpenAI’s Head of Go-to-Market for ASEAN, spoke with Vijay Seshadri—Chief Architect, JioStar, about building the experience for more than 15 languages in about eight weeks, and the lessons for leaders taking AI from demo to production.
What convinced you that AI would fundamentally change how people discover content?
Content discovery has evolved very little in the past 25 years. Recommendations were the last major shift. Much of what followed has been an iteration of the same idea.
But choosing what to watch is deeply personal. A person might say, “I’m feeling sad. Show me something that will cheer me up.” Even that simple request contains a lot of nuance. What kind of sad? What usually cheers that person up? Do they want comedy, comfort viewing or something completely distracting?
A traditional recommendation system may struggle to understand that moment. Conversation gives the viewer a way to explain it. We call this a voice-visual interface.
Listen
How did you turn that idea into a product in time for a major cricket tournament?
We began working through the concept in October and November, with a major cricket tournament coming in February. We had roughly two months and two very different audiences: entertainment viewers and cricket fans.
An entertainment viewer might say, “It’s Friday evening—surprise me,” or describe a movie without knowing its title. Sports viewers may want a more specific update, like fall of wickets, a series of sixes, or the match in which a player scored a certain number of runs. Cricket experts may want statistics about every ball.
These are very different discovery problems. We worked on bringing entertainment, sports moments and detailed cricket statistics into one experience, across multiple languages, in a very short period.
At JioStar’s scale, what tradeoffs shaped the technical design?
Very early, we framed the problem as a three-way tradeoff among accuracy, latency, and cost. Every engineering decision had to balance all three at once.
Voice made that especially important. More than 60% of our users use voice rather than text: people prefer to say what they want to watch. The response still has to be relevant, fast, and economically viable at scale.
Listen
What does an effective evaluation system look like in production?
I think about it in two parts: an evaluation framework and a validation layer. Before production, the evaluation framework should prompt changes. In production, a feedback loop should turn customer behavior and failures into new eval cases.
That flywheel can become self-amplified, but it is extremely difficult to get right.
Domain experts are essential. For sports-statistics evals, we worked with people such as sports-magazine editors who understood what serious fans might ask. You cannot begin with a prompt alone; you need to seed the system with deep human expertise.
How did a small team build and launch the experience in about eight weeks?
One thing we got right was the team. We started with a small team of data scientists and engineers around a clear problem statement. OpenAI’s forward-deployed engineers worked alongside us to further identify the few things we absolutely had to get right.
The first was scope. A voice or text interface lets users ask almost anything, so we began by deciding what the system should not answer. Guardrails came first.
For evals, we began with a seed dataset and used models to expand it with more variation. We created what you might now call a maker-checker pattern: one model helped determine how to answer a question, while another acted as a validator—an LLM as judge—with a competing objective.
That raised another question: who tests the judge? Designing the validator was itself an evaluation problem. Codex helped the team accelerate work such as generating eval cases and updating the system, but faster building did not remove the need for judgment and validation.
Looking back, what would you do differently?
I would invest earlier in production monitoring for model efficacy.
Traditional infrastructure measures such as P99 latency remain important, but they are not enough. You also need to monitor model efficacy in production.
What should executives keep in mind as they move from AI experiments to production systems?
First, there is a large gap between what technology can do and the reality inside an enterprise. If your company has not matched every frontier-model announcement, you are not alone.
Second, keep focusing on outcomes rather than activity. It is easy to mistake visible motion for meaningful progress, particularly when companies emphasize input metrics. Lines of code generated, for example, do not tell you whether you created meaningful value.
Listen
Finally, most enterprises underestimate the human skill and agency required. This cannot be only a generic skilling program. Leaders need people who can apply these tools with judgment. Give a strong engineer a tool like Codex and the impact can multiply; without the judgment to validate production systems, the risk multiplies too.
You have a rocket in your hands. Especially in production systems, you need validation and guardrails, and you need to give the keys to the right people.
