# Explore a candidate level for your workflow

The worksheet at https://reedos.dev/gradient_ascent/worksheet/, as text. Seven questions, asked in order, each testing one level from the lowest up. A "settle" answer produces a candidate classification, not a final recommendation. Compare it against the desired automation, final deliverables, and acceptable hands-on effort before choosing. A lower-level option that hands unwanted work back to the user does not satisfy the brief. Then ask all four cross-cutting questions. They do not change the level, they add cautions. A question that does not fit the shape of the job (the documents question, for a job that sorts messages and acts on them) is answered no.

## The seven questions that classify a candidate design

### 1. Can the job be done by a fixed rule, a search, or a plain form, with no model involved at all?

Consider fixed logic only if the complete workflow meets your automation and hands-on effort requirements. Technical feasibility alone does not establish the best fit.

- **Yes. A rule, a lookup table, a search, or a plain form covers every case.** Settle on level 0, Conventional software (https://reedos.dev/gradient_ascent/levels/0/). A fixed rule, a search, or a form does the job on its own. No model is involved, so there is nothing extra to build, test, or pay for.
- **No. It needs to understand or produce language, or use judgment a rule cannot capture.** Go on to the next question. The input is language you cannot write rules for, and a wrong answer is cheap to catch.

### 2. Does one request, written well, with everything the model needs already in it, reliably get a good answer?

This covers rewriting, drafting, or answering a question when all the facts are already in your message.

- **Yes. One clear message, sent once, does it.** Settle on level 1, Direct prompting (https://reedos.dev/gradient_ascent/levels/1/). One well-written request, sent once, reliably gets a good answer. There is no second step, and no outside information to gather first.
- **No. It needs information the model was not given: documents, current data, or something specific to us.** Go on to the next question. The right document or the right current fact has to be found and handed to the model before it can answer. Nobody can write it all into a single request ahead of time.

### 3. Does finding the right information and putting it in front of the model answer this, where one search or one set of documents is enough?

This covers answering from a manual, a knowledge base, or a set of notes, where a single lookup finds what is needed.

- **Yes. Hand it the right document or search result and it answers well.** Settle on level 2, Added context (https://reedos.dev/gradient_ascent/levels/2/). Finding the right information and giving it to the model answers this. One search or one set of documents is enough; nothing has to happen in a fixed sequence of steps.
- **No. It takes more than one step, or the steps have to happen in a set order.** Go on to the next question. More than one retrieval is involved, or the steps have to happen in a fixed order, so something has to hold that order instead of leaving it to a single prompt.

### 4. Can you define the steps and allowed branches in advance, including how model outputs choose among those branches?

This covers sorting inputs into categories, chaining prompts, and checking drafts. A model can select a predefined branch; software owns the available paths and stopping rules.

- **Yes. Software defines the steps and branches, even if a model helps choose a branch.** Settle on level 3, Workflows (https://reedos.dev/gradient_ascent/levels/3/). Software defines the steps, routing rules, and stopping conditions. Model outputs can select among those predefined paths without creating an open-ended agent loop.
- **No. It has to act on the world while it works: look something up live, run code, or operate something.** Go on to the next question. Writing the steps down in advance is not enough once the task has to reach outside itself while it runs: something has to be looked up live, run, or operated, not just described.

### 5. Can the model do this by picking one bounded action (calling a function, running a lookup, clicking one thing), with your code carrying out that action and stopping there?

The model chooses which action to take and with what details, but only one action, and your code performs it and hands back the result.

- **Yes. One action; your code runs it and the task is done.** Settle on level 4, Tool use (https://reedos.dev/gradient_ascent/levels/4/). The model can do this by picking one bounded action: a lookup, a function call, a click. Your code carries out that action and returns the result; the model does not chain actions together on its own.
- **No. What happens next depends on what the last action returned, and the model has to decide that for itself, more than once.** Go on to the next question. The next action depends on what the last one returned, so the model has to choose again and decide when to stop.

### 6. Can the steps NOT be known in advance, so the model has to plan, act, look at the result, and decide for itself what to do next and when it is finished?

This is the difference between following a plan you wrote and working one out as it goes, the way debugging or open-ended research does.

- **Yes. It plans, acts, checks its own result, and decides for itself when it is done.** Settle on level 5, Agent loops (https://reedos.dev/gradient_ascent/levels/5/). The steps cannot be known in advance. The model has to plan, act, look at what happened, and decide for itself what to do next and when it is finished.
- **No. Even one model working alone in a loop is not enough for this.** Go on to the next question. A single model, even one working alone in a loop, cannot cover this. The work needs a second, independent perspective, more than one agent's worth of room, or longer than one sitting.

### 7. Does the work need to be split across more than one agent or checked independently, or does it have to start on its own or keep running for a long time?

Pick the closest answer. "Independent" means an agent with its own access, not a second pass by the same one.

- **It is too big for one agent to hold, or the subtasks cannot be known until the work is split among several agents.** Settle on level 6, Teams of Agents (https://reedos.dev/gradient_ascent/levels/6/). The subtasks cannot be known until the task is read.
- **It needs a second, independent agent to check the work, with its own access: one agent checking itself shares its own blind spots.** Settle on level 6, Teams of Agents (https://reedos.dev/gradient_ascent/levels/6/). One reviewer shares the author's blind spots.
- **It has to start without being asked, run on its own schedule, or keep going for days or longer.** Settle on level 7, Always-on agents (https://reedos.dev/gradient_ascent/levels/7/). The work outlives one context window or one sitting.

## The four questions that change the advice

### 1. If the model gets this wrong, what does that cost?

- **Not much. Someone notices quickly and it is easy to fix.** No extra caution.
- **Real rework, a bad customer moment, or a delay before someone catches it.** A wrong answer here costs real time or trust. Check the work before it goes out, and keep a record of what was decided and why. Read: https://reedos.dev/gradient_ascent/techniques/reviewing.md, https://reedos.dev/gradient_ascent/techniques/ops.md
- **Money, legal exposure, safety, or something that cannot be undone.** A wrong answer here is expensive or dangerous. Keep a person in the loop before anything ships, and be able to say why the model was trusted with it. Read: https://reedos.dev/gradient_ascent/techniques/human-in-the-loop.md, https://reedos.dev/gradient_ascent/techniques/safety.md

### 2. How easily can someone check the result before it is used?

- **Easily and fast: a glance, or a simple test, confirms it.** No extra caution.
- **It takes real effort: reading closely, or running it, to know if it is right.** Build the check into the process instead of relying on a read-through. A standing eval set catches drift a one-off spot check misses. Read: https://reedos.dev/gradient_ascent/techniques/evals.md
- **It is hard or impossible to check: there is no ground truth, or checking takes as long as doing the job.** When nobody can easily confirm the result, treat it as unverified until proven otherwise, and keep a person responsible for what happens with it. Read: https://reedos.dev/gradient_ascent/techniques/reviewing.md, https://reedos.dev/gradient_ascent/techniques/human-in-the-loop.md

### 3. If the action turns out to be wrong, can it be undone?

- **Yes, easily: nothing has shipped, been spent, or changed yet.** No extra caution.
- **With some effort: it can be corrected, but it takes real work.** Log every action taken so a wrong one can be traced and reversed without guessing what happened. Read: https://reedos.dev/gradient_ascent/techniques/ops.md
- **No: money moved, a message went out, or something was deleted.** An action that cannot be undone needs approval before it happens, not review after the fact. Read: https://reedos.dev/gradient_ascent/techniques/human-in-the-loop.md, https://reedos.dev/gradient_ascent/techniques/safety.md

### 4. Does private or sensitive data leave your own machine to do this?

- **No: everything runs on infrastructure you control.** No extra caution.
- **Yes: a cloud model or a third-party service sees it.** Know what leaves the machine and who can see it. Check the provider's data-handling terms before sending anything sensitive. Read: https://reedos.dev/gradient_ascent/techniques/safety.md