Thank you for joining me today. My name is Imat Will. I'm a distinguished engineer at Quantum Black. And in today's talk, I want to really cover how AI-native organizations run on skills.
But before I really get started, I just want to do a quick exercise, a show of hands. Can you raise your hand if you have already created and are using skills? Amazing. Now, can you keep your hand up if you are using and sharing them within your teams? Great. Now, keep your hands up if you have governed and maintained skills across your organization. Amazing. I see a few hands. But that is what this talk is about. Today, I'm really looking to break down why this is really critical, why it's important, and how you can actually adopt it across your organization.
But before I get started, what I really want to cover is the agentics software stack. So the agentics software stack has two loops. The first loop is all you know, right? It's the coding agents or the coding agents harness, right? And then you have some core components. You will have your context manager, the tool and MCPs, memories and states, and skills loader, right? But then there's an outer loop, which is your workflows, right? Those have skills, sub-agents, MCP servers that you use, and some hooks. Sometimes you need them.
To have this running properly, you will need some enablement components at the bottom. So what you would have is an environment sandbox. You would have your MCP gateway to manage and simplify all of the MCP tools across your organization. A model gateway to, again, manage and optimize for all of your LLMs, either open servers running locally or front-term models, and also a graph, knowledge graph, that abstracts your IT core systems, your code base, your skills registry, and, at the end, the workflow marketplace.
And then you have your context layer, right? The context layer will bring all of what is needed to get the task done. So this is the project instruction. Think about it as the cloud code MD file, the agency MD file. Your tool and MCP schema are actually to understand which tool to use and when. Your memory, right? Conversation history with the end user, the human is in the loop. And finally, the retrieved contents that you can pull from files, your code base, etc.
Now, what I want to really focus on today is the workflow, right? And I think this is where we think it's a pretty simple workflow in day-to-day life when you're trying to actually create an end-to-end product software delivery lifecycle in your organization. In reality, we all have seen the four steps. Specify to define what you want to build, the design or plan to plan what you're looking to build. Then you go to the tasks, you break it down into tasks, and then, finally, you start implementing, right? I think this looks familiar. I think this is how most of our coordinations actually are shaped today.
In reality, that is not how it is composed at scale when you look at the organizational complexity. This is just one step in the journey. This is like building a product increment. When you really look at the overall end-to-end lifecycle of something that's a business one that builds to capture the value out of it all the way to shape it to the client, you will start, first of all, by defining your product strategy, what to build and how to build it, right? You set the different success metrics, you identify and break down your plan, roadmap for your products. And to do this, you may need a lot of insights, right? So then you do your market research, you do a competitive analysis, you bring this as an input with some customer interviews.
Then you go to the discovery side, right? So then you start discovering, okay, now I understand what to build. I'm going to break this down into some problem statements, find the solution, validate the solution, and then probably experiment and then create user stories.
And before we start building, in reality, you actually need to prepare your data, right? In some cases, you will actually need to clean up your data catalog that will support the build of your products, or maybe adjust some of the endpoints, connection, and integration to your core systems that will help you actually build your products. And this is where the data product delivery comes. So you build your data pipeline, you validate your data quality, and you put your catalog data assets ready for development.
Then we go back to the product increment. That is where we start. But then, building up products in every organization that I have been serving for the past 18 years in my career, I can see that in one organization, you will find different SDLCs scattered across the organization. Some of it is actually for a mobile application, others are different departments or different platforms. Some of it is an internal platform that is for your employees, others are actually customer-facing. So it is not one workflow that can actually build anything you want for your organization.
When you figure out what to build and how to build it, you need to run it. Then you come to the platform engineering ops, right? That is, again, when you have your provisioned infrastructure, thinking about how you build your infrastructure as code modules, et cetera. And then you launch your products. And the moment you launch it, then you start the journey of optimizing the performance of your products, trying to look for any incidents to resolve. And then you start the loop again, right?
So at scale, when you look at really building a digital platform, not a very simple product that you can build and deploy, the landscape is way more complex than expected. And what you're looking at here is literally probably 10, 20% of what it is. And it's really different from organization to organization. Now, going back to the stack, right? When you look at the workflow, there are four core components. The first one is hooks, MCP services, and sub-agents. Those are given, but they don't really bring the right structured value to your workflows, right? That's why skills is one of the critical components in your workflows.
Hooks, basically, what it does, it just pre-grounds events to do something along your workflow. The MCP service, we all know that you may need an MCP tool, but tell me, who actually built a lot of MCPs? We just use MCP tools that are actually provided by the tool that we used before, right? So we don't really own those. The sub-agents are just to minimize the context window. We just delegate to sub-agents to execute a specific task that is needed. So at the end of the day, you will find all of your know-how is actually at the skills level. And if you don't have the right structure of your skills, then you're not really having a deterministic workflow.
And one thing to mention is workflows, think about them as harness blueprints that actually shape the behavior of your coding harness, for example, in the runtime. Now, looking at the rise of skills adoption, right? So just eight months ago, Entropic published the first article about skills, right? Two months later, we had the standard, an open standard that is adopted, and a lot of agent harnesses started adopting this new standard. Around February this year, we have seen most of the agents actually adopt this. Even though you don't see them, right? If you pay attention when the agent is thinking, you can see that he's pulling skills as he's going and doing the task.
The other indication here that you need to pay attention to is actually the number of skills that are created, right? This is literally just a snapshot that I did across some public GitHub repos and public skills registries, right? There's way more than this publicly and within your organizations, right? So the creation of skills and the demand is rising, but we need to understand why.
In the latest skills bench, comparing the latest models against running the same tasks against auto engineering and cybersecurity without skills, it did well, right? Because that's what it is expected to do. And it's going to continue improving day after day, right? But then, when we applied skills that are more deterministic, the outcome was clearly higher than without it.
Now, if you think about the anatomy of skills and how you actually design and implement skills in your organization, this is not a new problem that we are trying to solve here, right? We have solved this with the microservice movements, right? So your microservices need to have all of these design principles, right? This is a software problem that we used to solve. It's similar. So skills need to be reusable, right? They need to be modular, need to be discoverable, so you can discover your skills. So if you are sitting in one team and you need the skills, you can actually automatically discover and capture the skills. It's portable so that you can actually use skills across workflows, but also you can use skills
improving day after day, right? But then when we applied skills that are more deterministic, the outcome was clearly higher than without it. Now, if you think about the anatomy of skills and how you actually design and implement skills in your organization, this is not a new problem that we are trying to solve here, right? We have solved this with the microservice movements, right? So your microservices need to have all of these design principles, right? This is a software problem that we used to solve. It's similar. So skills need to be reusable, right? They need to be modular, need to be discovered, you can discover your skills. So if you are sitting in one team and you need the skills, you actually can automatically discover and capture the skills. It's portable, that you can actually use skills across workflows, but also you can use skills across harnesses. Again, if everyone adopted the same standard. So if I'm having a skill on cloud code and I want to move it to cursor, it's going to just work. Specialized skills, that is where the value, you should not build one skill, a monolith again. It should be specialized to define one task specifically. Composable skills need to be designed in a way that can actually compose, so you don't have duplication across your skills when you're trying to run them that conflicts with each other. Consistence, that is actually one of the key items of skills, is actually consistency and deterministic. And finally, cost-efficient. And for cost, I can go for another hour talk, but it's the skills come to solve a key problem around the context window, right? It's actually put in with the progressive disclosure pattern, the right skills, the right amount of skills, at the right time to solve the right problem. And that reduces the token usage. This defines a new unit, right, that makes your know-how in your organization executable, portable, and cheap.
On the right-hand side, you just have a very simple example of data retention policy, right? When it came to regulation, you need to understand and make sure to instruct your agents why you're manipulating, for example, your customer data. You should make sure that this data is manipulated according to the regulation, right? And that brings me to the next example. On the left-hand side, you can see that there's a, think about a catalog of skills. And on the right-hand side is your harness, and the output is on the right-hand side, right? So the composable skills at the regulation level, you have the skill that I just showed earlier, which is the retention policy, but you will need disclosure standards. You will need the GDPR rules that need to be respected. You will need the filing templates, right? So all of this, think about it, is defining how any data, any feature that is built across your web, mobile, different applications across your organization is really respecting these rules. And this gets pulled automatically at runtime by the regulatory disclosure review workflow. And the outcome is expected. It's deterministic. You have an audit report that you can actually store. You have specific identification of if there's anything to improve, and there's a loopback to improve your codebase.
However, if we don't govern skills, we will start creating a new class of technical debt, right? First of all, you will find out that you are having a lot of duplication in your organization. So if teams are not collaborating and everyone is using the same technology stack, the same infrastructure, you're for sure building the same skills over and over again without sharing them. Quality. If you don't test and make sure that you're maintaining and validating your skills, not against your task, but also against the latest models that come, right, then the quality starts degrading over time. You should be able to discover your skills. In reality, without governance, you cannot really discover it. Think about it as the backstage, the IDP, right? It comes to solve a problem where, okay, I need to understand who owns this microservice back in the days, right? I don't need to talk to anyone. I just need to tap into the service catalog and immediately find who actually owns it. That brings the ownership part. If you don't have an owner, then no one will be able to maintain, scale those skills. Composability is not something that comes by default. You need to have a governance way to align what to build and how to design it. Think about the domain-driven approach that we have been taking also for many years, right? It's similar to how you shape your skills catalog. Security. Again, all of us experiment with the public skills, right? But when you think about it, some skills may have some prompt injection, and skills actually do have scripts because that's the deterministic part of it, because it's going to run a specific script for a specific task. So if you don't have, again, a pipeline that checks your security, you may be pulling something that is insecure. And permissions. Not every skill is actually something that anyone in the organization should access. Some skills may have some business logic that is very sensitive, right? So the access control is also crucial at this stage.
Now, how to bring this to your organization? First of all, you need to allow, at the individual level, to create, test, improve, and use those skills. Again, you shouldn't be around them. You should be structured way. There are different tools out there. You just need to decide which tool actually you want to agree on, and you use that mechanism at the individual level. The moment you create a skill, you need to be sharing this with your team, right? Your team starts collaborating to improve the skills. And think about it, you build the same technology stack, building the same products. So it's going to evolve very quickly. But then you move on to a very critical point, which is the centralized platform. That is where all of what I've been covering so far comes to play. You need a centralized platform that has a catalog with metadata in it that actually can discover skills and could be searchable. You can have an MCP that actually plugs into this catalog, search for the skill, and a CLI to pull the skills back to either your IDE, if you're locally, or to your sandbox in your factory. Then you have the dependencies. You need to understand the dependencies between the skills as well. You have the versioning and lifecycle, so you understand which version of the skills is actually the latest. And a very good example, when I'm using, for example, building a functionality, I can, the agents automatically capture that there is a latest version of the skill and pull it, right? So this versioning helps also to pull the right latest changes from the skills registry. Access control. Again, as I said, if you don't know who is accessing what, that is a huge gap. And finally, evaluation observability. And then all of this is actually played around a governance.
And this is where technology stops solving the problem, right? So you figure out all of this, all good. Now, who's going to govern this? And that is where it really depends how your organization is structured today. That is where you should have your architects, your engineering leads, infra leads, et cetera, and cyber leads actually sitting down, owning parts of those domains, and making sure that these skills, when they get updated, are actually according to the policies you want to adhere to within your organization and drive this change. And finally, when you get this right, what you will have, you will have at the organization level all of your teams pulling from one centralized place high-quality skills, executing them, and pulling them back to the centralized platform if they are improved.
Now, what I want to bring this, because this is a little bit of an unclear view. So what I created, I created a simulation, right? So think about this. This is your organization today, right? And what I have here, I have just a random team. So I have 15 teams created, 5 to 12 per team. You have skills per engineer's contribution. You have the average skills utilization, on average, how much time skills are being pulled per day, the duplication across the team as a ratio, and the skills quality and security ratio. Now, if I run this across six months, what's really happening, and think about it, this is already happening within your organization. If teams are creating and using the skills, right, but we don't have visibility. And skills, again, they are tightly coupled to your productivity uplifts. If, for example, the example that I shared earlier on the regulation, if we don't have a skill about the regulation, that is someone is vibe coding back and forth and trying to figure out exactly how to steer the agent to implement it properly, right? That is burning more tokens from one side cost-wise, but also the productivity is spending more time rather than getting in one shot the right answer. And the quality and security is similar. If you don't have
how much time skills are being pulled per day, the duplication across the team, as a ratio, and the skills quality and security ratio. Now, if I run this across six months, what's really happening? Think about it, this is already happening within your organization. If teams are creating and using the skills, right, but we don't have visibility. And skills, again, they are tightly coupled to your productivity uplifts. If, for example, the example that I shared earlier on the regulation, if we don't have a skill about the regulation, that is, someone is vibe coding back and
forth and trying to figure out exactly how to steer the agent to implement it properly, right? That is burning more tokens from one side, cost-wise, but also the productivity is spending more time rather than getting, in one shot, the right answer. And the quality and security is similar. If you don't have clear skills defined and maintained, you will have a low quality in your implementation because then it's up to the human to decide this, and different in the maturity from team to team, you can see the difference. And that is why, for example, if I look just randomly at this, this is, you can see the productivity of this team is a medium, right? If I look at this
one, it's a bit of, I don't know, it's low, medium, productivity, quality, and security, also a medium, but when it came to the cost, it's really high. Okay. Now let's actually say, okay, how this looks if I governed all of my skills in my organizations. What's going to happen is, of course, some of them were split, right? And this is reality. It's going to be perfect as we expect. But at least what you will see, you will see actually some common ground across all of your teams. The moment you govern, you publish one skill. The next engineer trying to build a new skill, the coding agent harness will identify the skill that is already available and pull it, right? So you
almost solve all of the issues that I covered about the governance. And one last point is, when it came to skills, it's just one component of your workflows, as I said, right? So that doesn't mean if you figure out skills, that says you're good. No, you need to apply the same approach and solution for your whole workflows. And you may think to apply this again, if you think about it, if you have a centralized platform that has all of your workflows, right? From one side, you're centralized in the workflows, which is also having the skills, but also if the next engineer came and went on, I don't know, provision infrastructure,
they can tap into a workflow and build that workflow with the required skills and run it and test it. Again, if it's something that needs to be improved in the workflow, you can easily push it back to the centralized platform for your organization to use. Now, before I wrap up, what I want to leave you with is this is just the start at the beginning. You see, this just we're talking about six to eight months. What's coming next, and I would invite you to already explore, is skills registry, right? You should have one, if not already. And the good news is all of the players that's been solving the IDP problem, like internal developer portal,
they already start centralizing this capability, right? So if you don't have it today, maybe in a couple of months, you will see it coming. But also, there's a lot of tools that's actually solving this specific problem. Second is skills evaluation. There's still a discussion on what is the right approach to evaluate skills. The easy thing that I found so far very valuable is actually tested, like you link static tests or evaluate your skills against the entropic best practices, right? If the skill is not invoked properly, if the skill is not structured properly, there's a high chance there's not going to be high quality. And finally, it's auto evolving. And again,
this is what everyone is the next hype right now. Like, yeah, I can create a closed loop that can evolve automatically my skills. So what, right? If you automatically start this machine, the impacts will be way more than it is today. Because what I shared earlier is going to be just maintaining auto evolving skills without that governance in place that actually put the guardrails for your organization. And at this point, I would leave you here. Thank you so much for your listening, and looking forward. If you have any question, I will be in the leadership lounge. Feel free to grab me. Thank you so much. Thank you.
an open standard that is adopted and starts a lot of agents harnesses starts adopting this new standard. Around February this year, we have seen most of the actually agents adopted this. Even though you don't see them, right? If you pay attention when the agent is thinking, you can see that he's pulling skills as he's going and doing the task. The other indication here that you need to pay attention to is actually the number of skills that are created, right? This is just like literally a snapshot that I did across some public gets to have reposts and public skills registries, right? There's way more than
this publicly and within your organizations, right? So the creation of skills and the demand is rising, but we need to understand why. In the latest skills bench, comparing the latest models against like, you know, running the same tasks against auto engineering and cybersecurity without skills, it did well, right? Because that's what it expects it. And it's going to continue to be improving day after day, right? But then when we applied skills that are more deterministic, the outcome was clearly higher than without it. Now, if you think about now like how like the anatomy of skills and how you actually design and implement skills in your organization, this is not
like a new problem that we are trying to solve here, right? We have solved this with the microservice kind of movements, right? So your microservices need to have all of these design principles, right? This is like a software kind of like, you know, problem that we use to solve. It's similar. So skills need to be reusable, right? Need to be modular, need to be discovered, like you can discover your skills. So if you are sitting in one team and you need the skills, you actually can automatically discover and capture the skills. It's portable that you can actually use skills across workflows, but also you can use skills
across harnesses. Again, everyone adopted the same standard. So if I'm having a skill on cloud code and I want to move it to cursor, it's going to just work. Specialized skills, that is where the value, you should not build like a one skill, like a monolith again. It should be specialized to define one tasks specifically. Composable skills need to be designed in a way that's actually can compose. So you don't have duplication across your skills when you're trying to run them. That conflicts each other. Consistence, that is actually one of the key items of skills is actually consistency and deterministic.
And finally, cost-efficient. And for cost, I can go for another hour talk, but it's basically the skills comes to solve a key problem around the context window, right? It's actually put in with the disclosure, progressive disclosure pattern, the right skills, the right amount of skills in the right time to solve the right problem. And that's reduced the token usage. This defines a new unit, right? That makes your know-how in your organization executable, portable, and cheap. On the right-hand side, you just have a very simple example of data retention policy, right? When it
came to regulation, you need to understand and make sure to instruct your agents, why you're manipulating, for example, your customer data, you should make sure that this data manipulates according to the regulation, right? And that brings me to the next example. On the left-hand side, you can see that there's like a...think about a catalog of skills. And in the right-hand side is your harness, and the output is on the right-hand side, right? So the composable skills at the regulation level, you have the skill that I just showed earlier, which is the retention policy, but you will need disclosure
standards. You will need the GDPR rules that need to be respected. You will need the filling templates, right? So all of this, kind of think about it, is like defining how any data, any feature that is built across your web, mobile, like, you know, different applications across your organizations is really respecting these rules. And this gets pulled automatically by on the runtime by the regulatory disclosure review workflow. And the outcome is expected. It's deterministic. You have an audit, uh, an audit report that you can actually store. You have, um, specific, uh, identification of if
there's anything to improve, and that there's kind of like loopback to improve your, your codebase.
However, if we don't govern skills, we will start creating a new class of technical lips, right? First of all, you will find out that you are having a lot of duplication in your organization. So if teams are not collaborating and everyone is, think about it, using the same technology stack, the same infrastructure, you're for sure building the same skills over and over again without sharing them. Quality. If you don't test and make sure that you're maintaining and you're validating your skills, not against your task, but also against the latest models that comes, right? Then the quality starts degrading over time. You should be able to discover your skills. In reality,
without a governance, you cannot really discover it. Think about it as the, the backstage, the IDP, right? It's, it's come to solve a problem where, okay, I need to understand who owns this microservice back in the days, right? I don't need to talk to anyone. I just need to tap into the service catalog and immediately find who actually owns it. That is brings the ownership part. If you don't have an owner, then no one will be able to maintain, scale those skills. Composibility is not something that comes by default. You need to have a governance way to, to align what to build and how to design it.
It's think about the domain driven approach that we have been taking also for, for many years, right? It's similar to how you shape your skills catalog. Security. Again, some of, all of us, like we experiment with the public skills, right? But when you think about it, some skills may have some prompt injection and skills actually does have scripts because that's the deterministic part of it because it's going to run a specific script for a specific task. So if you don't have, again, a pipeline that checks your security, you may be pulling something that is insecure. And permissions. Not every skills is actually something that's anyone in the organization
should access. Some skills may have some business logic that is very sensitive, right? So the access control is, is also crucial at this stage. Now, how to bring this to your organization? First of all, you need to allow at the individual level to create, test, improve, and use those skills. Again, you shouldn't be around them. You should be structured way. These are different tools out there. You just need to decide which tool actually you want to agree on. And you use that mechanism at the individual level. The moment you create a skills, you need to be sharing this with your team,
right? Your team starts collaborating to improve the skills. And think about it, you build the same technology stack, building the same products. So it's going to evolve very quickly. But then you move on to a very critical point, which is the centralized platform. That is where all of what I've been covering so far come to play. You need a centralized platform that has a catalog with metadata in it that actually can discover skills and could be searchable. You can have an MCP that actually plugs to this catalog. Search for the skill and a CLI to pull the skills back to either your IDE, if you're locally,
or to your sandbox in your factory. Then you have the dependencies. You need to understand the dependencies between the skills as well. You have the versioning and lifecycle. So you understand which version of the skills is actually the latest. And a very good example, when I'm using, for example, building a functionality, I can... The agents automatically capture that there is a latest version of the skill and pull it, right? So this versioning helps also to pull the right latest changes from the skills registry. Access control. Again, as I said, if you don't know who is accessing what, that is a huge
gap. And finally, evaluation observability. And then all of this is actually played around a governance. And this is where technology stops solving the problem, right? So you figure out all of this, all good. Now, who's going to govern this? And that is where the... You know, it really depends how your organization is structured today. That is where you should have your architects, your engineering leads, infra leads, et cetera, and cyber leads actually sitting down, owning parts of those domains and making sure that this skills when it gets updated, is actually according to the policies you want to adhere within
your organization and drive this change. And finally, when you get this right, what you will have, you will have at the organization level, all of your teams pulling from one centralized place, high-quality skills, executing them and pulling them back to the centralized platform if it is improved. Now, what I want to bring this, because this is a little bit of an in-clear view. So what I created, I created a simulation, right? So think about this. This is your organization today, right? And what I have here, I have just a random team. So I have 15 teams created, 5 to 12, like, per team. You have
skills per engineer's contribution. You have the average skills utilization, kind of like on average, like how much time skills are being pulled per day, the duplication across the team, kind of as a ratio, and the skills quality and security ratio. Now, if I run this across six months, what's really happening and think about it, this is already happening within your organization. If teams are creating and using the skills, right, but we don't have visibility. And skills, again, they are tightly coupled to your productivity uplifts. If, for example, the example that I shared earlier on the
regulation, if we don't have a skill about the regulation, that is someone is vibe coding back and forth and trying to figure out exactly how to steer the agent to implement it properly, right? That is burning more tokens from one side cost-wise, but also the productivity is spending more time rather than getting in one shot the right answer. And the quality and security is similar. If you don't have clear, you know, skills defined and maintained, you will have a low quality in your implementation because then it's up to the human to decide this and different in the maturity from team to team,
you can see the difference. And that is why, for example, if I look just randomly at this, this is like you can see the productivity of this team is kind of a medium, right? If I look at this one, it's a bit of like, I don't know, it's low, medium, productivity, quality, and security, also a medium, but when it came to the cost, it's really high. Okay. Now let's actually say, okay, how this looks like if I governed all of my skills in my organizations. What's going to happen is, of course, some of them were split, right? And this is reality. It's going to be perfect as we expect. But at least what you will see, you will see actually some common ground across all of your
teams. The moment you govern, you publish one skill. The next engineer trying to build a new skill, the coding agent harness will identify the skill that is already available and pull it, right? So you almost solve all of the issues that I covered about the governance.
And one last point is when it came to skills, it's just one component of your workflows, as I said, right? So that doesn't mean if you figure out skills, that says you're good. No, you need to apply the same kind of like approach and solution for your whole workflows. And you may think to apply this again, if you think about it, like if you have a centralized platform that has all of your workflows, right? From one side, you're centralized in the workflows, which is also having the skills, but also if the next engineer came and went on, I don't know, like provision infrastructure,
they can tap into a workflow and build that workflow with the required skills and run it and test it. Again, if it's something that needs to be improved in the workflow, you can easily push it back to the centralized platform for your organization to use.
Now, before I wrap up, what I want to leave you with is this is just the start at the beginning. You see, like, this just we're talking about six to eight months. What's coming next and I would invite you to already explore is skills registry, right? You should have one, if not already. And the good news is all of the players that's been solving the IDP problem, like internal developer portal, they already start centralizing this capability, right? So if you don't have it today, maybe in a couple of months, you will see it coming. But also, there's a lot of tools that's actually solving this
specific problem. Second is skills evaluation. There's still kind of like a discussion on what is the right approach to, you know, to evaluate skills. The easy thing that I found so far very valuable is actually tested, like you link static tests or evaluate your skills against the entropic best practices, right? If the skill is not invoked properly, if the skill is not structured properly, there's a high chance there's not going to be high quality. And finally, it's auto evolving. And again, this is what everyone kind of like is the next hype right now. Like, yeah, I can create like a closed
loop that can evolve automatically my skills. So what, right? If you automatically start this machine, the impacts will be way more than it is today. Because what I shared earlier is going to be just maintaining auto evolving skills without that governance in place that actually put the guardrails for your organization. And at this point, I would leave you here. Thank you so much for your listening and looking forward. If you have any question, I will be in the leadership lounge. Feel free to grab me. Thank you so much. Thank you.