follow the manual, and you can you can solve a Rubik's Cube. And I feel like the same thing now applies to to agents where like there was this whole debate of like workflow versus fully autonomous agent. It was like huge fight on X of like what is the best way to build an application. Everyone was kind of like, "Yes, you kind of both." And I think Mars this morning had like a good note where like the surface area of deploying agents is so broad that like for some you don't need like a coding agent even if it's like the best way you can build agents at the frontier today. Like you don't need this for every application. It makes things slow, expensive, and like there's this kind of like balance between workflow being very reliable and agent now having kind of like unlimited capabilities. And I think what's very exciting is that then skills are kind of like a formalized shortcut to make things more reliable where you historically would have built a workflow. Like I don't know. Like you have a customer like customer support agent and someone asked for like a password reset. Then historically you would have built like a workflow that's very reliable of like you have a router that routes to like an agent that can only do password resets and that agent has like the context to do password resets well. That was great, but also if the user then wants to do password reset but also change the email address at the same time, then like the router is kind of like, "Okay, I have this email router. I have this password reset router. What what do I even do?" And I think what's very exciting now is that an agent can just like progressively get the context needed to then solve like a problem that's multi-domain. Like that would have historically been in multiple workflows. So that's very exciting. However, it has always been hard to kind of like how to how to build an agent, what kind of use cases even exist because you have like this open-ended text input box often or like open-world context. So you didn't really know. So what we now see is what many teams do is they have the agent runtime, they trace everything. I mean, I'm building LangFuse this I put my logo here but you can also use whatever you want. In the end it's more about like the concept of tracing is what you need to like identify what happens at runtime when a trace when like an agent executed because then it helps you two things. One, like new kind of like use cases that you didn't expect a user to do because you might have expected that nobody ever wants to change a password but now they want to change the password. This you need to see the execution trace of someone being upset by like a production email to then derive that you need to add a skill for handling password resets well. And two, once you have these skills they can get out of date or you can realize they're not the most efficient way of actually solving for this use case. So it's like the second thing of like helping you improve skills that you already have in your agent. So, this is very conceptual, but this is