Transcript
Sam: Welcome to our Applied Podcast. I’m your host, Sam Duchscherer. Today, I’m joined by Brian Gowling and David Newton to explore the evolution of our RTD product, which is built on over 30 years of industrial experience and hundreds of deployments. And now, advancing into powerful AI-driven capabilities. Brian, David, welcome.
Brian: Hey, Sam.
David: Hey, Sam, thanks for having us.
Sam: All right, Brian, let’s start with you. From your perspective and personal experience, why is RTD so widely used today? And why do customers continue to regard it as an industry standard?
Brian: Thanks, Sam. Well, from my perspective, real time dispatching became widely adopted because it solves a fundamentally hard problem in the semiconductor manufacturing space, and that’s making the right decision at the exact moment conditions change.
So, when we think about it in a fab, conditions are constantly changing. Tool states, lot priorities, where bottlenecks are, they can pop up whether they’re planned or not, and they can change within minutes. Traditional scheduling systems simply can’t keep up with RTD. And RTD fills that gap by continuously evaluating the full factory state, and it executes these dispatch decisions in real time. And often it’s processing thousands of requests within seconds. What’s kept RTD as an industry standard, though, goes beyond just the speed. It’s really a combination of this proven impact and flexibility. Customers trust it because it consistently improves core metrics like your cycle time, your tool utilization, or your OEE, as well as your overall factory throughput.
It also allows customers to encode their own operational logic through our configurable rules in Formatter. This ability to tailor decision making to each fab’s unique constraints is critical in an industry where no two factories operate the same way, and I don’t think I’ve been in a factory where that was the case.
Just as important, I guess, RTD centralizes that decision making, so instead of relying on the operator’s manual judgment—the tribal knowledge that may exist in the factory—it really automates and standardizes the dispatching decisions across the operations and significantly reduces that variability and improves consistency.
Sam: Can you let the users know, how long have you been using RTD personally?
Brian: Yeah, so I’ve been involved with APF products and RTD for about 15 years.
Sam: Oh wow. So true expert here on the podcast for you guys.
David, what about you though? Let’s get your perspective on this. Why do you think RTD has earned so much trust in the semiconductor industry?
David: Thanks for the question, Sam. So honestly, I think part of the reason is the consistency and the transparency. One of the things that Brian brought up was the complexity of trying to make some of these decisions in real time. And a couple of the beautiful things about RTD is if you run those queries and you run those analyses over and over again, you get the same results and the systems are open. We can look at the rules. We can see exactly how they’re functioning, what they’re doing. So, from a user standpoint, you can truly believe what it’s telling you. You can walk through the rule yourself and see exactly where the logic is doing its thing and how it’s doing it. And you can understand the answer, and that answer is repeatable; it’s verifiable; and again, the logic is open and available for view. I think the customers have realized that transparency and consistency really set us apart from other systems.
Sam: And yourself, how long have you been an RTD user?
David: Okay, similar, I would say close to 16 years, 17 years total time with RTD as an owner and user.
Sam: Wow, so one more year over, Brian. Thirty years collectively between the two of you. Wow, super great.
You guys hinted on it: with longevity comes complexity. I guess my next question goes to you, Brian. How do legacy rules and logic start to create challenges for customers over time?
Brian: That’s a good question and one that I can relate to, as well as I’m sure David with their time using APF RTD. You know, one of those realities of that long-lived RTD deployment is that success breeds complexity, as you mentioned. And over time, our customers or even ourselves have continuously added rules to handle new products, process changes, or even edge cases. And what starts as a clean, well-constructed, simple rule can evolve into a highly intertwined system of local and global logic. It often is built by multiple engineers, and not only that, across many years. The challenge is that logic becomes deeply embedded in the day-to-day operations and, in many fabs, the rules sort of encode that tribal knowledge that is more on the coder base or the developer base (I’m not talking about the operator base as I did previously). But, that knowledge isn’t always well documented or easy to interpret, so new engineers can struggle to understand when they come on board. And they don’t obviously understand the certain dispatch rules and the decisions that are made. And even small changes can carry unintended consequences because of hidden dependencies across the rules. These rules are not just flat; there are many macros, there’s many things that are dependent upon each other.
Another issue is scale. So RTD is designed to evaluate the full factory state in real time. But as rule sets grow larger and more complex, maintaining performance clarity in the governance becomes harder. Without strong structure and a life cycle management, customers can end up with rules that are redundant, conflicting, or overly conservative. So ultimately, the challenge isn’t that RTD logic becomes less effective, it’s that it becomes harder to really understand; it’s harder to trust, and it becomes harder to evolve as it gets a little bit larger and more complex. So that’s why many of our customers, including David and I, are now focusing on ways to have better rule transparency to manage this complexity over time.
Sam: So David, is it true? Do you have a personal story where you can maybe relate to some of those pain points?
David: Absolutely. So, quite a few years ago, there was a specific rule multiple layers deep (I would have to say at least four layers of various macros and sub-macros and functions) that was functioning the way we expected it to except, as Brian mentioned, in certain edge cases. And it took a significant amount of time because of that complexity to drill down and use, at the time, existing debug options to find what was wrong with it. It was a particular macro that, as all the others had been updated over time and had been recompiled and changed and had been used to take advantage of new functionality and stuff, this particular macro hadn’t been changed in several years. And as Brian had alluded to, you have multiple owners and you have a long list of developers that have touched this particular role so it took, I would say, easily two weeks, three weeks to find the root cause of what was happening and why it wasn’t reacting the way we expected it to.
So bottom line, as these rules become more complex and without a serious version control and documentation system, it does become difficult to manage these. Although, as Brian alluded, we are working on some things to try and help with that.
Sam: Yeah, that’s crazy. Two to three weeks just to find the root cause. So, Brian, just to play into that a little bit, and again, sorry to focus on the challenges before we get to the fun AI topics, but how do you see the shifting workforce play into these challenges that you and David listed?
Brian: Yeah, this is a good question because it’s real and everybody feels it and it’s a growing challenge. So, as you alluded to, the workforce shift is—particularly with retirements and just increased mobility of people jumping to different roles or different companies—our customers (and we’ve experienced it ourselves) are losing a lot of the engineers who originally built and tuned those original RTD rule sets and grew them organically over time. And those systems often contain years, sometimes decades, of accumulated operational knowledge, but much of it lives in the logic itself rather than in formal documentation, as David was mentioning. And what I’ve seen is that the new engineers walk into these environments; they’re either new to the company or just out of school and face a steep learning curve.
The rules are complex, they’re highly interconnected, as we mentioned, and they’re often written in ways that reflect how the original author thought about the problem. And without that context, it can be difficult to understand what the system is doing and why.
This creates a few risks, right? First, it’s onboarding; it slows down. New hires take a lot longer to become effective. Second, confidence erodes. Engineers may hesitate to make changes to the rules, which limits your continuous improvement plans that you have in terms of improving your factory metrics. And third, there’s a real dependency risk where there are only a small number of experienced individuals who really fully understand the critical parts of the real system. So, the workforce shift isn’t just about people issues. It directly impacts how effectively our customers can sustain, evolve, and extract value from RTD over time.
Sam: David, would you agree with that? Do you see any additional challenges?
David: No, I think Brian really hit it on the head. The newer developers that are taking a look at these rules, especially given some of these legacy rules that have been out there for a while and have developed that complexity, really have to develop a lot of expertise before they become effective. And they really have to spend a lot more time trying to figure out what that rule does and how it functions before they can really make an impact in terms of updating that rule and maybe taking advantage of new data or new understandings of how you want your business logic to work. I think that, as Brian said, that extended onboarding really could impact how valuable a new employee could become, especially if you have a previous really experienced employee leave that had all that tribal knowledge and could understand the difference between three weeks and possibly a month troubleshooting and overall.
Sam: Yeah. Well, you guys have set the stage for the start of the discussion of AI. And Brian, I will start with you because, true transparency, I have accidentally misspelled your name as “brAIn” in multiple emails more times than I would like to admit, so I feel like the next set of AI questions feel especially appropriate. So, Brian, where do you see the first practical quick win when integrating AI into RTD?
Brian: Yeah, thanks, Sam. Well, you know, it’s maybe a Freudian slip when you call me Brain instead of Brian, but I appreciate the compliment. I think the practical quick win for AI within RTD is not optimizing dispatch itself. It’s really helping engineers understand the system faster. So, from what we were talking about previously, and from what I’ve seen and experienced, the biggest bottleneck isn’t the algorithm; it’s the human ability to interpret complex legacy rule logic. And AI, it can really immediately add value by acting as that conversational interface on top of RTD. So, really, I guess, essentially allowing engineers to ask questions like, what does this rule do? I mean, it seems like a very basic question, but anytime you open up a rule and you look at it for the first time, that’s exactly what you’re thinking about in your subconsciousness. What does this rule do? And, you know, you’re going through it to get a clear, plain language explanation today and, not unless it’s extremely well documented, annotated, and everything else, will you get that answer.
That’s really a powerful case because it addresses a universal pain point, as I mentioned and we had mentioned previously, that slow onboarding and that heavy reliance on a few experts that are knowledgeable in RTD and a Formatter and Activity Manager. Instead of digging through documentation or tracking down that original author, we think engineers can instantly understand, troubleshoot, or even improve the rules through AI. And that—again—that impact would be immediate and low risk. You’re not changing any of the dispatch logic; you’re changing how people interact with RTD through the formatter. And that means faster onboarding. Again, you’re reducing that risk and quicker resolution of any issues that you have without disrupting production.
You know, really the first one isn’t smarter AI decisions. It’s really faster human comprehension of what already exists. I think once teams can confidently understand RTD’s behavior, then you can layer in some more advanced AI use cases or agents.
Sam: Brian, without giving away too many Applied secrets if you will, do you see any other milestones for RTD that might be coming sooner rather than later?
Brian: Yeah, so I guess beyond just things that we’ve talked about, about rule understanding and improving onboarding, there are a few other near-term AI wins that are already emerging and can deliver value quickly. One of the biggest is just faster root cause analysis. Today, diagnosing why dispatch decisions lead to a bottleneck or a performance issue can take hours of manual investigation. AI can shorten that cycle by really correlating data across rules, across equipment, performance signals, and surfacing likely causes much faster.
And another one would be guided rule optimization. So instead of engineers manually tuning rules, AI can suggest improvements, highlight the inefficiencies, any conflicting logic or missed constraints based on actual factory behavior. And we’re also seeing that value in real-time decision support where AI really helps operators respond to disruptions like tool downtime or recommending recovery actions more quickly than traditional workflows. While full autonomous optimization is a little further out, these incremental capabilities like analysis and guidance and decision support are really practical, near-term wins that customers can start to benefit from soon.
Sam: David, what do these milestones really enable for a day-to-day RTD user? Paint the picture for me.
David: Well, we had talked a little bit earlier about a previous story—that I’ve had struggles with RTD and especially complexity and so forth, and that legacy rule trap that happens. And Brian had a great point talking about diagnosing these rules.
One of the biggest sort of open tasks that you end up getting as a rule developer, or if you’re supporting RTD in some way, is the user on the floor asking a question as to why. Why did the rule give me this answer? And traditionally, as I mentioned, it can take a significant amount of time to go through the rule in the various layers. Whereas, if you’re asking AI—and this is one of the great things about the applied AI system integration with RTD—you can start as simple as saying, you know, “How does this rule work?” and ask it for as much detail as you want. And it’ll give you a block-by-block, layer-by-layer explanation of the rule’s functionality.
From a quick standpoint, a brand-new user, first time supporting sort of an on-call situation and they’re asked this question, that may give them the answer, right? They may be able to get that answer within five or 10 minutes. To go further, as Brian mentioned, if we’re actually asking the rule, “Why would you provide this output?” and AI works through the rule and gives you that answer, that’s even like the next level to that. You’re taking that engineer and they’re becoming productive because rather than spending several hours or days walking through the rule and checking each block and looking at it, they’re simply interacting through that prompt and getting the answers they need directly from AI. And they can trust those answers because, again, they could go if they wanted and check that logic manually. So, this really takes that productivity and that ability to immediately be useful and speeds that up for any user. Plus, an experienced user now has another tool in their toolbox to be able to really get that answer and find out what’s wrong.
Sam: You mentioned trust in that answer, and I want to dive into that. And Brian, this is for you. It will be our final question before the lightning round. How are we ensuring RTD integrated with AI has a way to validate and gain customers’ trust?
Brian: Yeah, another good question, Sam. So, trust is absolutely critical, you know, especially in production systems like RTD, where decisions are directly impacting factory performance. It’s dollars we’re talking here. The approach we’re taking is, again, it’s deliberate. We don’t want to change RTD. RTD is great, but we want to augment it with AI. So, it doesn’t replace RTD; it’s just augmenting it.
First, the core dispatch logic that we have for RTD really remains unchanged. AI sits on a top layer to explain and guide and recommend rather than just, you know, autonomously control these decisions. That level of trust is important. It builds confidence. Customers know the proven RTD engine is still in charge of the execution. So that’s critical. They need to understand that.
Second, there’s a strong emphasis on transparency and explainability, so AI doesn’t just suggest a change. It explains why in plain language so engineers can validate the logic before they apply anything, and this keeps the humans happy and firmly in the loop.
And then, third, we’re incorporating validation safeguards. AI generated recommendations are checked against existing rules and system behaviors to ensure consistency and prevent unintended impacts. Ultimately, trust is earned. We don’t just expect you to take our word for it. It’s earned by design. So, you know, keep RTD stable, make AI transparent, and ensure that every change is really observable and verifiable.
Sam: Great answer. Great answer. All right, guys. Now we’re going to move to the lightning round questions. And I do this in all my podcasts. I’m hoping that they’re a fan favorite. And with two of you guys, I actually have four questions rather than the three that I normally have. So, let’s go through these four lightning round questions. Give it your best shot. There’s no wrong answer. Just answer what feels natural, okay? So David, let’s start with you. No need to be nervous. What’s the biggest misconception about RTD?
David: The biggest misconception that I’ve seen in terms of people being introduced to RTD brand-new is that it can do all of this stuff and it’s this magic box that’ll solve all their problems with no interaction. And what people have to understand is, it is a great tool, but it requires (as we’ve talked about here) development, and interaction, and validation. And it requires some of that extra work to really get the most out of it, but it is an amazing tool that does a great job.
Sam: All right. Brian, a different question, but what tends to slow down AI adoption for RTD users and how can they move past it?
Brian: Well, we did talk about it just a little bit ago with the trust. So, you know, what tends to slow down AI adoption in RTD is less about the technology and more about confidence and the risk or really that trust that we were talking about a little bit ago. And customers are understandably cautious. RTD is a mission-critical application so anything that feels like it could disrupt this proven dispatching logic that has been there for decades raises concerns. There’s also hesitation around perhaps data quality or validation or whether AI can truly be trusted in the production environments. So, there’s that.
I would say another barrier is the practicality. AI could mean a lot of things to a lot of different people. It can feel like a big complex transformation and teams may struggle to justify the effort versus immediate operational priorities that they may have, so it kind of gets pushed off to the right. The way past this, I think, is really start small and have low risk. Focus on those non-intrusive use cases, like we mentioned before: rule explanation, troubleshooting, or guided optimization—areas that improve how people work with RTD rather than changing the entire engine itself. You know, it’s an engine that’s going while production is running, so we don’t want to disrupt that. And when our customers see that value from those smaller, low-risk improvements, such as that faster onboarding or quicker root cause analysis or better decision confidence, naturally that will build trust and expand adoption from there.
Sam: Great answer. All right, two more; one for each of you guys. All right, David, hopefully this one’s a good answer from you, but if RTD had a job outside the factory, what would it be?
David: I honestly think RTD would be the world’s greatest librarian because it can give you the answer to any question you want. That’s my answer.
Sam: Electronic librarian or…?
David: Just the greatest librarian. Electronic, robot, whatever. I think it’s like that great librarian that you had back in the day in school that you could ask her or him any question, and they just knew the answer automatically.
Sam: Yeah, I know what you’re referring to. All right, Brian, a little bit different, but if RTD were a recreational hobby, what would it be?
Brian: A recreational hobby. Well, my son has gotten into chess a lot, and so I’ve been playing a lot more with him. So maybe RTD would be something like a game of chess. So it’s, you know, I think of chess, it’s not really loud or flashy like RTD. It’s deeply strategic and you’re constantly thinking ahead. Every move is based on evaluating the current state of the board—you know, anticipating what my son might do next, or maybe balancing a short-term gain of taking like a rook or something else with a long-term outcome of maybe I’ll lose my knight with that move.
And just like RTD, it’s about making the best decision in the moment, knowing that conditions can change quickly. I think it’s also a hobby where, even in my experience, it compounds over time. The more you play, the more patterns, strategies, and edge cases you recognize, very similar to how RTD rules evolve and capture years of operational knowledge. And I guess to an outsider, it can look complex, but to those who understand it there’s clear logic and elegance behind every decision.
Sam: You guys gave very different answers, but actually very similar at the same time. I can imagine this librarian just, you know, years of just knowledge and just as you said, Brian, right, where it’s compounding over time as you play chess. Really good.
Sam: So thank you both. It’s clear that RTD’s future with AI isn’t about really replacing expertise or people, but really amplifying them. Best of luck to you guys in this AI race. It’s going to be an exciting journey ahead of us. I really appreciate you guys being here.
Brian: Thanks, Sam. I really appreciate it.
David: Thanks, Sam.
Sam: All right, and for everyone listening, we will see you in the next podcast. Thank you.
