AWS re:Invent 2025 - Build an AI-ready data foundation (ANT304)

🦄 Making great presentations more accessible.
This project enhances multilingual accessibility and discoverability while preserving the original content. Detailed transcriptions and keyframes capture the nuances and technical insights that convey the full value of each session.

Note: A comprehensive list of re:Invent 2025 transcribed articles is available in this Spreadsheet!

Overview

📖 AWS re:Invent 2025 - Build an AI-ready data foundation (ANT304)

In this video, AWS Data Analytics leaders demonstrate building agentic AI applications using existing data foundations. They showcase a travel reservation demo using Bedrock AgentCore, Strands Agents, and Claude Sonnet, illustrating how AWS MCP servers for Redshift and S3 Tables enable natural language data interactions. The presentation covers context management through vector stores with OpenSearch, agentic memory implementation, and event-driven architectures using Amazon MSK for multi-agent systems. Key focus areas include automated metadata generation in SageMaker Catalog, Apache Iceberg catalog federation from Databricks and Snowflake, and the new polyglot notebook with built-in data agent that automatically generates and fixes code for tasks like sentiment analysis using DistilBERT and PyTorch.

; 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: Building AI-Ready Data Foundations for Agentic Applications

Everyone, thank you for coming. Good morning. You probably guessed, I'm Taz, Tech Leader for AWS Data Analytics. And I'm Shikha Verma. I'm the Head of Product for Data Analytics at AWS. Very excited to have you all here. Let's get started. Lots of content. Everyone ready? I know it's a little early in the morning, at least for me. Let's wake up.

Okay, so in terms of the agenda, what we have for you today is first, we will be level setting what exactly data foundation means because if you ask the person next to you, you'll get a different definition depending on the day, on the time of the day. So we'll level set what that means. We'll in fact take it to the next level, which is data foundation, what it means for data analytics and what it means for agentic AI applications. We'll talk about how you can bridge the gap between data and AI using the AI-ready data foundation on AWS.

Examples of this will include AWS MCP servers followed by an in-depth look at how you can use AWS data analytics to manage context. We'll also talk about event-driven architectures where your application may have multiple agents. And then, we will bring this all together with the most critical part for data and AI, which is how do you make your data ready for AI. We'll talk about data governance, we'll talk about metadata management, and that's essentially data readiness.

So, Shikha, shall we begin? That all sounds good, theoretically, but I think we need to root it in an example where we can show everybody how we can actually do this live. Don't you guys think? Yeah, so we should use a demo to demonstrate what we have. Can we do that, Taz? Can we use our own data for the AI agents?

Your wish is my command. I have a demo for you. We are a travel agent company. That's the premise of the demo. We'll use that to showcase how you can leverage the data foundation on AWS to build an agentic AI application and get the most out of it. All right, that sounds good, guys. Thank you. Let's do it.

Defining Data Foundation: From Analytics to AI Applications

So let's begin by level setting on what is the data foundation. On AWS, this is essentially for data analytics. This is what it means when we say data foundation, right? This is having access to data tools that allow you to deliver on basic constructs of data analytics like data storage, data processing, data integration, data governance, and all of this with the price performance and the ability to scale as and when you need it. This is at its very core what we mean by data foundation for data analytics.

And these foundation constructs basically, they come together to give you a typical data pipeline that you see over here with the different components coming together to give you an output that is important to your business. But what does this mean for AI? What we are trying to say is, when you are working on building AI applications, right, it doesn't actually have to mean that you have to look for something new or build something new in terms of data foundation.

You should be able to leverage what you already have, and that's essentially the crux of this particular section over here. You should be able to evolve and adapt to build your agentic AI applications because data and data engineering are key AI differentiators. Even though that might be a backend aspect of agentic AI applications, it is still critical. And here's that story in two pictures. Shikha, what do you think? What do we think guys? Sound okay?

Do we think data is a differentiator for AI? Just show of hands. Yeah, pretty much everybody. But do you guys ever say that data engineering is a differentiator for AI? Anybody says that? I mean, we believe you when you say data is important for AI, but let's be honest, when we talk about AI, is data processing, data storage, data governance, is that top of mind? Yeah, top of mind. Nice.

We have a great crowd here, and that is essentially the point we are trying to make over here, which is data is critical for a successful AI application and needs a strong data foundation. And it should be made up of data tools that allow you to extend the capabilities to build the AI application. All right, Taz, all right, Shikha, shall we proceed with the next section?

How AI Evolution Transforms Traditional Data Pipelines

Yeah, I think you have a good story to tell here, and I can see that our audience is engaged. So folks, I'm going to leave you in Professor Taz's hands for a bit, right? He's going to show us how this is done, and he'll show us some real data with real AI agents,

and then I'll come back on stage to talk about a few other things. Go for it, Taz.

Thank you, Shikha. Okay, so really quick. An AI-ready data foundation on AWS, at least for businesses, what does that mean? Essentially what we are saying is it's a foundation that lets you fuel AI innovation and speeds up efficient delivery with little to no impact to your bottom line as a business. That is the data foundation that businesses get from AWS, but we want to focus on what do developers and builders get out of this, and that is what we'll be covering for most of this talk. And this image here is actually a testament to the AI-ready data foundation on AWS. Really quick, any guesses as to what this image is? Project Rainier. Thank you. So yeah, this is our Project Rainier cluster compute that was recently launched, one of the world's largest AI compute clusters. It uses a lot of core components of the AI-ready data foundation that we have on AWS.

So for the most part of this talk, we want to focus on how data personalities like data engineers, data analysts, and data scientists can get the most benefits from an AI-ready data foundation. We are recommending two approaches essentially. The first is quite fundamental. It's actually understanding how your data foundation constructs, such as storage, processing, and ingestion, are influenced when you build an AI application. And the second is a more prescriptive approach about deploying the AI-ready capabilities that the data foundation has to accelerate your AI development.

The first approach is best understood by looking at the evolution of AI. Now this has rapidly progressed from something simple like assistants to more complex autonomous systems. We started with generative AI assistants that follow predefined rules to automate repetitive tasks, then quickly moved on to AI agents that are goal-oriented, capable of handling a broader range of tasks, and adapting to changing environments. And then today, where we are at, we are moving towards fully autonomous multi-agent systems that can make complex decisions.

The evolution of AI has a direct impact on your typical data pipeline. They also evolve when used in the context of building AI applications. The very first thing, one of the very first things that AI introduces, is the need for additional data sources. And these are primarily in the form of unstructured data. Now unstructured data is not a new construct. However, it is new in the sense that it doesn't conform to a preset data model and it doesn't have a predefined schema. And this is new territory for most data personalities. Functions like metadata management and data governance for unstructured data take on a whole new meaning and have a big influence on things like data processing, data integration, and data storage.

The next construct that gets influenced is around data processing, right? This is an area where you would start working on aspects of training or validating your data, moving data from data warehouses or data lakes to improve the model accuracy, or you could be running inference for your continued pre-training approach for near real-world scenarios, or managing vector data for a RAG-based application to provide real-time context. And all this data processing requires advanced forms of data integrations and data storage.

Next, some AI applications also incorporate techniques such as including human feedback to optimize the machine learning models. These applications need to capture user input in real time for a highly personalized user experience. Capturing this information in the right kind of storage with efficient pipelines helps with latency and accuracy.

And then finally, because an AI application opens itself up to a much wider variety of data sources and users, data governance becomes a function of the entire end-to-end pipeline. Behind the scenes, governance functions such as data privacy, data quality, and data cataloging are required to deliver comprehensive data governance for an AI application.

Demo: Building a Travel Reservation Agent with AWS Data Services

So that was the first part of how data professionals can make the most, right? Having a macro vision of what it means to the data pipeline. The next aspect is a little bit more prescriptive approach, taking a deeper look into how to make the most of the AI-ready Data Foundation. And that is about leveraging the enhanced capabilities of that foundation to drive AI developer and end user experience. We thought it best to cover this with an example agentic AI travel reservation application, just like I promised Shikha.

All right. This is an airlines reservation agentic AI demo application that we built. I asked the agent to show me all available flights from JFK New York to Los Angeles, California. The agent starts thinking about it and goes to work. For the purpose of this demo, you will see we are also printing diagnostic information, so that tells us what the agent is calling, what it's doing, and for what purpose. So we give it a few seconds for the agent to do its job, and then you can see very soon that the agent will return several flight options for me, and those options will include things like flight schedules for different airlines.

It will show me the ticket pricing again by each airline. In this case it was talking to a third party travel agency. It will show me user reviews from my colleagues in my organization that have flown the same airline in the recent past. So that gives me a well-rounded, well-informed way of choosing the flight that I want to use over here. It's also telling me that based on my company travel policies, there are certain cases where I might need an exception to book that flight, right? I mean, we at Amazon have that policy. I'm hoping most organizations have something similar that they can relate to. When picking and making a choice that doesn't align with the company policy, you have to work through an exception process. So that's what's happening over here.

And then finally, the agent is also making recommendations that are actually policy compliant and factors in my travel preferences. So this is the first part of the demo, right? Getting all that information. Now, we are calling this scenario one because there is a scenario two. This is where I feel I don't want to get in trouble with my manager, right? I mean, I don't need to get an exception, and I go ahead and I ask the agent to book the American Airlines flight. I know that is compliant looking at the pricing aspect that it showed me earlier. It works with the company policy and timing wise, let's say for now it works for me as well.

Again, the agent's thinking starts going to work. Similar to the previous part, we are printing some diagnostic information that we will come back to later. The agent confirms the reservation. It uses my travel preferences such as my meal type, the kind of seats I prefer, whether a window seat or an aisle seat, what kind of person I am, and performs a few backend operations like emailing me the e-ticket and stuff. So that was the demo, and for the purpose of the rest of this talk, we will use this reference architecture of the airlines demo to help us work through what's happening behind the scenes.

The user prompts, interacts with the agent, which in turn then works with a list of tools or API calls that integrate with different types of sources like the third party travel agency that makes flight data available, the user's internal corporate data warehouse and data lake which is on Amazon Redshift and S3, and a booking action with a third party. There are a few operational transactions happening behind the scenes that we will cover when we talk about multiple agents. So just for context, this is a demo that we white coded using Quiro and Strands Agents. People here are familiar with Quiro and Strands Agents? Nice.

For those who aren't, Quiro is AWS's AI IDE that turns prompts into specs and then into code. It's actually pretty cool. And then Strands Agents is an open source SDK that takes a model driven approach to building AI agents. Strands supports all LLMs. I suspect most of us have our favorite model. Mine is Claude Sonnet, and that is what we are using over here.

There you go. All right.

Understanding the ReAct Loop: The Heart of Agentic AI Applications

Before we jump into the details of the application, I want to take a slight detour over here to position what is generally called an agentic loop or a ReAct loop. In terms of the transaction workflow between the agent and the tool and the model or the LLM, one may think that the flow is more or less linear. As in, the user prompt invokes the agent, which in turn executes the tool API and then returns the results to the agent and then returns the final response to the prompt. Well, not really.

At the center of an agentic AI application is a loop. When the user instructs the system to complete a task or a transaction, the workflow enters an event loop where it iterates until it considers the task completed or the question answered. This design pattern is typically called the Reason plus Act or the ReAct loop and is the most popular design pattern for agentic AI applications. This is how we are illustrating it. This basic architecture allows an agentic AI application to accomplish tasks over the course of multiple event loop iterations.

Now, while on one hand, this event loop means a more meaningful and relevant response to the user, however, on the other hand, it also means a slower and less efficient agent. It also means an unpredictable number of model invocations consuming an uncontrolled amount of input and output tokens that impact both cost and performance. A good data foundation can help with minimizing that impact, starting with the AWS Data and Analytics MCP Service.

AWS MCP Servers: Enabling Agent Autonomy Through Natural Language

Coming back to the reference architecture of our agent demo, let's look at the tools that we are using. These are either hardcoded API calls or function calls that you can pass as tools to the agent to invoke. What this means is that the agent's capabilities are fixed at design time. It doesn't really have a choice or the ability to reason or plan which tool to use depending on the task. You're limiting its capabilities, and all the queries that it is using also need to be predefined for the usage over here.

This is where MCP servers bring value. You let the model figure out what it needs through natural language. It also replaces the heavy lifting of managing multiple API SDKs and formats, which I can imagine is a production nightmare to most. MCPs enable true agent autonomy, the ability to iteratively call tools, get results, and decide the next steps in a ReAct loop.

Just a little bit of overview on MCP servers. They don't really replace APIs. They add a conversational layer to the LLM. They act as a universal language, eliminating the need for custom integration layers between different AI models and tools. Too much structured data with traditional API calls tends to confuse the agent.

I do want to point out over here that MCP servers are not always a one size fits all. There are operations that are better served through traditional API calls. For example, the MCP-driven agents struggle with large scale data processing with structured data and complex data transformations, even such as the get flight details function that you saw earlier over there. We did not convert that into MCP. We didn't have an MCP server for it, but regardless, a direct API call serves a better purpose for those kinds of transactions.

Similarly, operations that require deterministic and time-sensitive outcomes like the booking a reservation, right, that function call, that is also a better fit for a direct API call instead of an MCP server call. It's very easy for these operations, the kinds that we just discussed, to exceed the LLM's context windows and drive up costs and latency.

In our demo, we used the Redshift and the S3 Tables MCP servers. The Redshift MCP server acts as a bridge between your Redshift clients sitting on the agent and your Amazon Redshift infrastructure.

It does natural language transformations and, among other things, automatically discovers your Redshift clusters whether they're provisioned or serverless, can work across multiple clusters, browse databases, schemas, tables, and columns through natural language, and execute SQL queries in a read-only mode which provides you with built-in safety protections. Likewise, with the Amazon S3 Tables MCP server, you can interact with tabular datasets using natural language. You can list and create S3 table buckets, namespaces, and tables. You can also query and commit data to an S3 table through this MCP server.

Context Management: Working Within Limited Context Windows

The AWS MCP Server repository is a suite of specialized MCP servers, and we invite you to check out all the publicly available MCP servers that can help you make your agentic AI applications more autonomous and less expensive. Moving on from MCP servers to context management, another area where data personas like data engineers, data analysts, and data scientists can leverage the AI-ready Data Foundation on AWS. We touched a little bit on context when we discussed the ReAct agentic loop. A simple way to think about context here is to think of it as the working memory of the model, of the LLM, the memory that lets it interpret, reason, and then take action for the best outcome possible. Let's look at that in a little bit more detail.

So while AI agents get sophisticated reasoning capabilities from models and LLMs, they face two key limitations. One, LLMs are stateless and unable to remember past interactions or maintain context. And two, the finite or limited context window that LLMs have restricts the amount of data that they can hold and use to process at each step. Now, the kind of data that the model typically keeps within the context window involves three core areas. First is the instruction set. Instructions such as the user and system prompts, the state of the conversation session that you're having, conversation history, learned lessons, user profiles, and so on. So that's the kind of data and information that sits in that instruction set.

The second area is the knowledge base. Knowledge bases are, again, think of them like centralized repositories of structured and unstructured data. This is information that serves as grounding data for AI. They can include things like documents, FAQs, product specifications, and best practices from your organization. In our demo, we are using the company travel policy documents as the knowledge base, and we'll look at it in a little bit more depth very quickly. This is where the agent can tell me which tickets are within the company travel policy and which are not.

And then we have data coming from the tools or the MCP servers that we just saw. In this demo, we bring the airline reviews from S3 Tables. These are reviews that my colleagues posted into that knowledge base that we use to make decisions. So the model needs to work with a lot of current and fresh information within its limited context window to be able to advise me on the right course of action. This is where context management or context engineering comes into play.

This working memory, as defined by a context window, is the length of the maximum amount of input data it can hold or consider or remember at any point in time. And here's the kicker for that. Context windows are finite and tokens are expensive. We saw earlier how MCP servers are designed to be more context efficient and less verbose than traditional APIs. So next we will look at how best to manage the limited and expensive context window with the help of agentic memory and vector stores.

Agentic Memory: Delivering Personalized Experiences with Amazon Bedrock AgentCore

All right, so let's quickly refresh our memory from the parts of the demo where the agent is retrieving and memorizing several data points including flight availability information,

my booking reservation, and my travel preferences. So this is the agentic memory in play and in action over here. For this function, we are using the Amazon Bedrock AgentCore to serve the purpose of agentic memory. AgentCore, some of you might know this, is a modular service that provides you everything you need to go with agents up to production, including observability.

In our example, we are using it to deliver personalized experiences with persistent memory stored in this particular service. It supports most of the popular frameworks and protocols like the Strands agents and the MCP servers that we saw earlier that we are using for our demo. And then depending on the nature of your agentic application and the business case, if you're a shop that needs an off-the-shelf kind of solution, Amazon Bedrock AgentCore is a good choice over there. Or if you're an organization that needs to build something custom, something more specific to your needs, AWS has several other options that agents can use to build their agentic memory.

These include things like ElastiCache for Valkey, an in-memory high-performance key-value data store. We also have DynamoDB, a distributed NoSQL database, Neptune Analytics for knowledge graph-based dynamic relationships, and several others. So the agent can retain knowledge to learn and problem solve. It can deliver contextual intelligence through pattern recognition and personalized interactions by remembering preferences and past conversations.

Knowledge Bases and Vector Stores: Powering RAG with Amazon OpenSearch

The next important piece of context management is knowledge bases, right? This is where unstructured data comes into the front. In our demo, we are using the company's travel policy documents such as PDF and HTML files scraped through to build our knowledge base on Amazon S3, and then we are using Amazon OpenSearch as a vector store to do a semantic search to apply the correct policy to the booking. Again, like we did previously, let's refresh our memory on the information that our agent is using from the knowledge base to apply the relevant travel policy.

We see a pricing policy around lower and upper bounds that was retrieved from the vector database to add to the context window. In this case, our agent is using the Knowledge Bases for Amazon Bedrock service to perform this function. Now the way this is working behind the scenes, this service provides the end-to-end RAG workflow for us. You simply specify the location of your data, which in this case is S3. It selects an embedding model to convert that data into vector embeddings and then has the service point to a vector store, which in our case is Amazon OpenSearch, to create that vector index.

Our agent fetches that context and adds it to the context window in the model, so the model is able to reason and use that information in the most appropriate way. A little bit about the vector engine for Amazon OpenSearch. It's a search service that delivers highly relevant and accurate responses. It provides vector indexes at scales that are production-ready, and at this re:Invent we are introducing the general availability of GPU acceleration for the OpenSearch vector engine. By offloading vector search computations to GPUs, OpenSearch can achieve up to 10 times improvement on speed and compute costs, which is great for applications like RAG, Retrieval-Augmented Generation, and recommendation systems.

And similarly, just like AWS for agentic memory, depending on your use case and your business needs, AWS provides additional choices for deploying a vector store for your AI application, including the general availability of Amazon S3 vectors announced at this re:Invent for cost-effective large-scale vector processing or vector storage. Besides personalized responses, another area of context management is to have a timely response.

A travel reservation agentic AI application is expected to maintain the latest information of the user's travel preferences as they can change over time. This is where Change Data Capture CDC events combined with streaming ingestion, storage, and near real-time processing provide current information to the AI application's knowledge base. Also, depending on the use case and business needs, AWS has several streaming and CDC options to choose from, including Amazon Kinesis Data Streams, AWS Glue, and Amazon Managed Service for Apache Flink for real-time aggregations.

Event-Driven Architectures: Coordinating Multiple Agents with Amazon MSK

Moving on to the next aspect of leveraging your AI-ready data foundation on AWS, let's talk about event-driven architectures in scenarios where you have multiple agents that are providing an agentic AI function. Multiple agents is where an agent needs to gather information from multiple sources, including other agents, tools, and systems. This is a very likely scenario in production when you build an agentic AI application where you end up with multiple AI agents.

Multiple agents, a good way to think about those, is like a loosely coupled asynchronous architecture that is very similar to a microservices-based application where multiple agents work independently but at the same time in collaboration with each other, moving data and events, making sure unavailability of one does not affect the other. This is scenario two, where let's say I want to book a flight which actually violates the policy exceptions. So this will demonstrate how multiple agents come into play.

As I said, scenario two of the demo, where I am having to book a ticket that is outside of my company policy but works better for my availability schedule. As expected, it comes back to tell me that this particular flight will need my manager approval. And as part of backend operation, what I'm doing is requesting and getting the approval from my manager. And then we'll wait for the agent. It's doing a little bit of hard thinking over here. It's a policy exception. So there it goes.

So now the agent is telling me that I need an approval from my manager because this choice of flight is violating my company policy. Like I mentioned, I get the approval from my manager through a backend operation, and then I tell the agent, yes, I have the approval. The agent takes that information and does some validation and then goes ahead and books the reservation for me. As you can see, it's performing the similar operations that we saw earlier, which use components of the knowledge base, the agentic memory, my user preferences, and also does a few backend operations.

Let's take a look at those backend operations. These backend operations are basically additional agents that are collaborating with our main agent. There's a confirmation email notification agent, an agent that triggers a rule if a company policy on expenses is satisfied or not, and an agent that logs all transactions to a backend database. Now, our main agent could actually be made to handle all these tasks in one, but if you recall the ReAct loop, agents can also get easily confused, and you're also working with the limited context window and the agentic memory.

So on the other hand, having multiple agents, how does that help? Multiple agents performing a unit or a single task are easier to build, and you can build in resiliency with an event-driven architecture. This is something that looks like this over here for us. Using a service like Amazon Managed Streaming for Apache Kafka or Amazon MSK, which is a fully managed Apache Kafka setup, you can loosely couple all the agents while ensuring real-time exchange for low latency with built-in scalability where there is a need to add more agents, for example, and manage persistent events with multi-AZ deployments and automated recovery.

An event-driven multiple architecture not only decouples and scales the agent task, it also provides a distributed processing platform for the agentic AI application with durable messages and delivery guarantees as provided with the Amazon MSK service.

A little bit about the Amazon MSK service: it can process high throughput events, enabling agents to respond to various patterns and real-time scenario changes. Asynchronous communication in Amazon MSK, facilitated by event-driven architectures, provides benefits such as decoupling, independent scaling, and improving fault tolerance through replication.

Data Readiness: Why Metadata is Critical for AI Agents

And now, I would like to invite Shikha back to us to tell us how data readiness can be made, can be worked upon through the AI-Ready Data Foundation. Shikha, thank you, Taz. How are you doing? That was a lot to consume, right? How are we doing? Good, good. All right, I think Taz did what he told me that he was going to do. He was like, okay, I will use our data to create agents, and he created multiple agents.

As we were getting ready for the session, we purposefully wanted to do more of a show rather than tell. So I hope it's working for you. Quick raise of hands if it's working for you. Yeah, okay, cool, cool. So, who believes in this? Does this make sense to you guys? Yeah, so just like how humans need maps, AI needs metadata.

So how does this fit into our overall picture of what we have seen so far? So we saw Taz use a lot of data and built-in context. We talked about context management and how context comes in through knowledge bases and through session logs and through data that is coming through tools or databases. Is metadata new, guys? Like how many of you have dealt with metadata for decades now, right? It's not new, but it is cool now. So I think metadata is definitely having a moment right now, and I think it's great because all of the context that we're talking about is essentially metadata and data that is sitting in unstructured files like Taz pointed out, the policy file.

We're going to go through more of the traditional data side of readiness, which is, you know, data sitting in your data warehouses, data lakes, and how do you get that ready for consumption by our AI agents, because that is where all of our data is sitting right now, right? So when Taz and I started thinking about our session, we were like, well, all of our data is literally all over and it's not even in AWS. Some of it is outside. How do we bring it all together? So if everybody accepts this, then I think we're going to go into the next side of the story.

So we have our data sources, right? Traditionally we've had data warehouses, data lakes, then came the lakehouses, then all these different data sources where data is just sprawling. All of that comes together through the architecture that Taz is pointing out, with generating more and more metadata, right? So we generate metadata as we enrich each of these data sets with more information. We generate metadata on data quality and data lineage as we get all this data moved into a form where our agents can use it and humans can use it. So metadata is definitely having a moment, and I would highly encourage everybody to think of this as a key foundation that you have to invest in for your AI initiatives.

So what does metadata really help us do, right? So I don't think the story will be very new, but again I'm going to emphasize that what we used to do for humans is a must now for AI agents, because AI agents are not going to call their friend, right? Like we want autonomous agents working on our data and on the context that we are providing them, so it becomes more and more useful for us to bake metadata into our systems.

So let me just talk about this cycle for a second. So there's, in most companies, and I'm assuming that this will sound familiar to you, there's data producers, people who create the data or own the data, and there's data consumers, which now is getting filled up a lot with not just humans but also AI, right? Does this sound familiar to you guys? Yeah, it's very much the story that we've been living with, but then it's now vital for us to have the context because AI cannot work without the context, right?

So we've got to make sure that we're building the right technology in the middle to bring these things together, right, to add the right context in terms of metadata, to have the right frameworks in terms of governance so that humans and AI can use the same systems that we have been using by adding the right components to it. Does this make sense? Quick show of hands. Okay, cool. All right. So let's go ahead. How many of you have heard of Amazon SageMaker?

Yeah, so we invested significantly in this platform over the last few years, and for those of you familiar with Amazon SageMaker AI, which used to be the traditional machine learning side of our offering, we really expanded that brand and portfolio to include all of our data analytics and AI capabilities. That is what Amazon SageMaker is now. It's really the center for all your data analytics and AI because we saw this coming and realized we needed to bring it all together, because we can't have these agents running havoc through your ecosystem.

What Amazon SageMaker is built on is a foundation of the lakehouse, which, if you're Apache Iceberg compliant, is going to be music to your ears because anything that is Iceberg compliant can come into this ecosystem and can bubble up through SageMaker's capabilities of data and AI governance as well as the unified studio, which brings all of these capabilities together. The next couple of demos that Taz and I are going to show you are really using these capabilities to build the context and the metadata for your users and your AI first, and then use that context to create an application quickly. We're going a little bit behind the scenes here where Taz really showed you almost the front end application of the agent and the customer using it to book a flight. Now we're going to go a little bit into the back end and show you just how this gets done.

At the center of that SageMaker picture you saw is data and AI governance. So what does that really mean? This is the center for where all of your data, your models, your agents come together for availability across your entire organization. I'm assuming most people here are data engineers, software engineers, data platform owners, that sort of demographic. Is that right? Okay, cool, so you deal with this.

What SageMaker really allows you to do is bring all of that together, and then you build trust in it. We talked about data quality and data lineage, words that are not really new but are of immense importance in this new world because we've got to get this right so that the context is all built into our data and metadata. Then we apply the right guardrails around who can use this data. You don't want your notify agent using your policy data. It's the whole picture. With humans you can call and make the right controls happen, but with agents it's all the more important to set the right guardrails and the right workflows in the system itself.

All of that, of course, is very transparent and auditable, so all of the metadata that gets generated through this, for example at the asset level, goes back into Amazon S3 Tables. What does that mean? That your agents can go read that data directly. If I put all the metadata that I'm creating through SageMaker back into S3 Tables, you can read that data, your agents can read that data, and infer information from it without having to go through the whole stack.

Two key important takeaways for data and AI initiatives in general: you want to apply the same framework across your data models and all kinds of assets, and you want to invest in metadata as well as comprehensive data governance around it. Let me show you some stuff in action.

Amazon SageMaker Catalog: Automating Metadata Generation and Governance

We talked a lot about metadata. Metadata is not easily available for the things that we've had for many, many years. Not every system that we own has useful business context attached to it. The tables are hard to tell. For those of you who are in the SAP land, the table name doesn't tell you much. It's things like that. What we need to do is really add the right metadata to all of our tables as well as columns, but we can't expect humans to be creating that.

What I want to show you here is for one of the tables that I showed you in the demo, we go and create metadata automatically through AI. Again with SageMaker, what we have tried to do is we are building the system for you to use for your AI initiatives, but we have also built enough AI into the system to make the system more productive. In this particular case, I'm picking the customer reviews table. You can see that there is a quick generate description button up here. It's showing me the typical technical metadata that is readily available usually, and I can add to it. I can see the schema of the table that I have.

It shows some data quality information, which we'll get to in a minute, but I want some more useful business context added to it so that I can feed it to my humans as well as AI. So it's going to take a minute. It's doing it live. We didn't want to shorten this for you so that you know that it does take a minute. But as you can see while it's loading, on the rest of the screen you have glossary terms and metadata forms, which you can add additional ones to. And there you go, the metadata is generated.

So here I have an option to edit the metadata if I want, but I've seen pretty good success, so I'm just going to accept it. And you can see that in the summary it's giving some very helpful pointers. So what does this data have? What can it be used for? These are things that we would be wanting somebody to put in the data so that we can query this information and use this information when we're trying to leverage it. And it just generates all of that automatically. That's the power of LLMs that we are getting the benefit of right now.

It also went to the column level and generated descriptions there too. So earlier, if you remember when we came to the schema, it was largely empty, but now you can see that there are even column-level descriptions added. And I am accepting all of the descriptions here as well because I think they're pretty decent for my use here. The other things you see on this screen are there is a data quality score that is available as well. So this got pulled in by looking at the rules that I had set for the table back in AWS Glue, which is how I brought it in. So those tables that are pulled in, I have a clear understanding here that this data is only 60% good. You really want to use it, but you want to at least show that to your users up front so that they know what they're getting into and they're not being misled.

Now the lineage story here, Taz and I were laughing that it just shows one table because we didn't combine it with a bunch of other things, but if you bring a bunch of things together, it shows a beautiful graph of how this data was constructed. Anyways, now that I have put all that information in, I published that asset back into Amazon SageMaker Catalog. So now it becomes readily available for another user to come in who's coming in right now, and they search for customer reviews and that table appears. So now another user from another side of the world or another agent can come in and search your catalog for this information using some keywords.

And if I like it, you can subscribe to it, which means that you're getting the actual grants to use this data for your systems, which is again something that is audited. You can query it and know who's using what data. So again, pretty useful. Really quick demo on the behind the scenes of how this data got ready for Taz to use.

So in this area we are really introducing a lot of capabilities. Some of you may be familiar, but some may be new, so I'm just going to quickly go through that. But metadata in general is getting a lot of investment across AWS. You'll see that we are adding metadata capabilities at the storage layer at Amazon S3. I'm going to call out some of the key capabilities that we have added to Amazon SageMaker Catalog, which is really at the column level. You can have enhanced descriptions. You can have metadata forms. It gives you so much more control over what kind of context do you want added to your data so that your agents and your humans have all the information available. You can also enforce that. So you can now say that for this use case, this particular table or column is not usable. That also gives you that feature with the enforcement of metadata forms as well as glossaries, because you can spell that out a lot more clearly when the context is added to your data.

Also, it's really hard to create these things from scratch. So we are continuing to invest in our automation where we gave the automated business descriptions first, and now we are also giving the capabilities to add business glossaries automatically. They will give you suggestions. You can accept them, or you can associate them with pre-existing glossaries. It just becomes super easy. And then like I mentioned earlier, we're putting that all back into Amazon S3. So then it's available at even your storage layer. The metadata itself is available for you to query and use with your agents.

How many folks here have data outside of AWS? Most of you, right? Yeah, even I do. So very excited for this particular capability, which is, if you subscribe to Apache Iceberg, this is great. We are investing a ton in Iceberg where this is catalog federation to external Apache Iceberg catalogs. So for example, if you use Databricks or Snowflake, you can bring in and read those tables from these third-party solutions, and you can bring them into AWS Glue Data Catalog so that it becomes available in the same Amazon SageMaker ecosystem that I showed you earlier. So you can, for example, bring in a table from Databricks, you can catalog it, you can add the automated business descriptions to it, and you can do all of that from within Amazon SageMaker if you're leveraging this capability.

I'm super excited about this one. This has been a huge ask from most of our customers.

Live Demo: Building AI Applications with SageMaker Unified Studio's Data Agent

All right, now that we have all of that data together, our data engineer and data scientist want to build something on all of that data, right? So how do you do that quickly without having to build the traditional pipelines or go to five different tools to do your things? If you're familiar with SageMaker Unified Studio, we're adding a ton here in the last couple of weeks. One is the one-click onboarding of existing datasets. What this means is if your data is part of AWS Glue Data Catalog or you just did the external federation from Databricks or Snowflake, with a single click, that data can be made available in SageMaker Unified Studio.

What that means is there is also a new notebook there that we have added, which is pretty cool. I would encourage you guys to try it out. Taz is going to come show that to us in a minute, but this is a polyglot notebook, so you can have cells with SQL, cells with Python. They can correlate, and it has a built-in data agent in it, which again Taz is going to help create the little application that we did, which we'll show you, which is really, really cool, guys. It can create code of all types automatically. We'll show you in a second. It can also correct coding errors within it. So if you guys are familiar with Cursor or Replit or Lovable or that breed of things, yeah, I think you will love it if you dabbled in that space because there is a lot of good stuff here that saves a ton of time.

I was playing with an application last week and literally it created the code for me and then I'm like, what the heck is this? And then there was an error and I did the click fix with AI. It fixed the code for me. We're actually going to show you that live in a second as well. So Taz, do you want to come back and show us how this works?

Absolutely. Well, if you haven't realized so far, I'm the demo guy. I know we showed a lot of demos, but this is the last one we promised, and this is the coolest one, and you can see how excited I am, right, with this. So you earlier saw Shikha talk about data agent data notebook. And what I want to show here is the customer user review data, how easy it is to do a subjective analysis of that data. Anyone here ever tried to do a sentiment analysis of a dataset that is human dependent? I mean, you can imagine the number of machine learning libraries that you have to use to get the code right and actually get the right results.

To me, I can imagine it can take me about two weeks of time. This demo took less than ten minutes. Let me stop talking about that. Let me start the demo. It's a little long, but pay attention. I think I can promise you that you'll enjoy this. All right, so we are starting with launching the IAM-based SageMaker interface and quickly navigating to our customer review dataset, right? And then we create a data notebook just by the click of a button, preconfigured with a cell that is telling me what my dataset is and a simple SQL query, so I can make sure I have the right permissions to my dataset and I'm looking at the right data in the right context.

I go ahead and run that query and confirm I have the right dataset. So keep in mind, this is the customer user review data that we are using in our agentic AI demo. On the right side of the data notebook is the data agent that Shikha was talking about earlier. I want to test this data agent, right? I want to put it through a grind to see how good it is, right? And this is what we are going to do over here.

I start with giving it something very simple by saying, give me the count of unique flights with reviews, right? I also intentionally use bad grammar to see, is it picking up my intent, what I'm really trying to find? It goes ahead, spins up a cell, it decides to use SQL on its own, and I run that query, and yes, that is essentially what I had in mind, what I was looking for. It gave me that data. Okay, so that was simple, right?

I want to test it with something more challenging. So I come up with something over here. I give the agent a complex task to do a subjective analysis of the customer reviews by asking it to do a sentiment analysis of the data that I have. So this is where I want to see, do I really have confidence in my user reviews, right? How's the distribution of positive versus negative? What does that look like?

I go ahead and ask it very nicely. Can you do a sentiment analysis for the reviews of my data? The agent goes into thinking mode. And then it comes back with an execution plan over here. Waiting on it. There you go.

What it's doing is it automatically decided to switch from SQL to Python for this task. I don't have to tell it anything. It determines the Python libraries that are needed and available for this task in my notebook environment. For example, it plans to use, and I know it's a little hard to see, but take my word for it, it's trying to use the TextBlob library to process textual data and the Transformers library that it found in my environment for natural language processing using pre-trained models for that sentiment analysis that I was asking about. In this case, it decided to use the DistilBERT model that is ideal for sentiment analysis in notebook style environments.

All right, and then the agent tries to show off actually by also proposing a visualization summary of the sentiment analysis, followed by a breakdown of the flight with the most positive reviews. We run the first cell over here and as you can see it is now working on the dependencies. It is thinking through it. Let's see what it comes back with. All right.

It came back with an error over here. This error is essentially telling us the data frame that was passed to the cell from the previous SQL query is not right. Being who I am, a little bit lazy, I know what's wrong. I just don't want to fix it myself. I use the Fix with AI feature that we have in this notebook. There you go. And folks, as it is fixing with the AI, I know we are coming up on time, so we tried something different here for this session. We did more show than tell. If this worked for you, please do give us feedback in the session survey because we'd like to do more of this if this worked for you.

So while that is fixing with AI, here's a human announcement for you. It did its job. Thank you for that. And all right, it fixed it. It made the code change. And now it is telling me, okay, I've made that change. I think this will work. If you like it, accept and run. I do that. Okay, as in the real world, another error, right? And this time it's a little bit more challenging what that error is. It's talking about a Keras library that is not compatible with what it's trying to do and the Python code is telling me, go ahead and install this to make it compatible.

Again, okay, now I want to test the Fix with AI a little bit more. I tell it, why don't you try to fix it? So this is what the data agent does, right? It looks at the error and it knows that there's a compatibility issue, but it takes a different direction in fixing that error. So instead of fixing the compatibility issue, it actually pivots to a different library like PyTorch because it knows that will work for sure because that's the response that it is giving me. You can see it's made the code change on line number eight. And again, like I said, the agent was actually showing off. It made the change in the comment as well, that I'm changing this library to PyTorch. All right. I accept it, I run it.

It's running the code. It's running the cell. All right, I got one output that it cannot, and I got the results of what it was trying to do. Okay, so that was the first cell where it was doing the analysis for the sentiment. Next, it's going to do a graphing of the results over here. Again, it generated the Python code on its own. It's using Matplotlib libraries on its own by itself. I simply go ahead and run it. This one runs without any issues. I got my data. I go from data engineer to data scientist to a data analyst, all in one over here.

All right. And then the last query, which is essentially giving me the highest count of the best airline with the most positive reviews. In the interest of time, I'm just going to move on to the next slide, which is the second to last slide over here. Key takeaways. I'm not going to read this slide. We talked a lot about this over here. Key idea is you don't really have to build anything new in terms of data foundation. AWS has what it takes for you to build your agentic AI applications. Leverage the critical path between data and AI through purpose-built capabilities, some of which we saw over here today, MCP servers, context management, vector stores, and data governance. And with that, folks, if you have additional needs, we do have programs to help you get started. Thank you for your patience staying with us. I appreciate that.

---

; This article is entirely auto-generated using Amazon Bedrock.