WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=LC3-P7v3yoI NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/LC3-P7v3yoI.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:03.520 --> 00:00:06.640 We'll talk about skills today. s2 00:00:07.760 --> 00:00:10.800 The current challenges about context. s3 00:00:10.800 --> 00:00:21.960 And then lastly about the ecosystem that's being built around skills lately, especially with open cloud and all of those stuff getting a lot of attention in the industry. s4 00:00:21.960 --> 00:00:24.400 So, let's get into it. s5 00:00:24.400 --> 00:00:28.520 Every AI or agent tech app typically has three layers. s6 00:00:28.520 --> 00:00:33.600 The one that user sees, which is typically the UI, the user interface. s7 00:00:33.600 --> 00:00:38.800 The one that model sees, which is the system prompt, as well as the tool descriptions. s8 00:00:38.800 --> 00:00:45.880 And then the one that data sees, which is the schema of data or the input and output of the tool calls. s9 00:00:45.880 --> 00:00:53.360 And these little bugs typically live on these second and third one, which is slightly hidden from the user. s10 00:00:53.360 --> 00:00:57.160 And so, let's talk about these problems. s11 00:00:57.160 --> 00:01:05.000 The first one is that beautiful lie that we've been told that the latest frontier models have infinite context windows. s12 00:01:05.000 --> 00:01:21.640 They typically promised that each one has 1 million, 5 million, and even latest models they promised us infinite context window, which incorrectly shapes our thinking perspectives about rag and MCP in a sense. s13 00:01:21.640 --> 00:01:32.400 Because if we consider that there's infinite context window, we just think that we can dump the whole list of documents to the context and expect it to magically work. s14 00:01:32.400 --> 00:01:34.400 This applies to MCP as well. s15 00:01:34.400 --> 00:01:41.160 Let's say we can write 100 tools and expect the LLM to use or pick the right tool at the right time. s16 00:01:41.160 --> 00:01:42.760 Which is typically not true. s17 00:01:42.760 --> 00:01:49.040 Because in reality, the longer context typically doesn't mean better performance. s18 00:01:49.040 --> 00:01:58.280 Because each time put more context into LLM, that's one more place where the LLM might be misled it or its context might be poisoned. s19 00:01:58.280 --> 00:02:12.280 In fact, there was a paper called context rot, and it proves that after 25% usage of the context window, so for example, for 1 million token, if you used 256K s20 00:02:12.280 --> 00:02:16.440 of it, the performance starts to degrade. s21 00:02:16.920 --> 00:02:28.160 So, I'm pretty sure it starts really well as day in the life, but as time goes and as the conversation grows, let's say there is 100 prompt input and output responses s22 00:02:28.160 --> 00:02:43.240 in your one shot, and added 200 shots, and then each one of them kind of calls MCPs or tools, each time out of them in the middle fails, and at the end of the day, the context is almost eating itself s23 00:02:43.240 --> 00:02:48.440 in a sense that the latest 100 model can perform like a really poor model. s24 00:02:48.440 --> 00:02:57.120 I'm pretty sure we'll have seen this, you are absolutely right from Cloud Code, even though Phil's a sharing, then you're absolutely right. s25 00:02:57.120 --> 00:03:04.600 At one point, makes you feel bad that Cloud Code is making the same mistake it made 5 minutes ago. s26 00:03:05.360 --> 00:03:10.600 The second problem is mostly about documentation websites. s27 00:03:10.600 --> 00:03:22.840 This is an interesting statistics that just from last year to this year, the traffic to documentation websites increased from 10% to 50% that's coming from coding agents. s28 00:03:22.840 --> 00:03:31.519 The challenge here is the fact that docs are written for humans, but models are expected in a different format. s29 00:03:31.519 --> 00:03:41.000 Because docs typically require some kind of intuition, asking for a follow-up, or if you don't understand it, well, you can just Google it quickly and then find the answer for it. s30 00:03:41.000 --> 00:03:48.280 But models typically doesn't have those capabilities until you actually build a context engine around it. s31 00:03:48.280 --> 00:03:58.640 I want to add one more strategic point about the future of enterprise AI and why we think that skills might be a huge contributor to where the enterprise agents s32 00:03:58.640 --> 00:04:01.480 or enterprise AI is heading towards. s33 00:04:01.480 --> 00:04:04.760 Let's talk a little bit about modes these days. s34 00:04:04.760 --> 00:04:14.560 Now, if you want to understand modes today or tomorrow, we can go back in time at today's history of software to see how has it been in the past. s35 00:04:14.560 --> 00:04:22.520 Typically, the things that have been the hardest to replicate have been the modes for the software companies or even hardware ones. s36 00:04:22.520 --> 00:04:32.760 So, for example, whoever controls the hardware, the data, or especially the integrations in the SaaS era would be the ones that would control the market most of the time. s37 00:04:32.760 --> 00:04:42.520 So, the real mode here would be friction where you would make it genuinely hard to you to leave to to make someone leave your platform. s38 00:04:42.520 --> 00:04:49.640 So, the core idea here is the switching cost was too much that it it was just hard to switch. s39 00:04:49.640 --> 00:04:58.080 Now, these days we're hearing news where Cloud Code would rewrite 100,000 or a million lines of code from Python to Rust. s40 00:04:58.080 --> 00:05:03.840 So, basically, we're getting really, really good at switching codes and reducing it. s41 00:05:03.840 --> 00:05:10.919 Now, we can have better tools, better APIs, just better languages, and then switching it in few days. s42 00:05:11.480 --> 00:05:20.480 Now, skills are creating an entirely different ecosystem where instead of creating a friction mode, they're actually creating fluency mode. s43 00:05:20.480 --> 00:05:32.000 So, the core idea is switching the the layer a little bit so that each time your skill makes the experience better for whoever is the one that that's using your platform. s44 00:05:32.000 --> 00:05:36.280 And that fluency compounds by experience. s45 00:05:36.280 --> 00:05:42.400 The the real result that the users of your platform is getting from here is the experience. s46 00:05:42.400 --> 00:05:52.000 If you would look at the definition of experience, you can realize that it's satisfaction or minimum amount of friction between intent and outcome. s47 00:05:52.000 --> 00:06:04.120 So basically, whatever the user is trying to achieve through your platform, achieving it in maybe minimum amount of time or trying to optimize the whole satisfaction layer or whole experience layer of it. s48 00:06:04.120 --> 00:06:10.760 If you look at the equation, you will see that overall friction modes and fluency modes are the opposite. s49 00:06:10.760 --> 00:06:12.840 Friction modes are typically defensive. s50 00:06:12.840 --> 00:06:17.960 So you're trying to make your experience in a sense that someone wouldn't switch. s51 00:06:17.960 --> 00:06:31.640 Now, fluency modes are offensive in a sense that you're making the whole experience really nice in a sense that you're making it genuinely hard for someone to switch anyways because they like the platform. s52 00:06:33.240 --> 00:06:43.919 So we think that the feel of the thing or the reliability of the outcome from the start, which is your intent, to the result is the whole experience layer. s53 00:06:43.919 --> 00:06:51.160 And the skills are one of the best tools that can actually, quote unquote, commoditize that experience layer for agents. s54 00:06:51.160 --> 00:07:05.000 So, the real mode in SaaS era might be the core idea of skills, where you would commoditize the feeling of your platform or, in other words, how trustful or reliable you are in terms of s55 00:07:05.000 --> 00:07:07.880 intent and outcome equation. s56 00:07:09.000 --> 00:07:15.800 When someone evaluates the platform, they typically have a checklist of things that they take a look, right? s57 00:07:15.800 --> 00:07:23.720 They typically look at how secure your platform is, are you compliant with all sort of new standards that's that's coming up every week. s58 00:07:23.720 --> 00:07:26.040 How is my data governance layer? s59 00:07:26.040 --> 00:07:27.840 Where is my data stored? s60 00:07:27.840 --> 00:07:29.360 Are your SLA guarantees? s61 00:07:29.360 --> 00:07:31.919 Can I see the logs of my agent? s62 00:07:31.919 --> 00:07:33.360 How about tracing? s63 00:07:33.360 --> 00:07:34.840 How is the integration layer? s64 00:07:34.840 --> 00:07:40.520 Are you able to integrate to my auth layer that's connected to my internal on-premise systems? s65 00:07:40.520 --> 00:07:46.680 So now we think that checklist really has a new item, a new guy in the room, which is the teachability. s66 00:07:46.680 --> 00:08:00.760 Again, coming back to the experience layer for agents, so here the core idea is if someone is new or if my agent harness is new to a platform, how easy is it for that agent harness to pick up that operational knowledge s67 00:08:00.760 --> 00:08:08.040 that you've encoded a skill and apply directly and then get into the result in less than few seconds. s68 00:08:08.040 --> 00:08:18.680 So, the core idea of teachability is to make that experience easy as possible whenever someone wants to use your platform for the first time or for subsequent times. s69 00:08:18.680 --> 00:08:29.280 So, if you wrap it up, we think that the skills might play a huge role in the enterprise AI or enterprise agent world in a sense that it might define what the mode is. s70 00:08:29.280 --> 00:08:41.080 If the mode these days is about fluency, skills will help it in a sense that the value that you are giving will get compounded by each skill you add to your platform. s71 00:08:42.360 --> 00:08:43.760 Why think about standards? s72 00:08:43.760 --> 00:08:47.000 I feel like I just need to skip this slide for this audience. s73 00:08:47.000 --> 00:08:48.440 Because standards are good, right? s74 00:08:48.440 --> 00:08:58.520 For example, React came out recently, but if you go back in time to 20 years ago, it almost feels like LLM and agent ecosystem right now. s75 00:08:58.520 --> 00:09:00.760 So, 20 years ago we didn't have React. s76 00:09:00.760 --> 00:09:07.000 It introduces a philosophy on reactivity and modularity to the to the way we build apps. s77 00:09:07.000 --> 00:09:13.320 And same for LLMs and agent ecosystem in a sense that we don't yet have that React moment. s78 00:09:13.320 --> 00:09:20.520 It's still up on here in terms of how to systematically develop really long-running agent systems. s79 00:09:21.120 --> 00:09:29.160 And as I said, context engineering in a sense is kind of a one attempt to to solve that problem in an organized way. s80 00:09:29.160 --> 00:09:41.520 So, if you would summarize what context engineering is, it's almost an idea of minimizing the amount of information that flows to the LLM at the right time so that we can filter s81 00:09:41.520 --> 00:09:48.120 so that we can fill the context with the right information at the right flow at the right moment. s82 00:09:48.440 --> 00:09:51.480 So, let's look at this example on the right. s83 00:09:51.480 --> 00:10:03.400 So, if you consider a typical agent whether it's cloud code or our own agent that we built for a customer it typically has system instructions cloud that I need s84 00:10:03.400 --> 00:10:08.880 couple built-in tools maybe also connection to MCP, right? s85 00:10:08.880 --> 00:10:16.120 And on top of that a user or a customer is kind of prompting the LLM. s86 00:10:16.120 --> 00:10:23.920 Typically this 40% is the smart zone where the LLM can potentially perform well. s87 00:10:23.920 --> 00:10:33.000 But if you would you are getting past this 40% context used it typically goes into a zone called dumb zone. s88 00:10:33.000 --> 00:10:44.880 The core idea here is the fact that even though you have 100% context available for you, but as you go past 40% um then you are actually getting really dumb responses. s89 00:10:44.880 --> 00:10:53.800 So, the core idea here is is to make sure that you're not passing 40% even without starting to work with your agent. s90 00:10:53.800 --> 00:11:04.520 So, imagine you have all sort of the instructions, a lot of MCPs here, and then you add one more block here for another MCP, one more block here for another s91 00:11:04.520 --> 00:11:09.360 MCP that's connected to internet, one more for web search, and things like that. s92 00:11:09.360 --> 00:11:16.360 And then even you haven't ever chatted to your agent yet now you've filled your 40% context window. s93 00:11:16.360 --> 00:11:23.320 And then when you just start to chat for the first time, you start from dumb zone from the first call. s94 00:11:23.839 --> 00:11:29.160 So, typically creating a great context has pieces to it. s95 00:11:29.160 --> 00:11:29.839 Right? s96 00:11:29.839 --> 00:11:31.440 Let's cover each one of them briefly. s97 00:11:31.440 --> 00:11:35.160 The first one is instructions that kind of comes by default. s98 00:11:35.160 --> 00:11:37.760 You put it to the system prompt. s99 00:11:37.760 --> 00:11:39.800 The second one is external data. s100 00:11:39.800 --> 00:11:44.120 Maybe the user will upload some PDFs or any kind of rag. s101 00:11:44.120 --> 00:11:45.280 And execution history. s102 00:11:45.280 --> 00:11:49.920 Obviously, LLM needs to have access to what happened on that session. s103 00:11:49.920 --> 00:11:54.880 What's the past tool call results and where are we in terms of state? s104 00:11:54.880 --> 00:12:01.800 And then latest agentic systems has memory in a sense that they can remember things across conversations. s105 00:12:01.800 --> 00:12:07.560 And then the output schema, the the correct way to output all of these stuff to the user. s106 00:12:07.560 --> 00:12:14.320 So, as you see, each one kind of adds one more level of complexity to the things that agent needs to handle. s107 00:12:14.320 --> 00:12:24.520 And it almost creates an M times N problem in a sense that one agent or one LLM needs to be connected to all of these stuff at once, at the same time, s108 00:12:24.520 --> 00:12:26.960 at any time of the conversation. s109 00:12:26.960 --> 00:12:32.640 Which is pretty hard task to do, actually, if we would emphasize LLMs. s110 00:12:32.640 --> 00:12:48.800 The core idea is instead of hardcoding everything into either one of these items, basically, and then loading it to the LLM, we would progressively load whenever those instructions is needed to the LLM. s111 00:12:48.800 --> 00:12:53.640 And then LLM would have access to a piece of it at runtime. s112 00:12:53.640 --> 00:12:58.720 And then it can load it to its memory whenever it's needed. s113 00:13:00.640 --> 00:13:06.520 The problem that skills to be solved is it enables a rich context access. s114 00:13:06.520 --> 00:13:16.200 In a traditional context, everything goes into the context, which would lead to context rot problem that we covered. s115 00:13:16.200 --> 00:13:29.080 But with skills, those capabilities, whether it's about web search or whether it's about some capability that doesn't exist in the main agent that lives externally, and then LLM or agent s116 00:13:29.080 --> 00:13:31.120 can have access to it. s117 00:13:31.120 --> 00:13:44.320 So, if you would give an example and compare it with MCP, typically, if an agent is connected to an MCP server, it even this number is really small for 15 MCP servers. s118 00:13:44.320 --> 00:13:53.920 If it's connected to 15 MCP server, I'm pretty sure it's consuming over 100,000 tokens per session just in tool definitions itself. s119 00:13:53.920 --> 00:13:57.040 Without starting the conversation yet. s120 00:13:57.040 --> 00:14:03.800 But same operational headache becomes really small, probably at least 10 times smaller with skills. s121 00:14:03.800 --> 00:14:06.320 Thanks to progressive disclosure. s122 00:14:06.320 --> 00:14:16.560 So, this one is only exposed metadata of skills to the agent or to the LLM at runtime so that it can act like an index in a database. s123 00:14:16.560 --> 00:14:21.960 Just like how indexes work in a in a DB so that you can quickly search for stuff. s124 00:14:21.960 --> 00:14:24.800 Same for the metadata for skills. s125 00:14:24.800 --> 00:14:37.360 Even if skills might have thousands of tokens in it, LLM has access to the metadata of it on which most of the time leaves at the top of the file, s126 00:14:37.360 --> 00:14:42.360 which is being loaded to the to the context on demand. s127 00:14:44.240 --> 00:14:51.480 This creates mental model shift on developers as well as the industry in a sense. s128 00:14:51.480 --> 00:15:03.720 Because the skills are are kind of becoming almost like a framework across platforms like cloud code, codex, and then all of them supports this perspective. s129 00:15:03.720 --> 00:15:05.240 Why, you would ask? s130 00:15:05.240 --> 00:15:11.760 Long running agents, even coding agents are acting like a general purpose agents, right? s131 00:15:11.760 --> 00:15:23.480 So, when a customer asks us to build a supply chain agent or an agent that's in a manufacturing space, we don't really have to build a separate agent for that specific use case. s132 00:15:23.480 --> 00:15:32.080 It's the fact that we can still take the main general purpose agent as the as the engine and then put skills on top of it. s133 00:15:32.080 --> 00:15:39.160 But you see how skills creates a shift in terms of perspective about how to build solutions. s134 00:15:39.160 --> 00:15:46.880 In a sense that right now you don't have to actually build the agent itself, the engine itself, but actually build skills for it. s135 00:15:46.880 --> 00:15:52.080 And then that's way to switch agents between industries, between different domains. s136 00:15:56.280 --> 00:16:02.520 All right, moving on to part two where we'll cover briefly on skills versus MCP. s137 00:16:02.520 --> 00:16:05.520 So, they kind of solve slightly different problems in a sense. s138 00:16:05.520 --> 00:16:07.360 So, I just want to clarify this. s139 00:16:07.360 --> 00:16:09.440 Both of them are from Anthropic. s140 00:16:09.440 --> 00:16:10.960 Both MCP and skills. s141 00:16:10.960 --> 00:16:14.000 So, they're not competing for a thing. s142 00:16:14.000 --> 00:16:20.360 So, in a sense that MCP kind of definitions for what actions the agent should take. s143 00:16:20.360 --> 00:16:27.600 In a sense that it doesn't change the agent definition and then what the agent is, what capabilities it has. s144 00:16:27.600 --> 00:16:38.960 And for skills, it's different in a sense that it helps to think about problem and then change you can basically customize the way agent acts through skills. s145 00:16:38.960 --> 00:16:40.680 How to think about this problem. s146 00:16:40.680 --> 00:16:54.160 And then skills introduces you a way to self-modify in a sense that agent can modify or update its own skills based on the experience that it had with that skill. s147 00:16:54.160 --> 00:17:08.600 On the other hand, for MCP, it's sort of a server that sits in a separate environment where the agent has access to the use that tool, but it doesn't have access to the code of that MCP tool in a sense. s148 00:17:08.600 --> 00:17:12.240 Anything to add here, Carson and others? s149 00:17:12.240 --> 00:17:15.520 I I think this is a good opportunity to answer to Jody's question. s150 00:17:15.520 --> 00:17:19.439 A thing a skill can do is expose an MCP server. s151 00:17:19.439 --> 00:17:22.240 It lets skills and agents say, "Here's your MCP server." s152 00:17:22.240 --> 00:17:30.680 It could also just actually you can dump the tools that were in your MCP server into your skill directly and the agent can then execute them. s153 00:17:30.680 --> 00:17:34.680 So, it can actually service and create its own MCP server as part of a skill. s154 00:17:34.680 --> 00:17:38.760 This is why we get so excited about the robustness of skills versus MCP. s155 00:17:38.760 --> 00:17:42.000 It's not just self-modification, which you could replicate with MCP, right? s156 00:17:42.000 --> 00:17:48.760 MCP with memory and caching and using customization and using tool calls that are actually agents themselves. s157 00:17:48.760 --> 00:17:54.680 Those agents may even have their own skills that you can specify as part of the tool as load these skills and execute this thing, right? s158 00:17:54.680 --> 00:18:10.800 Like there's this kind of incestuous relationship that still skills live on their own as a distinct thing that can operate, template-ize code, execute code, execute MCP servers, build and create and run and then therefore add to their root context window new MCPs s159 00:18:10.800 --> 00:18:12.040 just all via the skill. s160 00:18:12.040 --> 00:18:17.040 So, it's like an entire complete package of what an agent can become. s161 00:18:17.040 --> 00:18:20.440 Essentially, Copilot could be a skill. s162 00:18:20.440 --> 00:18:29.480 So, the core idea is use skills when the hard blood hard part is just about reasoning it or thinking in the right ways. s163 00:18:29.480 --> 00:18:43.400 But, MCP solves other problem for us in terms of authentication, access, or the horsepower if you want to actually isolate the process for for some of the execution that really requires a lot of resources, s164 00:18:43.400 --> 00:18:46.960 then that's easy way to let that have its own s165 00:18:46.960 --> 00:18:49.560 server that can interoperate, right? s166 00:18:49.560 --> 00:18:53.760 Skills run with your the agent's machine. s167 00:18:53.760 --> 00:19:04.320 So, there's a little bit of a loop-de-doop, but they're still sufficiently different that MCP, you know, gets to live in its own world and be a production piece of code and skills get to be kind of viable. s168 00:19:04.320 --> 00:19:08.840 I think MCP is intelligent adapts, which it is actively working to adapt, right? s169 00:19:08.840 --> 00:19:15.120 It's the older standard and the skills we didn't know quite how powerful were we were until we had 85,000 of them out there. s170 00:19:15.120 --> 00:19:19.360 You still don't want that hosting capability, right? s171 00:19:19.360 --> 00:19:29.680 I don't have access to a GPU on my computer that is sufficient in order to do a significant operations or to do semantic search across 400 terabytes of documents. s172 00:19:29.680 --> 00:19:33.040 In those cases, I still need a robust hosted MCP server. s173 00:19:33.040 --> 00:19:41.680 The way I get my agent to use that MCP server is you can use skills to do progressive disclosure for that MCP server that then has that 500 terabyte disk s174 00:19:41.680 --> 00:19:46.360 or that access to 75 GPUs or whatever it is that that tool needs. s175 00:19:46.360 --> 00:19:51.320 So, they're still interconnected in a way that they both have their uses and are kind of inescapable. s176 00:19:51.320 --> 00:19:59.880 Use that MCP server going to access data in a restricted environment in your medical records or or whatever that your personal computer can't access. s177 00:19:59.880 --> 00:20:04.640 Does it need resources that are unachievable on the agent that you're executing on? s178 00:20:04.640 --> 00:20:09.680 It's essentially a way to execute remotely and and that still always has a benefit. s179 00:20:09.680 --> 00:20:18.480 And one last argument against MCP, which might turn out to be interesting, is the fact that it turns out that current agents doesn't need a lot of tools. s180 00:20:18.480 --> 00:20:26.760 If you go into the way Codex or cloud code is developed, you will see that there's only like a handful of tools that's being run. s181 00:20:26.760 --> 00:20:40.840 It's not like there's hundreds of tools that's being executed in a in a separate MCP server, which also proves the fact that a typical skills folders or capabilities folders with different options can replace s182 00:20:40.840 --> 00:20:45.240 MCP as long as you have a good base reasoning model. s183 00:20:46.200 --> 00:20:46.560 All right. s184 00:20:46.560 --> 00:20:48.560 Skills has two different readers. s185 00:20:48.560 --> 00:20:53.400 The first one is the front matter, the top of the skill, which is here. s186 00:20:53.400 --> 00:21:03.920 If you see an example of our one of our skills, you see that this is almost part of that MD file, but this acts like an index for that skill. s187 00:21:03.920 --> 00:21:11.160 So, at run time, this is only thing that's loaded to the agent's context, agent system prompt. s188 00:21:11.160 --> 00:21:15.280 But this one is loaded to the agent's context, which is the body of it. s189 00:21:15.280 --> 00:21:23.080 So, when I say there's two different readers, the first reader is the agent's runtime, which is the system prompt. s190 00:21:23.080 --> 00:21:26.240 So, the reader for this one isn't the context itself. s191 00:21:26.240 --> 00:21:37.760 It doesn't really burn a lot of context because it's just a small XML that has probably less than 100 tokens typically, which agent do have access to prior to the execution. s192 00:21:37.760 --> 00:21:43.360 And then second one is the markdown body, which is read by LLM if activated. s193 00:21:43.360 --> 00:21:48.040 If the LLM thinks that we need that skill, then it will be loaded. s194 00:21:48.040 --> 00:21:50.440 So, this is the first one, less than 100 tokens. s195 00:21:50.440 --> 00:21:55.560 The second one, on activation, which is typically less than 5K tokens. s196 00:21:55.560 --> 00:21:59.800 The level three is what third one is, which is scripts. s197 00:21:59.800 --> 00:22:01.960 The scripts can be in two ways. s198 00:22:01.960 --> 00:22:15.280 For cloud code, for example, they're executable in a sense that their cloud SDK or cloud code can actually execute this get deployment features.py, and then only put the output of that execution s199 00:22:15.280 --> 00:22:16.760 back to the context. s200 00:22:16.760 --> 00:22:25.880 But a lot of other examples, a lot of other platforms supports this one, which is also code, but not executable in a sense. s201 00:22:25.880 --> 00:22:30.160 Just serves as a purpose of example for the agent. s202 00:22:30.160 --> 00:22:33.320 So, three levels of managing a simple skill. s203 00:22:33.320 --> 00:22:38.920 First one is the front matter, second one is the body, and third one is extra scripts or context. s204 00:22:38.920 --> 00:22:43.440 Part four, talking a little bit about the ecosystem and what's going on around there. s205 00:22:43.440 --> 00:22:48.640 So, there is 26 plus platforms that support this, right now. s206 00:22:48.640 --> 00:22:52.840 Like cloud code, code X, code pilots, Gemini CLI, and others. s207 00:22:52.840 --> 00:23:00.640 There is probably at this point 100,000s of skills out there, and then there is marketplaces where people sell skills for money. s208 00:23:00.640 --> 00:23:05.720 Devin Jensen talked about Claude, Agent which is registry for them. s209 00:23:05.720 --> 00:23:11.120 That being said, we are also part of ecosystem and we also published our open source agent skills repository. s210 00:23:11.120 --> 00:23:16.040 This is a really good demonstration of both the power and the risks of agent skills. s211 00:23:16.040 --> 00:23:23.280 Open Agent has become the repository that has the most stars, beating Winix and React. s212 00:23:23.280 --> 00:23:32.880 And I feel like there is a lot of marvelous ways they've done the context engineering in a sense that works across different apps and chat applications. s213 00:23:32.880 --> 00:23:48.000 But I feel like probably a couple details regarding their sub agents, which kind of serves the purpose of keeping the context clean, as well as self-evolving skills, made it really impressive for whoever looked at the code. s214 00:23:48.000 --> 00:23:58.600 The fact that it can kind of self-heal based on the experience of it with skills, as well as write its own skill to extend its capabilities, in a sense, s215 00:23:58.600 --> 00:24:11.120 scary, but what made a good impression, the fact that this is just a coding agent that has access to about 10 tools, which can do anything for you, as long as you have skills s216 00:24:11.120 --> 00:24:12.600 on top of it. s217 00:24:12.600 --> 00:24:23.080 So, that kind of changes the way we think about customers or enterprise solutions in a sense that we just need to develop one good agent, which is base for everything, s218 00:24:23.080 --> 00:24:33.320 and then you can just build skills on top, which solves your domain-specific problems or whatever your customers are asking for. s219 00:24:34.080 --> 00:24:37.960 So, if Open Agent can write skills, then let it write it, right? s220 00:24:37.960 --> 00:24:43.400 But this touches the fact that typically, we need humans to write skills. s221 00:24:43.400 --> 00:24:55.080 There's a lot of research on this that's recently published, but they published that actually the LM generated skills hurts the performance of LM in a sense that it uses more tokens. s222 00:24:55.080 --> 00:25:03.897 It's it spends more time to go and actually reason up about the problem rather than helping it to be faster or to use less context in a sense. s223 00:25:03.897 --> 00:25:05.840 [clears throat] s224 00:25:05.840 --> 00:25:19.320 There's a lot of risks to consider here if if the LLM is writing and executing its own skills, then obviously there's ton of risks in terms of prompt injection because everyone is writing skills these days and then publishing it out there. s225 00:25:19.320 --> 00:25:24.760 Pretty sure you have seen on the news there's bad stuff that that happened with open cloud. s226 00:25:24.760 --> 00:25:26.320 And there is no isolation. s227 00:25:26.320 --> 00:25:37.480 One of the advantages of MCP in the sense that the isolate the process for your MCP and your agent, but everything happens on your laptop, on your agent, on your environment. s228 00:25:37.480 --> 00:25:43.520 And last one here is about the fact that these marketplaces still lack the verification control. s229 00:25:43.520 --> 00:25:53.320 Just like how NPM was scary 10 years ago in a sense that you would still check the number of stars or who developed this before you downloaded the package. s230 00:25:53.320 --> 00:25:55.720 Same for skills. s231 00:25:56.000 --> 00:25:56.840 Closing thoughts. s232 00:25:56.840 --> 00:25:58.000 Context is a budget. s233 00:25:58.000 --> 00:26:03.440 Context is almost like a limited resource that we need to carefully filter information. s234 00:26:03.440 --> 00:26:06.440 Definitely the longer context doesn't mean better. s235 00:26:06.440 --> 00:26:14.520 Every irrelevant file, every irrelevant web search, or error message really drags agent's attention and then you lose a lot of reasoning power. s236 00:26:14.520 --> 00:26:18.400 Skills are complementing MCPs at least right now. s237 00:26:18.400 --> 00:26:22.960 A skill is only as good as the human who wrote it based on our experience. s238 00:26:22.960 --> 00:26:33.120 And lastly, skills are software which can take weeks to build so that we should actually start versioning them, evaluating and testing them, and actually writing good skills. s239 00:26:33.120 --> 00:26:35.280 There's a couple resources that we've used. s240 00:26:35.280 --> 00:26:37.520 Thank you.