Agents That Write Their Own Tools at Runtime — Sandhya Subramani, AWS
Read the talk
Agents That Write Their Own Tools at Runtime
Sandhya Subramani demonstrates how Strands Agents can write and load new tools during a running conversation, extend the same mechanism to sub-agents, and expose the evaluations and permissions that self-modifying systems need.
From a talk by Sandhya Subramani
At a glance
Ideas worth remembering
Meta-tooling combines a prompted tool template with editor, shell, and dynamic loading tools so an agent can create and use a new capability without restarting.
The same mechanism can create sub-agents: the Hawaii planner writes flight, activities, and itinerary agents from an ordinary travel request.
Generated code does not supply missing external access. The travel demo cannot retrieve real-time information without a tool connected to a real-world API.
Evaluate goal completion, answer correctness, tool selection, parameters, and inter-agent messages; a convincing final response can conceal an incorrect execution path.
Self-modifying agents need sandboxed code execution, constrained tools and permissions, controlled user access, and telemetry because the ability to write also enables modification and deletion.
A running agent acquires a capability it did not start with
Generating code is already familiar. The harder question is what happens when a running application encounters a task its existing tools cannot handle. Sandhya Subramani, an AWS developer advocate, opens with the possibility of an agent recognizing that gap, writing the missing code, and using it without restarting. Her first Strands Agents demonstration makes that smaller, concrete capability visible before turning to the larger ambition of self-repair.
The agent begins with an empty directory of task-specific tools. It already has a system prompt and three tools for creating and loading code, so “zero tools” describes its starting application capabilities rather than its entire tool inventory. There is no calculator waiting to be called. A request for help with a complex mathematical expression prompts the agent to create one.
The observable change is a new calculator tool in the tools directory. The agent describes its supported operations, including minimum and maximum, and then receives a follow-up request to square a number. It calls the calculator it just wrote and returns an answer within the same running session. Code generation has changed the set of actions available to the agent.
A character-counting request tests whether that expansion can happen again. The agent checks its available tools, finds that the calculator does not supply the needed capability, and creates a character counter. It reports 28 letters for a random input. Subramani immediately notices the weakness of that test: she should have chosen something she could count herself. She follows with three letters, letting the conversation carry forward the counting task without restating it. The exchange illustrates tool creation, invocation, and conversational continuity; the random-input result alone does not establish counting accuracy.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Meta-tooling separates writing code from making it callable
This pattern is called meta-tooling. Strands Agents supplies the agent harness: the structure that connects a model to tools and runs the interaction. Subramani presents it as an open-source, AWS-maintained framework with multiple model providers and community-written tools. Keeping that structure separate from the model lets developers experiment with another model without rebuilding the surrounding architecture.
The starting toolkit divides the work into three mechanisms:
- Editor: writes the new tool’s code.
- Shell: gives the agent access to its directory and codebase so it can inspect what is already there.
- Load tool: loads a tool from the directory dynamically, making generated code available during the running session.
The system prompt supplies the construction rules. It describes a tool template and specification, tells the agent where to write files, and includes the @tool decorator that identifies a function as a tool. It also tells the agent to check whether a suitable tool exists before creating another. That instruction keeps the character-counter example from becoming “write new code for every message”: reuse comes first, and generation fills a missing capability.
Dynamic loading is the crucial step between a file appearing and the agent being able to use it. Subramani describes an earlier directory-loading option, then explains that loading became a tool in its own right. The agent can therefore write code and explicitly load it as part of its work. The small agent constructor combines the system prompt with the three tools; the surrounding chat loop keeps the conversation running.
How does a request become a new callable capability? The diagram follows the character counter through the same session. Inspecting the existing inventory, writing a file, and loading that file are separate steps. The important relationship is the return from generated code to the live agent: the next invocation can use something that was unavailable at startup.
The user introduces a task the existing tools do not cover.
The editor creates the code; dynamic loading makes it usable without restarting the conversation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A missing capability can also call for a new sub-agent
The production motivation is a request that falls outside the original application design. Subramani imagines a domestic flight-booking app receiving a request to travel from India to Hong Kong. A fixed toolset may leave the agent unable to proceed, sending the problem back to engineering. Meta-tooling offers a way to create missing functionality during the interaction. This is a proposed use case, rather than a demonstrated international booking.
The same construction mechanism can write sub-agents. Before demonstrating that, the talk distinguishes several ways agents can cooperate:
- Swarm: sub-agents work in parallel and take different parts of a shared task.
- Graph: one sub-agent’s result feeds into another, making the dependency between stages explicit.
- Handoff: another named coordination pattern, though its mechanics are not developed here.
- Workflow: a combination of patterns, potentially mixing parallel work with dependent stages.
The second demo deliberately keeps the orchestration small. Its prompt asks for two to four sub-agents and supplies a template, specification, and rules for creating them. The agent again starts with the three code-writing and loading tools. The change is what the generated code represents: a focused agent rather than a standalone utility. There is no elaborate swarm in this example.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The Hawaii planner creates specialists from an ordinary request
The user-facing request is simply to plan an itinerary for Hawaii. It does not ask the system to create agents. The planning agent chooses that implementation itself and announces three focused sub-agents: a flight agent, an activities agent, and an itinerary agent. It calls the editor three times, once for each, turning a general travel request into newly written specialists.
The running system then calls the activities agent and produces travel guidance, including airports and beaches. Creating specialists does not create access to current facts: this demo has no tool connected to a real-world API, so it cannot retrieve real-time information. A weather-aware extension would need that access before a generated weather tool could fetch current conditions and use them to recommend activities.
That distinction matters for the flight-booking ambition. An agent can reorganize its work and write new code using the facilities it has been given. It still needs the external access required by the task. The Hawaii example demonstrates self-assembly and a sub-agent invocation, while live weather retrieval remains a proposed extension.
The next ambition is self-healing: inspect errors and edit the tool or agent that caused them. Subramani describes longer sessions in which audience requests break the system, it recognizes the errors, and it tries to repair its code. She also notes excessive chatter and the possible need for a maximum-token setting. Those accounts motivate the repair loop; this recording’s travel demonstration does not establish how reliably it recovers from failures. Changing the destination is another suggested reason to update an agent already created.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Evaluate the outcome, the tool call, and the path between agents
Once a system can change its own capabilities, a plausible answer becomes a weak test. A booking agent might discuss flights without booking one. A balance lookup might return a sensible-looking amount for the wrong account. Subramani says Strands has eight built-in evaluations and uses the following concerns to explain what needs inspection, without enumerating all eight by name.
- Session goal: did the requested action happen? For a flight-booking request, success means achieving the booking goal.
- Response usefulness and correctness: does a balance answer address the question, and does its amount match the actual balance rather than an invented value?
- Tool selection and parameters: did the agent choose the right tool and pass the right account ID? A correct tool with the wrong parameter can still produce the wrong result.
- Inter-agent flow: did tools and sub-agents run in the required sequence, and did the messages between them carry suitable information?
These checks connect the final response to the execution that produced it. In the travel planner, inspecting only the itinerary would miss whether a specialist actually ran or whether dependent work received the information it needed. The complete session trace gives developers a way to distinguish a good-looking response from a system that performed the intended work.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Protect the environment where generated code executes
Evaluation reveals behavior; it does not prevent damage. The permission to create code can also enable modification and deletion. A meta-tooling agent that writes into the wrong place could destroy existing work, even if its intended task sounds harmless. The ability demonstrated by the editor tool therefore creates a second design problem: how much of the environment should generated code be able to affect?
Subramani emphasizes sandboxing the code-execution environment itself. The protection must apply where the generated program runs, rather than stopping at a container around the agent process. She describes a recently introduced Strands feature intended to keep that execution from affecting other environments or writing and deleting in unintended locations. The talk does not develop its isolation mechanism or configuration, so that protection depends on how the execution sandbox is implemented and used.
The remaining controls address different parts of the system:
- Tools and permissions: constrain the actions the agent and its generated code can perform.
- User access and requests: constrain who can ask the system to act and what kinds of requests it accepts.
- Observability: retain evaluations, OpenTelemetry, and other telemetry so developers can inspect what happened.
Together, these controls make experimentation more accountable. The sandbox limits where execution can cause changes, permissions limit what actions are available, and telemetry supports the evaluations of outcomes and intermediate calls. Runtime adaptation needs all of those: repairing one tool is little comfort if the repair can damage unrelated code or cannot be inspected afterward.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From generating tools to changing the framework itself
The ending expands the idea in three stages: agents create tools, then create other agents, then update their own source code. Subramani frames that progression as the beginning of self-improving and self-evolving systems. Here, improvement means changing the software the system can use or execute; the demonstrations center on generated capabilities and agent code.
The most ambitious closing example concerns Strands itself. Subramani says the framework began internally three years earlier, was later opened to the community, and that its Python version wrote the TypeScript version. This is a reported development outcome rather than a demonstrated porting process; the recording does not specify the human involvement or validation behind it. It nevertheless brings the central subject back to developer tooling: the same framework used to generate a calculator can participate in building another implementation of the framework.
The closing invitation is to explore the code and slides with Subramani. The useful starting point is the modest version shown at the beginning: supply a tool template, let the agent inspect and write within a constrained environment, and load the result into the running conversation. Expanding from that mechanism to sub-agents and repairs raises the importance of checking both what the system accomplished and what it changed along the way.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
Related talks
- Beating RL With Reflection: GEPA and Optimize Anything
Explores how execution traces and evaluator feedback can guide changes to prompts and agent programs, complementing this talk’s mechanism for writing and loading capabilities at runtime.
Read the complete timestamped transcript
- 0:12
Hi, everyone. Um, welcome, welcome. Agents that forge their own tools. What is so great about this? Can't your Cloud code do this, or can't your cursor or your code editors, can't they all write their own tools? So what am I even talking about here? Why is this such a big deal, right? Like, any, all of your co- um, agents can write tools by themselves, but how many agents do you know that can
- 0:42
fix code at runtime? Let's say you've got something in production. It's running, everything looks great, but something is failing, then what happens? You have to probably bring it down, fix it by yourself, and then restart it, and then work with your Cloud code or whichever editor you're using, and then bring it back up, right? But imagine if your agent was smart enough to figure out, "Oh man, there is a bug here. Something's not working. I'm falling," fe- uh, "falling into an error. I need to fix myself." And
- 1:12
it realizes what it can do to fix itself, writes its own tools or writes its own agents and fixes itself. How cool would that be, right? And that's what I'm here to talk to you about today. Let me quickly show you a demo because I think I like leading in with demos so you know what you're getting into. So let's start with that, right? So here I have a... And you can see my screen. I'm hoping it's big enough. I can zoom in. Okay. So I have a simple agent
- 1:42
here called agents.py. This agent, we can go over the code in a bit, but this agent has nothing. It's just got, it's just got a, a pretty cool system prompt, and then it's calling the system prompt, and it's got three tools. And if you look at the tools package, there are actually no tools files that are written. So technically, this agent has no capability by itself, right? It shouldn't be able to do anything, right? All it should technically hallucinate because of the LLM that is
- 2:12
running under the hood. But let's say I say something like... Okay. So first, I'm gonna start running this so we know it's running. Okay. So in runtime, right now this is running. Now I'm going to say, "Hey, you know what? Um, help me calculate something, uh, some complex math equation." Right?
- 2:37
When I say this, this agent, which technically has nothing available, is going to be calling the three tools that it's got, and we'll look into the tools that it's got in just a bit. And it's going to say, "Oh, you know what? Let me create a math calculator tool because that's what you're asking for." And it's not just going to create, it's going to let me use this tool that I'm creating right now at runtime without having to rerun it. So okay. So it's clearly gone ahead and created. So let's look at tools again.
- 3:07
It's created the mathcalculator.tool, and it's saying, "Okay. I do all these things. I've got min, max, blah, blah, blah." It's gone and created this entire new tool, so it's saying I can do all these things, right? So let's say calculate, uh, oh, yikes, uh, what's the square of blah, blah, blah. Some number, right? I'm just typing out a random number. So now it- it's calling that math calculator tool that it just wrote by itself, and it's giving me the answer.
- 3:37
Not just that, right? So let's say I give it something completely out of blue, and I say, uh, cool whatever, count number of characters in my word. Okay? So then, so then it's like, okay, so it's gonna check if it can use any of the tools that it's currently got access to. It doesn't. So what it's saying is, "Okay, let me write a tool to count the number of characters you want," because clearly it knows that it does not have the capability to do it.
- 4:08
And so it's going ahead, and it's creating... Ah, there we go. Even before I could finish speaking, it created a character counter for us. So let's say, um, do it for this word, and it's not even a word. I'm just gonna put random things. You know what? I should have actually done something that I could count so I can validate it, but the thing is, it's calling a tool. It's calling the cha- character counter tool, and it's telling me that it's got 28 letters. Let's do it something we can test, so I'm just gonna do it for these
- 4:37
three letters, right? We'll see if it knows. So I'm not even telling it what to do. I'm just typing three letters. It knows that it has to do it, and it's doing it. How powerful is this? So what I want to leave you with today is show you how you can build something like this, where you can use it, I think it's pretty powerful, and how we can implement it in our work, day-to-day work. Very niche. So now let's get down to the code. This is an idea called meta-tooling, and I'm
- 5:07
using an open source framework called Strands Agents. And my name is Sandhya, and I work at AWS, and we at AWS built Strands Agents as an open source a- agentic harness that you can use to run your LLMs with. Right? And so, l- um, how, show of hands, how many developers do we have in the room? A quick show. Oh, most of you. Brilliant. I'm talking to the right audience. If not, I will change things around a little bit. So if
- 5:38
you guys like getting to the code, I'm gonna get into the code with me, right? So the main thing we need here for agents, and I have a slide deck that goes with it, is we need just three types of tools, the editor, the shell, and the load tool, along with the system prompt that lets us implement this function. So I'm gonna quickly go to my slide deck that helps us understand this better Like I mentioned, this is Strands Agents. This is our agentic
- 6:08
AI harness, and y- you can use your own LLMs, bring your own models. Another cool part, because this is a, a, an harness, is the fact that if, let's say tomorrow there's a new, the state-of-the-art LLM that comes out, you don't have to rewrite all of your system prompts. You don't have to rewrite the structure. You don't have to change your entire architecture. You can keep it as it is, and whichever model you use, you can just replace it. So it also lets you experiment with model performance without really
- 6:37
rewriting your entire architecture. So it's super, super powerful. It supports MCP, A0A, all of that cool stuff. It has a bunch of model providers. Um, you can get started. So what do we do? Very simple, right? Five lines of code. Uh, import agent. From there, import shell. Shell is the very first tool that we need, because we need to give it access to the directory. We need to give it access. It needs to know what it's running, where it's running, where your code base is located. So that is just one of the tools that you
- 7:07
need. And then if you ask it what can you do, it understands what's going on under the hood. So to techniques- technically start being able to use it on the fly, right? So then let's get into what I actually just built a couple of minutes ago and I showed you. Over here, what am I trying to do? The idea, because this is community-driven, AWS manages it and maintains it for you, people write a lot of pre-built inbuilt tools, but there's also community-written tools. And so
- 7:37
all you need is three tools to be able to start implementing meta-tooling. So what do you need? First of all, you need to have a system prompt that tells your agent what a good tool looks like. How does that work? We have to start with the @tool decorator function. That's how it knows it's a tool. Uh, excuse me. That's how it knows it's a tool, and then you tell it what a tool looks like and where it should be stored, right? And so you call the system prompt there. That's all you say,
- 8:07
and then you can give it access to different tools. I highlighted load tools from directory equals true, because that is what enables you to, uh, enables the agent to start letting it run the tools that it's generated at runtime dynamically. And we later on decided we should just make this into a func- uh, into a tool by itself, so now that's become the load tool. So now when you go and say, "Hey, create tool, create five new tools for yourself and start
- 8:37
using them," it's going to know what it's going to do. So let's go back to the code that I showed you earlier, right? Same thing. It's got the system prompt, and here I'm saying, "You are the meta-tooling agent that creates your own tools and custom tools at runtime." So I'm defining the tool template. I'm telling it what a tool looks like. I'm giving it the tool specification of what it's supposed to look like, and then I'm giving it rules for what it's supposed to do and where it's supposed to write into. And I'm also telling it, "Always check if it, if it
- 9:07
exists or not. Only if it doesn't exist, then write a new tool." And I'm telling it, so I'm giving it three tools: editor, which allows it to write; the shell tool, which shows it what it has; and the load tool, which allows it to load from the directory, the tool from the directory dynamically. And this is all you need, and it takes just one line of code, right? System prompt equals system prompt, three different tools, and this is just
- 9:37
code so that I can chat with it continuously. And so when I do this, it's actually able to start running. "Create five random tools for yourself." And so it's going to start creating these five new tools, and the power of this is, like I said, when you're, uh, deploying code into production, you m- you might want to wait for the agent to be smart enough to figure out what's wrong and to be able to answer questions for
- 10:07
itself. Let's say you're b- you're building this app that's supposed to book flight tickets domestically. But let's say you have one user who is saying, "No, no, I want a flight ticket from, I don't know, India to Hong Kong." And your agent gives up because it's not been explicitly programmed to do that or it's not been trained to have access to be able to do that. But do you just want it to fail? Do you want it to run into an error? Do you want to give it back to your deployment, to your engineering team, uh, and have a, uh, turnaround of two weeks and then come back? No, you want to be able to solve it.
- 10:37
So this is one of the ways by which you can handle that, right? So again, let's get back to the code, and we have more cool things coming up. Now, I was speaking about tools that can-- this agent that can write it own-- write its own tools. Can it also write its own agents? Yes, it can. And I have another demo for that, but wait until the last few minutes for that, right? So when we talk about agents that write their own, uh, agents also, we want to understand agentic patterns. We have three primary patterns. The first
- 11:07
one is swarm, where you have sub-agents that work with each other in parallel. So they work on a task in a combined fashion, and they take different parts of the task themselves. Then you have a graph where the result of one sub-agent gets fed into the other sub-agent, and then there's the handoff. And then you could also have workflows that have a combination of all of these, right? So with the workflow, you could have a parallel set of sub-agents calling each other, and then there could be nodes and graphs and
- 11:38
all of that cool stuff. And so this, and so they, all of this can be created by just the agent itself. We don't need to. We can do it our ownselves, but we don't necessarily need to. So, um, let's quickly go check how that looks. Um, so this is the exact same thing. This is for my meta-agents. I'm doing the exact same thing. I've given it three tools. Over here I'm actually, if you look at my agents file, it's pretty empty. And I'm saying
- 12:07
agent is the tool file template. So I'm saying just break it into two to four sub-agents. I'm keeping it simple. No swarm, nothing fancy here. A simple demo. And use it, and this is the tool spec for what an agent should look like. And I'm happy to share the code with you after this, right? And these are the rules that it follows. Same thing, right? One line is all it takes. System prompt, equal system prompt, three tools, and then same. So I'm gonna start running this now. Python3 agent.py.
- 12:37
And so I'm flying to Hawaii or whichever place, to some, uh, to Hawaii. Let's just say Hawaii. Help me plan my itinerary. Okay. So this is all I'm telling it. I'm not even telling it, "Hey, go make your own agent," or, "Go create your own tool." This is all I'm telling it. This is how your customers would chat with it, right? They just tell them what their problem is, and they expect you to figure it out, right? So
- 13:07
this agent is gonna be like, "Oh, great. Um, here I'm going to be printing out... I'm gonna be creating these into three focused sub-agents, the flight agent, the activities agent, the itinerary agent," and it's calling the editor tool three times, one for each of these. So I see that it's already created the activities. Yeah, it's creating... It's pretty fast. It's creating the activities agent. It's created, like, a flight agent that's doing something. It's created an itinerary agent. The w- let me call out the one thing this
- 13:37
can't currently do right now is access real-time information because I haven't given it a tool that has access to real-world API, right? So assuming you add that on, you can ask it, "What's the weather like?" And it'll be like, "You know what? Let me write a tool that can always grab the latest weather in whichever location and recommend stuff." So based off of that, it created those agents, and if you look at it somewhere here, it should technically be calling those agents. There we go. See, it's calling the activities agents, and then it's
- 14:07
saying, "These are the ma- main airports. These are the best beaches. These are what it is, and this is what you have to do." And so how amazing is, is it that you can now have your agent... So y- now your focus is not just building a good agentic system that can get the job done. You would also maybe want to start thinking about healing, writing self-healing code, about creating an agent that can sort of go over itself, look at what bugs are there, and fix itself. Had this been a longer session,
- 14:37
I usually do longer sessions, I usually ask the audience to ask it to do crazy stuff, and I try breaking it, and what happens is this actually ends up breaking. You would see a bunch of errors coming up, and this thing is just talking, chatting away. So I need to probably set the max token somewhere here. But, um, and so it actually ends up erroring and breaking, but it r- recognizes that it's erroring, and it says, "Oh, man, I'm erroring. Let me fix myself." And it would go and fix the same, uh, fix this exact same, uh, tool or agent that it's
- 15:07
got here. So now if I'm like, "I don't want Hawaii. Why do you make it for Hawaii? Do it for something else," it's gonna be like, "Sure, let me do it. Let me update the agent." So it's super, super powerful, but then again, we have to keep in mind that this is just autonomously doing things by itself. With great power also comes great responsibility, even greater responsibility. So what do we need to do with it, right? We need, A, evals. What are some inbuilt evals that Strands Agents has? We w- we have totally eight different evals. The
- 15:37
first one is at an overall session level. We want to figure out if I told it, "Hey, book my flight tickets," is it actually booking? Did it achieve the end goal? That is part one of it, right? End goal achievement. Second thing we wanna look at it is at a trace level. Um, was it actually helpful? If I say, "What is my balance?" It then says, "My balance is 500 bucks." Is that the expected type of answer? Part one. Part two, did it make up the answer? Is that the actual answer that you're supposed to get? You need to be able to evaluate that. But it doesn't
- 16:07
just end there. What about tool access, right? What about did it use the right tool to get to that answer, or did it use a wrong tool? And within that specific tool, did it use the right parameter? Is the account ID actually 123, or is it supposed to be... Is it messing up? We want insight into what is going on so that we can trust it and reliably give it access. Again, not just, it doesn't just end there. We also want to understand inter-agent dependency. When we're building
- 16:36
multi-agentic systems, we wanna look at the f- overall outcome and the overall response, if it's the way you wanted it to be. You want to make sure that it's calling the different tools and the different sub-agents in the right sequence, and you also want to take a deeper dive into what the messages, the inter-agent communication looks like and if that's up to the mark. All of this together gives us the full end-to-end agent conversation within our session. This gives us the insight. Again,
- 17:06
this also isn't good enough, right? We want to make sure it doesn't cause undue damage. If this meta-tooling or this meta-agent can spin off tools and agents, it can also modify and delete. Do I want it to delete my data? Do I want it to delete stuff that I have put all of my effort into building? No. So what do I do? I have to have guardrails in place. Four different types of guardrails. The first one is your environment. We need to make sure that we're sandboxing the environment. And when I say
- 17:36
sandboxing the environment, it's not your typical sandbox where your agent is in one container, and you're protecting it from the rest of the world. We want the environment in which this code is executing to be sandboxed. And Strands recently launched a feature about, I think, a few weeks ago where we can sandbox the, uh, code execution environment, and that is what guarantees that it doesn't touch the rest of your code execution environments, and
- 18:06
it doesn't mess up everything else, and it doesn't write into wrong places and delete from the wrong places, right? Next, we have to constrain the tools. We have to constrain permissions. We have to constrain the gu- who's got access and who can ask it questions and what types of questions we need to ask, and observability. All of your evals, your OTEL, your telemetry, all of that data needs to be there in order to be able to say that, "Hey," reliably and say, "Hey, I think I can go
- 18:36
ahead and build-"An agentic system that can think for itself, that it can do more than what it's just been set out to do because it can fix things when things are broken on the fly, on the run, and it can solve more capabilities than it has been initially taught to. This is the starting of self-improving, uh, agents and the self-evolving agents. At some point, I'm convinced they will take over the world,
- 19:06
and I'm, I'm going to be at risk, but until then, I think this is incredible. And if anything, if I want to leave you with anything, I would want you to-- I would want to leave you with a quick idea of where Strands is, where Strands started with, and where we are right now. We started with building their own tools. We, we moved to getting them to update-- uh, to create agents by themselves. Now it's at a point where they can update their own source code. Fun fact, we created Strands agents three years ago
- 19:36
internally. It was really this internal thing before agents was even a thing, and it was so powerful that we said, "You know what? Let's just open source it and give it back to the community." And we wrote the Python version of Strands, and the Python version of Strands wrote by itself the TypeScript version of Strands. So it did update its own source code. It's pretty powerful. I'm pretty psyched. And if, if-- this is my call to action. If, uh, this sounds interesting to you, reach out to me,
- 20:06
scan these, and we can have a conversation later. I'm happy to share my s- uh, slide deck and my code with you, um, and we can chat offline. Um, thank you very much. This is my LinkedIn. Uh, we have thirty seconds to go, I think.