Name: Enterprise Transformation with Claude on AWS: Paths to Production
Uploaded: 2026-09-16T18:32:34.706Z
Duration: 52 min 20 s
Description: Enterprise Transformation with Claude on AWS: Paths to Production

Transcript for "Enterprise Transformation with Claude on AWS: Paths to Production": Welcome, everyone. Thanks so much for joining us today on this webinar. We're excited to have you. My name is Scott Munson. I'm a member of the technical staff at Anthropic. And with me today as well are Jamal Arif, from Anthropic, and Iain Ray, one one of our partners at AWS. Before we get started, just a little bit of housekeeping. We are recording this session, and you'll be provided the recording after our session completes. We also have a question form. We'd love you to use that q and a form as a way to provide the information back to us, and try to get our questions answered live. We also have feedback. So, please give us, that feedback. We use it to update these as we go forward. We'd love to hear that. We wanna make sure we're providing you with the information you need. So I wanna just talk, upfront a little bit about Anthropic and how we're helping our customers get to the frontier. Anthropic exists to help the world get safely through the transition to transformative AI. What that looks like in practice is that our research teams keeps at the frontier. Safety is what makes, what we find deployable and products like, our models, cloud code, MCT and skills are how it reaches you. The only way that we can push the frontier forward is through a commitment to safety and continuous feedback from our customers. I wanna also highlight that, the partnership with AWS is, something that we've had for a long time, something that we built from the beginning, in order to serve our enterprise customers. That's been a focus for Anthropic from the start. We have been dedicated to making AI that's very useful for the enterprise. So that includes being trustworthy and auditable. We've got nine of the 10 Fortune 10 companies using Claude. We ensure that we have integrations that make, the model intelligence available to the data. We pioneered MCPs and skills, now industry standards. We work closely with AWS with significant mutual investments that are purpose built for entropics models to run really well, and we have integrated this technology with AWS. Along the way, it's a a major multibillion dollar investment in partnership that we are committed to and, has been really effective and successful for our shared customers. I wanna, set the stage a little bit by kind of centering us on Claude Code. I think most folks who are attending this webinar might be familiar with Claude Code. It is something that changed, software development. It landed back in 2025, and really, took off and became something that has just fundamentally shifted how, software development happens today. This is true inside both it's not as organization, AWS's organization, and for many of you as well. We've seen this growth of cloud code, be available across, AWS's versions of cloud, and we wanna kinda, like, talk through what that looks like, in our environment today. Alright. Let's talk a little bit more about, how you can access cloud on AWS. Cloud code is available across all of these offerings, and, it basically breaks down to there's two ways to access cloud in the API and two ways to access the apps. So for the builder persona, you can get the full cloud platform AWS experience, and, that's available on AWS through AWS billing. And you also have cloud on Amazon Bedrock Metals. For the apps experience, you have cloud enterprise on AWS marketplace. Again, also on AWS bill, and this is the full enterprise including chat, co work code, as well as desktop app, cloud dot ai, mobile cloud code remote, a lot of additional offerings including cloud security as well available on cloud enterprise. And we have cloud desktop, on Amazon Bedrock available. So this is the desktop app, chat, co working code, deployed, and powered by Bedrock on the back end, but running locally, which is a great use case for a lot of our enterprise customers. One kinda simple question, a great place to start, is to just think through, you know, can the workload that you're considering go to Anthropic as a data processor? If it can, that unlocks the option to do cloud platform AWS, and cloud enterprise and AWS marketplace, kind of a broader feature set. If no, then the answer is gonna be cloud on Amazon Bedrock or called desktop on Amazon Bedrock. That's kind of the simplest way to think about this and just to base on on what your workload is and who your users are. Let's go just a bit deeper on the API for builders. Here we have, two options. So basically, you've got, the cloud platform. I'll just highlight tools is a big part of what makes this, kind of valuable for a lot of our customers. Things like cloud managed agents, the cloud console, files API, MCP connectors on the server side. That's the kind of thing that a lot of our customers want, and web search is another one, web search, web execution. These are the kinds of things that would tend to bring someone over to the cloud platform alternative. On the cloud and Amazon Bedrock side, regional, in country inference is a big draw. So things like, and that's, you know, if they need it in EU or Japan or Australia, that's a common reason to bring it into, AWS as well as, of course, the data boundary, conversation that we touched on earlier. Additionally, Bedrock users, have, used the rest of the Bedrock capabilities. So that would include things like guardrails. And, you know, beyond that, the two do serve the same core, models. A little further on cloud platform. So again, full API experience that you would get, from us directly. We have, I'll go a little deeper on cloud managed agents shortly. But this is the one that, for those customers who wanna have the latest, and greatest kind of frontier development capabilities available to them, this is the one that they would choose. So one of the best ways, I think, for us to kinda grasp this is to jump into a demo. I've got a a demo now that I'll I'll show you a little bit more that deeper on cloud managed agents. One really powerful feature of cloud platform is cloud managed agents. It allows you to rapidly create and ship sophisticated, production ready agents, where Anthropic handles the sandboxing, long running agents, multi agentic coordination, and much more. In this demo, we're gonna talk through a scenario that is related to fraud detection with a human in the loop. We are going to create an agent that supports a human reviewing payments to their vendors before they leave the firm. We'll use this policy to automate acceptance, rejection, and the triggering of human approval based on the policy. You'll see us create an agent, configure an environment, a sandbox, for the agent to run-in. We'll see a session started, and events will flow to this session to, trigger an approval process. Now let's go to the console. Again, Cloud Managed Agents is for builders. You can access these capabilities through, CLI, through Cloud Code, and through the platform user interface. For For the sake of this demonstration, we'll use, Cloud Manage Agent's Quick Start, which is available here. Click Create Agent to kick off a new process. I've prepared a prompt here. In this case, we're gonna provide a little bit of context, for the agent to build from and the actual system prompt as well. So I'm gonna copy this text and then drop that in. Upon doing so, Cloud Manage Agent's quick start will write up the agent file. It's a YAML, as you can see. It's populating on the right, and that system prompt that we provided is now available in addition to some basic identifying features, like which model, effort level, and the name of the agent. Once you have a YAML file, you've actually got the basic element you need to create your agent. Click create agent, and this will walk us through the process where we'll also create our sandbox environment. Click configure environment, and here we will see the opportunity to name the environment. We We're gonna create a new environment. It'll come up with a name on our behalf. It'll ask us a little bit about the configuration. So in this case, limited network access is the right approach, And it will build out that environment. Click create environment. And now that will also be available and ready to go once you wanna start a session. From here, let's go ahead and kick off a session. We'll provide our own data here. So here we're providing, an approved payee list as well as tabular data, a series of transactions for us to process alongside the agent. We'll send that in, and now we can see the session is running. The session itself, kicks off, runs in the in the sandbox environment. You can see it's making a directory. It is writing out that data that we shared as a CSV file, and it will proceed to the process based on that system prompt with all of the tools it has available to it in order to, do agentic work on our behalf. It's written out a Python file to do the actual processing based on the policy, and here's a response. It's, got three of the items that we shared require some decision. One is a high transaction, which I think will approve. The second is, looks like a likely rejection. And the third would be for someone who processes this payment all the time. It's a fraud risk. But if we know, as the human loop here, that Meridian Legal Partners is actually the correct payee field, then we'll go ahead and approve. So I'll pop that in here next and send that along. The agent waited for that human approval process. It would go to idle if it was waiting for a long time. The session persists, and it waits for that event of a user input. We provided the input, and now it is proceeding with the remainder of the task. The batch is closed out. And just to kinda get a a confirmation here, we can see, what's been completed. That's actually asking for an audit log as well. So this auditlog.md file was built as part of the process. In In this case, we've released, $329,000, and, here is the audit log as well, all provided by the agent. Let's go take a look at what this looks like in the console after this, initial session has been run. We can go and view the sessions that have run. In this case, we'll take a look at this one that we just ran three minutes ago, open that up, and take a little bit of a deeper dive. Here you see the entire process by which, this session of events took place. So you've got, the user input, the writing of the batch and policy script, all laid out here. This is all available, as you scroll down as well, so you can dig in a little bit deeper to understand exactly what happened when, fully auditable. Also get a view of the cost. The session that we just ran was 22¢. And beyond this, you can also, dig a little deeper into events, tools, resources, and threads. And all of this is a JSON file, which you can download and interrogate, and add to your data however you'd like. In this session, we're able to configure a payment approval agent, bill the agent, define an environment for the agent to run, kick off a session, and process payments. This entire agent was built out for production scale and was completed in a matter of minutes. With that, I wanna invite Ayan Ray to go a little bit deeper on cloud and Amazon Petrock. Cool. Thanks, Scott. Quick introduction about myself. I Andre. I'm the worldwide tech lead for the Anthropic partnership at AWS. And in my present role, I, build better together, integrations between Anthropic and AWS products and help our joint customers adopt cloud on AWS. Now, what I'm seeing on the field first and foremost is very simple. The demand for AI is a reality and together between AWS and Anthropic, we serve tens of thousands of joint customers starting from startups, small and medium businesses, ISVs, and all the way to large enterprises. And, that count is exponentially increasing every day. Now when you work with such a large scale of customers, one thing is common, one lessons everywhere that is the requirements are extremely diverse. For example, let's say tech startups, their success is measured in terms of velocity and that's the reason they want every new model, every new feature, every new application right on day one. On the other hand, say enterprises, their success is measured in terms of trust, like security, compliance, data residency, data sovereignty, and neither of them is wrong. They are just solving different problems. Right? And the enterprises are going through a very interesting shift because they are in a journey of a radical AI transformation. For example, say two years ago, the conversation was, like, you know, was about building a chatbot pilot in a sandbox, highly likely funded from an innovation budget. But today, it is a board level mandate. You know, it has a real budget. It has real deadlines, real goals, and also real consequences of it of it going wrong. Right? The questions also have changed. Right? Two years back, mostly the questions were, like, should we do this? But now the questions are, how do we do this fast? How do I do this across all my departments? And how do I do that safely without rebuilding the security and the governance model from scratch? Let me share a real experience of what that looks like. This is from a customer conversation, and this is a global healthcare enterprise. Met their head of platform engineering. Let's call him David, and they have a clinical workflow product that runs across North America, Europe, and Asia Pacific. And he's putting Claude inside a product that their end users actually use. So it's not a a pilot, not an internal tool, but a real, product which is used by their end users who are clinicians. Now patient data is in play, so the bar is set accordingly. They need HIPAA, they need SOC two, they need full CloudTrail auditability. They don't want, they want the data to never travel outside of the AWS account boundary, and also they need private connectivity from their VPC to the inference provider. And the product is only half of David's mandate. His internal developers also want AI coding tools. His analysts, want an AI assistant that works on their documents for knowledge work. And here's the thing, the constraints don't relax just because the users are employees in this case. They are still touching highly sensitive, medical data. So the same constraints are applicable in this case as well. AWS as the data processor is what they prefer. Inference should lie within AWS account. All the evidence should be there in CloudTrail. And so whatever whatever inference solution David picks has to cover his product, has to cover the developers, and also has to cover the knowledge workers under one set of rules. And then, the conversation proceeded and he talked about another requirement, which makes it even more difficult to scale. Right? He has to roll this out globally while keeping the architecture in uniform, right, across North America, Europe, and Asia Pacific. Now to add to the complexity, the customers in Asia Pacific and Europe has to be served from an inference endpoint, which is in region. Right, because of the health data residency expectations. So three geographies, three data residency rules, but he cannot afford three architectures. He needs to design one architecture, one policy set, one audit story with only the endpoint changing based on the region. Now he also needs to go through a third party audit. And most often, the first question that the auditor asks is who is the data processor? Right? For our cloud with Amazon Bedrock, the answer is simple. It's one word. It's AWS. Inference runs as an AWS service that is Amazon Bedrock in their own account, and that's that's that answer usually helps to clear the vendor review. And that is why workloads like David's workload often lands on Amazon Bedrock. But now what is Amazon WebRock? It is a fully managed service from AWS that provides the set of high performing foundation models like cloud along with a broad set of other features that helps you to build, but more importantly, to scale your AI applications. You can access it, access the inference of your choice, like the mod foundation model of your choice like Cloud through a single API inside your AWS account with IAM, with networking, with logging, and with AWS billing. And also, while doing this, it also guarantees the standard AWS SLA, which you're already familiar with. So you don't manage infrastructure, and your existing security model is unchanged. And the model is only one part of the story. Right? It's definitely at the center of it, but around the model, Bedrock provides a broad set of other capabilities, like guardrails. If you don't want, you know, a model to respond, with an answer that impacts any particular section of the community. So we you can assign a topical guardrails using the guardrail feature in Amazon Bedrock. You can also, do retrieval augmented generation using knowledge basis, available in Amazon Petro. You can, let the model derive context from your own proprietary data. It also provides PPC endpoints, private link for private connectivity. All all the logs are audited. All the API calls are audited through CloudTrail, and you can log all the observability and the agent DPI traces in cloud, CloudWatch. It also supports cross region inference for higher availability. And the good news is that, and we'll cover about the apps. I know, Scott briefly touched upon it. So plot code, which you are already very familiar with, whether it is plot code CLI, plot code in desktop, or as a Versus code extension, all of those work with Amazon Bedrock as an inference engine. And also Cloud Desktop, and we'll touch upon this again in some time also works with Bedrock. Initially, it was only code and core which was working with Bedrock, but recently, Anthropic also shipped a new update to cloud desktop where chat also works with Bedrock. Now enough said, let's jump to the demo of Amazon Bedrock. This is the Amazon Webex console in US East 1. I'll filter to anthropic, and there's the cloud family of models with each model's card, capabilities, supported regions, and how you get access. Now watch this. Same console, same page, but this tab is Sydney, AP Southeast 2. And there are the cloud inference profiles for Australia. This solves the requirement of customers where the inference needs to be served from the region for data residency requirements. Finally, the playground, the fastest way to try a model before you write a single line of code. And you can connect to Amazon bedrock from plot code. Let's list down the AWS profiles I've already created. I'll start cloud, fire the slash login command, And I'll choose third party platform and choose Amazon WebRTC and choose the AWS profile. That's it. Now restart cloud. And now prompt it to build the code you want. Like in this case, I'm building a to do application. Done. And now I'll test it. And it is working as expected. You can also connect cloud code to Amazon bedrock via cloud apps gateway. Cloud Apps Gateway comes in the same Cloud Binary and provides features like authentication, spend limits, manage policies, and observability. Here, I have connected Cloud Code to Bedrock using CloudApp's gateway. It is now connected to the CloudHat's gateway, and you can see it's connecting to SONNET via gateway. You can also set spend limits in core apps gateway. You can set it at a org level, group level, or at a user level, and you can set the period to be monthly or daily. That's about the demo where I showed Amazon Bedrock connected it from cloud code and also connected cloud code to Amazon Bedrock via cloud apps gateway. That's a demo of cloud on Amazon Red Rock. With that, I'll hand it over to my colleague, Jim Alarif, member of technical staff at Anthropic. Alright. Thanks, Ayan and Scott. So we have now, looked at how kind of builders and developers are using cloud API and across the two paths. So you have both kind of cloud platform on AWS and cloud, on happens on Bedrock for the API and developer users. Now let's shift gears to the broader workforce. Right? Like users who are utilizing cloud or want to use cloud as a product. They kind of open up in the morning. They wanna use chat, hard code, or co work, maybe on a laptop or on a mobile device, but also want to have the enterprise controls behind it. Right? So, essentially, there are two ways to give your workforce, your employees access to cloud apps on AWS. And they split the same way, Scott was sharing earlier. Right? Like, the way the API apps did on who processes the data. Cloud enterprise through AWS marketplace, where Entropic hosts the full product. You get all the latest, and greatest, apps and features. On cloud desktop, where you are pointing to the Amazon Bedrock endpoint, and your prompts and completions stay within your AWS boundary itself. So on the enterprise side, you get kind of kind of the full product. You have desktop with chat, co work, cloud code. You have all the different kind of availability across different services, so across the web app, across the mobile, cloud code on the web, cloud availability in Slack as well with cloud tag. Plus, additionally, the solutions kind of build on top of it. Right? You might have seen, our feature list around, you know, cloud for financial services or legal or life sciences, or product services like cloud security and cloud design. In addition to these, you also get, like, server side capabilities, for instance, web search and, web fetch inside your conversation and sessions, and, like, you know, the hosted connected directory projects and so on. If you look towards the right on the desktop side, it's the desktop app on Bedrock. So the inference endpoint would be your Amazon Bedrock endpoint. You get the similar kind of applications. So you have chat, homework, and, code available. And they were of course, there would be some kind of differences on the application, on the feature set itself. But think of kind of the mental model being, like, with cloud enterprise, in AWS marketplace, you're getting the whole cloud apps product, which is operated by Entropic within the AWS boundary but built through AWS. So your procurement kind of stays the same. And on cloud desktop on BetterHelp gives you the same desktop app, but then your data kind of stays within the AWS boundary with some, feature set which is more related towards Amazon bedrock. But what I always kind of, shared with our customers and majority of our enterprise customers are kind of in that phase as well where they understand this being kind of a more of an additive, in nature where your majority of organization might be just using Cloud enterprise for most of the users, getting all the latest and greatest features and all set that they are used to. But then also kind of using Cloud Desktop on Bedrock for some specific teams where the data has to live, within that AWS boundary that you have. So let's dive a bit more deeper into, the Cloud enterprise on AWS Marketplace. So, again, it's, the simplest way to get your organization's access to cloud. The same cloud enterprise product you would buy essentially from Anthropic directly, but this is kind of procured through AWS. And for, like, teams who, like, just to kind of give you a context, with Cloud enterprise, it's a combination of three core products. Right? You have chat, Cloud Code, and Coburg. Chat is where everybody, you know, already understands. You have that interface where you're doing back and forth conversations. You ask these questions, synthesizing documents, summarization, all those kind of use cases. Cloud code is, again, majority of users might be already using it. That's where developers build that Frontier coding agent where best in class agentic coding performance. And then CoWork is our newest one. It takes the same agentic power and brings it to the knowledge workforce. So the people who are, you know, aren't living in the terminal all day, your broader workforce, that's where a coworker is really kind of transforming, the broader enterprises. And we are seeing some great customer feedback, on this one as well. Now all of that comes with the enterprise governance you need. So SSO, SIM from your identity provider, rollback rollback access control, cost controls that you can set spend limits per user and per group. Your administration would also have, access to creating the MCP allow and deny this. You'll have access to the compliance API, which lets your security team kind of pull conversation, and build kind of, that data to your SIEM tooling that you already might be using as well. So, essentially, kind of, all the access to those apps, but with the enterprise controls that you are mostly used to. Alright. So let me switch over to the demo. I'll start from the administration side because most enterprises are always, you know, focused on having that enterprise controls as well. And then I'll quickly show you, kind of how that looks like from a user perspective as well. Alright. So here I am on my cloud desktop app. It's the same cloud desktop app that you might be using already, but this is procured through cloud, for enterprise in AWS Marketplace. So the procurement path is via AWS Marketplace itself. I'm logged in to my user. The settings would actually show me my own, specific settings on the user itself. Then organizational settings would open up the organization setting as as an admin provider. Here's what enterprise security and administration gives you. Identity from your own provider, SSO and SAIM, role based access, who can use which capabilities, connectors, and models, custom retention, audit logs, and a compliance API. And again, Anthropic does not train on your data. In day to day, you have one dashboard. So who's active, what's being used, what are the different spend by model alongside with spend gaps, and you can also get capability controls per user or group. So engineering gets slot code and maybe the finance team doesn't. That's kind of the admin view. Now let's move over to the teams or individual user. Alright. So now we are back in the cloud desktop app. I'm working through co work for folks who haven't used this. CoWork is essentially an agent for, the broader knowledge workforce. It's built for people who aren't in the terminal all day. So if you have used plot code, think of CoWork working in the same engine kind of, but pointed at more of the everyday work. So it has similar reach where it can read files and write files on folders on your machine. You can point it to a specific folder, and it would be able to read and write files right from there. It's also where the outputs would land. It also can query the systems you are connected to to connectors. So for instance, in my case, I have a few connectors that are added, by the administrators and authenticated as well. It also has the concept of skills and plugins similar to what you are used to in Cloud Code. Essentially, once you build the skills and plugins, you can actually share it across, the team, and you can utilize it across cloud code or, co work as well. And for today's demo, we'll be essentially working inside of a project. Now projects are a great way to share resources across a team. You can have standing instructions and documents everyone kind of works from. So for instance, in this example, we have a launch brief for the specific newer feature that we are launching, and then also a bit more deep dive data on the churn from our customers. Alright. So let's give it the first task. I'll choose a folder as well. Alright. So what it's doing right now is it's planning. It pulls in the project instructions and the two knowledge files. It works out which tools it needs and kind of lays out the steps that will follow. And I've also, set up the approvals for automatic, so it should end to end to end kind of run without asking me. And as it kind of builds up the plan, it will start kind of reading through the different tools as well. So it's going to read through, for instance, the drive tool for our q three, churn data, the HubSpot tool for any data related from directly coming from CRM. It might be even running code and writing a running code result, maybe for building out, like, those usage drops or, the revenue at risk where it needs to do a bit more of arithmetic. So it is going to a bit of take a bit of time. So what I've done is I've already run it yesterday as well. So you can see that it has completed the run. It has looked at a number of different tools. So there was CRM. There was a Google Drive tool. On the right hand side, I can see the progress across all steps and the outputs, also the specific context to use for this one and the connectors and skills used. If I scroll down, I can open up the specific files as well, Let's talk about a bit more, detail on what particular documents and Excel sheets it created. Here's the plan. Four sections. The churn drivers with the sources it used, the top 10 rank by revenue at risk, a three week outreach plan, and an engineering follow-up, which has product effects it found in the support tickets, including a few preview bug. In the same ranking as a working spreadsheet. So all 30 accounts and the scoring behind it. It also doesn't need to be one off, so you can have same prompt, same project, set it out, run weekly. And every week, there is a fresh version of this plan before, for instance, your pipeline call, and you understand what's the next step of, tasks are. So that's all from Cloud enterprise in AWS Marketplace. You get access to those three chat surfaces, chat, co work, and cloud code with the enterprise governance and administration controls, and you procure through AWS marketplace counting against your AWS commitment. Alright. So that was it. So I'll hand it back to Ian, to cover some details of the cloud desktop on Amazon Bedrock. Thanks, Jamal. Back again. So I'm back again just to say that cloud desktop now works with Amazon Bedrock as the inference provider, as Jamal mentioned. Now you get the cloud desktop experience, chat, co work, and code all works with Amazon Bedrock as the inference engine. And, obviously, it's paper token, because it's Bedrock in play. Now important thing to notice, the conversation content, like the prompts, responses, files, tool outputs goes only to Amazon bedrock, and the conversation history is stored on the user's device. So your confidential data lives in your AWS environment and on a machine you already manage. There is no third place. And inference requests, go directly from the user's machine to also the regional endpoint that you have configured in Bedrock. So if you have data residency requirement, your inference call can land in, you know, your in in region your in region or GeoCris regions in Asia Pacific or Europe or US. Cloud has Aethropic has also recently launched the cloud dot ai admin console for cloud desktop with Amazon Bedrock. Earlier, it was only available in cloud enterprise. Now using that, admins can set the provider, the models, which of the three tabs each group sets, and per user token limits. And commercially, you know, it has no sets, usage bills as Bedrock tokens, and it is counted as native AWS spend, and it also draws down your EDP. With that, let me jump to a demo of how Cloud Desktop works with Bedrock. Here we will see how Cloud Desktop integrates with Amazon Bedrock. So listing down the AWS profiles that I have on my laptop, then opening the Cloud Desktop, Developer, configure third party inference, connection, choose Bedrock, choose the Cloud vendor profile as the option, specify the AWS region, copy the AWS profile name, and paste it in the AWS profile name text box. And then you should specify the model identifiers, the model list, the the list of models you want to give access to, relaunch the app, and now you can see you are connecting to Amazon Bedrock. You can use chat and call over. Let's test it with a simple prompt. You can also use code as part of the cloud desktop application, testing it using like a simple prompt to write a to do application. Once done, you can test it. Seems like it's working as expected. You can also connect cloud desktop to a regional inference endpoint in Amazon WebRock. So what I have to do is, again, open the cloud desktop app, third party inference profile, and update the AWS region to the new one. Here in this case, I want to connect to AP Southeast two, and then add the new model identifier. Apply changes, and relaunch the application. Now you are connecting to the regional endpoint of OPUS 4.6 in the Sydney region. You can also attach bedrock guardrails in Cloud Desktop. For example, here I have created a card rail, which restricts the model from giving any kind of investment advice. I'll add the guardrail identifier and the version as custom inference header in plot desktop. Any normal prompt goes through fine, but whenever you ask any question related to an investment advice, it restricts that prompt. Okay. So that's about the demo of how Cloud Desktop works with Amazon Bedrock. And with that, I'll hand it back to Jimar. Alright. Thanks, Ayan. So let's kind of bring it together for everybody. Right? So we have four paths. And I would kind of go back to the question that Scott had right at this at the start of it. Think about a workload, whether, being kind of a data processor, whether it can be within, the anthropic boundary or within the specific your own AWS boundary. If yes, then kind of take that full feature set, and you have the options of cloud platform on AWS for builders, and cloud enterprise for the workforce. And for the AWS boundary, you have the options on cloud Bedrock, again, cloud and Amazon Bedrock or the cloud desktop on Amazon Bedrock. The same kind of model experience in every path, cloud code being available across all the four four paths as well. The build kind of goes through or the procurement go through AWS, for all, paths as well. And finally, all of them being kind of additive in nature. So you pick kind of the workload, you pick kind of the option for your workload, and that kind of defines, the four different options that you have, on the use case specifically. Alright. So what are the next steps that you could do this week? I have four resources on the screen over here. You will get the links for them available within the webinar. And right after this webinar, you'll also get an email with all of these four, resources sent to your inbox. And the first one is a cloud and AWS workshop, a great way to get hands on on the different paths that we talked today. Second is Anthropic Academy. It gives you free resources on, you know, cloud one zero one, AI fluency, cloud code, in action, and resources like more depth on MCP skills. I would definitely recommend to take a look at that and utilize as you go deeper into either of those, paths that we talked today. And then Entropia Partner Academy, gives you access to the certifications which are available by Anthropic, across the three or four different paths that we have available today. And then finally, our GitHub samples are, our samples and cookbook deposit fees are available on GitHub. Alright. So thank you again, everybody, for joining. Really appreciate your time.