Good morning and thank you for having us again. Last time we were here, we were still figuring out what an agent even is. Today, many of us are using agents on a daily basis, but we still notice gaps. Agents have intelligence and capabilities, but not always the expertise that we need for real work. I'm Barry, and this is Mahesh. We created agent skills. 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. Cloud Code, our first coding agent, launched to the world, and our Cloud Agent SDK now provides a production-ready agent out of the box. We have a more mature ecosystem and are moving towards a new paradigm for agents: a tighter coupling between the model and a runtime environment. Put simply, we think code is all we need.

We used to think agents in different domains would look very different, each needing its own tools and scaffolding, meaning a separate agent for each use case and domain. While customization is still important for each domain, the underlying agent is actually more universal than we thought. What we realized is that code is not just a use case, but the universal interface to the digital world. After we built Cloud Code, we realized that Cloud 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, analyze it with Python, and then synthesize the insights in an old file format—all through code. The core scaffolding can suddenly become as thin as just Bash and a file system, which is great and really scalable. But we very quickly run into a different problem: domain expertise.

Who do you want doing your taxes? Is it Mahesh, the 300 IQ mathematical genius, or Barry, an experienced tax professional? 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 amazing things when you really put in the effort and give proper guidance, but they're often missing important upfront context. 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, throw them in Google Drive, and zip them up to share with your team. We have used files as a primitive for decades, and we like them, so why change now?

Because of this, skills can also include many scripts as tools. Traditional tools have pretty obvious problems: some have poorly written or ambiguous instructions, and when the model struggles, it can't really change the tool. So, it's stuck with a 'cold start' problem, and they always live in the context window. Code solves some of these issues: it's self-documenting, modifiable, and can live in the file system until truly needed. Here's an example of a script inside a skill: we kept seeing Claude write the same Python script repeatedly to apply styling to slides. So, we just asked Claude to save it inside the skill as a tool for its future self. Now, we can just run the script, making everything much more consistent and efficient.

At this point, skills can contain a lot of information, and we want to protect the context window so that we can fit hundreds of skills and make them truly composable. That's why skills are progressively disclosed. At runtime, only the metadata is shown to the model, just to indicate that it has the skill. When an agent needs to use a skill, it can read the rest of the `skill.md` file, which contains the core instructions and directory for the rest of the folder. Everything else is just organized for ease of access. So, that's all skills are: organized folders with scripts as tools.

Since our launch five weeks ago, this very simple design has translated into a quickly growing ecosystem of thousands of skills. We've seen these split across a couple of different types: foundational skills, third-party skills created by partners, and skills built within an enterprise and within teams. To start, foundational skills give agents new general or domain-specific capabilities they didn't have before. For example, we ourselves built document skills that give Claude the ability to create and edit professional-quality office documents. We're also excited to see companies like Cadence build scientific research skills that give Claude new capabilities like EHR data analysis and using common Python bioinformatics libraries better than before.

We've also seen partners in the ecosystem build skills that help Claude better interact with their own software and products. Browserbase is a good example; they built a skill for their open-source browser automation tooling, Stagehand. Now, Claude, equipped with this skill and Stagehand, can navigate the web and use a browser more effectively. And Notion launched a bunch of skills that help Claude better understand your Notion workspace and do deep research across it.

I think where I've seen the most excitement and traction 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 to teach agents about their organizational best practices and the unique ways they use bespoke internal software. We're also talking to very large developer productivity teams—teams serving thousands or tens of thousands of developers—who are using skills to deploy agents like Cloud Code and teach them about code style best practices and other internal development workflows.

All these different types of skills are created and consumed by various people within an organization or globally. What they have in common is that anyone can create them, and they give agents new capabilities they didn't have before. As this ecosystem has grown, we've observed a couple of interesting trends. First, skills are becoming more complex. The most basic skill today can still be a `skill.md` Markdown file with prompts and basic instructions, but we're starting to see skills that package software, executables, binaries, files, code, scripts, assets, and more. Many skills built today might take minutes or hours to create and integrate into an agent, but we believe that, increasingly, much like a lot of software we use today, these skills might take weeks or months to build and maintain.

We're also seeing that this ecosystem of skills complements the existing ecosystem of MCP servers built over this year. Developers are using and building skills that orchestrate workflows of multiple MCP tools, stitched together to perform more complex tasks with external data and connectivity. In these cases, MCP provides the connection to the outside world, while skills provide the expertise. Finally, and I think most excitingly for me personally, we're seeing skills being built by non-technical people in functions like finance, recruiting, accounting, legal, and more. I believe this is early validation of our initial idea that skills help non-coding professionals extend these general agents, making them more accessible for their day-to-day work.

Tying this all together, let's discuss how these fit into the emerging architecture of general agents. First, we think this architecture is converging on a couple of things: an agent loop that manages the model's internal context and controls what tokens go in and out, coupled with a runtime environment that provides the agent with a file system and the ability to read and write code. This agent, as many of us have done this year, can be connected to MCP servers—tools and data from the outside world that make the agent more relevant and effective.

And now we can give the same agent a library of hundreds or thousands of skills that it can decide to pull into context only at runtime when it's deciding to work on a 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 Enthropic deploy Claude to new verticals. Just after we launched skills 5 weeks ago, we immediately launched new offerings in financial services and life sciences. And each of these came with a set of MCP servers and a set of skills that immediately make Claude more effective 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 evolve 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 loading and triggering skills at the right time and for the right task, and tooling to help measure the output quality of an agent equipped with the skill to make sure that's on par with what the agent is supposed to be doing.

We'd also like to focus on versioning; as a skill evolves and the resulting agent behavior evolves, we want this to be clearly tracked and to have a clear lineage over time. Finally, we'd like to explore skills that can explicitly depend on and refer to other skills, MCP servers, and dependencies and packages within the agent's environment. We think this will make agents much 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. Overall, these efforts should hopefully make skills easier to build and integrate into agent products, even those besides Claude.

Finally, we believe a huge part of the value of skills will come from sharing and distribution. Barry and I often think about the future of companies deploying these agents at scale. The vision that excites us most is a collective and evolving knowledge base of capabilities, curated by people and agents within an organization. We think skills are a big step towards this vision. They provide the procedural knowledge for your agents to do useful things. As you interact with an agent and give it feedback and more institutional knowledge, it starts to get better, and all agents within your team and organization improve. When someone joins your team and uses Claude for the first time, it already knows what your team cares about, your day-to-day operations, and how to be most effective for your work.

And as this grows and the ecosystem develops further, this compounding value will extend beyond your organization into the broader community. Just as an MCP server built by someone else globally makes your agent more useful, a skill built by someone else in the community will help make your own agents more capable, reliable, and useful. This vision of an evolving knowledge base becomes even more powerful when Claude starts to create these skills itself. We designed skills specifically as concrete steps towards continuous learning. When you first start using Claude, this standardized format provides a very important guarantee: anything Claude writes down can be efficiently used by a future version of itself. This makes the learning truly transferable.

As you build up the context, skills make the concept of memory more tangible. They don't capture everything or every type of information, just procedural knowledge that Claude can use on specific tasks. When you've worked with Claude for a while, the flexibility of skills matters even more. Claude can acquire new capabilities instantly, evolve them as needed, and drop obsolete ones. This highlights what we've always known: the power of in-context learning makes this much more cost-effective for information that changes daily. Our goal is that Claude on day 30 of working with you will be much better than Claude on day one. Claude can already create skills for you today using our skill creator skill, and we will continue pushing in that direction.

We'll conclude by comparing the agent stack to what we've already seen in computing. In a rough analogy, models are like processors: both require massive investment and contain immense potential, but are only so useful by themselves. Then we started building operating systems (OS). The OS made processors far more valuable by orchestrating the processes, resources, and data around them. In AI, we believe that the agent runtime is starting to play this role. We're all trying to build the cleanest, most efficient, and most scalable abstractions to get the right tokens in and out of the model.

But once we have a platform, the real value comes from applications. A few companies build processors and operating systems, but millions of developers like us have built software that encoded domain expertise and our unique points of view. We hope that skills can help us open up this layer for everyone. This is where we get creative and solve concrete problems for ourselves, for each other, and for the world, simply by putting stuff in a folder. So, skills are just the starting point.

To close out, we think we're now converging on this general architecture for general agents. We've created skills as a new paradigm for shipping and sharing new capabilities. Therefore, we think it's time to stop rebuilding agents and start building skills instead. If you're excited about this, come work with us and start building some skills today. Thank you.