{"slug": "podcast-strands-agents-with-clare-liguori", "title": "Podcast: Strands Agents with Clare Liguori", "summary": "Clare Liguori, Senior Principal Engineer at AWS and technical lead on the open-source Strands Agents SDK, said the SDK grew from an internal project to a full agent harness running in production by using a model-driven architecture that requires only a system prompt, a set of tools, and a choice of model. Liguori explained that the approach avoids brittle predefined workflows by using modular prompts called Steering hooks to inject determinism when needed, improving accuracy for multi-step tasks.", "body_md": "In this episode, Thomas Betts talks with Clare Liguori, the technical lead on the open source Strands Agents SDK. The conversation covers how Strands Agents has grown from a Python SDK to a full agent harness running in production. Clare shares some lessons learned from building agents at scale, shifting to a model-driven architecture, and what comes next as the LLMs that underpin agents continue to improve.\n\n### Key Takeaways\n\n- Strands Agents is an open source SDK for building AI agents without the cognitive load required for most agentic frameworks.\n- Strands Agents requires just three things: A system prompt; a set of tools; and your choice of model.\n- As opposed to frameworks that require scaffolding and workflows, the Strands approach is model-driven, with hooks that provide guardrails.\n- Because monolithic prompts can be ineffective for large, multi-step workflows, the Strands SDK uses a modular prompting paradigm called Steering. Steering hooks inject a small amount of determinism when needed, resulting in greater accuracy.\n- Architectural principles are still relevant when working with agents. Design, build, and test small modules, like the tools provided to the agent, because holistic agent tests are difficult.\n\n### Subscribe on:\n\n## Transcript\n\n**Thomas Betts**: Hello and welcome to the InfoQ Podcast. I'm Thomas Betts and today I'm talking with Clare Liguori. Clare is a Senior Principal Engineer at AWS and a technical lead on the open-source Strands Agents SDK. Our conversation today will cover how Strands Agents has grown from just a Python SDK to a full agent harness running in production. I'm looking forward to hearing some of the lessons that Clare and her team have learned building agents at scale, shifting to a model-driven architecture, and what comes next as LLMs that underpin these agents continue to improve. Clare, welcome to the InfoQ Podcast.\n\n**Clare Liguori**: Thanks.\n\n**Thomas Betts**: So, tell us about Strands. What was the problem you were trying to solve and what was lacking from other agent frameworks, or maybe there weren't any agent frameworks when you got started?\n\n**Clare Liguori**: Strands started as an internal project with really us trying to solve a problem. We were building a set of agents to help people with AWS, and we were just finding it really challenging to build a reliable production agent easily. There were existing frameworks at the time, but they required a lot of cognitive load as a developer. So we started Strands as an internal project for a very specific set of agents that we were building, and we found that it generalized really well to the other agents that other people inside of AWS were building as well. And then May last year, we released it as an open-source project because we found it was working so well for us, we figured it would probably work pretty well for others as well.\n\n## The Model-Driven Approach [[02:16](javascript:void(0);)]\n\n**Thomas Betts**: And what do you mean by \"generalized well for the other things\"? What was the thing that everyone else was able to just grab onto that you thought you were just solving your one problem?\n\n**Clare Liguori**: We call this the model-driven approach. I think that a lot of the frameworks at the time were very heavy into defining workflows, and through our own building of agents, we had found that to be very brittle. We couldn't really predict what inputs were going to come into an agent. We say at AWS that customers will use your service in ways you never predicted, and I think that's true for agents as well. People will feed input into agents that you never predicted. And we were finding that as we were building these workflows, they were simply too brittle for the inputs coming in. They would not handle things like a customer asking a compound question, \"Tell me about this and tell me about that\", things like that.\n\nWe arrived at this model-driven approach where models at the time—this was around the time that Sonnet 3.7 was out from Claude—and they were getting better at doing, one, their own tool calling, and two, their own reasoning. They were becoming much better at planning their own kind of trajectory to solve a problem. They were getting better at chaining tool calls together. And so we found that actually it was much more powerful to let the model do the reasoning. So the model-driven approach is effectively you give a system prompt, you give a set of tools, and you choose a model.\n\nAnd with those three simple things, it was good for two reasons. One was it's a lot easier for developers to get started. People can grok what is a system prompt, what are a set of tools that I need, and what model do I want to pick. So it makes it really easy to get started in just a few lines of code. You have three choices to make basically to get started building an agent. But the other one that we found was the more that we built scaffolding and workflows around the agent, the more we hampered the model, and actually the worse that we made the model.\n\nWe found that we would proactively try to stuff the prompt with a bunch of context we thought the model needed, but actually the models are really good at determining when they needed to retrieve information as opposed to what was very popular at the time, which was this kind of RAG-based context pipeline. So those two things led us to build new agents and get them into production in a matter of weeks.\n\n## Guardrails and Evaluation [[05:06](javascript:void(0);)]\n\n**Thomas Betts**: Oh yes, when you simplify down to, you said just those three things. I've used—so I build agents at Blackbaud—and we have a platform that's kind of closer to what you were describing, you have to build stuff into our workflow engine and what are your little sub-agents, and you compose all these pieces. One of the reasons we approached that was we wanted to make sure that we had this responsible AI, it can only do the things we have told it to do. And so if we didn't tell it how to do something, then it couldn't do it. And we thought that was for security. You're coming at it from the other approach, which is just let it run wild. How do you introduce the guardrails? How do you make sure it doesn't run off and do its own thing that you weren't expecting it to do?\n\n**Clare Liguori**: So I think that's a combination of evals and hooks. You know, the likelihood that a frontier model, or even some of the smaller open-source models, does go run wild is in practice very small. We found that over-architecting for that small percentage was holding back the power of the overall agent for all of the happy cases where it was legitimately trying to solve the customer's task. So I think that, one, is quantifying how often does it go on a wrong turn, and that's about the evals. We launched the Strands Evals Kit in preview last December, and it's just recently gone 1.0.\n\nSo that's a really nice set of tools for evaluating how often does the agent go off-script, how often does the agent go outside of some of the behavioral guardrails that you set maybe in the system prompt, for example, that it's not respecting. So understanding the scale of the problem is kind of step one. The second step of the problem is how do you control that in production? How do you ensure that it doesn't go off the rails? And that's really where hooks comes into play.\n\nSo a great technique that we've used here is what I'll call kind of an inline LLM as a judge, where you ask an LLM based on the output of this agent, did it go outside of its behavioral safety guardrails, is pretty well known. But using LLM as a judge inline in the actual execution of the agent is where you can actually control it at runtime. So Strands supports the hooks where you can add a hook before it returns a final response to the user, for example, to run even a very small model, right? GPT-oss:20b probably is sufficient for looking at the output of the agent that's about to go to the user and say, \"Is this telling the user something I don't want them told?\" You can also hook into tool calls, for example, \"Is this agent doing something that I don't want it to be doing?\"\n\n**Thomas Betts**: Yes, I like the idea that you can use the smaller models because sometimes you think if I'm a student taking a test, I need the teacher who knows all the answers to be the judge. But in this case, compare the output to the expected requirements isn't that complicated. You don't need the higher reasoning models, they don't need to go off and think about it for a while. It should be does this fit that or does it not look like that? So that's a nice little thing because people think you're adding all this extra overhead, it's like I'm already spending all these tokens, now I got to spend all these other tokens. Well, those are the cheaper tokens, right?\n\n**Clare Liguori**: Exactly. And you still get the benefit of using a different model, right? A lot of folks are worried about, you know, if you use the same model as your judge versus your agent orchestrator, it will always agree with itself, right? But using a completely different model can help as well.\n\n## Taking Agents to Production [[08:57](javascript:void(0);)]\n\n**Thomas Betts**: So when you said you're getting other teams at AWS and open-source teams or people using the open-source project to get up to speed, are you providing some guidance and best practices on how to build good system prompts and how to create the tools that it's using?\n\n**Clare Liguori**: On the Strands Agents website, strandsagents.com, there is a full guide around how to build agents with Strands, but also how to take that agent to production. Because another thing that we found was kind of lacking when we started building agents was it was easy to build a prototype, easy to demo it, and then it would take us six months to try to get into production. So that was a big focus for us because we were building production agents and we needed a framework that had the right telemetry, had the right hooks, had the right evaluation kit to go with it so that we could actually get this into production.\n\nAnd so I think that's really what is such a proof point that I've heard from AWS teams, but also AWS customers using this, is everybody can write an agent in a day, but hearing how quickly teams are able to get into production has really been the proof point for me that it's really an end-to-end kit for you to write an agent but also take it to production.\n\n**Thomas Betts**: Yes, so what does production look like? Is it only hosted in AWS? My company is mostly on Azure. Is this open source, is this something I could install in Kubernetes and run it on our servers?\n\n**Clare Liguori**: You can run it anywhere and you can run it with any model provider, so it's also not restricted to Amazon Bedrock. You can use Anthropic, you can use OpenAI, you can use locally hosted models. You can run it locally on your laptop and run the exact same agent in the cloud. It follows the whole life cycle development as well for agents. We find a lot of folks will maybe prototype with one agent with one model from one provider, and then once they're going to production, they've got to use their enterprise's light LLM endpoint, things like that when they actually get into production, and it's really easy to switch out the model provider within your agent as well.\n\n## Engineering Liabilities vs. Scaling [[11:20](javascript:void(0);)]\n\n**Thomas Betts**: Yes, the point to get to production is I can see that as a selling point. I can understand the, \"Hey, I got a demo\", and they're like, \"Great, make it live\". That's also where I've seen the customers are going to use your product in ways you didn't expect. I've heard one story that, well, it didn't respond to the prompt, it kept saying it didn't know how to respond. It's like, \"Well, did they follow the list of our 25 approved prompts they're allowed to ask?\" It's like, that's the only thing you could use it for, that's not how these are supposed to work.\n\nBut I think there's some idea that we have people who have been used to building traditional software working in this non-deterministic LLM world. Are there engineering instincts that people have that become liabilities when you're shifting to I'm going to build an agent?\n\n**Clare Liguori**: Oh, absolutely. I think the first one is thinking about answering the question, \"Does this thing work?\" Because as software engineers, we have been trained our whole career and in our schooling that if you write a test and it passes, then you can rely upon that test to catch regressions. And there is no determinism that way in agents, and so you have to start to think a little bit more like a scientist where you have to think about what is a good set of evaluation cases, what is the data set that I'm going to use, and how am I going to evaluate whether the output of the agent was good or not.\n\nWe provide evaluators that use LLM judges where you use an LLM to determine if it's good according to, you know, some rubric that you give the judge LLM. Often I tell folks, if you're building agents for the first time, look for something where you can evaluate it by its tool calls. So what I mean by that is often I think people go towards an agent whose output is incredibly ambiguous. Like if you think about a coding agent, whether the code is good or right based on the prompt is incredibly subjective.\n\nBut we see a lot of customers who are starting out by automating some process, and in that case, you know, you can look at what are the tool calls that it made for a particular task that it was given. And if it made all of those right tool calls and maybe even in the right order, it's highly likely it did the right thing. Or cases where it's something that is information gathering. If it called all the right tools to gather all the right information, likely the final output is probably correct, right? It got all the right information and now the model is summarizing that information. And that is really nice because you can have very deterministic evaluation.\n\nPart of the challenge even with evaluation with using LLM judges is you always get a slightly different percentage point, right? Because the judge itself is not deterministic. You know, if you're dipping your toes in as a more traditional engineer, it's nice to at least have some kind of determinism somewhere in the system.\n\nI think the other part is I often find that as engineers, we do want to add determinism to the system, and so we reach for the sort of procedural constructs that we know. We reach for for loops and if statements and while loops. Those workflow-based constructs in agent frameworks. And we have this idea in our head that if we add workflows, then our agents will be more reliable. They will be more likely to succeed in production because there's an if statement, there's a for loop there.\n\nIn my testing, that's actually not true. You can actually have more powerful, more accurate and reliable agents without workflows, that you have to think about other techniques for increasing the reliability and accuracy of your agents. So I recently did a case study where I ran hundreds of evaluations against a few different techniques for how you steer agents. Things like instructions in the system prompt on, you know, what are the rules of the road for this agent and how it needs to get things done.\n\nI also did workflow, I also did a really, really long prompt with very explicit instructions on the rules for the agent, and then I did something that we call steering hooks in Strands. The difference was really, really interesting. I actually found that simple instructions were more accurate, had a higher pass rate than workflows. So I was able to achieve 82.5% pass rate for just simple instructions, literally four sentences, than workflows.\n\nBut for steering hooks, which I'll describe in a second, 100% accuracy, which is kind of unheard of for agents. And so often with workflows, you end up in this downward spiral where you write the workflow a little bit naively about what you think the inputs are going to be, and then you see a few inputs from users coming in and you start to add more if statements and more if statements and more if statements. And it's a lot of maintenance and a lot of going back to the drawing board on how to guide this behavior that is not actually deterministic. And so one of the things that simple instructions or even these very, very long instructions can give you is allowing the model some flexibility to handle those unexpected inputs, but still adhere to the guidance that you've given it. But of course that can't be completely relied upon, right? We don't trust models to always adhere to our instructions.\n\n## Steering Hooks and Stateful Decisions [[17:28](javascript:void(0);)]\n\nSteering hooks are a way to inject a little bit of determinism at runtime, only when the model needs it. Workflows try to put that determinism on top of the model and try to constrain ahead of time what the model can do, and create smaller agents, micro agents they sometimes call them, that do specific things. But they’re all still subject to going off the rails.\n\nSteering hooks in Strands are a next layer on top of regular hooks.I think of a lot of people are familiar with hooks from their coding assistants. You can say before you run a tool call, run my command and I'll tell you whether you can continue with that tool call. Steering hooks are very similar. You can do a piece of Python code that you want to run before a tool call runs, you can do an LLM judge to determine if the tool call should continue, but the thing that steering hooks adds is what we call the ledger: the full history of every tool call that's happened so far.\n\nSo I sometimes use this example of a mortgage processing agent. And a sample hook here would be you cannot approve mortgages more than a million dollars, whatever it might be. You can do pass or fail on that with any normal type of hook, which all agent frameworks have, based on the inputs into that, you know, mortgage approval tool. But steering hooks gives you the full ledger, so you can enforce things like this agent must have done income verification before it can approve a mortgage.\n\nAnd how can you do that with, you know, a lot of agent frameworks today are just plain hooks? It's very difficult to have kind of a stateful decision on individual tool calls. Often you can put these things in your instructions, you can put them in a, you know, very adamant phrase in your instructions, \"Do not call mortgage approval before income verification\", but in order to reach that 100% accuracy, you need that ledger so that when it gets to that mortgage approval step, you can actually check in the ledger, \"Has income verification tool been called and did it get an acceptable income or whatever it is output out of that tool before this is being called?\"\n\nBut at the same time, it still leaves it flexible for you to take on inputs like, \"I don't want to submit a mortgage yet, but I want to see if I would be approved for a mortgage\", right? If you have a workflow that's very structured towards the user's going to be asking to approve a mortgage, the workflow just kind of falls on its face in the face of these related but slightly unexpected inputs.\n\n## Procedural Memory [[20:25](javascript:void(0);)]\n\n**Thomas Betts**: Yes, the thing that a lot of people are running into, we design this and the way you describe it is like, \"We need to add one more if statement\". Well, it goes back to if you think about how LLMs are built, like I've had to explain basic machine learning algorithms to people, it's like, \"Hey, if I have the image recognition and it's like, is there an animal in this photo, yes or no?\" Like that's a yes or no question. And then the next question is, \"Is it a cat or a dog?\" \"Oh, it's a cat\". \"Well, what type of cat is it?\" You know, you might just be asking yes or no questions, but if you're 10 layers deep, you've got hundreds of—or thousands quickly—of if statements. No human can write that code, that's how machine learning works. It's like, it's amazing, but it's all predictions.\n\nYou have to sort of adopt that mindset in how you're attacking the problem because that's what you're using. The steering hooks sound very interesting. I've definitely seen, like you said, the simple ones. Does this get into evaluating tools—because someone has talked to me about having a tool evaluation system where it tries to call a tool, sees what the result is, and then like, \"I have another tool I'm going to use\", or maybe I'm looking at the new one and saying, \"Oh, I can see that over history, this new tool is better, I'm going to stop using the old tool\". Does it rate that, or when you're talking about the ledger, it's just in the context of that one conversation?\n\n**Clare Liguori**: That one's just in the context of that one conversation. I have seen some really interesting work around what I'll call kind of procedural memory for agents, which is basically the memory of the trajectory of the agent, the memory of the set of tools that it called to achieve an outcome. We had a similar challenge very early on where we were building a network issue resolution agent. And in order to do that, the agent had to go and collect a lot of information. It had to call like 15 different APIs in order for it to have all of the information it needed to diagnose a network issue.\n\nAnd at the time, at least, it was very difficult to get the agent to do that reliably. When it's, you know, 15 tool calls, it could likely get up to 10 reliably, but not 15, and it just wasn't super reliable. One of the things we did there was we kind of hacked it together, but I'll call it procedural memory, where once it had arrived at a successful answer for a particular input, let's say, \"Why can't I SSH to this EC2 instance?\" then we saved that sequence of tool calls it had made for that particular input and put it in a semantic search database.\n\nThen the agent was able to retrieve past successful trajectories. And so it was able to use that learning about that particular input, \"Why can't I SSH to my EC2 instance?\" to \"Why can't I access port 443? Why can't I access port 8080? Why can't I, you know, curl from this EC2 instance?\" because broadly those were the same tool calls that it needed to make even if they were slightly different use cases coming in.\n\n## Observability [[23:35](javascript:void(0);)]\n\n**Thomas Betts**: You keep talking about I'm looking at how it behaved and keeping track of this stuff. What is in the observability stack? Because it seems like what I have from traditional software probably isn't enough to be tracking all of the things my agent is doing in production: what tools it is using, what was the response, was it the right response. Goes back to your question of how do I know it's working? I kind of need to see it run in production and then also I need the signals to say it's not working. How do you track all that?\n\n**Clare Liguori**: Strands supports OpenTelemetry, which provides metrics and traces for you. I think a lot of people are familiar with OpenTelemetry for traditional systems, but I think compared to traditional systems, traces are actually so much more important for agents. Instead, with an agent, all those hops are inside of the agent as individual tool calls, and so understanding what went wrong with a particular request is all about walking through what were the tool calls, what was the model outputting after each of those tool calls, so that kind of data is gold for continuing to evolve your agent and continuing to improve the quality.\n\nYou know, internally we will have evaluations before we launch a new agent, of course, but what's interesting is—and we keep going back to this—that people's inputs will surprise you. Your evaluation data set before launch is almost never actually representative of your production traffic, right? And so after you launch this agent, it's now a constant job to go and look at the traces, look at sample inputs, and look at how the agent did. And so there's a lot of evaluation to be done not just on your test data set, but also now on your live traffic.\n\nHow well did the agent do? Do you have any signals about how happy the customer was with the output, right? Did they curse at the agent? Did they click the thumbs down button? Or maybe it's just ask follow-up questions, things like that. That often, you know, leads back into your test evaluation set, making it more representative. When we launched a chatbot in the AWS console, this was one of the things that we found to be surprising. We had assumed before launch our test data set was all about things like, \"What is S3? What is EC2?\" And so we had kind of tuned the prompt for being very concise because you probably don't want a wall of text if you're just asking, “What is S3?”\n\nBut we found that as people were actually interacting with it, a lot of people were asking how-to questions: \"How do I connect an EC2 instance to an S3 bucket?\" things like that. A concise answer for that is not what you want, you want the wall of text, you want it to tell you actually how to do this. And so we went back and categorized a lot more types of questions and added those to our test data set so that's always super important and a continuing ongoing job to do. I think that’s probably something that’s different for traditional software engineers. We’re used to ongoing maintenance on systems, of course. But, we also don’t expect to have to continually reevaluate the quality of the system. But agents it’s a constant feedback loop of what people and how people are actually interacting with your agent.\n\n**Thomas Betts**: Do you have anything that feeds back in? So if you're talking about you just have a system prompt and you have tools and maybe you're adding new tools as you want to give it more capabilities, when do you go and revise your system prompt and what drives that feedback cycle?\n\n**Clare Liguori**: Often for us, it's about those evaluations that we're running against live data. Looking at how well are we doing compared to what our pre-launch evaluations told us, are we significantly worse, and are we finding new use cases that we need to evaluate as well. And so once you do that, you can start to use something like the Strands Evals Kit to start playing with your prompt, right? And because Strands runs locally, it runs in the cloud, you know, it runs the same anywhere, you can start to make changes locally and see what the impact on evaluations is, but I think the most important thing is reflecting on whether your test evaluation set actually reflects reality so that you can have that local feedback loop really quickly.\n\n## Modularity, Future Horizons, and Agent Harness vs. Framework [[28:10](javascript:void(0);)]\n\n**Thomas Betts**: And since you mentioned that engineers aren't used to—like we're used to “I built it, it runs, it's fine,” and nothing's changing, it's constantly changing—that's a shift in engineering mindset. Are there other examples on the flip side of, you know, here's some core engineering principles that we really needed to lean into because we're building agents? So some of it's you have to think differently, but some of it's you need to think the same as we have been. What do you guys emphasize for building this?\n\n**Clare Liguori**: A lot of the same architectural principles apply. For example, modularity. Often I see that folks test their agent and even a complex agentic system entirely holistically, so they only rely on evaluations, but there's a lot of pieces of your system that you can test individually. Tools are a great example. Unit test the hell out of it, right? Get to really high test coverage on your tools and make sure that they are rock solid. I think also things like chaos testing, you know, a lot of the same security red-teaming principles apply where you intentionally give your agent unexpected inputs and see how it responds.\n\n**Thomas Betts**: Now you mentioned a little bit about having people ask, \"What is EC2?\" and then they said, \"Well, how do I use EC2? How do I connect it?\" Where can people see this in production? Is that an interface that I could log into and try out?\n\n**Clare Liguori**: Yes, if you go to the AWS console, there is a chatbot button on every page on the AWS console, you can open it up, and it slides out, and start asking it questions.\n\n**Thomas Betts**: Gotcha. So that went from—I'm guessing there's a first version that was just a simple chatbot and then it became an agent?\n\n**Clare Liguori**: Yes, that's exactly right. It started out as a very, very—I mean this was 2023—so it started out as a super simple prompt pipeline like we were all building on the early Claude 2 models. And over time we found it wasn't sufficient, we needed to do tool calls. People wanted to know about their AWS account, they wanted to know about their AWS resources, and they were expecting this chatbot to know because it was literally sitting side-by-side with the EC2 console. And they would ask, you know, more and more complex questions and things that needed to combine a lot of different tool calls like the network troubleshooting agent is a sub-agent of the chatbot in the console.\n\nAnd so yes, over time we had to move to it, but it was also that the models got better at tool calling and that's one of the things that is also super different in this space is that the thing that is driving your agent is constantly getting so much better. And we went through multiple iterations where, you know, we'd build something and it would be in production for six months and we'd realize a new model came out, we don't need any of this anymore. And so the comfort level with throwing away code, throwing away scaffolding because it's no longer serving you and it's potentially even making your agent worse is something we've had to get very comfortable with, but at the time, this was all, you know, mostly handwritten, so it was really emotionally painful to throw things away.\n\nI think that's another point around the model-driven approach that Strands embraces is embracing the power of newer models should be as easy as replacing a line of, you know, a string in your agent. And for us early on, we had built so much around the model, so much scaffolding and workflows, that that wasn't true. We had to change everything about the entire system to take advantage of a new model, but the model-driven approach allows us to be a lot more agile with the agents, and so our agentic applications become more powerful just by adopting a new model with the same agent.\n\n**Thomas Betts**: Now is there any concerns about the cost of the new models? I know sometimes like a new model came out and it costs exactly twice as much as last one and it costs 15 times more than the previous one. Is that a concern you guys are looking at before you're just like I can just change this line of code and use a new one?\n\n**Clare Liguori**: Well, definitely, yes. But what's also interesting is the flip side, the use cases where you can go down in model cost, especially with a lot of the smaller models that are out there now that are, you know, hosted on Bedrock and other providers, where for a lot of use cases, you know, you can develop your agent and do a proof of concept for your agent with a frontier model and then that's really expensive. But then try out a bunch of different models by changing a single line of code. And so actually with the steering hooks use case that I talked about earlier, I actually achieved those results with gpt-oss-120b.\n\nI think that is probably the thing that surprises folks the most: that you can really get excellent accuracy and pass rates, you know, maybe not for a coding agent, but for a lot of these automation cases where you just need the model to reason through a collection of tool calls being put together, and you can give it some just-in-time guidance with steering hooks, you can achieve really cost-effective agents with smaller models.\n\n**Thomas Betts**: Yes, sometimes the more isn't better, it's just more. It's like having an RV as your daily car to go get groceries, it's hard to park and fill up the gas tank.\n\nSo let's look back a little bit then we'll look forward. If you were starting Strands all over again, from scratch, what would you design differently? I’ll let you throw in that time has passed and the agents have gotten better. What would you do differently for the design?\n\n**Clare Liguori**: I think what we’ve been seeing more and more is people needing the tools to build agents that can do really complex work. And that was not something that models were really capable of when we initially built Strands or when we open sourced it last summer. But, since then, we’ve had Opus 4.5 and GPT 5.4 in November and December, and now we’ve had multiple iterations of those models since then. The models are so much more capable. Not just of tool calling and reasoning, but really doing complex, long-running tasks.\n\nThat’s really where a harness comes into play. Not just an agent framework that helps you go through this loop of tool calls and model reasoning, but really looking at complex, long-running tasks. This has been the focus in Strands for the last few months of what are the tools people need to be able to build an agent around a Strands harness. Things like context management becomes super important, of course, when you have long-running tasks. The models do have a million input tokens, but even so, it’s important to think about agent memory, have tools around agent memory. Proactive summarization is something that we’ve been playing with, where as you reach a natural point in the agent’s conversation or history summarizing a chunk of it so it can focus on the next task.\n\nThe ability to persist and resume state is super important because as you have longer-running tasks something about the compute is gonna fail before the agent is finished, right? So you want to be able to persist that state, put it on another compute node, and then resume and keep going. This is something that, for example, machine learning training jobs have known for a long time. They take days and days and days. But agents so far have been very focused on very synchronous use cases. Chat, things like that, where the person is actually watching and looking for the response within a few seconds or a few minutes. Now we see agentic jobs that are hours long, so the model needs context management, ability to persist and resume, and also tools that help the model track its work.\n\nWe’ve added things like task lists, to-do lists, out-of-the box tools to Strands that help the model have a place to basically save its work, save its planning to, where it can more reliably work through its plan of things to do with a task list or a to-do list. With a lot of these pieces out of the box, and there’s probably more to come as we continue to help folks with these long-running agents, you start to get really, really powerful use cases popping up for agents, which is exciting.\n\n**Thomas Betts**: Since you mentioned it again, what's the difference between an agent harness and an agent framework?\n\n**Clare Liguori**: I think with the agent, it is that ability to do long-running, complex tasks. An agent framework, you know, I think of a lot of the agent frameworks as kind of a big while loop, right? Where it helps you go through the model's next turn, so to speak. It helps you through executing tools, advertising tools, connecting to a model. But we've seen the limits of what a while loop can do until the model yields back and says, \"I'm at the end of my turn\". But with a harness, it helps the model to go for longer and longer, it helps the model to, because of that, again, context management, tools that help the model track its work, the model can go for longer and longer and you can go through many, many more turns before the agent returns with a complex task that's been completed.\n\n**Thomas Betts**: Well, I think that's definitely looking forward. I think you're right, we're going to have a lot more of these longer running agents, it's not just a little chat right now and building whole systems that are built around that, so it sounds like Strands is a good way to go. I'm going to go check it out, I've been doing some research, I definitely want to learn more. Clare, thank you so much for talking to me today on the InfoQ Podcast.\n\n**Clare Liguori**: Thanks for having me.\n\n**Thomas Betts**: And listeners, we hope you'll join us again soon for another episode.\n\n**More about our podcasts**\n\nYou can keep up-to-date with the podcasts via our [RSS Feed], and they are available via\n\n[SoundCloud](https://soundcloud.com/infoq-channel),\n\n[Apple Podcasts](https://itunes.apple.com/gb/podcast/the-infoq-podcast/id1106971805?mt=2),\n\n[Spotify](https://open.spotify.com/show/4NhWaYYpPWgWRDAOqeRQbj),\n\n[Overcast](https://overcast.fm/itunes1106971805/the-infoq-podcast)and\n\n[YouTube](https://youtube.com/playlist?list=PLndbWGuLoHeZLVC9vl0LzLvMWHzpzIpir&si=Kvb9UpSdGzObuWgg). From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.", "url": "https://wpnews.pro/news/podcast-strands-agents-with-clare-liguori", "canonical_source": "https://www.infoq.com/podcasts/strands-agents/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global", "published_at": "2026-07-20 11:00:00+00:00", "updated_at": "2026-07-20 13:33:43.978076+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "large-language-models"], "entities": ["Clare Liguori", "AWS", "Strands Agents SDK", "InfoQ Podcast", "Thomas Betts"], "alternates": {"html": "https://wpnews.pro/news/podcast-strands-agents-with-clare-liguori", "markdown": "https://wpnews.pro/news/podcast-strands-agents-with-clare-liguori.md", "text": "https://wpnews.pro/news/podcast-strands-agents-with-clare-liguori.txt", "jsonld": "https://wpnews.pro/news/podcast-strands-agents-with-clare-liguori.jsonld"}}