Updated March 5, 2026
0:00 Welcome to the Deep Dive, brought to you by Colaberry AI Research Labs and Carl Foundation. Imagine for a moment, the sheer complexity involved in manufacturing just one single tire. It's immense, isn't it? Right. Every second, every degree of heat, every tiny movement of machinery, it all counts. 0:16 Now picture trying to find a minuscule, almost hidden inefficiency in that whole process. Not easy. Not easy at all. And not just in one machine, but across hundreds of them, spanning different continents. That was the, well, the staggering challenge facing Apollo Tires, a major international tire manufacturer. 0:34 Today, we're diving deep into their really groundbreaking collaboration with Amazon Web Services, AWS. Mhmm. They've leveraged something truly cutting edge, Agentic AI, specifically to optimize their complex production lines. So our mission for this deep dive is to really unpack how this complex real world industrial challenge was tackled using these highly technical advanced AI solutions. Yeah. 0:57 Get into the nuts and bolts of it. Exactly. We'll look at the methods, the results, which are pretty surprising, and the key learnings. We wanna pull back the curtain on the technical vocabulary, you know, the terms that underpin this kind of innovation. Get ready to understand how generative AI is, well, profoundly transforming industrial operations. 1:17 Okay. Let's unpack this journey then. Apollo Tires, huge global player. Production facilities in India, Europe. They kicked off this big digital transformation. 1:29 Right. Across the whole business. Whole business. But manufacturing was a key target. And, specifically, they focused on their highly automated curing presses. 1:37 These are absolutely critical in making tires. Right? Absolutely vital step in the process. So before they brought in this AI solution, what was the, the the specific bottleneck? What were they really struggling with? 1:48 What were the limits of how they were doing things already? Well, what's really fascinating here is the precise challenge, reducing something called dry cycle time or DCT for these curing presses. DCT. Yeah. Now you might picture a modern factory as, you know, fully automated, lights out manufacturing, that kind of thing. 2:06 But identifying these tiny inefficiencies that often fell to the plant engineers. Manually. Manually. They were analyzing industrial IoT data that you know, sensor data coming off the machines, but looking at it through descriptive dashboards. Just charts and numbers, basically. 2:23 Pretty much. And this wasn't a simple task. They had to sift through literally millions of parameters, things like different SKU start keeping units, meaning different tire models Mhmm. Various cure mediums used in the process, different suppliers for raw materials, specific machine types, and then getting even more granular, individual subelements and even subselements of the curing process. Wow. 2:46 That sounds incredibly complex to track manually. Oh, it was. The sheer scale of this manual effort was, well, incredibly time consuming. It's like trying to find a needle in a haystack, except the haystack keeps getting bigger and changing shape. So how long did it actually take? 3:00 The process could range from about seven hours per issue just to diagnose one problem. Seven hours? Down to maybe an average of two elapsed hours just to get an initial handle on it. And, building on that, the question is, why was it so tough? Why couldn't existing tools handle it? 3:18 Yeah. What were the limitations? Well, traditional root cause analysis or RCA tools, they simply couldn't perform what's called sublimental level analysis. Sublimental meaning? Meaning drilling down into the tiny steps within a larger step. 3:33 Imagine the tire curing process is like a complex dance with lots of precise movements. Okay. Traditional tools could tell you if the whole dance was off rhythm, maybe which dancer was stumbling, but they couldn't tell you which specific foot movement or tiny gesture was causing the delay. Gotta Lacks the granularity. Exactly. 3:50 It couldn't get down to those tiny activities causing the real delays, so it required subject matter experts, SMEs from different departments to collaborate, often physically getting together Which takes time. A lot of time. And because the insights weren't real time, any corrective actions were significantly delayed. They were looking to improve metrics beyond just the standard ones like TEEP and OE total effective equipment performance and overall equipment effectiveness. Those are the usual manufacturing benchmarks. 4:18 Yeah. Prestandard. But Apollo wanted to go deeper beyond just the overall score. They needed to optimize those microprocesses. That manual process sounds like a huge drain, a real bottleneck impacting efficiency and responsiveness. 4:33 So given that scale and complexity, what did Apollo Tires and AWS actually build? What was the breakthrough? Right. So to tackle this, they developed something really innovative. They called it the manufacturing reasoner, and it's powered by Amazon Bedrock agents. 4:46 Okay. Manufacturing reasoner and Agentic AI. What does that actually mean in this context? Good question. So if you think about the bigger picture, Agentic AI solutions like this one, they're designed to automate complex multistep tasks. 5:01 The key is they seamlessly connect with the company's existing systems, their APIs, their data sources. Like an orchestrator. Exactly like an orchestrator. In this specific case, the manufacturing reasoner lets plant engineers interact with all that industrial IoT big data using just natural language, plain English. So they could just ask it questions. 5:20 Yeah. Basically, they can ask questions like, why did press twelve have a high DCT yesterday? And get relevant insights and specific recommendations for fixing operational issues in the DCT process. How does it get the data? The machines themselves are fitted with industrial IoT sensors. 5:36 These sensors stream data in real time sensor readings, process parameters, operational status, event logs, condition monitoring, you name it, directly to the AWS cloud. Forming a central data pool. Precisely. A centralized data lake. Then the manufacturing reasoner uses generative AI powered by Amazon Bedrock to pull out actionable insights from this massive, constantly updating dataset. 6:00 That sounds incredibly powerful. Almost like having a super intelligent detective team just on demand. That's a good way to put it. Can you walk us through the technical steps? Like, when an engineer ask a question, what actually happens behind the scenes? 6:11 What are the different agents doing, and which AWS services make it all work? Absolutely. Let's trace a query. It starts when the engineer asks a question in natural language, maybe typing it into a web app like a specialized chatbot interface. This app runs on Amazon Elastic Compute Cloud, Amazon e c two. 6:30 E c two, AWS's scalable computing service. Right. Provides the virtual servers. Yeah. So the question gets picked up by the primary AI agent. 6:38 Think of this agent as the, the dispatcher or the lead detective. The orchestrator again. Exactly. Its job is to analyze the question, figure out how complex it is, and then decide which specialized agents running within Amazon Bedrock agents need to be called to handle the multistep reasoning. Okay. 6:55 So it delegates? It delegates intelligently. And Amazon Bedrock agents uses tools like Amazon Bedrock knowledge bases and the vector database capabilities of Amazon OpenSearch service. Knowledge base is in OpenSearch for context. Precisely. 7:09 Think of the knowledge bases as super fast. AI ready libraries holding relevant technical info, procedures, past issues. OpenSearch service lets the system do incredibly fast searches based on the meaning of the query, not just keywords, to pull in all the necessary context. Okay. So the primary agent calls specialized agents. 7:28 Like, which ones? Well, there are several working together. For instance, there's the complex transformation engine agent or CTE agent. CTE agent. Yeah. 7:36 It acts like an on demand data analyst. It understands the query's context and performs specific data transformations needed to answer it, pulling, combining, reshaping that raw IoT data. Got it. And for the root cause part? That's where the RCA agent comes in. 7:50 This is the forensic expert. It constructs a pretty sophisticated multistep workflow using multiple large language models or LLMs. Multiple LLMs. Yes. Specifically designed for detailed automated root cause analysis. 8:03 This is absolutely crucial for digging into those really complex diagnostic scenarios, getting to the why. Okay. CTE for data, RCA for diagnosis. What else? So concurrently meaning at the same time, using multiple threads to speed things up, the primary agent calls two other important agents. 8:20 Working in parallel. Exactly. First, the explainer agent. This one uses Anthropic's Claude Haiku model. Hiku is known for being fast and efficient, so it's great for generating clear explanations quickly. 8:32 Quickly. Explain the reasoning. Yes. In two parts. First, it gives you the step by step logic showing the query execution any CTEs used, basically showing its work. 8:41 Second, it provides a brief conclusion referencing specific data records it pulled from Amazon Redshift. Redshift, the data warehouse Okay. And the second parallel agent. That's the visualization agent. This one's powered by Anthropic's Claude Sonnet model, which is a bit more capable, good for creative tasks like like code generation. 8:59 Generating charts. Exactly. It dynamically generates Plotly chart code. Plotly is a popular library. This means the system creates live interactive charts based on the specific data for that query, not just static images. 9:13 Very cool. So you get the answer, the explanation, and the visual. Correct. Finally, the primary agent gathers all these pieces, the relevant data records, the explanation from the Haiku agent, the chart code from the SONNET agent, and streams it all back to the chainlet application on e c two. And the engineer sees it all rendered neatly. 9:30 Right. Dynamic plots, data formatted in tables, the whole thing, a seamless flow from question to insight. You mentioned something else, guardrails. Ah, yes. Very important. 9:42 Amazon Bedrock guardrails are layered into this whole system. Think of them as safety nets and rule enforcers. How so? They let Apollo set custom filters and response limits. This ensures interactions are secure, relevant to the manufacturing context, and compliant with their operational rules. 9:59 Critically, they also help prevent errors by double checking information validity, which is absolutely vital for accurate RCA. You can't afford mistakes there. That whole architecture sounds incredibly advanced, really impressive system design. So let's bring it back to the factory floor. What was the actual tangible impact? 10:15 What were the measurable benefits Apollo tires saw from deploying this manufacturing reasoner? Yeah. The impact was well, it was significant. Really significant. How significant? 10:26 Okay. Get this. The Agentec AI solution achieved an approximate 88 reduction in the effort needed for assisting root cause analysis for dry cycle time. 88%. That's huge. 10:37 It's massive. That generative AI assistant cut the DCTRCA time from potentially seven hours per issue down to less than ten minutes per issue. Wow. From a full day's work to less than a coffee break. Pretty much. 10:52 That is an astonishing leap in efficiency. This virtual reasoner really became like a high powered microscope for their operations. In what way? It identified specific focus areas across more than 25 different automated sub elements or activities within the curing process. The granular level again? 11:09 Exactly. And it did this across over 250 automated curing presses, handling data for more than a 140 different skews, three types of curing mediums, even accounting for two different machine suppliers, and across three separate manufacturing plants. The scale is incredible. It really is. And beyond just the speed, the system provides real time triggers for any anomalous shifts in DCT. 11:33 This actively supports what's called an error prevention or poke yoke approach. Poke yoke. Uh-huh. Mistake proofing. Precisely. 11:40 It's a Japanese term. It means the system doesn't just find problems after they happen. It helps prevent them from occurring or reoccurring. It builds quality right into the process. Any other benefit? 11:50 Oh, yeah. Unparalleled observability engineers can now see elemental wise cycle time with graphs and statistical process control or SPC charts to monitor stability. They can do direct press to press comparisons using real time streaming data, which was basically impossible before, and they get on demand RCA with daily alerts sent straight to the relevant manufacturing SMEs. And the bottom line, the financial impact. The targeted financial benefit just from this initial rollout in the passenger car radial PCR division across those three plants is projected to be around 15,000,000 Indian rupees per year in savings. 12:25 15,000,000 INR. Impressive. Yeah. And Harsh Marthan, who's the global head of the digital innovation hub at Apollo Tires, put it really well. He said, and I'm quoting roughly here, the precision of generative AI driven insights has enabled plant engineers to not only accelerate problem finding from an average of two hours per scenario to less than ten minutes now, but also refine focus areas to make improvements in cycle time beyond TEEP. 12:51 So it's not just faster. It's enabling deeper optimization. Exactly. Moving beyond just overall efficiency numbers to fixing the fundamental microprocesses. Those results are genuinely jaw dropping. 13:03 Really highlights how targeted AI can create massive value. But look, no complex system deployment happens without hitting some bumps in the road. Right? Absolutely not. There are always challenges. 13:14 So what were some of the significant technical hurdles Apollo tires faced on this journey, and what did they learn from overcoming them? Yeah. That's a critical question. With results like these, you know, there were lessons learned. They really highlighted, four key takeaways from this pioneering work. 13:29 Okay. What's the first one? Firstly, applying generative AI to streaming real time industrial IoT data. Data. It demands extensive research. 13:38 It's not like working with a static dataset. Because the data is constantly changing. It may be messy. Exactly. You've got gaps, fluctuating reading, sudden spikes. 13:48 It all needs intelligent handling. Definitely wasn't a plug and play kinda deal. Makes sense. What was the second takeaway? Response times. 14:07 Initially, using Amazon Bedrock, especially with multiple agents involved in that reasoning chain, the response time for a full cycle often exceeded one minute. A minute. That feels long if you're an engineer on the floor needing answers now. It is too long. So they worked hard on optimization. 14:23 They got significant speed ups by carefully selecting the right LLMs for specific tasks. Sometimes a smaller language model, an SLM, was faster and sufficient. Choosing the right tool for the job. Exactly. And a key optimization was intelligently disabling unused workflows within the agent structure. 14:41 If a query didn't need a chart, for example, the visualization agent wouldn't even be triggered. Streamlining the process. Right. This meticulous fine tuning got the response times down to roughly thirty, forty seconds. Much better. 14:54 And it really boosted efficiency in the user experience. Okay. Faster responses. What was the third challenge? Generating those visualization charts accurately, especially with large datasets. 15:04 The initial plotly code the AI generated, well, it often had inaccuracies or just couldn't handle large data volumes correctly. Charts would look wrong or fail completely. So the AI wasn't a perfect coder out of the box. And not for this specific complex task. They had to implement a process of continuous refinement, iterative development. 15:22 They fed back corrected code examples, fine tuned the prompts to teach the model how to generate dynamic Plotly code that could handle data efficiently within a data frame no matter how many records there were. Teaching the AI through feedback. Essentially, yes. Crucial for turning that raw data into truly useful visuals. And the fourth key learning. 15:42 Data consistency. This was paramount. They solved potential issues here by being really rigorous about the data format being ingested into their Amazon data lake, the system's knowledge base. How so? All the data had to be structured in a very specific JSON format, like a strict template question, the natural language question, query. 16:02 The CTE scripts used metadata, relevant metadata. A standardized structure. Precisely. This strict format ensured the system could reliably understand and process every piece of incoming information, preventing errors and guaranteeing that accurate root cause identification. It's fascinating how much detailed refinement and, well, precise engineering goes into making these advanced systems work reliably in the real world. 16:28 It's not just about the core AI model. Not at all. The integration, the data handling, the optimization, it's all critical. So looking ahead, what does this all mean for the future of manufacturing and AI? What are Apollo Tire's next steps? 16:40 Where do you see this kind of technology heading more broadly? Well, Apollo Tire isn't stopping here. They're already scaling this solution, taking it beyond tire curing into other manufacturing areas, other locations. They're really pushing towards that industry five point o goal. Industry five point o. 16:55 That's the one emphasizing human robot collaboration. Right? Exactly. Where technology human capabilities rather than replacing them. And Amazon Bedrock will be absolutely pivotal as they extend this multi agentic, our retrieval augmented generation solution. 17:11 They'll use specialized agents for different functions and different processes. So more specialized agents for more tasks? That seems to be the direction. They're also relentlessly focused on benchmarking and further optimizing those query response times. Shaving off even more seconds means faster decisions on the factory floor. 17:29 Continuous improvement. Always. And beyond that, they're actively exploring using generative AI with Bedrock for other manufacturing processes and even looking at non manufacturing areas within the company, like logistics or supply chain perhaps. Interesting. It really points towards a future where AI and humans collaborate much more extensively. 17:49 The AI amplifies human intelligence, turning overwhelming data into intuitive, actionable insights for the experts. Experts. This whole concept of asset sweating, you know, getting the absolute maximum efficiency out of existing machinery through these intelligent factories that can basically talk in natural language. Yeah. It it's truly transformative, isn't it? 18:09 It really changes the game. It makes you wonder if this kind of highly specialized agentic AI can unlock such precise, granular efficiencies in a process as complex as tire manufacturing. What other deeply nuanced domains could be revolutionized? Mhmm. Good question. 18:25 Think about health care diagnostics maybe or complex global logistics networks, scientific research. What hidden capacities might we uncover across other industries when we empower human experts with this level of granular real time insight. Yep. The possibilities, they feel pretty limitless. It's an exciting time for AI and industry. 18:43 That's for sure. Thank you for listening in. Subscribe and follow Colaberry and c a r l on social media links in the description, and check out our website, www.colaberry.ai podcast for more insights like this.
