Last verified 23 September 2026. Claude projects exist on every plan, but only the Team and Enterprise plans let you share one with a deputy. A PubMed email alert needs you to be signed in to My NCBI, PubMed's personal account. Details for experts at the end of this book.

The idea in one page

There are five rungs. Each one up does more for you, and each one up gives you more to maintain.

Before rung 1 there's rung 0: something you already have. A template, a spreadsheet formula, a saved search, a form. It often does the job alone.

Three questions pick the rung.

1. Must it run when nobody is there? If no, stay on rung 1 or 2. If yes, try a fixed automation before an agent.
2. Must several people enter or see one current version? If yes, you need shared state, one current version of the data that everyone reads and writes: a form, a shared sheet, perhaps an app. That's a different need from running unattended.
3. What measured requirement did the lower rung fail? "An agent is more interesting" isn't one. "The draft must be ready at 07:30, before anyone is in" is.

Count a month, not the build. A build takes hours once. Upkeep comes back every month:

Saving five minutes on each of four runs frees 20 minutes a month. If the new build needs 30 minutes of upkeep a month, it has cost you time. It may still be right, for example because it meets a deadline, but then say that's the reason.

Every rung needs the same kit once colleagues depend on it. This is what makes it Level 3:

The higher the rung, the harder each part gets. A saved prompt's README fits on half a page. An app's needs a section on accounts and backups.

Worked example: two builds, four quadrants

Both follow the four quadrants from T01-L01 · From Idea to Working Result: The Four-Quadrant Method. Follow the one closer to your work. The people and numbers are examples written for this book.

Lab: the Friday reading shortlist

Structure it. Mira, a postdoc in a group of eight, writes: "Every Friday I send a shortlist of eight to ten new papers on our topic, with one line each on why it matters. The group plans journal club from it. A good result: the shortlist goes out every Friday, also when I'm away, and every paper on it is real, recent and on topic."

Understand it. She times four Fridays. Searching takes about 25 minutes, reading abstracts and choosing about 20, formatting about 10. Then she tries the top rung on a copy of the job: she asks an assistant's research mode, where it searches the web and reads many pages by itself, to find this week's relevant papers. It returns twelve. Three are older than a week, one has a wrong journal, and two she'd never put on the list, because the group already knows them. The choosing is the part that needs her judgement, or her deputy's. Searching is fixed: the same query every week. Formatting is fixed too.

That changes her problem. Back to Structure it: "The search and the formatting should run without thought. The choice stays with a person, but any of two people can make it, in 30 minutes, from the same instructions."

Choose tools. She goes up the ladder from the bottom.

• Rung 0. PubMed can save the group's search and email new results automatically. That does the unattended part for free. No automation needed.
• Rung 2. A shared Claude project turns the pasted alert and the chooser's notes into the group's shortlist format, and flags anything missing. The chooser reads every abstract; the project does the layout.
• Rejected: rung 3. An n8n workflow could fetch the results and post the list. But the alert already runs unattended, and a person has to choose anyway.
• Rejected: rung 4 and 5. An app for one operator, or an agent that chooses papers, would automate the one part that needs judgement.

Her decision paragraph, kept at the top of the README:

We use a PubMed alert plus a shared Claude project because the search is fixed, the choice needs a person, and either of two people can run it in 30 minutes. We rejected an automation because the alert already runs without us, and an agent because choosing papers is the judgement we want to keep. We'll look at an n8n workflow if choosing and formatting take more than 45 minutes on four Fridays in a row.

Build it. First the search: she and Tobias each save the group's PubMed search and click Create alert under the search bar, so the new results reach both inboxes every Friday. Then she writes the project instructions and gives them a version number. PMID is PubMed's ID number for each paper. Markdown is plain text with a few marks for layout, such as | between table columns and # for a heading, so it reads fine in any editor:

Then the known-answer test. She saves four records from an earlier alert in a file called test-input.txt, one of them a correction notice and one without a note, and writes down what the table must look like in test-expected.md. The expected result has four rows, CORRECTION on the third title, "no note" in the fourth row, and one line under CHECK BEFORE SENDING. Both files go into the project's knowledge, the files the project reads in every chat, and into the group drive. She shares the project with Tobias (Share next to the project name, Can edit).

She runs the test in a new chat. The first result drops the correction notice, because an earlier version of her instructions said "keep only research papers". She fixes the rule, which is why the version line says v1.2, and reruns. Four rows, as expected.

The README is the instruction sheet that travels with the build. Hers fits on one page, also in Markdown:

Then the only test that matters. In October Mira is at a conference, and Tobias runs the shortlist from the README. Two things go wrong. He can't open the project: Mira's invitation went to his old email address. And he doesn't know that "why it matters" should be one line, not a paragraph. Mira fixes the access and adds "one line" to step 1. The next Friday he runs the known-answer test first, gets four matching rows, then sends the real shortlist.

Where it stops. In December the group leader asks whether the shortlist could go straight into the institute's reference manager and wiki. Those are institute systems with institute logins. That's the stop line: Mira writes down what the group wants and takes it to IT, instead of wiring her build into their systems herself.

What it taught her: the build took an hour. The test, the README and Tobias's first run took two, and they're what made the shortlist the group's, not hers.

Company: the Friday status report

Structure it. Jonas leads a project office at a mid-sized lab-equipment maker. "Every Friday I turn updates from four workstream leads into a one-page status report for management. A good result: the report is correct, on time, and shows plainly when an update is missing."

Understand it. He logs one month. Gathering and copying updates takes 96 minutes, drafting and checking 48, sorting out which version of an update is current 44, fixing mistakes 12. He tries a saved prompt on the drafting: the format is fine within a week. But the slow part isn't drafting. Updates arrive by email, chat and a spreadsheet, and two leads send corrections after he has started. Back to Structure it: "One place where each lead enters an update, one current version per workstream, and a missing update shows as missing." The new need is shared state. Nobody asked for the report to run without a person.

Choose tools. He compares two options over a normal month, and keeps the build time separate:

The company already has a form tool in its office software. Each lead fills in the same four fields by Thursday 16:00, and the latest entry per workstream counts. The saved prompt drafts the report from the exported table. The app loses on upkeep and on build time. An n8n automation that drafts the report at 07:30 would be the next rung, but nobody needs a draft before Jonas starts work.

Build it. The instructions, versioned like Mira's, include one hard rule: "A missing or 'pending' figure stays 'not given'. Never write 0. Never add a total across workstreams." That's the zero from the opening story, written down so it can't come back. His known-answer test has three rows:

The expected report shows North at 12, East and West as not given, lists the three gaps under CHECK BEFORE SENDING, and has no total. He writes the README with the same headings as Mira's, names his deputy, and adds a fallback: if the form is down, leads email the four fields and the deputy pastes them in the same order. In his holiday week the deputy runs the test, gets a matching result, and sends the report on time.

Where it stops. Three months later management asks for budget figures to come straight from the finance system. That system belongs to finance and IT, with its own access rules. Jonas writes the request down and hands it over. Connecting assistants to the organisation's systems is Level 4 work.

In both cases the first idea was a rung too high, and trying a lower rung showed where the real problem was. That's the Structure it ⇄ Understand it loop doing its job before anyone builds.

When to climb, and when to stop

Climb a rung only when a trigger you wrote down fires: a measured time over a threshold for four runs in a row, a deadline nobody can meet by hand, a second person who must enter data. Write the trigger into the decision paragraph when you choose, not when you're tempted.

Stop building when any of these is true:

• The next step needs the organisation's logins, customer data or systems of record, the official systems where the organisation keeps its data, such as finance or HR. That's IT's job, and Level 4.
• Upkeep is growing faster than the time the build saves.
• Nobody but you can run it, and fixing that would take longer than the job itself. Go down a rung.
• The job has changed and nobody uses the output any more. Retire the build, and say so in the README.

What goes wrong

Building the interesting rung. Symptom: the project starts with "let's build an app" or "let's try an agent". Fix: write the three questions and the requirement the lower rung fails. If you can't name one, stay lower.

Counting the build, not the month. Symptom: "It only took a weekend", and it needs an hour of fixing every other week. Fix: estimate a normal month for each option, keep the build time in its own row, and check your estimate after four runs.

No known answer. Symptom: someone changes the instructions, and a month later a correction notice has been silently dropped every week. Fix: keep a known-answer test with one awkward case, and run it after every change and before a deputy's first run.

A README only you can follow. Symptom: your deputy's first run turns into five messages to you. Fix: let them run it from the README while you watch without helping, and fix the README, not the deputy.

Access you never tested. Symptom: the deputy can't open the project, form or workflow on the day. Fix: the deputy opens every link in the README with their own account before you leave.

A missing value becomes zero. Symptom: a report shows a figure that nobody sent. Fix: a rule that missing stays missing, and a known-answer case that proves it.

Wiring into systems you don't run. Symptom: your build logs into the finance system with your personal password. Fix: stop at the line, write down what's needed, and take it to IT.

Do it yourself (3 hours, over one or two weeks)

1. Structure it (15 min). Pick one recurring job colleagues depend on. Write who uses the result, how often, and what a good result looks like, including what happens when you're away.
2. Understand it (40 min). Time the job once or twice, step by step. Try the lowest plausible rung on a copy of the job. Note which step is slow and which step needs judgement. Rewrite your Structure it sentence if you learned something.
3. Choose tools (20 min). Answer the three questions. Estimate a normal month for your pick and one alternative. Write the decision paragraph: the choice, two rejected options with a reason each, and one trigger.
4. Build it: the build and its test (60 min). Make the smallest version. Version the instructions. Write a known-answer test with three to five cases, one awkward, and run it.
5. Build it: README and deputy run (45 min). Write the one-page README with a maintainer, a deputy, a fallback and the stop line. Give your deputy access, and watch them run the test and one real job without help. Fix every place they got stuck.

Exit check

What you hand in: one working build for a recurring job, with:

• the build itself: a saved prompt in a shared project, a form, an automation or an app;
• a one-page README: what it does, where it lives, maintainer and deputy, pinned version, how to run it, how to check it, what to do when it fails, where it stops;
• a known-answer test with three to five cases, one of them awkward, and the expected results;
• a decision paragraph naming the choice, two rejected options and a trigger for climbing a rung.

It passes when your deputy runs the test and one real job from the README alone, without asking you, and the test results match.

Rule to remember

Build the lowest rung that meets the need, and make sure someone else can run it.

Details for experts

Checked on 23 September 2026. You don't need this to follow the book; it's for setting things up or answering a colleague.

Further reading and tools

Next books

• T01-L02 · Check AI Output Before Your Team Relies on It: the check behind every known answer.
• T02-L03 · Build a Shared Assistant Your Team Can Test and Take Over: rung 2 in depth, when a whole team uses the saved prompt.
• T03-L03 · Put a Test Set Under the Prompt Your Team Depends On: known-answer tests for prompts, done properly.
• T05-L03 · Chain Checked Steps Into a Weekly Digest Your Team Can Rerun: rung 3, when a trigger has to start the run.
• T06-L03 · Turn Your Team App Into One Colleagues Can Depend On: rung 4, when shared state needs a screen.
• T07-L03 · Build a Small Agent Your Colleagues Can Run, Test and Stop: rung 5, once a fixed workflow has failed.
• T16-L03 · Test a Tool on Your Own Work Before Your Team Depends on It: checking the tool on the rung you picked.

Tools

• Claude: Taught. A shared project holds the instructions, the test files and the chat.
• ChatGPT: Catalogued. Shared projects do the same job if your team already uses them.
• PubMed: Taught. A saved search with an email alert is the lab example's rung 0.
• n8n: Catalogued. The fixed-workflow tool for rung 3. To run it yourself, use Heidelberg AI Desk (Catalogued).