Stop pressing go on every step. Hand the AI a job, a finish line, and a way to check itself, then let it run.
No coding needed, and you do not have to read it all. Want a loop running today? Jump to the worked examples and paste one. Want to understand them first? Read on. Use the tabs below to skip around. New here? The Leverage Ladder is the map this page hangs off.
Theory
What a loop is
A normal prompt gives one answer and waits for you. A loop runs a cycle on its own until it crosses a finish line you set.
It is a smart intern you do not micromanage. Hand it a goal; it works out each step, checks its own work, and only comes back once it has passed its own check.
You stop prompting and start designing. Instead of typing every step, you build the system that prompts itself.
1Reason. Work out the single next step toward the goal.
2Act. Do that step: write the section, draft the email, pull the numbers.
3Observe. Check the result against the finish line. Hit the bar, or still weak?
4Repeat until done. Fix the weakest part and go again. Once it clears the finish line, or hits a hard stop you set, it stops and reports back.
No coding needed. Home base is Claude chat and Cowork (the do-it-for-you tab in the Claude app). All you need is a finish line it can check against.
Why a loop beats doing it yourself
The same feedback and iteration happens either way. A loop just outsources it, and starts higher.
AI never nails it first try on anything you would actually accept. Quality climbs with attempts, not on pass one.
By hand you climb slowly. Read it, give feedback, read it again. A loop hands that whole chore to the agent, starting higher and climbing faster, for free, while you do something else.
By handslow climb
Pass 1rough
Pass 2better
Pass 5+good
You do the reading and feedback every round, by hand, until you are happy.
A loopsame climb, hands-off
Pass 1higher
Pass 2faster
Pass 3-4past you
The agent does the reading and feedback itself, while you do something else.
Illustrative, not measured. The shape is the point: a loop starts higher and climbs faster, hands-off.
This is why someone can say they did it in one prompt and mean it. It was never one shot. It was a loop with a self-check running underneath.
The two pillars: goal and verification
Two things matter more than everything else. Get these right and the rest is detail.
The goal. What is the actual objective? Make it objective, not subjective. Humans are good at this: we know what we want and what the end looks like. The goal tells the agent where to go.
Verification. How does the agent know it is done, and how does it check each pass? Verification is what lets it know it has actually arrived. It matters more than the architecture: a loop is only as good as its done-check.
The cake-and-fork test for done. How do you know a cake is baked? Stick a fork in, and when it comes out clean, it is done. Give your agent that kind of objective, checkable definition of done.
Two questions before you build anything
1
What does done mean?
Write it so a machine could check it, not so a person has to judge it.
Vague: "a strong summary."
Checkable: "under 200 words, cites three named sources, ends with one recommendation."
The test: could someone with no taste and a checklist tell whether you hit it? If yes, the AI can too.
2
How will it check?
The AI needs a way to verify it each pass, and that way changes with the work.
A word count it can count itself
A layout it has to look at
A tone it scores against a rubric (a scoring checklist)
A risky decision it has to bring to you
Match the check to the job. The four types below are your menu, and most office work leans on the first.
Copy this to pressure-test your finish line
Before I build a loop for this task, answer two questions for me, concretely.
1) WHAT DOES DONE MEAN?
Write the finish line as something a machine could check, not something a person has to judge. Push it as objective as possible, ideally a specific number or a yes/no rule.
2) HOW WILL IT CHECK?
Tell me exactly how the agent will verify it hit that finish line each pass, and what tools or sources it needs to run that check.
Then show me the gaps: where is my done-criteria still subjective, and what would make it checkable?
The four checks
Question 2, in detail: pick the check that fits the work. Start at the first and stay there whenever you can.
FFunctional
A clear rule the work either meets or it does not. No opinion involved. For non-technical work it usually means a countable or yes-or-no rule, not a coding test.
e.g. a market summary that must be under 200 words, cite three named sources, and name a single recommended action. The AI can count the words, count the sources, and confirm the recommendation is there, with zero judgement.
Easiest and most reliable. Turn as much of your finish line into rules like this as you can.
VVisual
Work that has to be seen to be judged. The AI produces it, looks at the result, compares it to what good looks like, and fixes what is off.
e.g. a board slide where the chart must fit on one page, the title sits top left, and nothing overlaps. The AI renders it, looks at the layout, and adjusts until it is clean.
Use when the thing only makes sense as a picture: a slide, a chart, a one-page layout.
JJudgement
Work that needs taste, but taste you can write down as a checklist. You give the AI a rubric, and a second AI scores the work against it instead of the worker grading itself.
e.g. a cold outreach email scored 1-10 on: opens with a specific reason for contact, names a concrete benefit, under 120 words, one clear ask. The reviewer scores each line and sends back what is weak until every line clears the bar.
Only as good as your rubric. To trust the grader, run it through a few evaluations first.
YYou decide
Work that is irreversible, or pure taste no checklist can capture. The loop does everything up to that step, then pauses and waits for your approval before it continues.
e.g. a loop that drafts a client proposal, prices it, and formats it, then stops before sending and asks you to approve the final number and hit send. The send is a one-way door, so a human owns it.
For risky, one-way-door steps: anything that goes to a client, spends money, or cannot be taken back.
Go deeper Three shapes a loop can take
Verification is the idea. The architecture is just how many agents you wire up to deliver it.
Solo loopOne agent reasons, acts, observes, and repeats, all by itself. One session, one good prompt, no extra machinery. This is the common default and what most loops should be, because most tasks only need the verification, not the architecture.
Maker-checkerTwo agents: a maker that does the work, and a separate checker that grades it and feeds back. Reach for it when grading is subjective and you want a dedicated critic rather than the maker marking its own homework.
Manager with helpersOne orchestrator (a manager agent) coordinating a set of helper agents underneath it, like Russian nesting dolls, managers prompting agents prompting agents. Powerful, but the most architecture and the most ways for it to break. Most people do not need this most of the time.
Rule of thumb
Start solo. Add a checker only when the work is subjective. Reach for helpers only when a job genuinely splits across several workers.
Go deeper The four kinds of loop, by what sets it off
A different cut from the shapes above. Those were about how many agents. This is about what sets the loop off and stops it. Each kind hands off one more piece of your own judgment.
1Turn-based
You hand off: the check. Every normal prompt is already a tiny loop: the AI gathers context, acts, checks itself, and comes back. You still decide if it is good enough and write the next turn.
Reach for: short, one-off tasks. Upgrade by saving your check as a skill, so it self-verifies more each time.
2Goal-based
You hand off: the stop condition. You state what done looks like and it keeps going until it clears that bar or hits a try-limit you set, instead of stopping when it feels finished.
Reach for: /goal in Claude Code. A number, a passing check, or a rubric score work best.
3Time-based
You hand off: the trigger. The work runs on a schedule, or when something changes, not when you remember. Use Cowork scheduled tasks, which run while your computer is awake and the Claude app is open, or a cloud routine that runs on a server.
Reach for: recurring work, like a Monday summary or a daily digest.
4Proactive
You hand off: the prompt itself. A steady stream of well-defined work runs with no one watching, each piece exiting when its own goal is met. The autonomous end of the ladder: you own the design, not the button.
Reach for: the top rung, once you trust the design. You set it up, it prompts itself.
The spine
A loop is a ladder of handing over one more piece of your judgment. Turn-based, you hold everything but the check. Proactive, you have handed over the prompt and only own the design. The line people quote, "I do not prompt anymore, I have loops that prompt for me", is just the top rung of this.
Find your first handoff
Take one task where you are the bottleneck and ask which single piece you could hand off first. Can you write the check (turn-based)? Is the goal clear enough to state (goal-based)? Does the work arrive on a schedule (time-based)? Start with one handoff and watch where it stalls.
This cut on loop types comes from the Claude Code team.
Worked examples
Loops in the wild
Theory sticks once you watch a loop actually run. Six worked loops, each a real prompt you can paste and fire.
Each card names three things: the finish line, how it checks each pass, and the one lesson it teaches.
Every prompt starts with /goal, the Claude Code "run as a loop until done" command. In Claude chat or Cowork, delete it and the prompt still works.
These six are reskinned from the coding demos that made loops famous. The originals:
Thumbnail loopScored 10 thumbnail ideas against MrBeast thumbnails on a rubric (a scoring checklist), iterated to a winner (27 min).
3D planeBuilt in code, checked by spinning it in a browser (37 min, still not perfect, because loops get you close, not perfect).
Abbey Road coverRecreated in pure code, scored each pass against a clear rule. Stop at an average score of 9 or above, hard cap of 8 passes. It stopped at version 7.
One caution
A loop with a hard goal but a fuzzy finish line can run forever. Useful loops run 35 minutes to a couple of hours. A 12-hour-plus run usually means the done-criteria was never checkable in the first place.
For the analyst
Pricing brief, sourced or it does not ship
A one-page brief comparing five competitors' pricing, ready to hand to leadership without re-checking facts.
Done
Zero unsourced claims. Every fact links to a source it opened.
Check
It re-reads its own brief each pass. Any claim from memory fails.
Lesson
Make done a number, not a feeling. Unsourced claims equals zero.
Copy this /goal prompt
/goal is the Claude Code "loop until done" command. In plain Claude chat or Cowork, just delete it and the prompt still works.
/goal Build me a one-page brief comparing the pricing and packaging of these five competitors: [Company A, B, C, D, E]. For each one, capture their plan tiers, the price of each tier, what is included at each tier, and any free trial length.
DONE WHEN: every number and every factual claim has a real source link next to it that you actually opened and read, not something you remember.
EACH PASS: re-read your own brief, list every factual claim, and check each one has a fetched source. If a claim has no source, go find the real source, or replace it with a clearly labelled note that the figure could not be confirmed.
KEEP LOOPING until the number of unsourced claims is zero. Do not stop because it looks done. Stop only when that count hits zero, then tell me how many claims you confirmed and which competitors had gaps.
For the founder
Board update that ties to the real numbers
The monthly board narrative, where every figure and trend claim matches numbers already locked in last quarter's deck and this month's metrics.
Done
Every claim traces to a real source cell. Every "grew" or "fell" matches the data.
Check
It treats the prior deck and metrics as truth. A mismatch fixes the prose, never the source.
Lesson
Match the check to the task. This one needs a source of truth, not a visual look.
Copy this /goal prompt
/goal Write this month's board update narrative. Your two sources of truth are last quarter's board deck at [path or paste] and this month's metrics file at [path or paste]. Write the narrative however reads well.
DONE WHEN: every number you state, and every up, down, grew, or fell claim, traces back to an actual figure in those two files.
EACH PASS: build a reconciliation table at the bottom, one row per claim, showing the stated value, the source cell or line it came from, and whether they match. If a number does not match the source, or you said a metric rose when the data shows it fell, fix the narrative, never change the source numbers.
KEEP LOOPING until the reconciliation table shows zero mismatches, then show me that table so I can see your work.
For the marketer
Cold email batch on a rubric, with a hard cap
Ten cold emails rewritten to clear a fixed rubric (a scoring checklist) for inbox-friendliness and tone before any go near a send button.
Done
Every email clears every rubric line. Hard cap of six passes.
Check
It scores every email line by line each pass. Fails get rewritten and rescored.
Lesson
Always set a hard stop. A tough finish line can run forever.
Copy this /goal prompt
/goal Here are ten cold outreach emails [paste or path]. Rewrite each one to pass this rubric on every line: no spam-trigger words or phrases, under 120 words, exactly one clear call to action, no more than one link, sounds like a real person writing to one specific human, and the opening line is specific not a generic hook.
EACH PASS: score every email against every rubric line and show me a scorecard. Rewrite any email that fails any line, then rescore.
DONE WHEN: every email passes every line.
HARD CAP: stop after six rewrite passes no matter what. If an email still fails after six, leave it as is, mark it clearly, and tell me it needs my eyes.
Do not send anything. Just give me the rewritten batch and the final scorecard.
For the consultant
Market-entry memo with a devil's advocate
A recommendation memo on entering a new market, where a second independent agent tries to tear the argument apart before it is final.
Done
Zero unaddressed objections. Each one is fixed or stated as a risk.
Check
A separate checker plays devil's advocate. It returns numbered objections to answer.
Lesson
Split the doer from the grader. A dedicated critic catches the writer's blind spots.
Copy this /goal prompt
/goal I need a recommendation memo on whether [client] should enter [new market]. Run this as two roles.
WRITER: draft the memo, the recommendation, the reasoning, the key assumptions, and the risks.
CHECKER: switch roles into a sharp devil's advocate who has only seen the memo and this brief. Return a numbered list of every weak assumption, every claim with no support, and every counter-argument the memo ignored.
EACH PASS: switch back to writer and answer every numbered objection, either by strengthening the memo or by openly stating it as a risk we accept. Then run the checker again on the updated memo.
DONE WHEN: the checker has zero unaddressed objections left. Show me the final memo and the checker's last objection list so I can see it came back clean.
For the manager
Hiring plan that plans before it writes
A vague headcount ask turned into a defensible quarterly hiring plan, forcing the agent to get the outline approved before it writes a single role spec.
Done
You approve the outline before it writes. Nothing is invented outside it.
Check
It stops for sign-off on the skeleton. A misread direction costs one paragraph.
Lesson
Plan first. It stops the agent racing off course.
Copy this /goal prompt
/goal I need a quarterly hiring plan for my team. The ask is roughly [vague ask], the budget ceiling is [number], the current team and its gaps are [paste], and a realistic time-to-hire is [weeks].
PHASE 1: do not write the full plan yet. Give me only a short skeleton, which roles, in what order, and a one-line check that each fits inside the budget ceiling and fills a real gap. Stop there and wait for me to approve or change it.
PHASE 2: once I approve, write the full plan strictly against the approved skeleton, a section per role. Then check each section back against the skeleton and flag anything you added that I did not approve.
DONE WHEN: every section maps to an approved item and nothing is invented outside the agreed scope. Plan first, get my yes, then build.
For the ops lead
Weekly ops report that remembers last week
This week's operations report that reads last week's first and explicitly tracks what changed, what is still open, and what is newly broken.
Done
No prior item silently dropped. Each is marked resolved, open, or escalated.
Check
It reads last week's report from a fixed path. Then saves this week's to the same place.
Lesson
Give the loop a memory. Same file in, same file out, so it compounds.
Copy this /goal prompt
/goal Write this week's operations report.
FIRST: open last week's report at [fixed path, for example ops-reports/latest.md] and read it. Pull out every item marked open or at-risk last week.
THEN: write this week's report covering the current state of operations. Mark any brand-new issues clearly as new.
DONE WHEN: every prior open or at-risk item appears in this week's report with a clear status of resolved, still open, or escalated. Nothing from last week is allowed to silently disappear.
EACH PASS: check your report against last week's open list and confirm every prior item has a status. If any is missing, add it.
LAST: save this week's report to the same path so next week can read it. Then show me the report and a short list confirming each prior item was carried forward.
Build it
What makes a loop work
Seven things separate a loop that earns its keep from one that burns your plan for nothing.
A checkable goalA finish line the AI can confirm on its own, written as a rule not an opinion. The best loops say keep iterating until X equals Y; until you are satisfied is the weak version.
A hard stopA back-up exit so it gives up after a set number of tries instead of running all night. Abbey Road paired a quality target with a hard cap of 8 passes.
Good toolsThe right access for the job: the file, the inbox, the drive, a browser, the data it needs to both do and check the work. Make sure it can verify, not just act.
Memory and a logA running record of what it tried, the versions, and the scores, so each pass builds on the last and you can see how it got there and trust it.
A separate checkerWhere you can, a dedicated grader judges the output rather than the maker checking itself. For subjective scoring, validate that grader through a few evaluations first.
Plan firstIt reasons and maps the approach before it starts building, the same reason you sketch before you write.
Make it worth the runWeigh the loop against its cost. A hard goal with a finish line it can never hit runs forever for little gain. Useful runs are 35 minutes to a couple of hours, not four days.
Do you even need one?
The honest part most write-ups skip: most tasks do not need a loop.
A single good prompt is faster and cheaper. A loop earns its setup when all four hold.
It repeats. You do this often, not once.
A real check can reject bad output. A rule, a rubric, or a layout, not just the AI nodding along.
The AI can do it end to end without handing half of it back to you midway.
Done is objective enough to write down as something checkable, not a gut feel.
Worth it
A weekly competitor summary, a recurring report in a fixed format, scoring a batch of emails on a rubric, cleaning data into the same template every time.
Not worth it
A one-off strategy memo, a sensitive message to your boss, a creative pitch where the value is your judgement. Those want you in the chair.
Not a hard gate, though: even a light solo loop earns its keep when a quick self-check makes the output better. Do not overstate the bar.
Does this even apply to you?
You are not behind without five agents running all night. A hardcore coder running fleets of agents got 10x'd by how they already work. Scaling a process you do not understand just scales the mess.
The saner cadence: fire one chunky loop before bed, wake to a 4 to 8 hour run, then polish it yourself. Run loops on a schedule or a trigger, not endlessly.
The maker-checker loop prompt
One prompt that keeps the worker and the reviewer apart, so the worker can never grade its own homework.
This is the maker-checker shape from the theory above, written as one reusable prompt. Reach for it when grading is subjective.
Copy it into Claude chat, Cowork, or Claude Code. Fill the brackets with your task and your finish-line rules. The more checkable each rule, the better it runs.
Copy this loop prompt
You will run two separate roles in a loop until the work meets the bar. Keep them strictly apart. The WORKER produces the work. The REVIEWER judges it. The worker never grades its own output and never sees its own score until the reviewer hands it back.
TASK: [what you want produced]
FINISH LINE (strict rules, no soft passes): [rule 1, written so it can be checked, not judged] | [rule 2] | [rule 3]
LOOP, every pass:
1. WORKER produces or improves the work, then hands it over with no self assessment.
2. REVIEWER, acting as a strict separate critic, scores each finish line rule out of 10, brutally honest, and lists exactly what is still weak. The reviewer assumes the work is not good enough until proven otherwise.
3. DECIDE: every rule 9 or above, print FINAL and stop. Otherwise print ITERATING, name the single weakest point, and send it back to the WORKER to fix that first.
HARD STOP: after 6 passes, stop and report the best version with its remaining weak points, even if it has not hit FINAL.
RULES: never call it done under 9 on any rule. Each pass fixes the previous weakest point. Do not ask me questions, make a sensible assumption and keep going. Begin, and run until FINAL or the hard stop.
The receipts
The receipts: six studies behind all of this
AI tells you what you want to hear about 88% of the time. That number is real and web-checked, and so is the move that fixes it.
Six studies on working with AI. Each names its finding, states its caveat plainly, and ends with the exact move that fixes it and a prompt you can paste.
Pick the card that matches a problem you hit this week. Paste its prompt. If it helps, save the skill so the fix runs by itself next time.
You do not need to be technical. Every prompt pastes straight into Claude chat or Cowork. The strongest evidence comes first, so lean on the early cards most.
Why every card shows its source
Most AI advice cites studies it never lets you check. Here, every finding names the study and links the source, so you can verify it yourself. Where the evidence is thinner than the headline number suggests, we say so plainly.
The studies · Study 1
AI agrees with you far too easily, so its yes means almost nothing
The study (web-checked)
What was tested: a Stanford-led benchmark called ELEPHANT measured how often AI models push back on the way a person frames an advice question, versus how often humans do.
The finding: on those advice questions, the models failed to push back about 88% of the time. Humans failed about 60% of the time. That is a gap of roughly 28 points.
One caveat on the 88%: it comes from a 2025 preprint (an early paper not yet peer-reviewed), and it is the failure-to-push-back rate on advice-style questions only.
Why it matters
AI is trained to be liked, and agreeing is the easy path. So a flawed plan can sail straight through on a confident yes.
The more personal and detailed your chat gets, the more it leans toward telling you what you want to hear.
If you only ever hear agreement, you are not getting a second opinion. You are getting an echo.
What to do
Treat the AI's agreement as the cheapest possible signal, not as proof you are right.
On any decision that matters, make disagreement the AI's job before you trust its yes.
Never lead the witness. Do not ask "this is a great idea, right?"
Make it argue against you first
Before you agree with me, argue against me.
MY POSITION: [what you think or want to do]
1. Give me the single strongest case AGAINST this.
2. Tell me what I would have to be mistaken about for my position to fall apart.
3. Then, and only then, give me your honest view, even if it contradicts me.
Don't soften it to be nice. I would rather hear the flaw now than find it later.
Save this as a skill
A "Devil's advocate" skill: any time I paste a plan, decision, or opinion, attack it first (strongest counter-case, my blind spot, what I am assuming), then give your real view last. Never lead with agreement.
Source: ELEPHANT sycophancy benchmark, Stanford-led research preprint, 2025. arxiv.org/abs/2505.13995 · Cited from a practitioner video, then web-verified.
The studies · Study 2
Done is not the same as working, and AI cannot reliably grade its own homework
The study (web-checked)
What was tested: researchers had an AI coding tool write nearly 1,700 small programs, then checked them for safety flaws.
The finding: about 40% had serious holes, even though the AI presented them as finished.
One caveat on the 40%: it is a dated 2021 number from an early version of the tool, so take the direction as true, not the exact figure as a live reading.
Why it matters
AI will call a job finished when it is not. And it is the weakest judge of its own work.
The everyday version is not code. It is a report that compares all five competitors but quietly skips two, or a content calendar marked full with blank days you only spot later.
Output that looks complete is the most dangerous kind, because it switches off your own checking.
What to do
For anything that matters, ask for the proof it is done, not the announcement that it is done.
Make the AI switch hats and review its own work as a hostile critic who gets nothing for being kind.
Spot-check the boring details yourself: counts, names, dates, and any claim that uses the word "every".
Force it to prove it is finished
You've told me this is done. Now audit it as a hostile reviewer who WANTS to prove it isn't finished and gets nothing for being kind.
1. List the things that had to be true for this to count as finished.
2. Go through each one as that hostile reviewer and show me, concretely, that it holds. Where you can't show it, mark it FAILED, not "probably fine".
3. Tell me the one part most likely to be off, thin, or skipped.
If any box isn't genuinely ticked, say it's not done yet rather than papering over it.
Save this as a skill
A "Prove it" skill: after producing any deliverable, re-check it against the original request line by line, confirm every all/every/each claim is literally true, and report any gap before saying done.
On the ladder: the Finished is not working habit, the everyday version of the worker-cannot-grade-itself rule behind Level 4, A loop, and Level 5, /goal.
Source: NYU, "Asleep at the Keyboard", IEEE S&P 2022: GitHub Copilot generated 1,689 programs across 89 security-relevant scenarios on a 2021 Copilot model. arxiv.org/abs/2108.09293 · Web-verified, recency softened.
The studies · Study 3
AI gets worse the longer a chat runs, well before it hits any length limit
The study (web-checked)
What was tested: a study ran 18 of the top AI models and measured how well they did as the amount of input grew.
The finding: the answers got worse as the chat got longer. The drop started well before the chat got truly long, and it happens quietly, with no error message.
One caveat before you lean on this: it is research from a vendor (Chroma), not a peer-reviewed paper, and the drop is uneven, so there is no single fixed percentage to quote.
Why it matters
A long, bloated chat starts forgetting your earlier instructions, repeating itself, and going vaguer, all without warning you.
More history is not more intelligence. Past a point, extra back-and-forth actively makes the answers worse.
You can waste an hour pushing a tired chat when a fresh one would have nailed it in minutes.
What to do
Keep chats lean. One job per chat wherever you can.
When a chat gets bloated or the answers go vague, do not push on. Start a new one.
Hand the new chat a tight summary instead of dragging the whole history along.
Get a clean handoff into a fresh chat
This chat is getting long. Write me a tight handoff I can paste into a brand-new chat so we lose nothing important:
- What we're doing and why
- Decisions already made (and what's settled, so we don't reopen them)
- The current state and where we got to
- The exact next step
Keep it short and concrete. No recap of the chit-chat.
Save this as a skill
A "Fresh start" skill: on command, produce a clean handoff summary (goal, settled decisions, current state, next step) sized to paste into a new chat, then tell me to switch.
Source: Chroma, "Context Rot" research: 18 of the leading AI models including GPT-4.1, Claude 4 and Gemini 2.5, with answers worsening before the chat reaches its length limit (the most text the AI can hold at once). trychroma.com/research/context-rot · Vendor research, web-verified.
The studies · Study 4
For jobs that split into independent parts, a team of AI helpers beats one AI alone
The study (web-checked)
What was tested: Anthropic compared one AI doing a research job alone against a team of AI helpers working on different parts at the same time, with a lead helper pulling the results together.
The finding: the team scored about 90% on Anthropic's own research test (a 90.2% mark), clearly ahead of one AI working alone. That 90% is a test score, not "90% better".
One caveat on the 90%: that is a test score on Anthropic's own (not independent) research test, not "90% better", and it cost roughly 15 times more to run.
Why it matters
When a job splits into parts that do not depend on each other, doing them one at a time makes you the bottleneck.
Each helper works on its own slice with a clear head, so none get bogged down. Then the results are combined.
It only helps when the parts genuinely stand alone. If they need to talk to each other mid-task, this is not the tool.
What to do
Spot the jobs that break into stand-alone parts, like "research five suppliers" or "summarise four documents".
Run a fresh helper on each part at the same time, then have them merged into one summary.
Be honest about independence. Overlapping parts are better done in a single focused pass.
Split a job across parallel helpers
Split this into separate jobs and run a fresh helper on each one at the same time, then combine the results.
THE JOB: [the overall thing you want]
THE PARTS (each must stand alone, no overlap):
- [part 1]
- [part 2]
- [part 3]
When they're all done, combine their results into one clean summary for me, and flag anything where two parts disagree. Don't start until the parts are genuinely independent.
Save this as a skill
A "Split and run" skill: take a job, propose how to cut it into independent parts, confirm they do not overlap, run a helper on each at the same time, then deliver one merged brief with conflicts flagged.
On the ladder: Level 6, Ultracode, where a manager agent runs helpers in parallel.
Source: Anthropic engineering, multi-agent research system: a lead helper with several helpers running at once beat a single AI by 90.2% on Anthropic's own test of broad, wide-ranging research, but used roughly 15 times more computing (so 15 times the cost). anthropic.com/engineering · Web-verified, scope softened.
The studies · Study 5
Becoming the AI person in your role is now a job expectation, not a bonus
The study (web-checked)
What was tested: IBM's 2026 CEO Study surveyed 2,000 CEOs across 33 countries on how AI is reshaping roles.
The finding: 85% said all functional leaders, not just technical ones, must become technology experts in their own domain.
One caveat on the 85%: it is self-reported CEO sentiment from a survey, so read it as what CEOs say they expect, not a measured outcome.
Why it matters
Within the same role, the people who turn AI into repeatable recipes pull away from everyone else fast.
The edge is not raw talent. It is having saved AI workflows that your colleagues do not.
Most people stay on Level 1 forever, retyping the same request from scratch every single day.
What to do
Stop aiming to use AI more. Start turning your real, recurring jobs into saved skills that run the same way every time.
Pick the three things you do every week and bake each one into a reusable recipe.
Treat the skills you save as a career asset. Those compound. One-off prompts do not.
Build your first weekly skills
Help me become the go-to AI person in my role: [your role].
1. Ask me what I actually do in a normal week, one question at a time, until you understand my recurring tasks.
2. Pick the 3 tasks that are most repetitive and most worth turning into a saved recipe.
3. For each, draft a saved skill in plain English: when to use it, the exact steps, my style, and what a good result must hit.
4. Show me the one-line command I'd use to run each one next time.
Start by asking me about my week.
The skill is the output
This card builds skills directly. The prompt's output is your first set of saved recipes, like your weekly report, your client email, your post formatter, each stored once and reused forever.
On the ladder: the save-a-skill move under Level 2, An eval check (turning recurring work into a compounding asset).
Context beats wording, so stop hunting for the magic words
The principle (well-supported, not a single study)
What it is: the everyday lesson behind a shift the field calls "context engineering" (giving the AI just the right information for the job), a framing popularised by AI researcher Andrej Karpathy.
The point: with today's models, most weak answers on a single request come from missing context, not clumsy wording. Give the same question with your real background and you get a usable answer. Leave it out and you get a bland template.
One caveat: there is no number here. It is a working principle from practitioners, not a numbered study, so treat it as a well-supported way of working.
Why it matters
People burn time collecting prompt tricks when the real lever is just telling the AI who you are and what the situation is.
Clever phrasing helps far less than naming who the answer is for and what matters to you.
More is not always better. Irrelevant detail crowds out the actual question and drags the answer toward generic.
What to do
Stop chasing the perfect wording. Feed it your situation instead.
Lead every real request with who you are, the situation, the audience and your constraints. Then the task.
Put in only what is relevant. Drop in a screenshot or photo when that is faster than describing.
Give it context, then the task
I'm going to give you context, then a task. Use the context, don't invent details.
CONTEXT:
- Who I am: [your role]
- The situation: [2-3 plain sentences]
- Who this is for: [the audience]
- What matters to me: [tone, length, any hard constraints]
TASK: [what you want produced]
If the answer depends on recent facts, search the web first and tell me your sources. If anything important is missing, ask me one question before you start. Otherwise go.
Save this as a skill
A "Brief me first" skill: whenever I give a thin request, ask me for who, situation, audience and constraints before producing anything, so I never get a generic answer again.
On the ladder: Level 1, A good prompt, where your context does most of the work.
Source: "Context engineering" framing from AI researcher Andrej Karpathy's own post. x.com/karpathy (the original post) · A working principle, not a numbered study, so stated as such.
Back to the map
This page is the engine room behind Level 4, a loop, and Level 5, /goal (the Claude Code command that runs a loop with a separate grader built in). The manager-with-helpers shape at the top end is Level 6, ultracode.
Want each run to start from a sharper brief? The Translator turns a rough ask into a clean one.