The simplest thing that works: chat, automation, app or agent

2. Eleven repetitions do not automatically require an agent

You have completed the same task by hand eleven times this month. In a lab, it is a weekly check for new papers; in a company, it is a Friday status report. You promise to make the next run easier for colleagues. One colleague suggests an app. Another suggests an agent that can search, decide, and write by itself.

Both could be built. Both may be the wrong answer.

The task might take ten minutes with a saved prompt. Its inputs may change every week, making automation brittle. The underlying process may still be unclear. Building first would convert that uncertainty into code, credentials, maintenance, and repeated failures that affect everyone using the result. A dropped correction could misdirect a lab group's reading; an invented total could distort a team's plan.

At Level 3 Builder, colleagues depend on something you create. Start with the simplest version that produces a useful result, and add another layer only after it fails a measurable requirement. The goal is not the most capable system. It is one you and a substitute can still maintain on a difficult day.

3. After this you can

• Choose between a chat, saved prompt, automation, small app, and agent.
• Estimate each option's setup time and continuing upkeep.
• Identify when unattended execution or shared use changes the responsibility level.
• Write a one-page decision before building anything.

4. Prerequisites

• T01-L02 · Trust but verify.
• One recurring task you understand well enough to describe.
• A rough count of how often it occurs and how long it takes manually.
• No software account is required. This book is a decision exercise, not a build tutorial.

Use only public, synthetic, or explicitly approved examples. Do not connect live inboxes, databases, instruments, customer systems, or credentials while comparing options.

The decision may describe a real recurring task, but test candidate behaviour with synthetic fixtures. Connecting a candidate to real systems or data belongs at Level 4, after the Level 3 ownership, failure, and handover questions have answers.

5. The idea in one page

Complexity is rarely paid only once during setup. It is paid through updates, broken connections, changed inputs, access reviews, monitoring, support, and handover.

Five options with honest costs

These are planning ranges, not promises. A regulated environment, difficult integration, or missing owner can turn a small build into a long project.

Two questions decide most cases

Does it need to run when I am not there? If no, stay with chat or a saved prompt unless another requirement forces a change. If yes, consider an automation with a known path before considering an agent.

Does anyone else depend on the output? If yes, the work needs ownership, documented inputs, failure handling, access rules, and a handover path. A personal shortcut has become a shared product.

Use a third check before moving upward: What measurable requirement did the simpler option fail? “An agent is more interesting” is not a requirement. “The task arrives overnight and must be ready by 08:00” is. “Three colleagues need the same current status” may justify an app. “The correct next source varies and cannot be expressed as stable rules” may justify a bounded agent experiment.

The ladder is not a maturity score. A saved prompt that reliably solves the job is not less professional than an app. It is a better design when it carries less unnecessary upkeep.

6. The worked example: one task, several solutions

Compare a complete operating month

Setup time is visible and often smaller than continuing work. Compare each candidate over a normal month, including run time, review, failure recovery, access changes, updates, user support, and handover. Use a simple estimate rather than false precision:

monthly effort = supervised run time
               + review time
               + expected failure recovery
               + access and update work
               + user support

Record assumptions such as four runs per month, one input change per quarter, and two reviewers. The estimate prevents a five-hour build from being compared with only one ten-minute manual run. Keep it beside the decision so observed effort can replace assumptions later.

Define a stop and rollback before choosing. A chat stops at a reviewed answer. An automation stops and alerts on missing input. An app rejects an invalid state. An agent limits tools, attempts, elapsed time, and actions requiring approval. The fallback may be the saved prompt, previous version, or manual checklist. If only the builder can recognise or recover failure, the candidate is not ready for colleagues to depend on it.

Convenience alone is not dependency. Several colleagues can each run and review a saved prompt. Dependency begins when they rely on one maintained source, shared state, schedule, or service. At that point name the service owner, content owner, and substitute.

Use one reproducible decision sheet

Use the same sheet for every candidate so an attractive build does not receive easier assumptions. Copy it into a plain-text file and keep every answer inside that one file:

TASK AND USEFUL OUTPUT:
OWNER / SUBSTITUTE / REVIEWER:
FREQUENCY AND OBSERVATION WINDOW:
APPROVED INPUTS (no live data in this exercise):
DEPENDENT USERS AND FAILURE CONSEQUENCE:
MUST RUN UNATTENDED? WHY?:

CANDIDATE 1:
  setup estimate / monthly effort estimate:
  failed-input behaviour / stop / rollback:
CANDIDATE 2:
  setup estimate / monthly effort estimate:
  failed-input behaviour / stop / rollback:
CANDIDATE 3:
  setup estimate / monthly effort estimate:
  failed-input behaviour / stop / rollback:

DECISION PARAGRAPH (chosen option, two rejected options, evidence):
RECONSIDER WHEN (measure + threshold + observation window):
TEN CHECKS: task, owner, frequency, inputs, output, reviewer,
            failure consequence, monthly upkeep, rejected alternatives, trigger
SCORE: __/10 (owner and failure consequence must both pass)

Label each number observed, estimate, or unknown. Hold the task, fixture, acceptance checks, and observation window fixed while comparing candidates. A second person must be able to recalculate the monthly totals from the entries and reach the same pass or revise decision. If an important field is unknown, keep the choice supervised rather than replacing the blank with a favourable guess.

For the supervised saved-prompt candidate in both framings, use this fixed instruction. Preserve it with the fixture so the handover run tests the same thing:

Format only the supplied pipe-separated records as a Markdown table.
Use the supplied header as the output header. Preserve provided values exactly.
Write "not provided" for a missing or non-value field such as "pending" or "[missing]".
Do not search, infer, calculate a total, or add a record.
After the table, list every "not provided" field under REVIEW REQUIRED.

Lab framing: the weekly literature check

Mira checks a public literature index every Friday for papers related to a fictional project. She records title, source link, and one sentence explaining possible relevance. A human decides what to read and cite.

Mira asks the two questions. The check does not need to run without her, and nobody needs the result before she reviews it. The saved prompt is therefore enough today. It standardises the output while keeping source selection and judgement with her.

She records one possible future trigger: if the weekly search itself consistently takes more than 30 minutes and the public source offers a stable approved interface, she will test a read-only automation. An agent is considered separately and rejected: choosing searches, following related terms, and deciding when to stop would add tool, stopping, quality, and cost controls, but no current requirement needs flexible tool choice.

Before accepting that decision, Mira tests the saved-prompt option on four synthetic records:

title | link | note
Northstar fixture study | https://example.org/northstar | relevant comparison
Harborlight methods note | https://example.org/harborlight | out of scope
Cedar assay correction | https://example.org/cedar | correction notice
Untitled record | [missing] | apparently relevant

The prompt must preserve each supplied link, mark the unrelated record as out of scope, keep the correction attached to its status, and label the missing link for review. Mira repeats the run after changing the output heading. If those stable cases pass and the work still takes less than 30 minutes, the saved prompt satisfies the current requirement.

She stores the four lines, the prompt text, and the expected treatment in the decision sheet. Her substitute reruns exactly those inputs in a new chat. This does not prove that a model can judge scientific relevance; it proves only that the proposed formatting step preserves supplied evidence and exposes missing input. Source selection and the decision to cite remain human work.

Company framing: the weekly status report

Jonas prepares a Friday report from three synthetic team totals and a short note from each workstream. The report is reviewed internally; it is not sent to customers.

Today, only Jonas produces the report. A saved prompt is the smallest useful choice. If several workstream owners later need to maintain shared status, a small app may become justified. If the report must appear unattended at a fixed time, a bounded automation may be appropriate. An agent that decides whom to chase and how to interpret gaps is rejected because it adds unnecessary authority and variability. Neither future change automatically calls for one.

Jonas also runs a failure drill before colleagues depend on the method. He removes one workstream total and changes another field from a number to pending. The saved prompt must mark both gaps instead of calculating a plausible total. He gives the prompt, synthetic inputs, expected output, and recovery checklist to a colleague who was not involved in the decision. The colleague can complete and verify the report without asking Jonas which hidden assumptions to use.

His fixed company fixture has the header workstream | total | note and the rows North | 12 | on track, East | pending | supplier reply due, and West | [missing] | [missing]. The expected report preserves 12, labels the East total not provided, labels both West fields not provided, and omits any combined total. Jonas records the exact lines and expected treatment in the same fields Mira used. Both framings therefore test the same behaviour: preserve provided values, expose absence, stop unsupported inference, and require review.

That handover test distinguishes a reusable solution from a personal trick. If the test fails, Jonas improves the instructions before moving upward. Building an app would hide the unclear rule behind an interface, not solve it.

Work the escalation decision with observed evidence

Three months later, Jonas does not begin by asking which product to buy. He opens the observation log and rewrites the requirement. The fictional workstreams now have four owners. Two owners send updates late, Jonas copies their entries into the report, and everyone asks which version is current. The report still does not need to run unattended. The changed requirement is therefore shared entry and one visible report state, not autonomy.

He separates measured work from guesses before comparing options. Over four representative weeks, his log shows these synthetic observations:

The app does not clearly win on monthly time. Its value would be controlled shared state, while its cost would include permissions, validation, support, and recovery. Jonas marks every app figure as an estimate because no app has been tested. He also keeps setup effort separate: an estimated three-day build cannot be hidden inside a favourable monthly total.

Next he runs a minimum-change test. Could a shared approved form plus the existing saved prompt solve the new requirement without a custom app? In a synthetic trial, each owner submits the same fields by Thursday afternoon. Jonas exports one table, checks missing values, and runs the prompt. The trial has explicit pass conditions:

• all four owners can submit without Jonas rewriting an entry;
• one row is visibly the current submission for each workstream;
• a missing total remains missing rather than being inferred;
• Jonas can produce and review the report in no more than 35 hands-on minutes;
• a substitute can recover by using the export and saved prompt if the form is unavailable.

If the trial passes for four consecutive reports, Jonas keeps it. This is not reluctance to build; it is evidence that the smaller intervention meets the changed requirement. If version disputes continue or access rules cannot represent the required owners and reviewer, he has identified a specific failure that a small app could address.

Now change only one condition: leadership requires a reviewed draft in the queue by 07:30 every Friday, before Jonas starts work. Shared state alone no longer solves the job. Jonas first compares a fixed automation, not an agent, because the steps remain known: check required fields, reject incomplete input, calculate only declared totals, draft fixed sections, and place the result in a review queue. The workflow must stop and alert when a required field is absent or has the wrong type. It must never invent a value to meet the deadline.

An agent would earn a trial only if representative failures show that the next valid step varies in a way stable branches cannot handle. Even then, Jonas would write the boundary first: approved input location, read-only access where possible, allowed actions, attempt and time limits, required approval, run log, stop conditions, and the fixed automation or manual checklist as rollback. “It can chase missing updates” is not enough; that phrase conceals decisions about whom to contact, what information to expose, how often to retry, and when to stop.

This worked escalation shows how the ladder should be used. A new user-dependency requirement can justify shared state without unattended execution. A new timing requirement can justify automation without flexible tool choice. Only evidence that the path itself cannot remain fixed creates a reason to evaluate a bounded agent. At each step, change the solution because a named requirement changed or a simpler test failed—not because the more complex option became available.

The one-paragraph decision

Write the conclusion before building:

We will use a saved prompt for the weekly status report because one owner runs and reviews every report, the input changes each week, and a fixed format removes the main repetition. We reject an automation for now because unattended execution is not required, and we reject an app because no other user needs shared state. We will reconsider automation if manual input collection exceeds 30 minutes for four consecutive weeks.

The paragraph names the chosen option, two rejected options, evidence, and a review trigger. That is enough to stop interesting technology from silently becoming the requirement.

Score the decision, not the technology

Use ten yes-or-no checks. A defensible choice names the task, owner, frequency, inputs, output, reviewer, failure consequence, monthly upkeep, rejected alternatives, and measurable reconsideration trigger. Eight checks must pass, and the owner and failure-consequence checks are mandatory. The score does not prove the choice will never change. It proves that the choice can be challenged using visible evidence rather than enthusiasm.

Keep a small observation log after the choice enters normal use. For four representative runs, record elapsed hands-on time, review time, one input exception, one failed or delayed step, and whether the final output was accepted without repair. The log is not a second deliverable. It is evidence for the review trigger already written into the decision note. A saved prompt that takes twelve minutes every week and needs no repair is still doing its job. A supposedly simple automation that needs forty minutes of recovery twice a month is not.

Review the decision when the trigger occurs, not merely because a new product appears. Compare the observed month with the original assumptions and change only the requirement that the evidence disproved. If three colleagues now need shared state, compare the prompt with a small app. If the task must run overnight, compare it with a fixed automation. If the path itself varies, first list the decisions that cannot be expressed as deterministic branches; only then test a bounded agent. Record why the previous option no longer passes and preserve it as the rollback path where practical.

Finally, repeat the handover test after any escalation. Give the instructions, synthetic fixture, expected result, failure signal, and recovery step to a colleague who did not build the solution. If that person cannot operate it without private explanation, the added capability has not yet earned its maintenance cost.

7. What goes wrong

You build the interesting thing

Symptom: the project begins with a framework or product choice rather than a measurable job.

Fix: state the input, output, frequency, owner, review, and failed requirement before naming a tool.

You count setup but ignore upkeep

Symptom: a one-day build is called cheap even though it needs weekly fixes and only one person understands it.

Fix: estimate a normal month: input changes, access, monitoring, failed runs, support, and handover.

You automate rare work

Symptom: more time is spent maintaining the solution than completing the task manually.

Fix: multiply manual time by realistic frequency. Keep an occasional, changing task in chat or a checklist.

You automate a moving process

Symptom: every run needs an exception because the team has not agreed on the steps.

Fix: run the task manually with a saved template until inputs, decisions, and exceptions are stable.

You skip the chat version

Symptom: after building, you discover that reviewers disagree about what a good result means.

Fix: complete several supervised chat runs first. Use the failures to define requirements and tests.

You confuse autonomy with value

Symptom: the solution is praised for acting alone although every output still needs repair.

Fix: measure accepted outcomes after review, not steps performed without a person.

Nobody owns the simple solution

Symptom: the team chooses a low-maintenance prompt or automation but assumes it needs no owner.

Fix: name who updates instructions, checks failures, controls access, and hands the work over. Simple means less upkeep, not zero responsibility.

Estimates look more certain than the evidence

Symptom: a comparison claims an exact annual saving before anyone has measured normal runs or failures.

Fix: use ranges, state assumptions, and record actual effort for four weeks before making a larger investment decision.

8. Do it yourself: a 30-minute decision note

Minutes 0–5: name one recurring task and its current owner. Record frequency and approximate manual time.

Minutes 5–10: define the input, useful output, and human check. If you cannot define these, choose chat for exploration and stop the build decision.

Minutes 10–15: answer: must it run without you, and does anyone else depend on it? Name what happens when it fails.

Minutes 15–22: compare at least three options. Include setup, monthly upkeep, access, failure handling, and handover. Use ranges when you do not know exact values.

Minutes 22–27: recalculate the monthly comparison from the sheet alone and identify the stop and rollback for each candidate. Resolve any hidden assumption in the same sheet, then choose one option and reject two. Tie every reason to a requirement, not preference.

Minutes 27–30: add one measurable review trigger, such as task frequency, manual time, number of users, or a repeated failure the chosen option cannot handle. Score the note against the ten checks in section 6.

9. Exit check

Deliver exactly one artifact: a passing decision test: the completed one-page note plus its ten-check score, with at least 8/10 checks passing. The owner and failure-consequence checks are mandatory.

It passes when another person can identify the task, owner, frequency, inputs, output, reviewer, need for unattended execution, dependent users, upkeep, failure consequence, two rejected options, and measurable trigger for reconsidering the choice. If the score is below 8/10, revise the same note; do not submit a second artifact.

10. Rule to remember

Every extra layer is something you will maintain on a bad day.

11. Further reading & tools

• Taught: T01-L02 · Trust but verify — sets the checking level for the output you choose to create.
• Catalogued: T05-L01 · Your first automation — builds a fixed trigger-and-action workflow when unattended execution is justified.
• Catalogued: T06-L02 · A tool from a prompt — explores a small app after shared use becomes a real requirement.
• Catalogued: T07-L03 · Your first agent — compares a bounded agent with a deterministic workflow.
• Catalogued: NIST AI Risk Management Framework (opens in a new tab) — a broader voluntary framework for mapping and managing AI risk.
• Catalogued: Tools index — product references to consult only after the solution type and boundary are clear.