The AI Delegation Loop

What's Inside

• Why agents that work in the demo die within two weeks
• The three layers of a playbook: the process, the toolbox, the proof
• Four copy and paste prompts, each one a complete spec, not a one-liner
• What belongs in a toolbox, with filled examples for four different jobs
• Checks that can actually fail, so your agent stops handing you 90 percent
• The folder template and a full worked example, week by week

This is the full build, not the summary. Four prompts, what goes inside each layer, worked examples for four common jobs, and the checks that stop your agent handing you half-finished work. Budget about thirty minutes for your first playbook. Every prompt below is written to work from a completely blank setup.

Why your agents keep dying

The common advice is one agent per job. One for email, one for content, one for leads, then wire them together. Every agent carries its own prompt, its own tools and its own wiring, so the moment the job changes, something in that wiring breaks and you are the one who finds out.

Vercel, a company that sells the infrastructure people use to build agents, did exactly this for their data team. They chained specialist agents together, gave it to their own staff, and in their words the immediate response was that it was awful. The rebuild that worked was not a smarter agent. They gave a general AI a folder of their own files and a few plain tools, and their internal score roughly doubled. Anthropic's engineers made the same move: they stopped building a separate agent for every job, because the general agent underneath had become better than the wiring around it. What it was missing was never intelligence. It was your job knowledge, written down.

Before you start: where the playbook lives, and who writes the files

A playbook is a folder for one job. How you run it depends on whether your AI can write files, and this is the part that trips people up, so get it right before you start.

If your AI can read and write files on your machine (Claude Code, or any agent with file access), make a real folder, for example ~/playbooks/weekly-client-update. The prompts below work exactly as written: it creates SKILL.md, saves files into the folder, and updates them itself. This is the version that compounds, because nothing depends on you remembering to sync anything.

If you use Claude or ChatGPT in the browser or desktop app, you can still do all of this, but with one important difference: a Project holds files you upload, and the AI cannot write back into it. It can read your playbook, and it can print you a new version, but you are the one who saves the file and uploads it. Nothing you paste into a chat updates the project's copy.

So in a chat-only tool the loop is: keep the real folder on your computer or in your Drive, upload the files into the Project, and whenever the AI gives you an updated SKILL.md or a new template, save it into the real folder first, then replace the uploaded copy. Delete the old upload rather than adding a second one, because two versions of the same file is how an AI starts following instructions you retired weeks ago.

One warning about cloud storage: uploading from Dropbox or Drive creates a copy, not a link. Editing the file in Drive later does not change what the Project sees. Whatever tool you use, there is exactly one master copy, and every upload is a snapshot of it that goes stale the moment you edit the master.

Pick your first job with these three tests: you do it at least weekly, you would recognise a bad version instantly, and explaining it to a new hire would take you under twenty minutes. Do not start with the most complicated thing you do. Start with the most repeated thing you do.

Layer 1: the process

The process layer is your judgment, written down in the order you actually use it. You are not going to type it. You are going to be interviewed, because the parts of a job you would never think to write down are exactly the parts that make the output sound like you.

A good SKILL.md has seven parts: a one-line purpose, when to use it (in the words you would actually say), the inputs and where they live, numbered steps, the decisions with the rule behind each one, the definition of done, and the edge cases that have burned you before. Paste this prompt into a new chat in whichever tool you chose.

You are helping me turn a job I do repeatedly into a written playbook you can run without me.

The job is: [describe it in one line].

First, interview me. Ask one question at a time and wait for my answer. Do not write any files until you have asked at least eight questions and I have said we are done. Cover all of this:
- what triggers the job, and how often
- the inputs, and exactly where each one lives
- the steps in the order I really do them
- every decision I make, and the rule behind it
- what I check before I call it finished
- the edge cases that have gone wrong before
- the tone or standard the finished thing has to hit
- what a bad version looks like

When you could run this without me, create a folder called [job-name] and write SKILL.md inside it with these sections: Purpose (one line), When to use this, Inputs, Steps (numbered, plain language, no jargon), Decisions (if X then Y), Definition of done, Edge cases.

Then show me the whole file and ask me two questions: what did you get wrong, and what did I forget to tell you.

If you cannot write files yourself, do not pretend you did. Print the complete file contents in the chat, tell me the exact file name and where it goes in the folder, and remind me to replace the old uploaded copy rather than adding a second one.Copy prompt

Best practice while you do it: answer in full sentences, name real examples rather than describing them in the abstract, and when it asks a question you find annoying, that is usually the question that matters. Expect the first version to be about eighty percent right. Fix it in the file, not in the chat.

Layer 2: the toolbox

The toolbox is every reusable thing the job needs, saved in the folder and pointed at from SKILL.md. Without it, your AI rebuilds the same script, the same template and the same formatting rules on every run, which costs you time and money and produces a slightly different result each time. Anthropic's team watched Claude rewrite the same slide-styling script over and over, so they had it save the script inside the skill as a tool for its future self.

What actually belongs in a toolbox:

1. Scripts that do a mechanical step, like pulling numbers, renaming files, converting a format.
2. Templates with placeholders in square brackets, so the shape is fixed and only the content changes.
3. Reference data: client names and spellings, product list, pricing, links, account IDs.
4. Examples of finished work you were happy with, which teach tone faster than any description.
5. Rules files: your brand voice, your formatting standards, the words you never use.
6. Saved prompts for sub-steps you run often.

What does not belong: one-off outputs, anything with a password or key in it, and half-finished drafts. If you would not hand it to a new hire on day one, it does not go in the folder.

How to create each artifact without doing the work yourself: run the job once with the AI, and the moment something comes out right, freeze it. Ask for the reusable version, with your specifics swapped for placeholders, and save that. The second run is where the toolbox really fills up, because that is when you see what got rebuilt. Use this prompt each time something works.

Look at the [script / template / email / checklist] you just produced.

If I will need this again, do all of the following:
1. Save it into [job-name]/files/ with a descriptive name, like numbers-pull.py or update-template.md. No dates or version numbers in the name.
2. Turn my specifics into placeholders in square brackets so it is reusable, and keep one filled-in example underneath as a reference.
3. Update SKILL.md so the step that needs it points at the file by name, and says when to use it and when not to.
4. Add one line to [job-name]/files/INDEX.md: the file name, what it is for, and today's date.

Do not save one-off outputs, anything containing a password or API key, or a draft I have not approved.

Then run the whole job again from scratch and tell me which saved files you used and which parts you rebuilt from nothing. Anything you rebuilt is a candidate for the toolbox, so tell me what you would save next.

If you cannot write files yourself, do not pretend you did. Print the complete file contents in the chat, tell me the exact file name and where it goes in the folder, and remind me to replace the old uploaded copy rather than adding a second one.Copy prompt

Worked examples of a filled toolbox:

Weekly client update: numbers-pull script, update-template.md, two past updates the client praised, client-names.md with exact spellings, tone-rules.md.

Content repurposing: hook-bank.md, caption-template.md, brand-voice.md, three posts that outperformed with a note on why.

Chasing invoices: three email templates by lateness stage, escalation-ladder.md, account-contacts.md, tone-rules.md for staying friendly at day sixty.

Hiring screens: scorecard.md, role-brief.md, five rated example answers, rejection-email.md.

Maintenance: review the folder monthly, delete anything you have not used, and keep one file per purpose. Two files that do almost the same thing is how an AI picks the wrong one.

Layer 3: the proof

This is the layer almost everyone skips, and it is the difference between AI that hands you ninety percent and AI that hands you something finished. The proof layer is a definition of done that the AI has to check its work against, with evidence, before anything reaches you.

The important part is what counts as evidence. Anthropic's engineers are explicit that the AI reading its own draft and saying it looks good is worth nothing. A real check produces something outside the draft: a number that traces back to the source file, a link that returns a live page, a screenshot of the rendered output, a test that runs, a claim matched to a quote, a word count, a spelling checked against a reference file. If a check cannot fail, it is not a check.

Add a Definition of done section to SKILL.md for [job-name].

Write between five and ten checks that are specific to this job. Every check must be verifiable with evidence outside your own opinion: a number traced to its source file, a link that loads, a screenshot of the rendered result, a test that runs, a claim matched to a quote, a count, or a value checked against a reference file. No vague quality words like clear, professional or high quality.

From now on, whenever you finish this job, before you show me anything:
1. Run every check.
2. Fix what fails.
3. Run them again.
4. Give me a one-line pass or fail for each check, with the evidence you used.
5. List anything you could not verify, and say why, instead of assuming it passed.

If more than two checks fail on the first pass, stop and tell me which part of the process caused it rather than patching the output.

If you cannot write files yourself, do not pretend you did. Print the complete file contents in the chat, tell me the exact file name and where it goes in the folder, and remind me to replace the old uploaded copy rather than adding a second one.Copy prompt

What good checks look like, by job:

Weekly client update: every figure appears in the pulled data file, no adjective without a number attached, under 200 words, client name spelled as in client-names.md, last week's promised action is addressed.

Content repurposing: hook is under 12 words, no banned word from brand-voice.md appears, the claim matches the source transcript quote, caption first line is not the payoff.

Invoice chasing: amount matches the invoice record, the due date is correct, the tone matches the stage of the ladder, the payment link opens.

Hiring screens: every score cites a line from the candidate's answer, no score without evidence, the summary contradicts nothing in the transcript.

The loop: fix the playbook, not the chat

When it gets something wrong, the instinct is to correct it in the chat and move on. The chat closes and the lesson goes with it, so next week you type the same correction again. The loop is the habit of putting every correction back into the folder, which is why this system gets better with use while agents get worse.

There is a diagnosis step, and it matters. Ask which layer failed. If a step was missing, that is the process. If it rebuilt something that already exists, or used a saved file that is wrong, that is the toolbox. If the mistake would have been caught by a check that does not exist yet, that is the proof.

That output was wrong because [describe exactly what went wrong].

First, diagnose which layer failed:
- the process: a step is missing, out of order, or the rule behind a decision was never written down
- the toolbox: you rebuilt something we already have, or a saved file is out of date or wrong
- the proof: no check exists that would have caught this

Tell me which one it was and why, in two sentences.

Then make the smallest durable fix in that layer. Do not rewrite the whole playbook. If the same mistake has now happened twice, add an explicit rule that prevents it rather than a gentle reminder.

Add one line to [job-name]/notes.md with today's date, what went wrong, and what you changed.

Then run the same task again from the start and show me the before and the after, so I can see the fix worked.

If you cannot write files yourself, do not pretend you did. Print the complete file contents in the chat, tell me the exact file name and where it goes in the folder, and remind me to replace the old uploaded copy rather than adding a second one.Copy prompt

Read notes.md once a month. Repeated entries in the same layer tell you where the job is genuinely hard, and that is usually the next thing worth automating properly.

The folder, once it is built

[job-name]/
  SKILL.md              purpose, when to use, inputs, steps, decisions, definition of done, edge cases
  files/
    INDEX.md            one line per saved file: name, purpose, date
    numbers-pull.py     a script that does a mechanical step
    update-template.md  a template with [placeholders]
    tone-rules.md       your standards, in your words
  examples/
    2026-09-08-good.md  finished work you were happy with
    2026-09-01-good.md
  notes.md              corrections, newest firstCopy prompt

One folder per job, not one folder for everything. If two jobs keep getting confused, the problem is the first line of each SKILL.md: write the When to use this section in the exact words you would type when you want that job done.

A full worked example: the weekly client update

Process: the interview surfaces that you pull last week's numbers from the ads dashboard, compare them to the plan, name what changed and why, and write it in a short honest voice with no hype, and that you always open with the number that moved most. That last detail never appears in anyone's written SOP, and it is the thing that makes the update sound like you.

Toolbox: the first run produces a numbers-pull script and a structure you like, so both get saved. The update you sent in week two, the one the client replied to, goes into examples. Your client's name spellings and the plan targets go into a reference file.

Proof: five checks, being every figure traces to the pulled file, no adjective without a figure, under 200 words, the client name matches the reference, and last week's promised action is addressed.

Loop: in week four it invents a number that is not in the data. You diagnose it as a proof failure, add a check that every figure must appear in the pulled file, and note it. It has not happened since. By week six you read and send, rather than write.

Five mistakes to avoid

1. Writing the steps yourself. The interview is what gets your judgment out of your head, and the questions you find annoying are the ones that matter.
2. One giant folder for everything. The AI cannot tell which job you mean, so it guesses.
3. Vague descriptions. Help with content means it never loads when you need it. Write when to use this in the words you would actually type.
4. No proof layer. Without checks you are the quality control, which is the job you were trying to hand over.
5. Correcting in the chat. If the fix is not in the folder, you will be typing it again next week.

Your first thirty minutes

Pick the job you do most often. Run prompt one and answer the interview honestly, which takes about fifteen minutes. Run the job once and save whatever comes out right with prompt two. Add the proof checks with prompt three. Run it a second time and watch how much less you have to explain. The second run is the moment this clicks, so do not stop at one.