🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.
Overview
📖 AWS re:Invent 2025 - Ericsson Innovation: Optimizing Mobile Networks & Unified Development with AWS
In this video, Christian Finelli and Ibrahim from AWS and Ericsson discuss how Ericsson transforms mobile network operations using AI on AWS. They explain Ericsson's cognitive loop framework for autonomous networks, implementing specialized agents across measurement, assurance, proposal, evaluation, and execution stages. The architecture leverages Amazon SageMaker for ML pipelines and Amazon Bedrock Agent Core for multi-agent orchestration. Dag from Ericsson's System Comprehension Lab addresses the challenge of being "comprehension bound" in complex systems engineering, while Bastian details their technical implementation using MCP gateway, custom LLM training for proprietary hardware frameworks, multi-modal data processing pipelines, and Agent Core's observability and identity management. Real field deployments show measurable improvements in network coverage, capacity, and quality optimization through reinforcement learning agents like cell shapers.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
Introduction: Ericsson's AI Transformation Journey with AWS
Good morning, everybody. Can you hear me? Thanks for being here today. My name is Christian Finelli. I'm a Senior Solutions Architect at AWS, part of the Telco Business unit. Today we'll be learning how Ericsson is transforming their in-house development experience with AI on AWS. Bastian and Doug will be talking about that in the next session. Ibrahim and I will walk you through how Ericsson is optimizing their customers' mobile network experience with AI on AWS.
AWS is working with Communications Service Providers to achieve their business objectives, which are to increase revenue, optimize cost, and reduce customer churn. CSPs are migrating and modernizing complex BSS and OSS systems on AWS. They do that to reduce time to market and increase product agility. At the same time, they migrate complex IT workloads to increase operational efficiency through AI automation. CSPs are also migrating and virtualizing network functions on AWS to increase elasticity, scalability, and business continuity through disaster recovery options on AWS.
CSPs are transforming their customer experience by starting with data, modeling customer behavior, and providing personalized customer experiences. AWS and CSPs are working together to build beyond connectivity, creating new revenue streams and protecting and monetizing existing network investments. They explore new business models, such as software as a service, which gives them options to explore new pricing structures and increase agility of their product lines. AI is a key component in all these areas, and we are seeing that Ericsson, as a key AWS partner, is best positioned to scale these initiatives globally.
Building Successful Agentic AI Solutions: Key Requirements for Trust and Operational Excellence
Ericsson is transforming their business and product lines with AI and ML. Let me bring a few examples of how they're achieving that. They're reducing product delivery time by leveraging agents to integrate complex software stacks in the field. They're optimizing mobile network performance for their customers, CSPs, by leveraging a combination of traditional ML and agentic AI solutions. They're also reducing time to bring new features to market that are implemented by internal teams by building an MLOps platform to accelerate adoption of ML technologies and empowering their large base of software developers to improve their efficiency and build better products.
We are working closely with Ericsson and have firsthand experience of what it means to build a successful agentic AI solution. It's not just about identifying and picking an LLM or adopting an agentic SDK. The complete AI stack, including the accuracy and economical viability of the AI stack underpinning the agentic AI solution, is a critical factor for its success. There are a few areas we've identified. We start with the fact that the business must be able to trust agents and the output of these agents. This means access to data and knowledge that is authorized at the lowest ground level. At the same time, it's important to note that in traditional machine learning training, data lineage plays a key role in keeping track of the origin of data for data sovereignty requirements.
Trust comes with explainability, being able to determine and dissect how agents behave, the turns they take, the reasoning process, and the different tools they call and their performance. As a next step, context is king. The way knowledge and data are delivered at the right time to the right agent concisely matters because size means cost. It's another element for success.
In a multi-agentic solution where multiple agents work in combination, it's important to attribute value to each agent. When we say value, we mean the overall outcome of the multi-agentic solution. The value is split across different agents, and determining what value each agent brings along with the cost allows an atomic determination of ROI for each agent. This goes into explainability and observability as the foundation for operational excellence.
Being able to understand and monitor end-to-end the performance of these agents is essential, and also being able to operate them. When we say agents, it's not just operations, but also everything that falls into the underlying AI stack, including LLM operations and ML operations. Being able to run these operations efficiently through AI SDC capabilities is crucial. Ibrahim, you might want to talk to us about why explainability is important for customers.
Explainability and the AWS AI Stack: Enabling Secure Agent Deployment at Scale
Thank you very much, Christian. One thing we understand from people working very closely with Agentic AI is that agents are not just about deployment of technology. When a CSP, a service provider, sources agents from Ericsson, they trust the outcome that comes out from this agent. They are outsourcing network operation for a national infrastructure to someone like Ericsson. For them, it's extremely important that we have explainability in the whole stack regarding why a decision by an agent is made that way, why a workflow is designed this way, and what tools are being used and why these tools are making such decisions to implement changes in a national infrastructure like telecom.
Explainability is extremely important, and the stack that AWS provides gives us the tools and capabilities to have this explainability for CSPs. Explainability and observability are crucial, right, Christian?
Absolutely. Thank you, Ibrahim. The observability, as Ibrahim said, is across not just the agentic AI layer, but across the whole AI stack. Ericsson is leveraging different services from the AWS AI stack. We will see both use cases showing how they leverage these services, but the stack covers multiple personas for different business cases.
We start from the bottom layer where data scientists use AI compute to run training jobs and host models for inference, from GPU to Amazon chips. Amazon SageMaker is used by data scientists to run the entire MLOps for their ML models, including preparing data, training models, evaluating models continuously throughout their lifecycle, hosting models for inference, and monitoring model performance. Moving up the stack, engineers and developers use Amazon Bedrock to run agents at scale securely in production. This gives them choice of models and foundational models, and provides capabilities to run that at scale and securely.
Agentic SDLC applications are leveraged by developers to increase their efficiency in coding, developing software, and maintaining operations throughout.
Today, we have firsthand experience with two teams from Ericsson coming on stage to discuss these two use cases. The first one is Cognitive Network Solutions, or CNS. They are leveraging a combination of traditional ML inference and a multi-agentic solution to optimize CSPs' mobile network performance. The second is System Comprehension Lab, which empowers Ericsson engineers to build better products through AI. I'll leave the stage to you, Ibrahim. Thank you again, Christian.
Ericsson's Global Impact and the Autonomous Networks Framework
Let me take you through our journey of partnership in building agentic AI. But before I take you through this journey, I would like you to understand what we stand for at Ericsson, what our mission is, and what impact we are actually having on society. With 5G networks today, there are around 340, and 189 of them are actually running using Ericsson innovation. That's more than 50% of 5G networks worldwide, and more than 50% of worldwide 5G traffic outside China is running on our equipment.
I can tell you that here you are in Vegas. If you are having mobile services from AT&T, Verizon, or T-Mobile, there is a 100% chance that you are using Ericsson innovation. CSPs are using Ericsson innovation to deliver services to you. This is the impact we are having on society. This is the impact we are providing to the world. In order to make sure that these services are provided at the best in class level, we have a heritage of innovation that extends 150 years. The most obvious thing you see is the number of patents we bring for mobile technology—more than 60,000 patents.
What actually proves that this kind of technology and innovation is providing value is that more than 74% of worldwide CSPs always come first when they are benchmarked against their competition in the market when they are using Ericsson equipment. For us at Ericsson, it is extremely important to make sure that the impact on society, what we bring to CSPs when it comes to performance and innovation, is top notch. That is why it is important for us to partner with someone like AWS to provide such value, and AI is a cornerstone of that transformation we provide to our customers.
We worked on transforming our portfolio offering across different parts of the stack in mobile technology and also for network operation using AI. We leveraged our own competence and shifted our own competence to make sure that people inside are capable of delivering new value to customers using AI. We also worked on shifting the mindset of people and understanding what it means to provide AI in each and every offering. We built our networks for the kind of AI traffic we see today and see growing in the future. We are also using AI in network operation and across the stack, as will be explained a little bit later.
We provide this in the portfolio of how mobile innovation is delivered to CSPs and also the way we operate these networks. This is the framework we talk about for autonomous networks. Autonomous networks is a framework defined by TMF on how we operate networks for today and for the future. It is actually across five different levels that you see here on the slide. One thing I would like to bring to your attention is the graph below. The percentage of CSPs today who are barely reaching level 3 or beyond level 3 is less than 10%.
The transition to Level 3 plus occurs when you start to integrate AI into network operation systems. You might hear in the community or here at CSP about reaching a higher level of network autonomy and reaching Level 4. We cannot reach Level 4 without embedding AI in the way that we operate networks, which is why autonomous networks is a very important framework to bring to our CSPs.
The Cognitive Loop: Implementing Agentic AI Across Network Operations
We realize this in our Telco AI portfolio through what we refer to as the cognitive loop, a five-stage workflow for network operation. It starts with measurement, where we have measurement agents that understand network data and ensure we are capturing the information we need to move to the next step, which is assurance. In the assurance stage, we have agents like classifiers and root cause analyzers that tell us what is happening in the network, what anomalies exist, and what the root causes of those anomalies are.
We then move to the proposal stage, where we have AI recommender systems and AI agents equipped with recommendation tools to propose the next best action. However, since networks are complex, we have an evaluation step to ensure that the best decision is the final one implemented in the network, which is a national infrastructure for each country. After evaluation, execution and activation occur, and the cycle continues. This is what we call the cognitive loop.
The agentic AI framework and agentic AI fabric are implemented across the entire cognitive loop to ensure it functions end to end through different specialized agents. These agents are specialized in certain workflows and receive runtime context from the network as traffic shifts and changes occur every day and every hour. To achieve this, we believe in openness and horizontalization. The architecture we have built together with AWS encompasses these two main objectives: openness and how we get data and expose it to the upper layers toward agents through different AWS services.
These services provide agents with different capabilities. For example, we leverage tools for agents, which is how we provide agents with the capability to understand what is happening in the network and execute changes on these networks. Observability is extremely important, along with the different services in the stack we have from AWS. It all starts by ingesting large volumes of data from the radio access network. At the bottom, there is the ETL layer, which runs on AWS services including serverless services, containers, and fully managed services by AWS like Athena and Glue.
This processes data coming from the radio access network and prepares it to be consumed by an ML pipeline. Amazon SageMaker is where the ML pipeline is built, where data are prepared, models are trained, models are evaluated, and then they are hosted for inference. Point inferences are then invoked by our applications, which are ML-powered and consume predictions about network performance. These applications contribute to the context of the associated agents.
The agents themselves also rely on other data sources and knowledge bases through RAG techniques, which include data that are product guides, network configuration, and natural data structures and correlations among different network parameters. An agent is then able to invoke our applications to consume the prediction and retrieve this information.
Amazon Bedrock Agent Core then provides Ericsson with capabilities like memory and observability to offload these functions on AWS managed services. In essence, the full stack plays a role, with SageMaker for producing accurate predictions through machine learning and agents, and Agent Core to manage the full lifecycle of agents.
Cell Shapers and Reinforcement Learning: Optimizing Network Performance with Real-World Results
If I go back to the tools that we provide for these agents, which are basically our radio applications that can provide such predictions and understanding of what's happening on the network. One example is what we call cell shapers, which are reinforcement learning agents where we have a digital twin representation of the network. For those familiar with how networks are built from a radio perspective, the network has been designed since the early times with an antenna that has a certain coverage area. The very first problem that engineers try to solve is how to optimize coverage and quality. This is a multi-generational problem that started from 2G, 3G, 4G, 5G, and we also see it in 6G.
How can we make sure that we have optimal coverage, capacity, and quality in this network? The typical approach in the industry has been to do simulations before deployment and before the signal is in the air. What we do with reinforcement learning agents, which are the tools we provide for agents on the AWS stack, is reconstruct the radio environment based on live traffic and always learn from what's happening in the network. This learning happens through multi-objective reinforcement learning algorithms to ensure we are always providing the best trade-off between coverage, capacity, and quality for the different layers.
The agents are always learning from the network as traffic changes and different aspects impact it. For example, introduction of new spectrum, densification of sites, or addition of new technology like cloud RAN or 6G on top of 5G. These cell shapers belong to what we call the proposed stage in the cognitive loop, and they help us realize such autonomy on top of a stack like AWS. These are not the only agents we use. I provided more details about the kinds of agents we have developed and are now working together with AWS to bring to their stack in different parts to improve user experience, improve network operation, and improve efficiency in operating networks.
The numbers you see here are not lab results. They are actually coming from real field deployments for these agents. We are able to measure the impact and understand that the impact we bring through Ericsson technology is very profound for society. I would like to hand over to my colleague Dag to tell us how we build that. I told you a little bit about how we operate, so Dag can tell us about how we build that.
System Comprehension Lab: Addressing the Challenge of Being Comprehension Bound
So let's take a step back. We have a lot of AI applications in the networks that I talked about. But where does the actual intelligence come from? It partly comes from observing the network and applying control function theory, but it also comes from the fact that we built mobile network infrastructure for four decades. If we're talking about intelligent networks, lots of this is actually about representing the intelligence that we have institutionally, the people we have, and the data assets that we have in the company. This is why we created something called the System Comprehension Lab, which has a couple of different objectives.
Mobile networks across a large country, especially here in the US, are astoundingly complex and represent very complicated distributed systems. They are complicated both in deployment and management, as Abraham discussed, but also quite complicated in design. We have all the different kinds of radio products. We have 2G, 3G, 4G, 5G, and 6G coexisting. We have millions of configurations that are set to operate and configure these networks.
Our AI journey started some years ago when we began working with AWS, and it started from the notion that to really solve an interesting problem with AI for Ericsson and for our customers, we needed to realize that we have this massive system complexity out there in the real world. I would say that this is actually not a particularly Ericsson-specific problem and not even a telecom-specific problem. If you are designing aircraft or nuclear power plants or something of that nature, you are dealing with massive system complexity, and AI somehow has to help you.
So we arrive at this fundamental question for us. Are we comprehension bound? Actually, it is not even a question at this point—we are comprehension bound. When I say us here, I mean Ericsson's R&D, which consists of several tens of thousands of people working in the space of distributed systems. When you think about building 6G or building the next generation of 5G, are we bounded by the traditional three pillars of project execution—cost, scope, and time—or can we actually say that we are probably more limited by the amount of comprehension that the humans involved can actually apply to these processes?
I am not going to be overly self-critical about this. As Abraham said, half of the world's 5G traffic goes through our products, so we are doing a good job. However, we can still say that we are probably comprehension bound as humans developing mobile network infrastructure. So our AI mission is this: how can we actually make AI work in the limit of complex systems engineering? Again, it does not matter if you think about telecom, nuclear power, aircraft, cars, or whatever you want to think about.
For us, the System Comprehension Lab starts from the point that we have millions and millions of documents in-house. We have been doing what we are doing for three or four decades without AI. So our first mission is to take all of our data and our in-house data assets and make us better at designing mobile networks. If we do that well and we do that with Amazon Web Services, with Bedrock and so on, which I will speak to you about in a little bit, we put down a foundation of institutional knowledge and intelligence about how mobile networks are built.
We can then layer on top the kind of data that Abraham was talking about, which is when we actually see these enormous data streams of what is happening in the live networks out there. We can explain what that means, we can act on that, and we can be intelligently integrated into that data flow. That then lays the foundations for thinking about how we make our products understand our human intents in ways that are derived from the fact that we are consolidating our institutional knowledge, which makes us better at designing our products. Then we are layering on top the real network telemetry that is out there.
What I also want to mention here is that there is a real disconnect out there in the world. I think we are all part of this information flow where the frontier AI capabilities that get a lot of attention—like competition-level programming, competition physics, and competition mathematics—are opening up a very wide gap towards the reality of AI impact in an industrial setting or in a product development setting. This gap is actually much bigger than what I try to visualize here. The gap between how much value we can generate on our own with AI in product development versus the state of the art is significant.
We have been working a lot with AWS to say, what does it take to close this gap for a company of Ericsson's size? We are a fairly large R&D organization, and we need to close this gap so we can actually deliver the value that Ibrahim spoke about. This is about the challenge that every organization has a lot of data, but nobody has clean data. All of these demos you see about competition programming and so on have underneath them an enormous amount of data work. One has to do that and combine different kinds of data assets across this very complicated design space.
Multi-step reasoning makes this harder. We were used to saying that it's great to have a new multi-step reasoning LLM capable of helping us. However, the more steps you have in reasoning, if you're applying this to some complex technical problem, every step has a chance to take you off the rails and then you diverge into nothing very quickly unless you can constrain that reasoning as we move forward. These are some of the challenges that inspired us to work on AgentCore and working with Bastian and AWS over the last couple of years.
What we basically mean is information fusion. Again, this is different in a DevOps setting, but from my standpoint, we're an embedded systems company. We collect requirements, we systemize, we develop, we test and integrate, we release and deploy, and then our products are out in the field for a decade or more. It is about taking a vastly complicated set of data assets throughout this flow and fusing them in a way that we haven't been able to do before. The key question for us is how do we then determine what assumptions or what architecture we need to be able to do this at the scale of our R&D organization, which is several tens of thousands of developers.
Key Pillars of the System Comprehension Lab: Data Fusion, Agent Integration, and Evaluation
The first thing we want to accomplish is a kind of decoupling. We have tools like Amazon Q Developer or Quiro as a sort of user front-end facing tool, but that in itself doesn't know anything about Ericsson's internal R&D assets. Through MCP, we standardized on MCP as that decoupling layer between the front-end tools and whatever we design in-house. We put a lot of effort into not being end-to-end AI products, but building specialized AI agents, specialized AI technology that is somehow differentiating for Ericsson, specialized models, specialized developer tooling, and specialized agents. Especially in the specialized agents category, I would like to invite Bastian to talk a little bit about different aspects of this and how this all came together for us.
Thank you so much, Doug. Thanks for talking about the concept of being comprehension bound, which is important to keep in mind here. It's something that is important for all enterprises that have history, especially in R&D heavy enterprises. It's great how we tackle that with the System Comprehension Lab, and I'm going to talk a little bit about what are important factors within the System Comprehension Lab and what are the key pillars that we have to work on to make this successful.
On one hand, we say that the agents are the ones that interface with the humans, but they need the right data. We've already talked about this quite a lot—there are different data silos that have to be fused together. One part of that is that while multi-step reasoning has its own problems, multi-step reasoning is one of the things that is really important because we have to move beyond the traditional naive RAG where you just find similar text in a text space that you have. It's just impossible to get something sensible, or you get something, but is it right? It's important to have a system where you actually evaluate the user query, where you query different data sources, combine this data, and maybe step back, think again, maybe interact with the user again to get to the right data that your agent needs.
On top of that, this is getting the right data, the concise data at the right time for the agent. The other thing that an agent needs to act upon this is sometimes you need to go a step further. Context depends on traditional AIML models at some point, but it also might need that you have a custom large language model. I'll go a little bit into why that is important in the next step. Multi-modal processing is also important. The data that we see is not like we just ingest very well structured text documents. There's a lot of different modalities in the data and I'll show a little bit more detail in the following slide.
Now we are ready to see that the agent can get the right data. Even though this is a simplified view, the agent has the right data. What else is important for it? It is important that it can integrate with downstream tools. There are these agents that need to interact with the physical or digital world. This is supposed to be for engineers to build better products. Engineers work with
a multitude of different tools. When they do their coding and engineering, they may need a connection to the project planning tool they're using, the knowledge they have there, and the source control tool they're using. There are different kinds of tools, and you need to have access to that. You would like to remove all of these friction points for the user, so you hand it over to the agent.
MCP is the layer here that connects all of this. How do you actually work with this downstream system? You make these tools available through MCP, and the agent can use them. They can use each other through that as well. Now we have downstream integration. The other thing you want to have is to surface this information to the user. Ericsson follows a nice principle here of making it available to the user where they want to work.
Sometimes it may be the right thing to work on a deep research task within a browser, so they have a dedicated front end for that. Sometimes you may want to do that directly in the IDE where you do your coding for a specific project, and then you want to utilize it directly through Amazon Q Developer. The agent has the right tools and the right data, but there's more to it. There are non-functional pieces that are important.
We've already talked about observability quite a lot. It is important to understand what tools are called and whether we selected the right tools. Are they relevant for the task? Do they get the right output? Do we get the right context? Is the context that we have created through multi-step reasoning actually relevant for the question that was asked or for the task that the agent is supposed to work on?
Observability also goes beyond that. These systems are not just an agent and a model somewhere. They are complex systems with many moving pieces. You have your regular application, your models, data sources, and pipelines to process data. There's a lot of things you need to keep track of. So observability is of utmost importance.
Then there's scalable architecture. I'm not going to focus too much on the technical piece of that, but it is important. Ericsson is using Agent Core as one of the main core pieces to make that easy, so you get a serverless experience of running your agents. But there is another part to scalability, and that's organizational scalability.
What you have here is a two-sided marketplace where teams have expertise in certain domains and want to make this available through these agents. However, they may not necessarily want to become experts in agentic AI or how to train models. You need to be able to onboard these teams and their knowledge quickly, and this is what Ericsson is doing really nicely with blueprints and agents to help onboard teams onto the system.
You have the producer side and the consumer side. The consumers also need to be onboarded, and there's enablement involved. You need to make sure they're using the system in a way that makes sense from a cost perspective. Since there's cost involved with LLMs, you need to ensure this is working right. You also need to make sure these users can access the tools they should, but probably not everything. There's a certain amount of authentication and authorization involved here.
Lastly, but not least, it's actually something I personally talk about first in every meeting when there is a GenAI use case evaluation. It needs to come first. The only constant in GenAI projects is change, and it's very high velocity change that we see here. The only way you can actually keep up with the latest model you want to try, the latest technique and pattern you want to try, or simply update the data you have is to understand whether this change you introduced now is at least as good as yesterday. That only works if you build a robust evaluation framework from day one.
Architecture Deep Dive: Data Processing, Custom Models, and Agent Core Runtime
Moving on to something I'll take some time to explain. If we wanted to talk about this in its entirety, we would have a couple of days in front of us, so I'll focus on some things that I think are really critical. First is the data processing piece. Data processing is complicated in the sense that it's actually one of the most complicated pieces of the entire thing. This is highly simplified, but I just want to run through the most important pieces.
We basically have the raw data, and this is the hardest part. We have a pipeline that makes sense of this data, processes it, and then makes it available in data storage that is useful for the specific task for the agents. On the data side, the problem is that this is not homogeneous data. You have data in many different formats, whether that is a PDF, a Word document, an image of a napkin somewhere. You have lots of different data. On top of that, you also have data that is super well structured and that may come from a relational database. On the other hand, you have super unstructured data spread around your data lake. How do you make sense of that?
Then the third dimension in data is maturity or authority. What does it mean? Is this something that I can trust? Is this something that can give me a definitive and authoritative answer? In these data sources, you have everything from specifications like a 3GPP specification to coming back to the napkin, some napkin of an idea that some engineers drew during lunch. It's different kinds of data that you need to evaluate differently by the agent.
Now you have these pieces moving over to the data processing part. Ericsson uses AWS Batch and other services from AWS to make the most out of this data. Sometimes it's about integration to the data sources, but the more interesting parts are how do I actually extract the metadata. When you extract an image from a document that you have, you want to make sure of where it comes from. Does it fit to that document? Where is this document coming from? Can I resurface this later on?
You may also have more interesting tasks. This is engineering, so you will have mathematical expressions and tables of data that you need to extract, and you need to do that well. It's not good enough that you get close enough in these systems. So you have these different processing pipelines. In the end, they make that available to the agent through, for example, Amazon Bedrock Knowledge Bases if you need more of a traditional RAG approach. But again, this can be combined with multi-step reasoning later on in the agents.
If you need a structured search through semantic search, you can use Amazon Bedrock Knowledge Bases, for example, on OpenSearch Serverless. If you need more information about the entities and how they relate to each other, a graph database is a good choice, and that's also used in this system. Lastly, you may want to use some ad hoc analytics or other structured queries, and you can use Amazon Redshift in there. All of this can actually be behind the Amazon Bedrock Knowledge Base, which can make it relatively easy for you to get started with that. But sometimes you need a little bit more customization, as we have done in this case.
So we have the right data where we need it. There are other parts though. I already hinted that there is a custom large language model that has to be trained. Why does it have to be trained? Well, Ericsson provides and creates their own hardware, their own silicon. That silicon has your own proprietary frameworks and language on top of that. So helping your engineers with off-the-shelf large language models for coding-related tasks is just not going to do the trick. You need to be able to produce the right content, and in that case, Ericsson realized it's important to train our own model on that, and this is what we have on this slide.
I am not going to go into super much detail here. This is yet another two-day session if we want to go into detail, but suffice to say you need the source code, you need the system documentation or code documentation for that. You need to run it through a pre-processing pipeline to get high data quality, a high-quality data asset for training. In this case, this is done with continued pre-training, instruct fine-tuning, and reinforcement learning with human feedback on top of that to get the best possible model that you can then host on. Depending on the different models, because there is always a change in what is the best model, sometimes that works well on Bedrock Agent or Bedrock custom model import, and other times it is hosted on EC2.
And then of course, evaluation is king, so this is something that you constantly evaluate and retrain. Moving on to the last architecture slide where I want to just bring the whole thing a little bit together. How does it look at runtime? Let us start with the engineer again. The engineer wants to use it where it makes sense, where they work, so either in a dedicated front end or you use it through Amazon Q Developer or Qiro. The point of that is how do you utilize that? How do you actually integrate that or use the MCP gateway that Ericsson has created for that? The MCP gateway can then surface tools for the assistance that we have on the left side here for the network engineer.
The MCP gateway is the integration point where agents can talk to tools, agents can talk to agents, and even tools can talk to agents. Sometimes it's a tool that already exists and you just want to make it available through the Agent Core gateway. Sometimes it may be an original MCP server or a tool, and then you can run that on the Agent Core runtime. The Agent Core runtime is mainly used for running agents, and here is a selection of different agents that we have. Maybe it is a 3GPP agent, or an agent that is more specialized in a specific feature, such as LTE experts, and plenty of other specialized agents.
Then you have, for example, the code generation agent, which integrates with large language models. An agent is a piece of code that needs to integrate with a large language model for orchestration. You can either fall back on the many models available on Amazon Bedrock as a model provider, or you can use your custom models. The beauty of Agent Core is that it's super flexible, so if you do have an on-premises model, for example, you can integrate that easily there as well.
Agents need knowledge and they can integrate with many different knowledge layers. It's relatively easy. For example, if you use an agent framework like Strands, you can relatively easily integrate directly into the Amazon Bedrock knowledge bases. This wraps up the main pieces of the architecture, but then you have observability, which is important. Agent Core observability makes this possible and is compatible with OpenTelemetry. It's very easy to look at the entire end-to-end stack of your application, and it makes a lot of sense if you integrate it with other APM traces that you have across the entire stack.
The entire stack means there are applications front and back, there are Lambdas here and there, there are containers running here and there, so you want to have an entire picture of that. That's why observability is important. Specifically for agent traceability, you have Agent Core observability as a primitive. Identity is also important, so you need to make sure that an agent can only do what it's supposed to do. Agent Core identity makes it possible for you to manage inbound and outbound identities so you can ensure that the agents and the users can only get to what they need to, and you can go all the way down to row-level security and row-level authorization of your data in your data sources.
Last but not least, memory wraps it up. Getting the right context for your agent is important, and sometimes you want to transport it over sessions. Memory is one of the pieces that is used to transport preferences and topics across sessions. Agent Core was core, right? I have a quote here, but I think it's better if you just narrate this one. Thank you, Bastian. Great to see the work of the lab kind of compressed. I mean, we're quite serious. This is quite a big challenge to take the complexity that we face when we look at mobile network deployment or engineering, and all of that complexity, and how do we actually pull together all these pieces so that we tackle the challenge that I posed there, with the frontier of AI advancing much faster than the out-of-the-box industrial use cases of AI do.
We've been throwing requirements towards Bastian and the AWS team. I would say almost to test you a little bit, but to really push the collaboration to a new level. That ended up being one of the drivers for Agent Core. For us, it's the foundation where we can say, okay, let's get help at this knowledge fusion layer and get, again, to drink our own champagne and take complexity out, right? We don't want to be in the business of running Kubernetes clusters. We'd much rather have that offloaded to the core platform. Agent Core has been a key piece of how we scale.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)