Why a Bigger AI Skill Library Makes Your Agent Worse
Everyone thinks agent skills work by teaching the model facts. A Princeton and Stanford team pulled thousands of agent runs apart and found the opposite: skills are choreography, not knowledge -- and a growing library quietly makes your agent worse, not better. Then the twist that makes it dangerous: a self-replicating prompt attack that spreads agent to agent, where upgrading to a smarter model both lowers your odds of being breached and raises the damage when you are. And the counter-move -- a system serving a 750-billion-parameter model on a single desktop GPU by measuring your machine instead of assuming it's a datacenter.
Listen (MP3) · Watch on YouTube · Spotify · Pocket Casts
Cold Open
Eris: The skill you wrote to make your agent smarter taught it basically nothing. Nobody building these wants to hear that.
Vestra: Nothing it didn't already know. Not one new fact.
Eris: And it still made the agent better. That's the part that broke my brain. Because it was never about knowledge. It never was.
Eris: A team out of Princeton and Stanford pulled thousands of agent runs apart to find out why skills actually help --
Vestra: -- and the answer's almost embarrassing. It's choreography. Which step, in which order.
Eris: Not what to know. How to move. And once you see that, the whole "build a giant skill library" idea tips over.
Vestra: Tips over hard. Bigger library, worse agent. Stay with us on that one.
Skills Don't Teach Your Agent Anything
Eris: So start me here. If a skill isn't handing the agent facts, what is it actually doing on the runs where it works?
Vestra: Okay, picture the difference between a recipe and an ingredient. Everyone assumes a skill is the ingredient -- some missing knowledge you drop into the model's context. The secret spice.
Eris: And it's not the spice.
Vestra: It's almost never the spice. They tore apart something like eight thousand agent runs, and every time a skill made the difference, they labeled how it made the difference. Was it supplying a fact the agent lacked, or was it stabilizing the procedure -- the setup, the tool order, the checks.
Eris: And which one wins.
Vestra: It's lopsided. Call it fifteen to one in favor of procedure. The skill mostly just tells the agent: do these steps, in this order, verify this before you plate it.
Eris: Fifteen to one. So the thing we've all been calling knowledge injection --
Vestra: -- barely shows up. A sliver. Which is wild, because that's the mental model everybody has. You're not teaching it a fact. You're handing it a dance.
Eris: Here's what I want to know though. Before I believe the choreography story -- how do they rule out that it's just, you gave the agent any hint at all and it perked up?
Vestra: Good, because they checked that. They compared the polished skill against just dumping the raw transcript of a past run into the context. Same underlying experience, two ways of packaging it.
Eris: My money's on the raw transcript being almost as good. It's the same information.
Vestra: That's the intuitive guess, and it's wrong -- but not in the direction the hype wants. The clean skill does beat the raw dump. Just by a modest margin, a few points, not a landslide. And the reason is telling. The raw transcript drags along every dead end the agent wandered into the first time. Failed branches, noise, backtracking.
Eris: So the agent reads the transcript and re-lives somebody else's bad night.
Vestra: Basically. It burns its whole time budget wading through the mess. The skill is valuable because somebody threw the mess away. The compression is the product.
Eris: Okay, so who actually feels this? Where does a skill earn its keep in a real workflow?
Vestra: Setup and plumbing. This was the cleanest result in the paper. The failures that skills crush are the boring operational ones -- getting the environment right, the file paths, the dependency that has to be installed a particular way, the service that has to be running before step three. Those nearly vanish.
Eris: The stuff that has a right answer you just have to remember.
Vestra: Exactly that. It's highly skillable, in their words, because once someone discovers the reliable setup sequence, you can freeze it. But -- and this is the boundary -- a wrong algorithm? A task that needs you to actually rethink the approach?
Eris: The skill can't save you.
Vestra: The skill does nothing. The logic errors stayed flat whether the agent had the skill or not. Choreography gets your feet in the right place. It does not make you a better dancer.
Eris: I love that, because it draws the line so clean. Skills are for the parts of the job that are the same every time, not the part that needs a new idea.
Vestra: And here's the twist that made me actually sit up. Skills invent a brand new way to fail. One that raw execution basically never has.
Eris: Yeah, go on.
Vestra: The agent follows a plausible recipe straight into a wall. The skill looks right, it's confidently written, so the agent applies it mechanically -- misses a condition, carries over an assumption that stopped being true. On the runs with skills, that "followed good advice off a cliff" failure jumped up by a lot. It's the price of handing something an instruction it trusts.
Eris: So the abstraction that helps you is the same abstraction that can march you confidently in the wrong direction.
Vestra: One object, both edges. Now hold that, because it sets up the number that should actually change how you build.
Eris: This is the library part.
Vestra: This is the library part. In real life you don't hand the agent one perfect skill. You give it a folder and it has to pick. So they grew the folder -- from a handful of skills up to a hundred -- and watched whether the agent reached for the right one.
Eris: And with a hundred, I'm guessing it drowns.
Vestra: When the folder had a handful, it grabbed the correct skill maybe a third of the time. Grow it to a hundred and that collapses to basically noise. The right tool is in the drawer and the agent can't find it.
Eris: Right, so a hundred skills means a worse agent. That's the headline. Delete your library.
Vestra: And that's where they surprised me a second time. Watch the actual task success while the picking falls apart. Does it crater with it?
Eris: It has to. If it can't find the right skill --
Vestra: It barely moves. Success stays nearly flat while the precision of grabbing the exact right skill falls off a cliff.
Eris: Wait, back up. How does the agent keep succeeding if it's grabbing the wrong skill?
Vestra: Because grabbing the exact annotated "correct" skill turned out to be neither necessary nor sufficient. A neighboring skill -- not the official right answer, but close -- still carries useful procedure. The agent peeks at several, cobbles the choreography together, and gets there. And on the flip side, sometimes it grabs the perfect skill and still fails, because it can't operationalize it.
Eris: So the retrieval problem and the success problem are just... different problems.
Vestra: They're not the same axis at all. Which reframes the whole engineering job. For two years the question was: how do I write more skills. This says the writing was never the bottleneck.
Eris: The curating is.
Vestra: The curating is. A growing library isn't an asset that quietly compounds. It's a cost that quietly compounds. Every skill you add is one more distractor between the agent and the one it needs.
Eris: Okay, forget the recipe box for a second -- give me the bare principle. If someone remembers one sentence from this.
Vestra: A skill is a compressed procedure, and its whole value lives in the compression and the selection -- not in the content. The instant your library is big enough that finding the right procedure is hard, you've spent the compression you were trying to buy.
Eris: So -- back to the top. Why does a skill help, when it isn't teaching the agent anything?
Vestra: Because it's not there to make the agent know more. It's there to make the agent stumble less -- on the steps that are the same every single time. And the moment you have too many of them, even that stops working.
The Stronger Model Is the Better Carrier
Eris: So follow the thread with me. If a skill is just a folder of instructions your agent obediently follows -- what happens when one of those folders is hostile?
Vestra: And not just to that one agent. That's the whole nasty jump in this next paper. It's called Prompt Infection, and the word infection is doing real work.
Vestra: Because it spreads. It self-replicates. Classic prompt injection is one poisoned document tricking one model. This is a poisoned document that hijacks the first agent, and then makes that agent copy the attack into its own output -- so the next agent down the line reads it, gets hijacked, copies it again. Agent to agent, like a virus jumping cells.
Eris: And multi-agent setups were supposed to be the safe architecture. Lots of little specialists, walled off from each other.
Vestra: That was the comforting story. Distributed, so surely more robust. This paper's whole point is that the distribution is the attack surface. Every hand-off is a chance to infect the next one.
Eris: So what does the poison actually make them do?
Vestra: The scary demo is data theft, because it needs teamwork. One agent reads the malicious file and gets turned. It passes the infection to the agent that can reach the database, which quietly appends the sensitive records onto the traveling prompt. Then it hands off to the agent that can run code, and that one writes the request that ships everything out to the attacker.
Eris: So no single agent did the whole heist. Each one did one innocent-looking piece.
Vestra: Each one just did its job, on instructions it thought came from the user. The attack is the assembly line. And here's the question I actually want you to sit with, because everyone gets it backwards. You're running one of these systems. You upgrade to a smarter, better-behaved model. Are you safer?
Eris: Obviously yes. That's the entire pitch of a better model. It follows instructions better, it refuses bad stuff more.
Vestra: Predict the result then. Smarter model -- does the infection spread more or less?
Eris: Less. It sees through the trick.
Vestra: Half right, and the other half is the whole paper. The stronger model was much better at recognizing the attack and just ignoring it. Way more often than the older, weaker one. So as a front door, yes -- it's a better guard.
Eris: But something flips here.
Vestra: It flips hard. When it did get compromised, it was far more effective at carrying out the attack. Cleaner. It replicated the infection more faithfully, executed the malicious steps more precisely, botched them less. The weaker model would get infected and then fumble the job.
Eris: Oh, that's grim. So the upgrade lowers the odds you get hit --
Vestra: -- and raises the damage when you do. Capability isn't a defense. It's an amplifier. It points wherever the instructions point, and a hostile instruction gets a better executor for free.
Vestra: So the safety question can't just be "how good is my model at saying no." It has to also be "and if it says yes to the wrong thing, how much harm can it do at full skill." Those are two different questions and the field mostly asks the first one.
Eris: Let me push on the spread, though. In a lot of setups the agents don't share everything. They only see a slice of what came before. Doesn't that starve the infection?
Vestra: It slows it. When agents only see partial history, the attack drops off, because if even one agent in the chain shrugs it off, the chain breaks. But self-replication is exactly what makes it survive that. A non-replicating attack basically can't get past two agents. The replicating one is the only version that scales through a wall.
Eris: And there was a memory trick in here too that I thought was almost too clever.
Vestra: The persistence one. Some agents rank their memories by importance to decide what to keep. So the infection just... includes a line telling the model to rate this memory as maximally important.
Eris: It nominates itself for the hall of fame.
Vestra: And the model complies. Slots the infection at the top of what's worth remembering, which resets its freshness, which keeps it resurfacing. Without that line, the thing dies out after a few turns -- it can't compete with real memories. With it, it self-promotes into permanence.
Eris: So it games the ranking system into loving it. Okay -- what actually stops this? Please tell me something stops this.
Vestra: This is the part that matters for anyone building. No single defense worked alone. Not tagging every message with who sent it, not wrapping the untrusted text, none of it -- each one alone left most attacks working. But stack the right two together and the attack success dropped to essentially nothing.
Vestra: So it's layered or it's nothing. It's structural, is the deeper point. If an agent fundamentally can't tell an instruction from a teammate's data, then making that one agent smarter does not fix the topology. You've just seen -- smarter can make it worse. The fix lives at the boundary. Treat every message from another agent as untrusted input. Sandbox what each one can actually do, no matter what it's told.
Eris: And this lands right on top of the skills story. We just said skills ship as installable folders of instructions an agent follows with barely a glance.
Vestra: That's the collision. One paper says the future is agents installing folders of procedure off the internet. This one says a folder of procedure is precisely the vector, and in a team of agents it doesn't stay in one folder. The supply chain and the attack are the same shape.
Eris: Strip it to the principle. What's the one line?
Vestra: In a system of agents, a message from a teammate is not trusted just because it came from inside the house. The call is coming from inside the house is the normal case now.
Eris: So -- come back to the question. Upgrade your model, are you safer?
Vestra: You're less likely to be breached and more dangerous once you are. Safety isn't the strength of any one agent. It's whether the walls between them hold when one of them turns.
A 750-Billion-Parameter Model on One Desk
Eris: Alright, last one, and it's the counter-move to everything we just said. If you're nervous about your agent shipping your data through a chain of strangers -- where does the model have to live for that fear to go away?
Vestra: On your own machine. Which everyone will tell you is impossible for a frontier model.
Eris: The received wisdom is the big ones need a datacenter. Millions of dollars of clustered GPUs. You rent access, you don't own it.
Vestra: So here's the claim from this paper, and I want you to react before I explain how. A system called FreeToken serves a model with seven hundred and fifty billion parameters. On a single workstation GPU. One card, one desk.
Eris: That -- no. A model that size doesn't fit on one card. The weights alone are hundreds of gigabytes. Where does it physically go?
Vestra: That's exactly the right question and it's the whole trick. So predict: how do you fit a model many times bigger than your graphics memory onto one graphics card?
Eris: You can't hold it all at once. So you're... streaming pieces in and out as you need them?
Vestra: You're close, and the reason it's even possible is the shape of these modern models. They're what's called mixture of experts. Instead of one giant brain where every neuron fires for every word, it's more like a building full of hundreds of specialists, and each word you process only wakes up a handful of them.
Vestra: So the model is enormous, but the part working on any single token is small. Tiny, relatively. The compute per word easily fits on the card. The problem is you don't know in advance which specialists this word will need, and the full roster is way too big for the card's memory. So most of the experts have to sit in your regular system memory -- big, cheap, but slow -- and get pulled over to the GPU when they're called.
Eris: And that pull is the bottleneck.
Vestra: That's the bottleneck everyone's been fighting. And here's where FreeToken does the thing I actually loved. Give me the warehouse for a second. Your system memory is a giant warehouse -- huge, holds everything, but the aisles are slow. Your GPU is a tiny workbench -- lightning fast, no room. For every part you need, you've got two choices.
Eris: Carry it from the warehouse to the workbench.
Vestra: Or just do the work right there in the warehouse aisle where the part already sits. And which is faster is not obvious. It depends entirely on how wide your hallway is -- how fast the connection between memory and GPU actually runs on your specific machine.
Vestra: So the old systems picked one and committed. They guessed. They'd decide up front, this fraction goes to the GPU, this fraction stays on the CPU, fixed. And that guess is wrong on almost every machine, because a gaming laptop and a workstation have wildly different hallways.
Eris: And FreeToken doesn't guess.
Vestra: It measures. It literally clocks your machine's real transfer speed and your memory's real speed, and every single step it does the arithmetic -- how many experts should I carry over, how many should I just compute in place -- to keep both paths busy at once. Neither the hallway nor the warehouse crew ever sits idle.
Vestra: So the whole insight is: stop assuming, and read the actual hardware you're standing on. That's the principle, and forget the warehouse now -- here's the bare version. The right split between moving work and doing work in place can't be read off a spec sheet. You have to measure the machine you're actually on, and re-decide continuously as things change.
Eris: And "as things change" matters here, because this is your own computer. Your browser's eating memory, you launch a game --
Vestra: -- and the budget shifts under you mid-sentence. A datacenter GPU is dedicated to one job. Your desktop is sharing with everything else you're doing. So FreeToken can resize what it's holding on the fly without tearing the whole engine down. It treats "nothing here is dedicated to me" as the normal condition instead of a failure.
Eris: Give me the payoff, though. What does it actually run, on hardware a person owns?
Vestra: The felt version. On a thin eight-gigabyte laptop -- the kind of card that is genuinely small -- it serves a thirty-five billion parameter model faster than a popular production coding assistant streams to you today. On a gaming desktop, a model getting toward three hundred billion, interactively. And the headline stunt, the seven-fifty-billion, on one workstation card at twice the speed of the standard open tool.
Eris: Okay but you've got your skeptic face on. What's the asterisk.
Vestra: The honest asterisk. "Runs" is not the same as "runs pleasantly." Serving-system results are brutally sensitive to your exact hardware, this is a fresh preprint nobody's reproduced yet, and streaming from disk is slow in absolute terms even when it's clever. I want to see somebody who isn't the authors put a seven-hundred-billion model on their own desktop and report back. Feasible is a real word. Comfortable is a different word.
Eris: Fair, and worth saying there's a company this same week that just got valued at twenty-one billion dollars on the exact opposite bet -- giant custom racks, inference belongs in the building.
Vestra: And the beautiful part is they can both be right. The same thing that lets a datacenter push more throughput per watt -- that sparsity, only a few experts firing -- is the same thing that lets your laptop skip most of the model. One trend, two customers. It is not a winner-take-all fight.
Eris: So bring it home. Where does the model have to live?
Vestra: Increasingly, wherever you want it to. And the reason isn't a bigger card. It's software that stops assuming your machine looks like a datacenter and starts measuring what you actually own.
Wrap-Up
Eris: So if I'm pulling one thread through all three of these -- it's control at the boundary. Where does the smartness live, where does the trust stop, where does the model run.
Vestra: And each paper moves a line you thought was fixed. Skills: the value isn't the knowledge, it's the choreography -- and a bigger library moves you backwards. Infection: the strong model is the better guard and the better weapon. FreeToken: the frontier can sit on your desk if the software measures instead of assumes.
Eris: Give people the one useful thing, though. The sentence they repeat to a coworker tomorrow.
Vestra: This one. Your agent's skill library is not an asset that quietly grows more valuable -- it's a cost that quietly grows. The bottleneck was never writing more skills. It's deleting the ones that are burying the one that matters. Go look at your folder and cut it in half.
Eris: And honestly that's the rare kind of advice that saves you work instead of adding it. Do less, get more.
Vestra: Which almost never happens in this field, so enjoy it.
Eris: If you want the receipts on any of this -- the papers, the numbers we deliberately didn't read out loud, all of it -- every story we touched today is on our news site, Ground Truth. That's groundtruth.day. One clean feed, every day, human-checked.
Vestra: And the rest of today's news -- the acquisitions, the model launches, the stuff we didn't have time for -- that's all in today's AI News Today brief. Go grab it.
Eris: One thing before you go. We actually want to know: open up your agent's skill folder and tell us in the comments -- what's the one skill in there you know you could delete. Be honest.
Vestra: And if a paper here made you rethink something, say which. That's the comment that starts an argument worth having.
Eris: Follow the show, leave a rating if it earned one today, and send this to the one person you know who's about to build a hundred-skill library.
Vestra: Save them the trouble. See you tomorrow.