What Anthropic's Own Engineers Build Instead of AI Agents
Anthropic's agent-skills team explains why they stopped building a new agent for every job, and the four habits that make one general-purpose agent actually reliable.
Posted
today
Duration
Format
Tutorial
educational
Views
41.8K
799 likes
57 · 43
Big Idea
The argument in one line.
Anthropic's own agent-skills team stopped rebuilding a separate agent for every task and instead layers reusable, single-purpose skills onto one general-purpose agent, made reliable by four habits: reusing proven code, writing precise trigger descriptions, turning corrections into durable rules, and verifying output before it reaches the user.
Who This Is For
Read if. Skip if.
READ IF YOU ARE…
You already use Claude Code or a similar agent and keep watching it rewrite the same script or process from scratch every session.
You've built more than one custom skill, GPT, or agent and they sometimes trigger on the wrong request.
You want your AI workflows to actually get better run over run instead of repeating the same mistake.
SKIP IF…
You've never used Claude Code, Agent Skills, or a comparable agent framework — the concepts here assume that context.
You're looking for one specific skill to copy rather than the underlying design principles.
TL;DR
The full version, fast.
Anthropic's agent-skills creators, Barry Zhang and Mahesh Murag, say they stopped building a new agent for every job because the underlying agent had become general-purpose enough on its own. Now the model is the processor, the agent runtime is the operating system, and skills are the apps that give it specific capabilities. Four habits make that setup work: save proven scripts inside a skill instead of making Claude rewrite them every run (DRY), write a precise trigger description so Claude loads the right skill via progressive disclosure, turn every correction into a durable rule or reference file instead of losing it when the chat closes, and bake verification into the skill so your first look isn't the agent's first draft.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Cold open: Anthropic's Barry Zhang and Mahesh Murag stopped rebuilding a separate agent per job because the underlying agent got general-purpose enough to handle it with a skill attached.
00:23 – 01:26
02 · Why your phone?
The phone analogy: model = processor, agent runtime = operating system, skills = apps. A skill packages the process, context, scripts, and examples for one job.
01:26 – 03:03
03 · Stop repeating this
Habit #1 — DRY. Anthropic's team stopped Claude from rewriting the same slide-styling script every run by saving the proven script inside the skill and pointing future runs at it.
03:03 – 04:56
04 · Claude's guessing game
Habit #2 — picking the right skill via progressive disclosure. Claude reads only name+description until a prompt matches; vague or overlapping descriptions make it guess wrong.
04:56 – 06:14
05 · You lost it
Habit #3 — continuous learning. An uncaptured correction is a lesson thrown away; route fixes into SKILL.md (process), a reference file (voice/brand), or a hard rule (recurring mistakes).
06:14 – 06:43
06 · Model proof?
No skill forces a weaker model to match a stronger one. Because Agent Skills are portable, test important skills on a second compatible agent harness to expose hidden assumptions.
06:43 – 09:01
07 · 70% problem
Habit #4, the most important — an agent's first output is an internal draft, roughly 70-80% done. Bake verification (render-and-inspect, source-matching, persona review) into the skill itself.
09:01 – 09:47
08 · What now?
Recap of the four habits, then a pitch for Nate's paid AI Operating System course and his free community.
Atomic Insights
Lines worth screenshotting.
Anthropic's own agent-skills team stopped building a separate agent for every task because the general-purpose agent underneath had gotten capable enough to handle it with the right skill attached.
In the model-agent-skill stack, the model is the processor, the agent runtime is the operating system, and skills are the apps — you rarely touch the first two, but you fully control the third.
Anthropic's team watched Claude rewrite the same Python script from scratch every time it styled a slide deck, burning tokens and producing inconsistent results run to run.
The fix follows the decades-old DRY principle: once a script works, save it inside the skill as a 'tool for its future self' instead of asking Claude to reinvent it.
Claude loads skills through progressive disclosure: it starts with only the name and description (the YAML front matter) and reads the full SKILL.md only when a prompt matches.
A skill Claude can't find is a skill you don't have — vague or overlapping descriptions like 'help with content' cause Claude to guess wrong between competing skills.
A strong skill description names the exact output and the exact trigger phrase, for example 'creates LinkedIn carousels... use this when the user asks for a carousel.'
Test a skill's description with three prompts: an obvious match, a differently worded match, and an unrelated request that should not trigger it.
Every uncorrected mistake you wave off with 'fix it' gets thrown away the moment you close the chat, because nothing captures what actually went wrong.
Anthropic designed skills for continuous learning: a wrong process gets fixed in SKILL.md, a missing voice or brand gets its own reference file, and a repeated mistake gets a hard rule.
No skill can force a weaker model to match a stronger one's output — Anthropic calls this the limit of 'model proof,' since different models interpret the same skill differently.
Because Agent Skills are an open format, the same skill folder should be tested across multiple compatible agent harnesses to expose hidden model-specific assumptions.
AI output that looks finished is usually only 70-80% done — the remaining 20-30% is verification work most people do manually instead of building into the skill.
Verification has to produce evidence outside the model's own opinion of its work: a rendered screenshot, a matched source, a test result, or feedback from a different persona agent.
The goal of baked-in verification is that your first look at the output is the agent's fourth or fifth look, not its first draft.
Takeaway
Four Habits That Make Reusable AI Skills Actually Work
SKILLS PLAYBOOK
Reusable agent skills only hold up if you save proven scripts instead of regenerating them, write descriptions Claude can actually match, turn every correction into a durable rule, and verify the output before you ever see it.
02Why your phone?
Treat the model as the processor, the agent runtime as the operating system, and skills as the apps — you rarely need to touch the first two.
A general-purpose agent can already read files, write code, and call tools; a skill just points that same agent at one job's process, context, scripts, and examples.
03Stop repeating this
If Claude keeps rewriting the same script or process from scratch, save the working version inside the skill instead of letting it regenerate one every run.
Rebuilt-from-scratch outputs are both wasteful in tokens and inconsistent run to run — a saved script fixes both problems at once.
After a session where Claude produces code you like, have it save that script into the skill's own folder and update SKILL.md to call it going forward, then rerun and verify.
04Claude's guessing game
Claude loads only a skill's name and description at startup and reads the full instructions only once a prompt matches — vague descriptions make it guess wrong between skills.
Write descriptions the way a real person would phrase the request, naming the exact output and the exact trigger phrase that should fire it.
Test any skill description with three prompts: an obvious match, a differently worded match, and an unrelated request that should not fire it at all.
05You lost it
A correction you give Claude and then abandon at the end of a chat is a lesson thrown away — the next session starts from the same mistake.
Route each type of fix to the right place: a wrong process goes into the instructions file, a missing voice or brand goes into a reference file, and a repeated mistake gets a hard rule.
When something breaks, have Claude show its work and explain why it missed the mark before you hand it the fix — that explanation is what actually gets captured into the skill.
06Model proof?
No skill can force a weaker model to perform exactly like a stronger one — different models still interpret the same instructions differently.
Because the skill format is open and portable, test an important skill on a second compatible agent to expose hidden model-specific assumptions.
0770% problem
Treat an agent's first output as an internal draft, not a finished deliverable — it's typically only 70-80% done.
Bake the checks you'd do by hand into the skill itself: render-and-inspect for visual output, source-matching for factual claims, persona review for anything persuasive.
Verification needs evidence outside the model's own opinion of its work — a screenshot, a test result, a matched source, or another persona's feedback, not the model just saying it looks good.
Glossary
Terms worth knowing.
Agent Skills
Anthropic's open format for packaging a reusable process, scripts, and examples that a general-purpose agent loads only when a task matches its description.
Progressive disclosure
Loading only a skill's name and description into context at startup, and reading its full instructions only once a specific task actually needs them.
SKILL.md
The single file at the root of a skill folder that holds its YAML trigger metadata (name, description) plus the full step-by-step instructions.
DRY (Don't Repeat Yourself)
A long-standing coding principle: solve a problem once, save the solution, and reuse it instead of regenerating it from scratch every time.
Context rot
Degraded output quality that comes from stuffing an agent's working context with instructions and examples it doesn't need for the current task.
Model proof
The idea that a skill's process can transfer between models, but a weaker model still won't perform identically to a stronger one running the same skill.
Resources
Things they pointed at.
00:45toolClaude Code
09:15productNate Herk's AI Operating System course
“So Anthropic Engineers just said that they stopped building agents and they started building something completely different.”
flat, specific claim that reframes the whole agents conversation in one sentence→ TikTok hook↗ Tweet quote
01:38
“they had claude save that script inside the skill as, in their own words, a tool for its future self”
quotable metaphor for reusable code inside a skill→ IG reel cold open↗ Tweet quote
05:00
“a skill that cloud can't find is basically a skill that you don't have”
tight, aphoristic line about description quality→ newsletter pull-quote↗ Tweet quote
06:50
“A skill shouldn't hand you its first attempt and call the job done.”
clear thesis statement for the most important of the four habits→ TikTok hook↗ Tweet quote
09:30
“Your first look should not be the agent's first look. It should be the agent's, you know, fourth or fifth or maybe even sixth look.”
memorable closing line that reframes verification as the agent's job, not yours→ newsletter pull-quote↗ Tweet quote
The Script
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
17px
metaphoranalogy
So Anthropic Engineers just said that they stopped building agents and they started building something completely different. So if you're still focused on building agents, you're probably wasting hours on something that'll never work the way that you actually want it to. But if you focus on what these engineers are actually building, you'll have a system that improves on its own.
So in this video, I'm going to show you what they said to build instead and the four things that actually make it work so that you can start getting the same quality results that Anthropic Engineers are getting. So let's get into it. All right, so Anthropic isn't saying that agents are dead.
Barry Zhang and Mahesh Murag, the two people who created agent skills at Anthropic, said that they basically stopped rebuilding a separate agent for every single job because the agent underneath had become way more general purpose than they expected. So real quick, the easiest way to understand this is to look at your phone.
Your phone has a processor an operating system, and then all the apps that you actually use every day. And a few massive companies build the processor and the operating system.
You probably aren't changing either one of those things, but you can choose the apps. And each app gives that same phone a very specific capability. And the whole AI stack is starting to look pretty similar to that.
The model is kind of like the processor. The agent runtime is like the operating system. And then skills are the apps.
So Cloud Code can already read files, write code, call tools, and work through a task. You don't need to necessarily rebuild all of that every time that you want help. creating a presentation or researching a company or writing a LinkedIn post or doing whatever kind of things you need to do like that.
You give the same general purpose agent a skill that contains the process, the context, the scripts, and the examples for that specific job. So now let me talk about the four practical ways to make those skills work better. So the first one is simple.
Stop making Claude solve the same technical problem over... and over anthropics team kept watching claude write basically the exact same python script every time it needed to apply styling to a slide deck it would spend tons of tokens just recreating the code that has already been written and because it was rebuilding it from scratch the result could change from one run to the next so it wasn't super consistent so what they did is they had claude save that script inside the skill as in their own words a tool for its future self so now the next time it needs to style a presentation it can just run the version that already was proven to work and developers have followed this idea forever it's called dry or dry which stands for don't repeat yourself.
If you solve a problem in code, you can just save the solution and reuse it instead of rewriting the code every single time. And you can do the exact same thing with Claude. I've got skills in my own AI operating system that use the same renderers, the same templates, scripts, and stuff like that every time.
My carousel workflow doesn't ask Claude to reinvent how a slide gets rendered on every run. The skill just points it to the files that already work and then Claude can just focus on the new content like literally just changing the text. So the next time Claude writes a script that gives you a result that you really like, don't leave that code trapped inside the chat just to get lost.
later when you start up new sessions tell it something like save the script you just used inside the skills script folder update the skill .md so that future runs execute that file instead of trying to rewrite it again then i want you to run the skill again and verify the results and real quick you still obviously need to test it you run the same type of task twice you compare the important parts and make sure the skill is actually calling the saved file the surrounding ai output may still vary a little bit but you've replaced one fresh guess with a proven piece of code so moral of the story don't pay claude to rediscover a solution that you already have But once you start building a bunch of these skills, Claude needs to know which one belongs to the job in front of it.
So let's move on to number two. So think about a mechanic for a second. A mechanic might own hundreds of tools, but he doesn't dump every single one onto the bench before he starts changing a tire.
He basically just identifies the job and grabs the few tools that he needs and leaves everything else inside the toolbox. And skills work in a very similar way because of something that Anthropic calls progressive disclosure. So when Claude starts, it doesn't read the full instructions and all the examples and all the scripts from every single skill you have.
would be a huge waste of time and tokens. It starts with the name and the description of each skill, and this is called the YAML front matter. Then when your specific prompt matches a description of a skill, that's when it reads the full skill .md file, and any larger references or scripts can just stay in the folder until the task actually needs them.
Anthropic describes this as letting Claude load information only as needed. That basically keeps irrelevant instructions out of the working context, which helps you avoid the bloat and confusion, which sometimes gets called context rot. But this depends on your description being really, really clear.
If one skill says help with content, and another one says create marketing assets, then Claude's basically guessing because those descriptions sort of overlap and they don't tell the agent when either of those skills should actually run. So a stronger description might say something like, this skill creates LinkedIn carousels from a topic, from a transcript or an outline.
Use this when the user asks for a carousel, carousel slides or a LinkedIn document post. Now Claude knows what the skill does and exactly when to use it. So just keep each skill focused on one specific job, put the words a real person would use inside the description and make sure two skills aren't competing for the same request.
actually have cloud code audit this for you just say hey review all my skill descriptions for each one tell me what it does when it should trigger and where it overlaps with any other skills rewrite only descriptions that are ambiguous and then you can test these three things the first one is an obvious request that should trigger it the second one is a differently worded request that still should trigger it and the third one is an unrelated request that definitely should not trigger it and just remember that a skill that cloud can't find is basically a skill that you don't have so finding the correct skill handles today's tasks but the next step is actually making sure that the skill gets better every single time you use it.
So number three, every time you correct Claude and then you close the chat, there's a pretty good chance you just threw that lesson away. Maybe it used the wrong tone or it skipped a validation step, or maybe it formatted the final output in a way that you don't want to see again. And if all you say to Claude is fix it, then it probably will fix it, but the process stays broken.
And this is something I've had to work through inside my own AI operating system. If an agent tells me it can't find a file that I know exists, I don't just hand it the path and keep moving. I ask it to backtrack.
I basically ask it to show me its work, show me where it's searched, figure out why it missed the file, and then update the routing or the skill so that next run starts in the correct place. Anthropic designed skills as a step toward this kind of continuous learning.
Their guarantee is that anything that Claude writes down can be used efficiently by a future version of itself. Now, here's the thing. Skills don't remember every single thing, and they aren't a recording of every conversation that you've ever had.
They basically store the procedural knowledge that Claude needs to do the specific job. So when a process is wrong, update the instructions in the skill .md. When Claude is missing your voice or your brand or your examples, then add a reference file.
And when the same mistake keeps happening then add a clear rule that explicitly prevents that and then rerun the same task you can use a prompt like this review what went wrong during this run decide whether the cause was the process or missing context or a weak rule or unreliable code and then update the skill in the smallest durable place then rerun the same task and verify the fix over time the skill becomes a living record of how you want the job done and i do want to be precise about the phrase model proof no skill can just force a weaker model to perform exactly like the stronger one different models will obviously still produce different results and they interpret skills in different ways.
But your process can be portable. Agent skills are an open format. So the same core like skills folder can work across compatible agent harnesses like Codex or Hermes Agent or anything else.
So test an important skill with another compatible agent. If the result falls apart, then look for hidden assumptions, missing examples or instructions that only one model understands and then tighten up the skill and keep testing. All right, so the first three were very important, but this one is probably the most important.
A skill shouldn't hand you its first attempt and call the job done. This is probably the biggest gap that I see with a lot of AI workflows.
You run the skill, it creates the thing, saves the file, and then comes back to you and says, hey, I'm done. And then you open it and you realize that the formatting is broken, the sources don't support the claims, or that the script falls completely flat for the person you're trying to reach. So the AI did maybe 70 or 80 % of the job, and now you're the human, you know, manually doing the last 20 or 30%.
But if you already know how to personally check that work, then just bake those checks into the skill and let the AI close more of that gap for you. So for example, for a slide deck, have the skill render each slide as an image, inspect the screenshots fix anything that's cropped or hard to read or out of bounds and re -render it for a research report make it open the primary sources match the claims to the evidence and remove anything that it couldn't actually verify and if you're creating a script or an ad or something more subjective then have a few different personas like a few different sub -agents review it and discuss it.
A beginner agent can tell you where they're confused. A skeptical buyer agent can tell you what they don't believe. Someone from your actual audience can tell you where they would probably click away.
Now, you don't have to accept every single piece of feedback that you get from these different agent personas. That would probably make the output worse. But the skill can find the issues that show up more than once, make the strongest revisions, and then run the review again.
And sometimes just hearing those different perspectives is really helpful. And real quick, verification isn't clawed reading its own work and saying, looks good to me. It needs some kind of evidence outside of that first draft, whether that's a screenshot, a test result, a source, a reference example, or like I said, feedback from a few different agent perspectives.
And you can add something like this into almost any skill. Say something like, before returning the final output, define the acceptance criteria, create the first version, inspect it using the relevant verification method, fix every issue you find, and then run another pass. Return the output only after it meets the criteria with a short summary of what you checked.
And if something can't be verified, then tell me exactly what remains. It's even better if there's some sort of objective success metric that you can set and just have the agents keep working until it hits that objectively. But anyway.
ways. Now the first output is basically an internal draft. Cloud reviews it, catches the obvious problems, and then improves it before you see any of it, before you waste any of your time and attention on it.
Because you're ultimately still going to be the final judge, especially when there's things like taste or strategy or business judgment involved in the process. The goal though is just to stop spending your time catching problems that the AI could have caught on its own. Your first look should not be the agent's first look.
It should be the agent's, you know, fourth or fifth or maybe even sixth look. So now you know what anthropic engineers are actually building. They save proven code instead of rewriting it they give every skill a precise description so claude loads only the correct one they turn corrections into durable instructions that keep improving and they verify the work before it ever reaches you that's how you take a general purpose agent and you teach it how you work specifically and if you want to see how i organize the agents the context connections capabilities and cadence around all of this then i'll put my full ai operating system course on screen right up here i also have free courses templates and resources inside my free community that will help you build agents and workflows from scratch you can join with the link in the description and If you want to go deeper on turning these skills into a career, then you can check out my plus community.
But anyways, that is going to do it for this one. So if you guys enjoyed or you learned something new, please give it a like. It helps me out a ton.
And as always, I appreciate you guys making it to the end of the video. I'll see you all in the next one.
The Hook
The bait, then the rug-pull.
Nate Herk opens with a claim worth pausing on: the two Anthropic engineers who built Agent Skills say they quietly stopped making a new agent for every job. What they build instead, and the four habits that make it actually work, is the rest of this breakdown.
Frameworks
Named ideas worth stealing.
00:41concept
The Model-Agent-Skill Stack
Model = processor
Agent runtime = operating system
Skills = apps
A phone analogy for why one general-purpose agent plus swappable skills replaces a fleet of one-off agents.
Steal forexplaining to a client or teammate why you're not rebuilding a new bot for every request
01:25list
Anthropic's Four Practical Ways to Make Skills Work
Stop rebuilding the same solution
Pick the right skill
Make the skill get better
Verify before it reaches you
The video's core structure — four habits Anthropic's own team uses to keep Agent Skills reliable.
Steal forauditing any personal library of Claude Code skills
05:35model
The Skill Update Loop
Wrong process → update SKILL.md
Missing voice/brand → add a reference file
Same mistake repeats → add a hard rule
Where each type of correction should permanently live so it isn't relearned every session.
Steal forturning one-off corrections into a durable improvement to a recurring workflow
08:00model
Verification Before Delivery
Define acceptance criteria
Create the first version
Inspect it against evidence
Fix every issue found
Rerun and confirm
The loop to bake into any skill so the agent catches its own obvious problems before you see them.
Steal forany skill that outputs something visual (slides, images) or claim-based (reports, scripts)
CTA Breakdown
How they asked for the click.
VERBAL ASK
09:15product
“I'll put my full AI operating system course on screen right up here ... I also have free courses templates and resources inside my free community”
Soft bridge from the video's lesson straight into his own paid course, immediately followed by a lower-commitment free-community ask as the fallback CTA.
Add Modern Creator as a preferred source and Google shows you more of our breakdowns in Search, Top Stories, and AI Overviews. It only changes what you see, and you can undo it in your Google settings anytime.
Add to Preferred SourcesOpens your Google source preferences with us pre-loaded. Tick the box and you're done.
One creator ran two frontier AI agents through the same 15 real work tasks and tracked the winner, the time, and the exact dollar cost for every single one.
Nate Herk breaks down Boris Cherny's YC interview on cutting 80% of Claude Code's system prompt, then tests deleting his own skills to see what actually changes.
00:10
00:22
00:25
00:36
00:39
00:57
01:03
01:12
01:22
01:29
01:37
01:44
01:52
01:56
02:08
02:14
02:22
02:30
02:40
02:44
02:48
02:58
03:04
03:22
03:29
03:33
03:41
03:55
03:59
04:07
04:17
04:22
04:29
04:36
04:44
04:51
04:59
05:13
05:20
05:27
05:35
05:45
05:49
05:56
06:03
06:10
06:21
06:32
06:39
06:43
06:50
07:08
07:17
07:22
07:30
07:37
07:46
07:52
07:59
08:06
08:13
08:21
08:29
08:37
08:44
08:48
08:57
09:15
09:24
09:27
09:32
09:43
Video of the Day38:35
11:56
Video of the Day30:53
14:35
Video of the Day14:45
12:37