Strands Agents SDK vs Bedrock AgentCore
Chapters8
Explains how agents are configured with prompts, memory, and tools, and introduces the agentic loop that the LLM drives.
Strands Agents SDK and Bedrock Agent Core serve different roles: SDK builds the agentic loop locally, while Bedrock Agent Core provides a managed cloud platform to run and orchestrate those agents.
Summary
Be A Better Dev’s video by name-drops Be A Better Dev, walking through the core differences between Strand’s Agents SDK and Amazon Bedrock Agent Core. The host explains that Strand’s SDK is a model-agnostic toolkit that builds and orchestrates the agentic loop—handling thoughts, actions, and external tool calls—while Bedrock Agent Core is a fully managed service that hosts, runs, and stitches together the entire agent workflow in the cloud. He emphasizes the spectrum from local development with Strand’s SDK to cloud deployment, weighing the overhead of building memory, MCP gateways, and observability yourself versus using a hosted solution. The video includes practical, quick-code demonstrations: a simple hello-world agent with a calculator tool, switching to a custom model, and wiring a DynamoDB-backed memory example, all to illustrate how tools and memory are wired into the agent. A significant portion is spent contrasting deployment paths—AWS Lambda-based patterns with Strand vs. Bedrock Agent Core’s runtime, memory, gateways, and harness features. The host then presents two gotchas and two deployment workflows: starting from Strand’s SDK and deploying to Bedrock, or starting from Bedrock Agent Core and letting Strand behind the scenes generate the necessary files. Throughout, the talk stays high-level and accessible, aiming to clarify when to choose Strand’s SDK, Bedrock Agent Core, or a combination of both for AI projects. The conclusion nudges developers to start locally with Strand’s SDK for quick iteration and then decide between Lambda/ECS/Fargate or Bedrock Agent Core for scalable cloud execution, depending on the desired level of abstraction and control.
Key Takeaways
- Strand’s Agents SDK provides model-agnostic orchestration and exposes over 20 built-in tools plus support for custom tools, with memory, session context, and observability built in.
- Bedrock Agent Core is a managed, serverless platform that hosts and runs agent workflows, offering runtime compute in microVMs, memory persistence, gateways for MCPs, identity management, and optional features like a code interpreter and a harness.
- You can deploy Strand-based apps to Bedrock Agent Core or deploy standalone to Lambda/ECS/Fargate; Strand can also be used to develop locally and then deploy to cloud.
- Two common workflows are (1) develop in Strand’s SDK and deploy to Bedrock, and (2) start with Bedrock Agent Core and then generate the Strand-backed project files; both paths are supported but can be confusing at first.
- Harness in Bedrock Agent Core (in preview) promises to stitch together complex workflows via a single config, potentially simplifying multi-component agent setups.
- The recommended pattern is to develop quickly with Strand’s SDK locally, then move to Bedrock Agent Core for managed, scalable production runs when you need memory, persistence, and enterprise-grade tooling.
- When using Bedrock Agent Core, you get built-in observability, policies, evaluations, and a registry to manage, monitor, and govern agent behavior.
Who Is This For?
Essential viewing for developers curious about deploying AI agents at scale who want to know how Strand’s SDK compares to Bedrock Agent Core, and when to use each (or both) for local development versus production cloud workloads.
Notable Quotes
"The answer to what facilitates this is the strands agents SDK."
—Defines the SDK as the orchestration layer for the agentic loop.
"Bedrock Agent Core is a completely managed serverless AWS platform to both deploy and run your agent."
—Highlights the core value proposition of Agent Core as a managed service.
"You can use Strand SDK to develop locally and then deploy to Bedrock Agent Core instead of Lambda or ECS."
—Summarizes the two-workflow integration path.
"Harness is going to be the next big thing for Agent Core."
—Notes upcoming feature that could simplify workflows.
"If you want advanced features like memory and a full toolset, Bedrock Agent Core can handle that for you instead of building it from scratch."
—Contrast between DIY vs managed features.
Questions This Video Answers
- How do Strand’s SDK and Bedrock Agent Core differ in terms of deployment complexity?
- What are the best practices for using Strand SDK locally before moving to Bedrock Agent Core?
- Can Bedrock Agent Core replace Lambda/ECS for all agent workloads, or are there trade-offs?
- What is Harness in Bedrock Agent Core and when should I start using it?
- How do memory, sessions, and MCP access work in Strand SDK vs Bedrock Agent Core?
Strands SDKBedrock Agent CoreAWS LambdaMCPMemorySession contextTool integrationCode interpreterHarness (preview)Observability
Full Transcript
Hello everyone. In this video, we're going to be talking about the difference between Strand Agents SDK and Amazon Bedrock Agent Core. These are two different components that personally I was very confused about when I was trying to learn about the difference between the two. So, what I wanted to do in this video is kind of share with you some of those learnings. And I want to keep it kind of high level. I'm not going to go into super detail on each of these two things. I'm just going to give you just enough information so that you'll understand the difference between the two and know when it makes sense to use one or the other or both for your AI project.
So, let's just jump right into it. But before we can understand the difference between these two services, we need to do a little bit of a recap on agents and more specifically how agents work. And so, we're going to keep this pretty quick. Uh so, let's just assume that we have an agent here. And whenever you're setting up an agent, uh you need to set up and provide some configuration for that agent. So things like a system prompt which tells the agent what its role is, what it's trying to do, what its goals are, things like this.
Then you set up things like memory. So if you want to support memory, so longer term memory, if your agent can recall different memories about you as the user and be able to provide input to the questions that you're asking it, uh that's a configuration that you can provide. There's also tools and MCP servers, which is the ability for the agent to get information that exists outside of the agent's context. So things like calling databases, calling APIs, stuff like this, right? So this is all configuration that you need to provide initially when you're configuring your agent.
And so how agent workflows work is that you as the user provide some kind of input and then within the agent there's this kind of loop that occurs where the input is provided to the LLM and then there's a thought. So the LLM will try to break down what is the user trying to do maybe break it down to a series of steps and then try to execute on those steps. So it'll perform certain actions. uh action can be maybe recalling data internally, recalling a memory or or calling some of the tools that you provided to the agent.
So calling a database for example, that will produce some kind of result and then depending on whether or not that result satisfied the final goal of your user's prompt. Uh if it didn't, it'll just go in a loop over and over again, right? So then it'll go to step two, step three, and you just repeat this thought, action, result loop until you get to the final output. Okay. And so in this song and dance, the LLM is the reasoning layer. So whether it's claude, open AI, whatever LLM that you you choose to use, that's the kind of brain of the operations that's performing the thoughts.
It's analyzing the results, understanding the initial inputs and deciding whether or not when it makes sense to provide the final output back to the user. So this whole thing is called the agentic loop, right? And if you think about this agentic loop, the LLM isn't doing all of this. It's only doing a couple of the components, right? It's taking the input. It's doing the thoughts. It's analyzing the results and performing the final answer. But you need some kind of component that is going to be kind of performing this job, right? To do all these different things uh in order for the agent to get to its final end goal.
And so you need to think about like what is facilitating this? It needs to be some kind of code or some kind of um system that is doing this for you. And the answer to what facilitates this is the strands agents SDK. Okay, so that's where Strand's agents SDK comes into the picture. It performs the agentic loop for you. It has the code that allows the LLM to go and call these external tools, call these MCP servers, interact with memories and provide it to the LLM so that it could perform its function. Okay, so that's Strand's Agents SDK.
Now, I want to go into a little bit more detail on Strand's Agents SDK before we get to bedrock agent core just so that you can have a little bit of a better understanding of what it does and how it works with a practical just quick demo example. Um, so as we kind of talked about uh it's a model agnostic framework to develop agentic workflows and when I say model agnostic uh it means that you can use any model that you want. It could be provided through bedrock. So bedrock has a bunch of models you can access um through it or you can integrate directly with things like open AI and the strands agent SDK handles the agentic loop orchestration but it has a ton of other features as well.
So firstly there's tool and MCP discovery and usage and the nice thing about Strand's SDK is that it comes with over 20 built-in tools. It also has community tools that are being developed all the time. So things like being able to perform HTTP requests to other APIs, perform read and write operations on disk to do math operations, integrating with Slack, integrating with GitHub, calling AWS services. All these different types of tools exist that you can easily leverage in your agent with just a couple lines of code. Alternatively, if one of the tools doesn't exist, you can create your own.
So say you have a proprietary database that you want to provide your agent access to with trans agent SDK. You can in a couple lines of code and I'll show you this later on how to do it. You can very easily integrate a custom tool into your application with agents SDK. Moving on, we also saw uh there is session and memory integration. So being able to recall memories and also having access to the context of a session uh for your agent. There's multi- aent collaboration. So if you'd like to have a kind of fan out pattern where you have multiple agents performing subtasks and reporting them back to the top level agent also supported with trans agents SDK and you have a very powerful set of observability tools.
So um more details on what the agent is actually performing, why it's coming to certain conclusions, logs and metrics that get emitted automatically. And then on the quality front there's accuracy and consistency tools. So things like eval that allow you to ensure that your agent is actually doing what it's supposed to be doing and not kind of going off the rails and you know doing the wrong task for what the user input provided. Now the one of the caveats with at least currently the trans agents SDK is that there's only Python and TypeScript support. So um this is as of June 2026, but I imagine that as time goes on uh you're going to see more and more languages supported.
Now, the nice thing that I like about Strand's SDK is that it's very easy to set up an application quickly, which lets you develop and test locally and then when you're ready, deploy that application to the cloud. So, you can get it up and running, verify that it works correctly, configure it as you wish, and then when you have it good to go, you deploy it up to AWS. Now, one thing to remember about Strand is that it's an SDK, right? So, it's a toolkit that allows you to build aic applications. It's not a service in and of it itself.
It's just an SDK that allows you to perform a function. Kind of like CDK, right? CDK cloud development kit is not a service for AWS, but it's just a means to an end, right? And that's what Strand's agents SDK is. So, what I want to do now before we move over to the Bedrock uh agent core land is just give you a really quick uh demo with some code examples to show you what you're getting into if you're using uh Strand agents. Okay, so this one is kind of like a hello world example. So very bare bones.
Um, so if you look at the top line here, this is the installation command. This is just a one-time thing that you have to do to set this up. And by the way, um, it's by default going to use claude via Bedrock, but you do need to have AWS credentials. So AWS configure is the command and claude for sonic enabled in the Bedrock uh, console. So make sure you do that if you are using just the vanilla version of Strand's SDK. And then from there we are importing the agent object from Strand. This is going to be the main object that you're going to be interacting with to do things like provide your system prompts, add tools, which we'll see in a second.
And then on the next line there, we are importing an existing tool. So this is one of the the tools that is out there. So this is the calculator tool that allows uh the agent to perform complex math operations. And then on the next line we're seeing uh the instantiation of the agent and we are explicitly providing the agent with access to certain tools. Now one quick thing to keep in mind is that the agent will only have access to the tools that you specify. So even if you know there exists a whole bunch of tools out in the wild even in your application itself if you don't provide it as input to the agent itself the agent will not have access to it.
So one small detail to keep in mind and then finally we're just invoking the agent here. I think you all know how this works but uh you'll get an answer which you can stream back to the user or just print it um with a print line if you desire. Okay, another quick demo. Uh let's go on to uh just using a custom model as opposed to clot. And so if you look here on this particular line, we're providing a custom model to the agent. So this is an open AI model which is currently supported. And then you just specify the model ID that you'd like to use and the API key that you get from open AAI.
And this demo is also showing an example of using a system prompt, right? So you provide the system prompt in the agent instantiation uh for whatever the goal of this agent is. All right, moving on. One more quick demo just a little bit more of a fancy one on using tools. And so this is the code to do that. This kind of example is imagining we have like maybe some kind of a Dynamob table that contains who is currently on call for my team and you want to provide an agent with the ability to look that information up quickly.
And so what you can do is you see this this tool decorator here, right? This tool annotation that's on top of this Python function and it essentially tells strands that this is a supported tool, right? Whatever is in this method or in this function is callable from the strands agent SDK. And you can also see that we have some dock string here about what this function does. And this is extremely important for agents in general because the better documentation you have, the more it's going to know about when it makes sense to use this tool or not.
Also very important to have uh input types here. So input and output, right? So this is going to tell the SDK what it needs to uh provide, which is also very very useful in its reasoning. So it doesn't need to go through loops of trying to figure out like what do I need to provide this function? Um and then next we are going to provide the agent with the ability to call this tool. And so we set up here we have this function called get on call and we added this tool decorator on top of it.
And now we are providing that tool the function name of the tool into the tools section of the agent instantiation. Okay. So that's creating custom tools in action. Okay. So let's move on now and I want to talk about deploying to the cloud. Say you build this whole thing out right like this get on call agent let let's run with that example and so you develop this application locally and like okay this thing looks good you decide hey I want to deploy this thing okay so the simplest way to deploy this this application is to deploy it to AWS Lambda right and say you want to add some of those extra features right you want to add those features for uh memory right or just session context right so it's able to recall this information outside of the initial invocation.
What you would need to do is you would need to create a DynamoB table and you would need to link it up in your Lambda function so that you can recall information. And so you would need to programmatically do this implement this in your Lambda function so that you can recall information about this user about this conversation and then provide it back to the agent so that it can have that line of continuity. Right? And then you need to kind of decompose that agent object to decide what metrics do I want to emit to to cloudatch what do I want to log right and then say you want to integrate with other tools that exist elsewhere you would need to call that tool or MCP server that maybe exists in other lambda function right and then same thing if there's other APIs that exist out there as well so all this extra stuff that you would need to do and I will add very briefly that there's other deployment options that exist not just for Lambda for your agent strands agent SDK.
So there's Fargate, there's EKS, there's EC2, um there's a couple other ones as well, but I'm not going to go into when it makes sense to use one or the other. Um some of you can probably imagine, but just know that there are other options. So if you think about this whole workflow, right? All this extra work that you need to do of like setting up a lambda function, setting up a Dynamo table, deciding what to log, how to access tools and MCP servers, and then permissions, right? It's a whole nightmare. There's a ton of problems with this approach.
And the big one is that it's just complex and timeconuming to do all this stuff. Like we as developers don't necessarily want to waste our time with all this minutia. We want to build applications that actually provide value. Okay. And so what if there's a better way to do this? What if we take our work that we just did, so what we developed on our Stratton's agent SDK and we took all of that application, right, that we just kind of hypothesized, all the components that we need to to create to support our app and we put that in a box.
And wouldn't it be nice if we can replace all this custom work that we did with something else that provides us with the compute to run our agent with maybe a memory and persistence layer for retrieval and storage. Maybe the ability to call MCP servers APIs, have the ability for authentication, authorization to other tools, and to support things like browser interactions and code execution. And this is just a sample of things that we want, right? There's all that observability, there's evals, there's testing, there's so so much more. It would be so nice if we just put this all in a box and had something do all this for us without having us to worry about the complexity.
And this is Bedrock Agent Core. It is a managed service that handles all of the hosting, all of the minutia of running your agentic application in a very simple way. Okay, so that's just kind of how this fits into this giant puzzle. And you're going to see that you can use Strand SDK. You can define the code in strand's SDK of how you want your agent to work and then just integrate and deploy to to bedrock agent core instead of lambda or instead of ECS or instead of EC2 right so we're going to see that in a couple minutes here okay so let's uh again just talk about what is Bedrock agent core to give you a better understanding of how this works uh so it's a completely managed serverless AWS platform to both deploy and run your agent Right, running is the key aspect here and the important bit about this is that it supports any framework any model right so you can use strands you can use slang graph crew AI whatever you want you can use foundational models that are served via bedrock claw gemini openai doesn't matter you decide what you want to use it's meant to be very agnostic and within bedrock agent core there's 12 different managed components and the key is that you can pick what you need you don't need to use all of them there are a couple that are just kind of the basics that I think you will need to use for just your run-of-the-mill agentic application.
But it's kind of an allocart menu, right? Where you can pick and choose what you want and then if you didn't add one when you initially set up a core, you can easily add it later. All right, so the first and most important one is runtime and this is your compute layer and runtime allows dedicated and isolated sessions of your agentic invocation on a microVM. Okay, so this is the actual compute that is running your agent workflow. And from what I can tell, this is pretty much a Lambda function behind the scenes. It has so many of the characteristics of a Lambda function.
Maybe like an enhanced version of it, but it really feels like it. So, it's got problems like cold start. It's got like versions and aliases and things like this. These are hallmarks of Lambda functions. So, I'm like 99% sure that they're using Lambda behind the scenes for this. although I couldn't find any documentation that actually says that explicitly. Okay. And then another one you'll probably use is memory. So memory is for both short, long, and then just persistent storage of memory in case you want to dump it somewhere that so that you can examine it.
So that's also supported. And there's no like database that you need to worry about here. Bedrock agent core handles all that stuff for you. And then there's gateways which is kind of like a federated and governed way to access MCPs and API integrations. Um so provide you with external access to tools for your agent. And when you combine that with the identity component which is authentication which is the who and authorization what for your agents um you combine identity and gateway you can easily say like okay this agent only has access to this tool or MCP server.
You can kind of see some of the potential here of what identity is trying to do. It also supports like JWT and O tokens as well. So if you're trying to access other services, it handles all that token management for you. Also has the ability to use browsers, right? So if there's something where you need to interact and navigate uh with external websites and not they don't have an API maybe that's supported. Uh so it uses I think playwright or selenium I can't I think it's playright behind the scenes in order to do this for you.
So that's something you can easily add. Then it's got a code interpreter as well and for those of you that are using AI a lot you know that it's really good at writing code right so you can give it the ability to write its own code and then execute it on your behalf as well. Also has a ton of observability features. So both execution logs and metrics and graphs to show you about single sessions and just what's going on at a meta level for your agent. Very useful for alarming and just understanding the reasoning of your agent.
Also has a registry so that this is more appropriate for organizations. But it's a searchable catalog for your org to say okay we have an agent that does maybe analytics or we have an agent that does like data aggregation or you know these kinds of things. So then you can expose that uh to your org so that people can just reuse them instead of of building their own. Um then it also has the ability for payments. So a use case for this is like if there's microtransactions that's needed uh so interacting with things like Stripe APIs, maybe your agent needs some data from like a journal or something or some kind of data set that it needs to be able to to determine it needs to buy and purchase on your behalf.
You can give it that ability of course. of course with guardrails, right? Because we don't want it going completely off the rails here and and kind of bust in the bank. Uh next we have evaluations which allow us to kind of ensure or evaluate, verify, and tune agent performance so it's actually doing what we want it to do. And then there's policies that allow you to constrain what the agent is allowed or not allowed to do. And this integrates very nicely with the Cedar open- source language. And then finally, there's this new concept called a harness.
And the harness is it allows you to stitch the entire workflow together with a giant config file. Now, I will add that this is currently in preview mode. So, it's not something that I want to talk about too much, but I feel like based on what I've seen so far, harness is going to be the next big thing for Agent Core. Uh, so by the time this video or you watch this video, you kind of this may already be released for um outside of preview in in GA. And so um you may want to look more into this.
I'm not going to dwell on it too much because it's still subject to change. Okay, but it looks like harness is going to be the next big thing for kind of setting up your applications because today you need to use the agent core CLI to or you can also do this through the console itself. uh but to to add components uh and then you can also compose them with strands right so these are kind of two options to achieve the same outcome either use the agent core CLI to add stuff alak cart or you can add them via strands and I'll show you an example of that in a little bit so the one thing to remember with bedrock agent core if you remember anything at all is that it abstracts away these details to let you build a genic applications faster right if you weren't using agent core and you were just using Strand's SDK, you would need to do all this stuff manually, which is not something anyone wants to do.
Um, so that's kind of the main feature of agent core. Okay, so let's do another quick demo just to show you what you're getting into. So this one is going to show you how to deploy your agent written in strands to bedrock agent core. Okay, so again, very very simple hello world kind of example. Um, so you'll see here there's an import that I added here. Sorry, I forgot to add a box for this one in the animations, but you can see we're importing the Bedrock Agent Core app here at the top, right? So, that's kind of a key import that's going to indicate that, hey, we want to use um agent core for the deployment target here.
And then you can see we're instantiating the agent core app in addition to the agent, right? We're not just doing one or the other, we're doing both if we want to use a core. And then um on the next one here, we're also providing an app.ent entry point. So this is telling agent core that this is the function to run when you're provided with a prompt and you can see on the next one here we're supplying the agent with the prompt and then we're just kind of returning this result here. Right? So this is very very simple hello world kind of thing uh to show you how this works in practice and then finally just running the app.
Right? This is just another mandatory line that you need to provide as well. Okay. So that's like a hello world kind of example. Let's look at another one really quick. Uh so this one is if you start you do this in reverse. You want to start with the agent core CLI and deploy a strandsbased application. So kind of confusing and we'll talk about this more in a second. This is something that actually confused the hell out of me in the beginning. It's like what is going on here? Um you can start with strands or you can start with bedro aore and then use strands.
Like what? But anyways, this is kind of how it works. And I don't know, this this needs a little bit more thought because it's confusing for people. Anyways, here's the code example here of what you would do. And so, um, there's a one-time setup here where you would say agent core create. By the way, you need to have the agent core CLI installed. There's a command to run that. I think I omitted it here, but it's pretty simple to do. You can look it up. Uh, I think it's just like pip install agent core or something like that.
Um, and then we have agentore create. Uh, you're providing it with an agent here. you're providing it with a specific framework. So we're using strands for this but you can also use langraph if you want and then we're providing the model provider which is bedrock and then we're saying we don't want any memory for this application. Uh one thing to keep in mind is that if you change your mind on this and you want to add memory later you can easily do that with another command. Not going to show it here. This is just an intro but just know that that is available.
And then on the next line we are deploying it. So just a simple command agent core deploy and then that's going to be deployed out to bedrock agent core and then once that's done you're able to invoke that via the CLI right so you're able to test it make sure that it's performing as it should now whenever you deploy like as we saw up here um it's creating an instance of Bedrock agent core and that has an ARN that you can leverage to call it programmatically if you'd like and so this is the code in order to do that Right.
And so um for this we're we're just kind of pulling out the uh or sorry we're we're getting a client for bedrock agent core and then we're calling the invoke agent runtime right and then here we're this is the ARN of our instance and so uh you know and the name of it is is this guy here hello XYZ whatever it is then you do need to provide the session ID for it and then you can provide the input right so this is kind of what you would provide into the invocation this is like the user prompt for example.
Okay. So this is how you would call it programmatically from something like a lambda function or from you know your ECS instance whatever it may be. Okay. Uh I want to talk about two gotchas. We already kind of talked about this briefly but just really quick. Um so there's two ways that you can use agent core and strands. You can either initialize your project using the strands SDK and then deploy to a target of your choice with small code changes. One of those targets could be Bedrock agent core or you can do with lambda, ECS, Fargate, whatever you want or you can do this in reverse which is confusing.
You can create the project with Bedrock agent core which we just saw in the last demo and then that generates the necessary files that leverage strands behind the scenes and then when you run agent core deploy then you're pretty much good to go. It'll deploy that out to agent core for you. Okay, so that's kind of something that was really confusing to me for a long time. Uh, but hopefully it's clear now. And then like uh if you if you don't believe me, go and create an agent core project. Just do a core create using the command I showed you in the previous slide and then poke through all the files that that the project will generate.
You'll see a strands folder there that has like a bunch of information about uh the strands project itself. Okay. Uh okay. One more thing just to make this clear for people. when to use what because this is also kind of confusing. Should I start with agent core? Should I start with strands? My suggestion here and this is my opinion is that you should use strands to develop and test locally. It's very quick to set up a basic project. You can get a feel of some of the features that are are supported with it. And you can add tools.
You can verify everything works correctly on your desktop very very easily. And then when you're you're ready to deploy, you're like, "Okay, cool. We're good. We want this out to the AWS cloud." I would suggest you start with a lambda function if you're using a simple application, right? If if you want access to things like memory, um then I don't necessarily suggest you you kind of start with Lambda. But if it's just like something that's kind of contextless and just kind of a a singleshot question and answer uh pet application, that then use a lambda for this.
But if you want um full flexibility like you want to choose what database manages memory, you want to like store or store store the context of users separately. Uh I would say if you want those advanced features, use lambda and then roll your own for all those other things, right? So that you can completely control the entire life cycle of your application. This is probably a very very small subset of users, okay? Because this is exactly what agent core provides. So if you still want those advanced features but you want a manage solution then use Bedrock agent core.
At least that's my suggestion. Anyways that's the video on Strand's agents SDK versus Bedrock Agent Core. I hope you found this video useful. Please don't forget to like and subscribe and I will see you in the next
Get daily recaps from
Be A Better Dev
AI-powered summaries delivered to your inbox. Save hours every week while staying fully informed.





