The instructions library is the agency's growing methodology — not a deck, not a senior person's head
by Ygor Fonseca, Founder & Systems Lead
A couple of weeks ago we argued that the deliverable that actually runs an AI-native engagement is the per-client file — the working hypothesis at the top, the locked rules, the index of small task files the AI pulls in by name. We ended that piece with a promise: the index of task files is the part that compounds, and it deserved its own post. This is that post.
Garry Tan, YC's CEO, put the idea in one line earlier this year. "When someone asks how I 'prompt' my AI, the answer is: I don't. The skills are the prompts." He runs his own work off a library of small instructions files — each one a single task written out in detail, with its triggers and its edge cases — and a thin layer of code that routes each request to the right file. He says he runs more than a hundred of them. The method isn't in his head anymore. It's in the files.
That is the shift this post is about, moved from one person's desk to a services firm. Not the whole architecture — we covered the full shape elsewhere. Just one layer of it: the library of instructions files, and why a growing library is the closest thing a small team has to a methodology that outlives any one engagement.
Where method usually lives — and why neither place compounds
Ask most agencies where their methodology actually lives and you get one of two answers.
The first is tribal. The method lives in the senior person's head. New hires learn it by shadowing — sitting next to the person who knows, watching how they handle the case that isn't in any document. It works right up until that person is on holiday, or leaves, and walks out with the part of the method that was never written down.
The second is the deck. The method lives in a slide deck, a PDF, a Notion wiki — a "playbook." It describes the work in clean language and it ages the day it's published, because nobody opens it once the project starts, and it can't do anything. A playbook tells you how the work is done. It doesn't do the work.
Both are common and neither compounds. Tribal knowledge can't be copied without copying the person. The static playbook can be copied but it can't run, so it drifts out of date while the real method moves on in people's heads. A small team — three people or fewer — feels this faster than a large one, because there's no bench to absorb the loss when the one person who knew leaves.
The library is the third option
The alternative is to keep the method as a library of small instructions files — what an engineer would call a skill file, which is just a short document that describes one task in enough detail that the AI can run it: the trigger that should fire it, the steps, the edge cases, what "good" looks like, what to refuse. One file for the headline check. One for the way we pull self-reported attribution. One for the pre-publish review. Each is narrow. Together they're the method.
The difference from the deck is that these files run. The AI reads the relevant file when the matching task comes up and produces the work to the standard the file describes. The difference from tribal knowledge is that the file is the asset, not the person — anyone on the team, and the AI, can use it on day one.
And unlike either, the library grows. There's a slogan for this shape — Fat skills. Fat code. Thin harness — and it means most of the value sits in the files, not in the routing. The files accumulate. Every engagement that hits a task the library doesn't cover yet is a chance to add one.
How the library grows: capture, then reuse
The move that makes a library compound rather than just sit there is capture. You do a task manually once, and instead of moving on, you write it down as a permanent instruction the next person — or the AI — can run without you. Tan built a dedicated step for exactly this: hand it a workflow you just did by hand, and it extracts the repeatable pattern, writes the file, and registers it so the system can find it next time. The one-off becomes infrastructure.
The extension that matters for a services firm is the second word: reuse. An instruction written for one brand is rarely brand-specific all the way down. The way you run a conversion-research sprint, or cluster attribution answers, or check a headline — strip out the brand's name and you have a method that the next brand needs too. The first time you do it, it costs an afternoon. The fifth brand, the file already exists, and the engagement starts a week ahead of where the first one did.
That cross-engagement reuse is what turns a per-client folder into a firm-wide method. The files point to each other — the review instruction calls the source-check instruction, which calls the house rule on never inventing numbers — so the library becomes a web of linked files, not a flat pile. (The technical name is a knowledge graph; the plain version is that finding one file leads you to the three it depends on.) Six months of capture-and-reuse and the library is the methodology: not described, not remembered, but running.
The flow — the life of one instruction
The classic flow. A client asks for something the team hasn't done before. The senior person figures it out, does it well, and the how-to stays in their head. Next time it comes up, they explain it again, slightly differently. The method never leaves the person.
The AI-native version.
- Do it once, by hand. The lead on the engagement works the new task through manually — say, a first-time competitive teardown for a brand. No file exists yet.
- Capture it. Instead of closing the tab, they have the AI write the task up as a reusable instruction: the trigger, the steps that worked, the edge cases hit, what "good" looked like. Five minutes after the work is done, while it's fresh.
- Generalize it. The brand-specific bits get pulled out so the file describes the method, not this one account. The brand's facts stay in that brand's memory; the method goes in the library.
- Index it. The file gets a one-line description and a name, and links to the other files it leans on, so the next person finds it by searching for the problem, not the filename.
- Reuse it. The next brand that needs a teardown starts from the file. The lead reviews and adjusts for that brand instead of starting from nothing.
- Retire it. When a better version is written, or two files say the same thing, the old one gets merged or removed. A library nobody prunes turns into noise.
The closing edge. Each capture makes the next engagement start further along. The library's value isn't any single file — it's that the fiftieth engagement begins with forty-nine engagements' worth of method already written down and runnable.
Where it breaks. The whole thing depends on step two, and step two is the one that gets skipped under deadline. Skip the capture and the method quietly reverts to living in heads — the library stops growing and nobody notices for a month. The discipline is the same one that keeps the per-client file honest: the task isn't done until the reusable part is written down. The human decides what's worth keeping and what to retire; the AI proposes, a person approves.
Install note. This is the instructions layer of the per-client install — the same shape Codified Engagement ships for every brand we serve. The library is the part of the engagement that compounds; everything around it is scheduling.
Why the library is the asset
Tan ends his argument with a warning: the future belongs to people who build their own compounding systems, not to people who rent a centralized tool someone else owns. He's right, and it's worth sitting with, because on its face it argues against hiring anyone to do this for you.
The honest answer is that an AI-native firm builds exactly the system he's describing — but inside the brand's own repository, on the brand's own keys, on the brand's own data. The library that compounds belongs to the brand. The firm is the team that installs it and operates it well, then steps back to reviewer. That's the opposite of renting intelligence from a tool that keeps the value when you stop paying.
Which is also why we'll describe the shape of our library all day and never publish its contents. The shape is the marketing. The catalog — the specific instructions, refined across every brand we've run — is the part that took the work. A small team can't out-hire a large agency. It can out-compound one, by keeping a method that gets a little longer and a little sharper every engagement, in files that run, that anyone can pick up, and that don't leave when someone does.
Start the library before you think you need it. The first file feels like overhead. The fiftieth is the reason the work keeps getting faster while the team stays small.