📱

Get Our Mobile App

Take your business learning on the go!

Download on the App StoreGet it on Google Play

Are Agent Skills the New RAG?

The AI Automators20:45

Transcription

Agent skills have exploded in popularity in an incredibly short period of time. Anthropic published their concept of agent skills as an open standard last December, and since then, it has grown rapidly.

Vercel's skills.sh directory now has over 77,000 published skills that you can use, and as they're fully open, you can integrate them into any AI agent that you want. In this video, I integrate skills and sandboxes into a custom Python and React agent, and I'll show you step by step how you can do this yourself.

In a way, the popularity of agent skills is no surprise. LLMs are general purpose by design. Even though they are trained across lots of different domains, they usually have a mixture of experts architecture, they still lack expertise in your specific company and in your company's processes. And to get any real work done, you need specialists, not generalists.

RAG solved part of this because it helps you ground an AI agent in your company's data. But this alone isn't enough. A true specialist needs procedural knowledge. It needs to understand your company's workflows and your processes. And then it needs an environment where it can actually execute these workflows and processes and take real actions.

Before skills came along, the old approaches we had were very static. It was either a case of ad hoc chats with the LLM where you continually explained what you wanted every time, which grew pretty repetitive, or you could keep adding to the system prompt of the AI, but the problem with that is it kept getting more and more bloated and the AI became more and more confused.

Or you could create specialist agents, the likes of custom GPTs in ChatGPT or projects in Claude. Here you have dedicated system prompts for different versions of the AI, and you decide which agent you want to hand the task to. And in a way, this is the best of the three approaches here. But the problem was this became quite an overhead, and then you needed to start orchestrating these specialist agents as part of teams.

At this point, we moved from prompt engineering to context engineering and started trying to create dynamic context where an agent could discover capabilities as and when it needs them. At which point Claude took this idea of dynamic context and it packaged it as agent skills. And this concept is brilliant in that it's just so simple because a skill is essentially just a folder. And this folder teaches the AI how to handle a specific task or a workflow. And the skill can be as basic or as sophisticated as you want it to be.

The key requirement is that you have your skill.md file, which essentially provides the instructions and the metadata for the AI. There are lots of example skills that you can use because they're quite popular with coding agents. There's a lot of code helper skills, best practice skills, but it isn't just limited to coding. There's copywriting skills, brand guideline skills, document generation skills, so PowerPoints, docx files, Excel sheets, image and video generators.

There is essentially infinite potential with skills because all you're doing is just describing a process, and then you connect the various systems that you want to execute that process. And unlike the specialist agents that I mentioned earlier, the beauty of skills is that you can daisy-chain them within a single conversation. So in answer to one of your questions, it can load up one skill, carry out a task or an action, and then load up another skill, carry out a task or an action, and go again. So you essentially now have a single agent that can be a specialist on lots of different things as opposed to lots of different specialist agents.

And the single most important aspect of skills is the concept of progressive disclosure because you need to protect the context window of your main agent at all costs. So you can't have a situation where the more skills you add, the more bloat there is in the system prompt. So with progressive disclosure, the skills are essentially discovered on startup, and it's only a very short snippet, the metadata of the skill itself. And then if the AI decides to actually trigger that skill, it loads up the full skill.md file. And from there, then it can trigger execution. It can load up referenced files within that folder. It can trigger MCPs, API calls, etc.

But skills only really reach their full potential when they're paired with an executable environment somewhere that the agent can create documents, run Python files, and even things like search the web, trigger APIs, and MCPs. And this is what moves an agent from just generating chat replies to actually carrying out meaningful actions and tasks. And I really do think that this packaging of dynamic context as skills is one of the biggest developments in AI over the last 12 months because with RAG, you were able to give your agent knowledge, whereas with skills, you can provide the expertise that it needs, the organizational context, the step-by-step workflows and processes because for LLMs to be reliable, you need repeatable outcomes, and that's where skills really comes into its own.

And as I mentioned, Anthropic popularized the pattern, but because they've released it as an open standard, it's not locked to their platform. It's a universal design pattern, and you can build this concept of skills into any framework, any platform, any agent, and importantly, even in fully local setups. And that's essentially what we're building today. I'm going to show you how you can leverage agent skills and code execution sandboxes in a custom AI agent so you can deliver on this idea of specialist agents that can carry out meaningful tasks.

Let's kick off with a quick demo so you can see what agent skills and sandboxes look like in a custom AI agent. I've uploaded some test data that we can play with here. Um, the first one is a number of weekly reports. So it's a customer service team. And these weekly reports talk to things like, you know, ticket volumes, top issues, escalations, etc. So let's test this out. And I'm asking, can you give me the totals of the ticket volumes and escalations over the last two months?

Now, interestingly, the first thing it did was it went to vector search, which you can see there. It then went through an SQL query, which there isn't really anything there. It did find a particular document. So, it is analyzing it. So, these are kind of these sub-agents that we have set up on the system, and it has provided a summary of the ticket volumes and escalations. And from tracking back through what it's actually done, it has only loaded up three files, three of these weekly reports, and we have eight of them. And it is providing summaries. So my assumption here is it's actually picking up snippets or chunks of information from the vector search.

So this type of monthly reporting that we're asking for, maybe we want a systematic approach. Maybe we want the AI to load up every weekly report in a sub-agent, let's say, extract out the insights, and then use a calculator tool or the coding sandbox to actually generate the accurate answers. So let's create a skill for this within our custom AI agent. So I've created this section here called skills, and it's very similar to Anthropic's version of skills. We have a skill creator, and then we can just click "Try in Chat," and that kicks off a conversation. So it loads the skill, and now we can talk through what we want.

I'd like to create a skill so that when people ask about generating monthly reports from the customer service team, we can go through a more defined process. So we have in our knowledge base a reports folder. So if someone is asking for a monthly report, we need to open up each of the weekly reports and extract out whatever insights they're looking for. It's not enough to rely on vector search. And then I'd like to use our coding sandbox to carry out any calculations that are needed. Okay.

So it's working through understanding the use case of the scope of the extraction, metrics, trends, etc. And it's asking clarifying questions, particularly around this reports folder. So, I'm just going to get it to investigate the reports folder itself because it has access to list, GP, and glob, and it's reading some of the reports just to get a handle on it. Cool. Let's generate it as a Word document. So, now it's going to create the skill. So, this is the customer service monthly report. So, the fully defined workflow is that it navigates the reports weekly folder to find the right reports for the requested month, extracts raw metrics, calculates in the Python sandbox, generates a professional Word document.

Okay, so let's go into skills then. So now you can see on the left, we have our customer service monthly report, and it has the step-by-step instructions that are required. So let's kick off with this trigger. So, "Generate a monthly report for customer service." Okay, so it's loaded the skills straight away. That's brilliant. So we need to clarify now which month we're talking about, and let's go, "Feb 2025."

Okay, so then it uses the tree tool to figure out where the reports are. It's then using our analyze document sub-agent, and then it's going to load up each one of these weekly reports, and the analyze document sub-agent has its own isolated context, so it's not going to pollute the main agent with all of these weekly reports. So it's sending in the request, "Extract ticket volume metrics, top five issues," etc. And then each of these sub-agents is pushing back out that information to the main agent. So this is already way more thorough than the previous version, which was just picking up random chunks using semantic search.

Now it aggregates all of this data in Python. So it's generating the code as you can see there, and then it's executing the code now in the sandbox or LLM sandbox that we created. And now it's loading another skill. So this is the daisy-chaining of skills. It's loading the generate Word document skill, and it's now creating code for that.

Now, let me just quickly jump into Docker here because this sandbox just ran. And there's another sandbox about to kick off. So, there's the code, there's the sandbox, we have our report, and these are all of the sandboxes that are spun up on demand. And then there's the response. And let's click into the report. And there we go. There's our February 2025 customer service monthly report. And it has all of our key metrics, the weekly breakdown with the totals that were actually calculated by Python, not by an LLM potentially hallucinating, monthly aggregation, escalations, trends, etc. And you can see the data sources as well. So, it's a version of deep research. It's within a single context window of a main agent, but it's just so much more thorough than just standard searching across a knowledge base. And that's the beauty of skills is that you can be quite deterministic about how the LLM actually approaches a task without needing to write an entire AI system to do it. So, just very powerful.

And we go back into the skills. So that's the customer service monthly report. I've created another couple of skills here. "Create PowerPoint presentations." The "Create docx files" was one that I imported from Anthropic's repository of skills. So this has lots of reference files that are included in that skills folder, as you can see there. So all of these files are available to the coding sandbox when it goes to generate the PowerPoint or the Word document in this case.

As this is part of our Cloud Code AI Agent build series, if you're building along, you can grab the planning docs for this episode in the GitHub repo linked below. All of the checkpoints in this build series are available in our community, the AI Automators. So let's dive a little bit deeper into skills and how you can set them up yourself, and as well as these coding sandboxes. How can you run these Docker containers so that you can execute arbitrary code without putting your system at risk?

So, as you saw in the demo, skills are essentially just packaged folders. The key file being the skill.md file that defines everything. But then you have these optional folders, which I'll get into, where you can drop in reference files. They could be Python files, it could be branding guidelines, PDFs, Excel sheets, it doesn't matter. Any file that you can essentially work with in an executable environment would be usable in these folders. And here's a good example to solidify the idea. So this is ideal if you need artifacts like Word documents or press releases that need to be in a specific format or a tone of voice. So within this skill, there's an examples folder, and you can see there's a company newsletter example, an FAQ answers example, general comms, and the skill should be triggered when the LLM is asked to write those types of communications, and it gives the examples, and then there's the step-by-step instruction on how to execute the skill. So, pretty straightforward.

So how do they work then? The first section is this idea of discovery because an agent might have 10, 20, 50, 100 different skills, and it needs to know when to actually trigger those skills. And the key thing is progressive disclosure. So we're only loading a minimal amount of data in this discovery phase. And it's, as you saw there, it's this section at the top, this front-loaded metadata of the skill. That's what's injected into context, and that's what it looks like. So within a system prompt, you have your available skills. Each one of them is named, and the description is extracted from that metadata, and there's the location to the full skill.md file to load it up if needed.

And then once you have a match, once the AI wants to load up a skill, it activates it, loads up the full skill markdown file, and then it knows what step-by-step actions it needs to take to carry out the task. And again, we're still progressively disclosing. So, there could be 20 referenced files in the skills folder. They're not loaded up yet. At this point, it's only the skill markdown file. And then, depending on what step-by-step instructions are needed, it will load up the files as needed as well. And it could also pass things off to sub-agents if it needs to protect its own context window, as you saw earlier in my demo with that analyze document sub-agent. And as well as loading up documents, it can also protect itself by actually delegating the task of loading the document to the coding sandbox if there isn't any reasoning needed over the document itself. So again, that's another great trick to protect your context window.

So here's another example, the PDF processing skill. It's a really lean metadata at the start. That's what's [snorts] injected into context all the time. And then if the full skill is loaded, you get the step-by-step. And one of those steps is to run a specific extraction script, which might be listed in the scripts folder. So you have these optional directories then, scripts being one of them, references, assets, and these are really just guidance because you can have any number of directories that you want in a skills folder. The key thing is the skills.md file needs to just explain the folder structure. And it is this simplicity and flexibility which makes skills so powerful.

So common skills patterns then. The first one is sequential workflow orchestration. So in this example, you might have a skill where you want to onboard new customers, and it's a four-step process. Number one, you create an account. So you call a specific MCP tool, "create customer." You pass certain parameters, and then based off the back of that, you trigger step two, which is "set up payment," again via MCP. Then you might set up a subscription. Then you might send a welcome email. And in a way, skills is a way to steer an LLM through natural language. And there are similarities to actually a codified version. But the beauty is, if there's a problem at step two, the LLM is able to think on its feet. It could retry. It could ping you on Slack. So you have a probabilistic system that might actually be able to work its way around an issue.

The second pattern is multi-tool coordination. So if you have lots of MCPs and APIs that you want the agent to be able to access, you might want to coordinate and orchestrate the triggering of different APIs depending on the task. So here, for example, the first phase might be to export the design using Figma MCP. Then you want to upload the assets to Drive, create the tasks on Linear, notify everyone on Slack. Again, this could be a hard-coded agentic style workflow, or you can just have it as a natural language skill and let the intelligence of the model actually work its way through it.

Iterative refinement is another one. So, a lot of the time, the first draft from an AI is not good enough. So, you may need to iterate on the output to get it to a point where you're happy with it. And that could be a case of triggering validation scripts, checking for factual errors, whatever it is. So in this case, this iterative report creation, there's an initial draft created, then there's a validation script for quality checks, a loop to refine the outputs, and at the end, the final version is generated and saved to a Drive, let's say.

Context-aware tool selection is another one. So if you had a smart file storage skill, you could bake in your business process logic, whatever the decision tree is on where files get uploaded to depending on file size or permissions or who's uploading it, whatever it is. And again, all of this could be codified, but in a way, skills is allowing you to codify it just in a natural language interface. And the final one proves that with the domain-specific intelligence example for payment processing, you might have a step-by-step process that includes switches or if-else's that bake in audit trails and compliance checks. So this type of example shows how you can empower lots of members of a team who may not be technically proficient enough to create, you know, sophisticated workflows, but they are actually able to just document what the procedure is in the company.

But of course, it's not just as simple as that. You do need to test and validate and verify that the skill is being triggered and is actually working correctly. So if you're looking to implement agent skills in your own custom AI agent, definitely go to agentskills.io. Because this is the open standard that everyone is working towards, and it's a lot of what I've already talked to to date. The idea of what skills are, the skills.md specification, the YAML front matter metadata that we discussed. It also lists various optional fields that you can have within that, and it talks about the progressive disclosure aspects, as well as how to reference files within the actual skills folder.

And there are two main approaches to integrating skills into your custom AI agent. There's a file system-based way of doing it, or you can have it as tool-based agents as well. But because this is custom development, you can align to this as much as you want. But the benefit of fully aligning to it is that within your own skills interface, you can have an import from file and you can allow the actual upload of skills created on other platforms. This docx.zip zip file was one that I downloaded from Anthropic's repository on GitHub. So you do have interoperability if you actually align to the standard.

And definitely one of the most important aspects is actually to bake in the skill creator. So Anthropic have their own skill creator that you can access via Claude, and there's the full skill.md file. So I've used that as inspiration for my own skill creator to align with my system because if you're creating these skill.md files yourself, you might not be specific enough. So the skill is actually descriptive enough that it's triggered by the LLM. So this skill creator helper is very useful in that regard.

So once you have a version of skills built on your system, you're going to need a code execution sandbox to make the most use of them. I checked out lots of different sandbox options and repos on GitHub. The one I landed on was LLM Sandbox. It's essentially a lightweight and portable sandbox environment designed to run LLM-generated code in a safe and isolated way. Now, I know Docker containers aren't as secure as dedicated virtual machines, and the reason for that is they share the same kernel as the main host. So there is essentially less isolation between a Docker container and your own system. So if you are really looking to harden these sandboxes, I'd recommend using something like Gvisor, which sits between the sandbox container and your host kernel. That way, if anything tries to escape from the container, you're protected by that security layer.

LLM Sandbox supports different container backends. I'm using Docker here, as you saw in the demo, but you can use Podman or Kubernetes if you want. Lots of different programming languages are supported as containers. I limited my implementation to Python, but there are other runtimes that you can actually work with. And what's great about this library is you can specify your own custom images. So, my Python sandbox image has all of the libraries that I need pre-installed. And you also can pre-warm containers so that there's less latency and lag when you spin one up from the first time. There's full installation instructions on the repo here, so I'll leave a link for this in the description below.

If you're building AI agents that are connected to cloud LLMs, I highly recommend that you fully redact or anonymize any sensitive information going to those companies. This was a topic I jumped into in depth last week, so if you're interested in watching, check out this video here. Thanks so much for watching, and I'll see you in the next.