Zaals first stream!

0:00skills. In this talk, we’ll show you why we stopped building agents and started building skills instead. A lot of things have changed since our last talk. MCP became the standard for agent connectivity. Claude Code, our first coding agent, launched to the world. And our Claude Agent SDK now provides production-ready agent building blocks. We have a more mature ecosystem, and we’re moving towards a new paradigm for agents. That paradigm is a tighter coupling between the model and the runtime environment. Put simply, we think code is all we need. We used to think agents in different domains would look very different. Each one would need its own tools and

0:29scaffolding. And that means we’ll have a separate agent for each use case for each domain. Well, customization is still important for each domain. The agent underneath is actually more universal than we thought. What we realized is that code is not just a use case, but a universal interface to the digital world. After we built Claude Code, we realized that Claude Code is actually a general-purpose agent. Think about generating a financial report. The model can call the API to pull in data and do research. It can organize that data in the file system. It can analyze it with Python and then synthesize the insight in old file

0:53format, all through code. The core scaffolding has suddenly become as thin as just bash and file system. Which is great and really scalable, but we very quickly ran into a different problem. And that problem is domain expertise. Who do you want doing your taxes? Is it going to be Mahesh, the 300 IQ mathematical genius, or is it Barry, an experienced tax professional? Right? I would pick Barry every time. I don’t want Mahesh to figure out the 2025 tax code from first principles. I need consistent execution from a domain expert. Agents today are a lot like Mahesh. They’re brilliant, but they lack expertise. They can do No more slow. They can do

1:22amazing things when you really put in effort and get proper guidance, but they’re often missing the important context up front. They can’t really absorb your expertise super well, and they don’t learn over time. That’s why we created agent skills. Skills are organized collections of files that package composable procedural knowledge for agents. In other words, they’re folders. This simplicity is deliberate. We want something that anyone, human or agent, can create and use as long as they have a computer. These also work with what you already have. You can version them in Git. You can throw them in Google Drive. And you can zip them up and share it with your

1:48team. We have used files for as a primitive for decades, and we like them. So, why change now? Because of that, skills can also include a lot of scripts as tools. Traditional tools have pretty obvious problems. Some tools have poorly written instructions that are pretty ambiguous. And when the model is struggling, you can’t really make a change to the tools, so it’s just kind of stuck with a cold start problem. And they always live in the context window. Code solves some of these issues. It’s self-documenting. It is modifiable. And it can live in the file system until they’re really needed and used. Here’s an example of a script inside of

2:14a skill. We kept seeing Claude write the same Python script over and over again to apply styling to slides. So, we just asked Claude to save it inside of the skill as a tool for his version of for his future self. Now, he can just run the script, and that makes everything a lot more consistent and a lot more efficient. At this point, skills can contain a lot of information, and we want to protect the context window so that we can fit in hundreds of skills and make them truly composable. That’s why skills are progressively disclosed. At runtime, only this metadata is shown to the model just to indicate that it

2:37has the skill. When agent needs to use a skill, it can read in the rest of the skill.md, which contains the core instruction and directory for the rest of the folder. Everything else inside of the skill as a tool for his version of for his future self. Now, he can just run the script, and that makes everything a lot more consistent and a lot more efficient. At this point, skills can contain a lot of information, and we want to protect the context window so that we can fit in hundreds of skills and make them truly composable. That’s why skills are progressively disclosed. At runtime, only this metadata is shown

3:05to the model just to indicate that it has the skill. When agent needs to use a skill, it can read in the rest of the skill.md, which contains the core instruction and directory for the rest of the folder. Everything else is just organized for ease of access. So, that’s all skills are. They’re organized folders with scripts as tools. Since our launch 5 weeks ago, this very simple design has translated into a very quickly growing ecosystem of thousands of skills. And we’ve seen this be split across a couple of different types of skills. There are foundational skills, third-party skills created by partners in the ecosystem, and skills built

3:32within an enterprise and within teams. To start, foundational skills are those that give agents new general capabilities or domain-specific capabilities that they didn’t have before. We ourselves, with our launch, built document skills that give Claude the ability to create and edit professional-quality office documents. We’re also really excited to see people Cadence build scientific research skills that give Claude new capabilities like EHR data analysis and using common Python bioinformatics libraries better than they could before. We’re also seeing partners in the ecosystem builds that help Claude better with their own products. Browserbase is a pretty good example of this. They built a skill for their open-source browser automation tooling,

4:07Stagehand. And now Claude, equipped with this skill and with Stagehand, can now go navigate the web and use a browser effectively to get work done. And Notion launched a bunch of skills that help Claude better understand your Notion workspace and do deep research over your entire workspace. And I think where I’ve seen the most excitement and traction with skills is within large enterprises. These are company- and team-specific skills built for an organization. We’ve been talking to Fortune 100s that are using skills as a way to teach agents about their organizational best practices and the weird and unique ways that they use this bespoke internal software.

4:36We’re also talking to really large developer productivity teams. thousands of developers in an organization that are using skills like Claude Code and teach them about code’s best practices and other ways that they want their developers to work internally. So, all of these different types of skills are created and consumed by different people inside of an organization or in the world, but what they have in common is anyone can create them, and they give agents new capabilities that they didn’t have before. So, as the ecosystem has grown, we’re able to observe a couple of interesting trends. First, skills are starting to get more complex. The most basic skill today can still be a

5:08skill.md file with some prompt with really basic instructions. But we’re starting to see skills that package subtools, binaries, full code scripts, assets, and a lot more. And a lot of the skills that are being built today might take minutes or hours to build and put into an agent. But we think that increasingly, much like a lot of the software we use today, these skills might take weeks or months to build and be maintained. We’re also seeing that this ecosystem of skills is complementing the existing ecosystem of MCP servers that was built up over the course of this year. Developers are using and building skills that orchestrate workflows of multiple

5:36MCP tools stitched together to do more complex things with external data and connectivity. And in these cases, MCP MCP is providing the connection to the outside world, while skills are providing the expertise. And finally, and I think most excitingly for me personally, is we’re seeing skills that are being built by people that aren’t technical. These are people in functions like finance, recruiting, accounting, legal, and a lot more. Um and I think this is pretty early validation of our initial idea that skills help people that aren’t doing coding work extend the general agents, and they make these agents more accessible for the day-to-day of what these people are working on.

6:06So, tying this all together, let’s talk about how these all fit into this emerging architecture of general agents. First, we think this architecture is built on a couple of things. The first is this agent loop that helps manage the internal internal loop. in and out. And this is coupled with a runtime environment that has a file system and the ability to read and write code. This agent, as any of us have done throughout this year, can be connected to MCP servers, and these are tools and data from the outside world agent or relevant and Now, we hundreds of skills that only come into play at runtime when deciding to work on

6:38a particular task. Today, giving an agent a new capability in a new domain might just involve equipping it with the right set of MCP servers and the right library of skills. And this emerging pattern of an agent with an MCP server and a set of skills is something that’s already helping us at Anthropic deploy Claude to new verticals. Just after we launched skills 5 weeks ago, we immediately launched new offerings in financial and same with a set of MCP servers scripts for professionals in each of these domains. We’re also starting to think about some of the other open questions and areas that we want to focus on for how skills

7:09evolve in the future. As they start to become more complex, we really want to support developers, enterprises, and other skill builders by starting to treat skills like we treat software. This means exploring, testing, and evaluation. Better tooling to make sure that these agents are loaded of an agent with a couple of these skills to make sure that they’re on par with what the agent is supposed to We’d also like to focus on versioning. As a skill evolves and the resulting agent behavior evolves, we want this to be uh clearly tracked and to have a clear lineage over time. We’d also like to explore skills that

7:44can explicitly depend on and refer to either other skills, MCP servers, and dependencies and packages within the agent’s environment. We think that this is going to make agents a lot more predictable in different runtime environments, and the composability of multiple skills together will help agents like Claude elicit even more complex and relevant behavior from these agents. Overall, all of these set of things should hopefully make skills easier to build and easier to integrate into agent products, even those besides Claude. Finally, a huge part of the value of skills, we think, is going to come from sharing and distribution. Barry and I think a lot about the future

8:12of companies that are deploying these agents at scale. And the vision that excites us most is one of a collecting and collective and evolving knowledge base of capabilities that’s curated by people and can be used provision. They provide for your agent