Welcome to day one of the KeyBanc Technology Leadership Forum. Thanks everybody for being here. My name is Brandon Nispel. I cover communication services for KeyBanc. This presentation is a 25-minute fireside chat. We have Jeremy Legg, CTO of AT&T. Jeremy, welcome. Yeah, thanks for having me. It's a good place to have a conference. Absolutely. Real quick, safe harbor for AT&T. Before we begin, I need to call attention to safe harbor, which says some of the comments today may be forward looking. There's risks and uncertainties. Results may differ materially. Additional information is on AT&T's website. Again, Jeremy, thank you. Yeah, I'm glad to be here. Why don't we just get started? Help us understand your background, role at AT&T, and really your key priorities from a technology standpoint in 2025. Sure. I actually came over from the Time Warner merger, WarnerMedia merger. I was CTO over there. When John Stankey moved over to AT&T, he brought me with him. My responsibilities at AT&T are all of the technology there, with the exception of the operations of building out the last mile. I don't have the teams that are building the last mile. We do all the network architecture in my group for it, but we don't have the operations to climb up a tower or put the fiber in the ground. All the other stuff sits in my world. Got it. How would you characterize sort of your top priorities for 2025? Convergence is obviously the thing you hear a lot about, and that's perceived, I think, as a marketing bundling opportunity, which it certainly is. In my world, convergence is about how we actually get both sides of our scale businesses running over the same pipe. How do we actually become the lowest cost transport provider on the internet? What we're in the midst of doing right now is actually converging our wireline and wireless networks together so that as we think about how we amortize the cost of that, we're doing it over two businesses versus one. Historically, those have been pretty separate networks. Increasingly now, we're actually unifying all of that. Got it. You joined AT&T, I think, about five years ago. How do you sort of help us understand your excitement and the opportunity that you have in front of you from a technology standpoint? It's really an exciting time to be in telecommunications. I mean, you think about the kinds of investments that are going into the ground, going up in the air and satellite. It's really, you know, one of those moments where all the technology is transforming. What we embarked on, this began probably about four years ago, was actually removing the proprietary hardware out of our core backbone that goes around the country, so our core ring of our network. That's now software defined. That's x86 compute, Linux boxes, and commodity chips. What we're now doing is extending that out to our central offices. That's a big deal, right? There's over 4,000 central offices across the country, as well as mid zones ultimately when we start getting into the wireless side. That's now actually removing the proprietary hardware that sits in all of those central offices, as well as all those legacy services, and moving to Linux-based software compute inside of all of those central offices. That is a massive cost restructuring. It's a complete rebuild of the wireline network in and of itself. Our ability in the time frames that we've already articulated as part of Investor Day, we're in the midst now of completing that within those time frames. We actually will be lighting up some of this the first part of next year. Wow. Let's talk about some of your topics that you really discussed at the 2024 Analyst Day. It It was really about network simplification, application consolidation, and really generative AI. We'll hit on all of those, but maybe start by, you know, wireline network. Give us a high-level overview of what's being done. I think you were touching on it there in terms of simplification of sort of the core central offices. Yeah, I mean, to give folks an idea of the size of this implementation, we're laying fiber roughly the equivalent from New York to L.A. every month. That's last mile infrastructure, as well as middle mile infrastructure. We've taken up, as we said in our earnings last quarter from the tax cuts, we're going to be increasing the number of homes passed that we're doing on wireline. The endpoints that we're generating across the network, whether they be consumer endpoints or business endpoints, is going to increase the amount of traffic that sits on that network. In addition, it will be integrating in with the wireless network so that we're going to have essentially a complete rebuild from O- RAN at the RAN to Linux-based compute inside of our wireline network that really transforms our underlying cost structure associated with how we run those services. It's kind of a once-in-a-lifetime opportunity, honestly, or at least a once-in-a-career opportunity to be able to rebuild networks like that. You teased it a little bit, but talk about the approach towards software-defined networking and how you're pushing software-defined networking from sort of the core out to more of the edge facilities. Help us understand what that means architecturally. If you think about the way that these networks have been built historically, if you wanted to put a new router in, you're going to send someone into a central office or into a physical facility, and they're going to have to install that router. What this converts into is the ability to actually download software. You have software-based routing. You don't have to send human beings into those central offices in the same way that you did before. You can manage software updates akin to what you see many device manufacturers doing, where you're actually pushing updates from the cloud down into the infrastructure that sits in the network. That's what's really happening across our broader network, and that's a really, really big deal. For those of you that have ever been in a central office, there is a lot of gear in there. There's a lot of gear that dates back to all the legacy services that telcos have been providing for many, many decades, as well as the new services. You're talking about taking physical infrastructure of many, many, many racks of gear and basically putting it in a couple of racks. When you think about the number of central offices that you have to instrument with that gear, you don't have to put it in all of them. If you have 100 central offices, you may be able to only have the gear in 30 or 40 of them, and they just all talk to each other. Some central offices essentially just become pass-throughs. The physical infrastructure that we have to pay for hardware to put in those central offices goes down dramatically. The labor goes down dramatically, and then your ability from an operations standpoint to maintain that gear is driven by software. CI/CD pipelines and things that you hear about from software companies, that's how we're building that, both for our mobility cores as well as for our wireline network. Talk to us then what that means from a product standpoint, both from like a legacy product and maybe decommissioning some of those, and also from a product introduction, new product introduction standpoint. Yeah, our goal is to have as few of these legacy services as possible. You know it's well documented that we're well down the path of getting through the regulatory environment to be able to decommission as many of those legacy services as we can, and then offer catch products to them that sit on that new technology stack. What it means from a product perspective is that you're, in the same way that you can go to a website or go to an app and instantiate a product from, you know, an Amazon or whatever it might be, it's the ability to now do that with a telco. As you want to spin up a cybersecurity product to protect your network, if you're a company, you can actually go and provision that product through software and instantiate it inside of your network. Those kinds of things you really can't do today. It's much harder to do that. It takes physical gear that you have to put into those places. Once we're at the end of this journey, you're going to be able to do those things. How do you think about partners then from a new product perspective and layering on top from an application standpoint onto the network? Yeah, so there's a host of things that are actually happening in the industry now through CAMARA and TM Forum and API layers that sit on top of these networks. In some cases, I think we want to open this up to the broader industry because back to my original point, how do you get more bits on our network? That's a big piece of that and allowing companies to integrate in. Another area of this, though, is similar to what you see through traditional software companies where you begin to monetize APIs. You don't need to build a product. You're really providing a service that goes back, and that can be anything from location services to security services, quality of service so that people can see the performance of a bit inside of the network. A great example of this is most third-party companies can't really see the traffic in the last mile and the quality of service associated with that traffic. You can open that up through an API and allow people to see what's really happening with the bits in the last mile. That just becomes a service. It's not really a finished good product that you're going to put out into market. We intend to do both. We want to both monetize APIs through services as well as provide new products. There's some things that we've already done to start with that, with Dynamic Defense, which is one of our security products as an example, where you can begin to filter the bad guys at the internet peering points before they ever get down to the endpoints of the devices that consumers or businesses use. Got it. Let's switch gears a little bit, go towards, you know, the wireless side of the network. Talk about network simplification there too. What type of initiatives do you have going on on the wireless side? A lot. Our O- RAN initiative, where we did put at the Nokia, Ericsson components that we publicly disclosed, we're well down the path of putting the Ericsson gear into the O- RAN network as well as opening it up. We actually made one of our first phone calls off of that new infrastructure very recently. When you go back further into the network, into the mobility cores, we've actually built our mobility core cloud native in the public cloud. What that really means is that you're, again, being able to use software to build new products and services into the network itself and use public cloud infrastructure to be able to do that. All of the tooling you see in an Azure as an example, or an AWS, or in a Google, those kinds of services now become available to those mobility cores. We're well down the path of that standalone core. We've got millions of subscribers on it already, and we'll continue to ramp that up as well as finish out O- RAN. O- RAN will take the industry, right? That's not going to be just us. That's opening up of the wireless network in the same way that you think about opening up of the wireline network that I described before. Wireless networks have traditionally been very closed, and you can't just plug into a wireless network. O- RAN changes that equation and allows people through SDKs, RDKs, and other software tools to be able to plug into the network and leverage those services. Got it. I mean, it was a big decision for AT&T to go down this O- RAN push. Talk to us about what got you comfortable sort of making these changes. It was moving. It was a number of things. One was the economics of it, and it made sense for us to do. The second was that we thought the networks needed to be open. That ultimately closed network ecosystems generally break down, and you were starting to see that with a lot of the infrastructure providers for these closed networks. There was a lot of consolidation going on in that industry. The third point is that we got the culture and philosophy of people whose business models were really focused on closed ecosystems to realize that open ecosystems were ultimately going to be, whether they wanted it to be there or not, was ultimately going to be what was going to happen. Once we got all of that stuff aligned, you know, we really became comfortable in moving down this path. We think it's, we continue to believe it's the right path. A couple of years ago, you announced an agreement with Ericsson. Talk about how the partner ecosystem is developing around O-RAN for you specifically. Yeah, so it's a, you know, we want the ability to have multiple radio and antenna providers for a single RAN. We want there to be the ability to have virtualized RAN or centralized RAN and have different sets of software that are running on those baseband boxes. That makes a lot of sense. The long pole in the tent will be the API layers that sit on top of this infrastructure and how much adoption you really begin to see across the industry in leveraging those APIs. The fundamentals of O-RAN, it makes a lot of sense to do it. You'll see as you look and read about O-RAN or vRAN or C-RAN, they're all sort of close cousins and brothers and sisters of the same thing. The biggest issue is brownfield providers versus greenfield providers. If you're a brownfield provider, you already have a RAN at the base of every tower. How are you going to architect it so that you've got 100 RANs that are now coming back to a centralized point? That's a lot of engineering, both physical engineering as well as software engineering. That takes more time than doing a greenfield implementation of that. Most scale providers are brownfield providers like ourselves. Got it. I wanted to shift gears. I mean, we talked a little bit about sort of network initiatives that you had. I want to talk a little bit more about more internal initiatives that you have from a technology standpoint. Maybe help us unpack what you're working on from an internal technology standpoint. Yeah, if you think of the tech stack in sort of simple terms, you have layer one and two, which is what we've just been talking about, which is the physical network itself, the towers, the central offices, all that kind of stuff. As you move up, you get more and more software. The layer one and two is becoming more and more software, but you get more into pure software. You get into things like the mobility core, things like our point of sale systems, our digital applications, and all of the IT infrastructure that supports this stuff. We're rebuilding all of that at the same time as what we're doing down at the base levels. What we're trying to accomplish as a company, as we've talked about, what we did on Investor Day as an example, is over that same window that we're providing the financial guidance to the markets, we're rebuilding the infrastructure of the company to change the cost basis of what it takes to run these networks. That's really hard. We have a lot of old infrastructure. We have a lot of technical debt, just like a lot of telcos do. We've ripped out a significant amount of that. We've already retired a couple thousand applications that we no longer need. We've modernized much of our infrastructure up in the cloud. We're one of the largest cloud partners that one of the hyperscalers has today. We're going to rip out our point of sale systems. We've already done most of our customer care and call center systems, and those have been replaced. Over the next few years, our spending curves associated with what we have to do there are going to go down. Our ability to run the network and be the lowest cost bit transport provider, which is really what our goal is, is achievable. You sort of alluded to it, but help us conceptualize what this end state looks like for you. What does it enable AT&T to do in the next three to five years? If you take, I'll start at the top and then just sort of go down to the base, which is if you go to our digital application, you're going to have personalized services and personalized offers that can go to you because we have that customer relationship. If you go into a retail store, once we complete our Salesforce implementation as an example, we will have all the information consolidated from any calls you've made to customer care, any outages that you've experienced, where you are in your upgrade cycle for your iPhone, basic customer relationship management kinds of capabilities that retail that we have heretofore not had enough of. As you then move down the layer of that, you're running mobility cores and you've collapsed all these old mobility cores because we run a lot of mobility cores today. You've collapsed those cores into that cloud-based standalone core that I described before, and you'll have migrated your basis subscribers onto the 5G standalone core, which changes your cost structure. As you go down even further, you get into what's happening in the central offices, what's happening in the mid zones, what's happening in O- RAN, and the completion of that infrastructure. We are attempting to get all of this done within the guidance periods that we described before, and we're very well down the road on this stuff. It's very real. It's very hard. This is a lot of blocking and tackling and operational support that we have to provide. It requires a lot of software updates. It requires culture change in the people that operate these parts of the network. It's where it's all headed. We have a lot of conviction around getting this stuff completed for no other reason. We don't have any choice. If we're going to be competitive in the markets of the future, we have to change the infrastructure that we have today. Really changing the cost structure too with it. Yeah. Talk a little bit about AT&T's internal initiatives with large language models. Can you give us some examples of how you're using LLMs internally? Yeah, I had the fortune of running the Bell Labs components of the company in my group. We actually have a long lineage in AI. Now, you know, AI is Gen AI in particular, and now agentic AI is the current flavor of the month. We've been doing this for a long time. I'd mentioned before we've got over 600 models in production across our infrastructure. What we've done is, and again, I guess I'm using sort of layer cake metaphors, but we can build LLMs. We do build some SLMs, but our focus is less there. The focus is on how do we leverage that technology and the chips that underlie it for our own data. Because all of these LLMs were trained on the same information. They're trained on the open internet. Reddit is one of the primary ways that the LLMs validate whether they're accurate or not. They don't have any of our data. They don't have our network data. They don't have our customer data. As we've begun to ingest that data into these LLMs, we are tuning it for us. The insights and the data science that we're using are very specific to the kinds of problems that we have. This is where I get into the point of being a practitioner of AI versus, you know, focusing on some of the things that you read in the press of, you know, what one LLM said about another LLM. It's how do we use that to enhance the way we deal with RF and spectral efficiency? How do we use that to change the way we have relationships with customers to solve their problems? How do we use that to identify fraud? How do we use that in order to remediate issues in the network itself faster? An example is we've loaded every trouble ticket in the company into our generative and agentic AI frameworks. It now recommends what the fixes are and can write the code to do the fix. Should we just go ahead and automate that? We're still human in the loop there, but these are major, major changes. Also on the revenue side of the equation is how do you begin to ingest this stuff into the products and services that you offer? We're already doing that with things like upsells. We're doing that in products like Dynamic Defense, where on the cyber realms, you know, you can't be the unsecure network provider. You're seeing agentic and Gen AI threats coming in, and we're able now to block those from the network itself. Got it. Talked a lot about different technology initiatives. The AT&T of the past, I think, was sort of had a lot of tech debt, right? You're sort of dealing with that today. How do you make sure that you're architecting in a way that you avoid tech debt in the future? Yeah, I mean, there's a combination of things here. Some are technical and some are actually financed. Isolating the costs associated with the technical debt itself and understanding kind of product-based costing on that legacy infrastructure is essential, and then starving it. Making sure that when a new dollar of capital comes in, that you spend the minimal amount possible on that legacy technical debt so that you continue to build the new. The other things you do is, as you set up your human capital, it's bifurcating how many people are working on the old stuff versus how many people are working on the new stuff. The business is going to want to get things out to market as quickly as possible, which may push you towards doing things on the old infrastructure. You've got to be able to build out the new infrastructure and stay ahead. I call it the run fast strategy. How do we keep the new stuff running far enough ahead of the old stuff that ultimately it overtakes it? That's another big component of that. There's a regulatory angle to this on legacy products and services, and big hats off to our public policy groups that's assisting us in how we get out of some of the traditional voice services as an example, DSL services and other things for those legacy products. The first thing is to size the problem, understand the cost with it, put the human capital against it, and recognize that that's not something that happens overnight. It's a slog to get that stuff out of the network. It took decades to put it in the network. We're well down the path on doing that now. Great. With that, we're just about out of time. Thank you, everybody, for joining us. Jeremy, thank you for your time. Yeah, thank you. Appreciate it.