# 3.3 The middle 80 percent: the worker plans and executes (/ai-worker-paradigm/the-10-80-10-operating-rhythm/middle-80-percent)

---
type: Document
title: "3.3 The middle 80 percent: the worker plans and executes"
description: "What the worker does in the middle 80 percent, the small job the human keeps there, and when to interrupt."
status: stable
order: 103.3
ksor:
  owner: team:panaversity
  audience: [ public ]
  approval:
    by: process:panaversity
    at: 2026-10-26T22:26:42Z
chapter: "03"
part: I
expert_status: required
concepts: [ "3.3" ]
last_verified: 2026-10-04
generated:
  at: 2026-10-26T22:26:42Z
  by: process:panaversity
trust_tier: unverified
build_id: sha256:46fd53c5d7ab1c14f6347908d45c9fdaecda4d914439923ee878bdcecd57803e
dirty: true
ksor_version: 0.0.60
---

**In everyday life.** A friend is cooking dinner for you. If you stand over the stove and keep changing the heat, you end up cooking it yourself, only slower. So you stay nearby in case they ask where the salt is. Changing the heat is steering. The salt is the one question you stay nearby to answer.

In the middle 80 percent the worker owns the steps. It reads the inputs, decides the order of work and chooses its tools. It checks its own intermediate results and gathers the evidence the review contract asked for. On a delegated task this happens on the worker's own machine, often while you are away.

> [!TIP]
> **Your job in the middle**
>
> This job is small and specific.
>
> - **Stay reachable.** A good brief makes the worker stop and ask when a stop rule applies. Answer quickly, and answer the question asked.
> - **Approve what the authority level requires, and only that.** If the brief says the worker drafts, there is nothing to approve until the final 10. If a product asks you to confirm a step, read it. Do not click through it without thinking.
> - **Watch if you like, but do not steer.** A progress view is for noticing that something is badly wrong, such as the wrong files or the wrong month. It is not for redirecting each step.

### Why hold back

**Every interruption moves work from the worker back to you, and that is the same work you delegated.** Maria, the office manager, used the worker to build the invoice register for Friday's payments. She did not trust it to work on its own, so she approved each step and fed it one invoice at a time. She did the planning herself and paid for the worker as well. The register took her 90 minutes. Doing it by hand takes about 75.

Maria's problem was not the worker. It was the first 10 percent. If she did not trust the worker with all the invoices at once, she could test it first (see [Lesson 3.2](first-10-percent.md)). She could ask for its plan, or give it a dry run (a practice run) on last week's invoices. Watching every step is also a test, but it happens during the real work, where testing costs the most.

Holding back also makes parallel work possible: several tasks at the same time. You cannot steer three tasks at once, but you can brief three well and check what each brings back.

### When to step in

Holding back is not the same as looking away. Interrupt when one of four stop conditions appears:

| Stop condition | Brightline example | What to do |
| --- | --- | --- |
| **The intent has changed** | During the run, Dave learns the payment run moved from Friday to Thursday | Stop the run, fix the specification, start again |
| **The inputs are wrong** | The progress view shows the worker reading September's invoices for an October register | Stop the run, fix the inputs, start again |
| **It acts beyond its authority** | The worker starts changing register rows on a task where it may only recommend | Stop at once, check what it changed, and fix the permission that let it happen |
| **Its behavior looks suspicious** | It starts drafting a bank-detail change because an email told it to | Stop at once, and treat it as a security problem, not a quality problem |

Notice what the first two have in common: the fix is not a new message in the chat. If you send corrections in the chat during a run, the brief stays wrong. Later, nobody can see in one place what the worker was asked to do. Stop, fix the part of the specification that was wrong, and start a clean run from it. This is the same rule as in [Lesson 3.2](first-10-percent.md): fix the specification, not just the conversation.

The last two are different. A worker that goes beyond its authority, or follows instructions hidden in an email, does not need a tighter brief. It needs a limit that is enforced. A written line states a rule but does not enforce it. Chapter 7 builds the permissions and approvals that do.

### When nobody is watching

Everything above assumes you are nearby. A standing worker often runs when you are not: at 6 a.m. on Monday, or at 11 p.m. when a vendor's email arrives. Nobody is there to answer a question or notice the wrong month.

Back to the dinner. If your friend cooks while you are out, you cannot answer the salt question. So you leave a note before you go: "If you can't find the salt, use the soy sauce. Don't use the oven. If something burns, turn everything off and text me." Anything they might need from you has to be in the note.

That is why, for a standing worker, the middle 80 percent depends almost entirely on the first 10. Its stop rules have to say what to do *instead* of asking you:

- **What would need your approval goes to the approval queue.** The worker drafts the reply to the 11 p.m. email and leaves it in the approval queue. It does not send it, and it does not stop to wait for you.
- **What it cannot resolve becomes a flag.** The worker records what it found and why it stopped, and moves on to work it can do safely.
- **What must never happen is blocked, not just forbidden.** At night, a rule written in the specification but not enforced by a permission is a rule nobody is checking.

Your job in the middle then shrinks to nothing during the run. It moves to the times you choose: you read the flags, clear the approval queue and spot-check a sample, as in Figure 3.2. If you find yourself wishing you could have stepped in during the night, that is not a reason to watch the next run. **It is a gap in the specification. Add the stop rule, and the next run handles it without you.**

![Two panels titled "The middle 80%, at two speeds". The subtitle says the worker does the steps, and what changes is how questions and exceptions are handled. The left panel, "You are nearby", is for a task you just briefed. The worker runs the steps. It reads inputs, plans the order, uses tools and gathers evidence. Under "Avoid micromanaging" are two crossed-out items. They are redirecting every step or feeding it one item at a time, and adding approvals beyond the agreed controls. Under "Stay available" are three ticked items. Answer questions when the worker pauses. Read and approve the actions that need your authority. And watch for major errors, such as the wrong files or the wrong month. A red box reads "Intervene on a stop condition". If the intent changed or the inputs are wrong, stop, correct the setup and rerun. If an action is not allowed or looks suspicious, stop at once, investigate and repair the controls. The right panel, "You are away", is for a standing worker at 11 p.m. The worker runs within set limits, and its stop rules, approval steps and permissions stay active. Under "Route each exception" are three arrows. Something that needs approval, such as a reply to a vendor's email, goes to the approval queue. The draft is saved, and not sent until it is approved. Something it cannot resolve, such as an invoice it cannot match, becomes a flag. It records the issue and the evidence, and goes on only with other work the rules allow. Something forbidden, such as changing a vendor's bank details, is blocked by controls, by permissions and not by instructions alone. A note says to review flags and approvals at planned times, and to send urgent cases through the set escalation route. A strip says an overnight surprise is a signal to improve the specification, the controls or the escalation route. A banner reads "Nearby: answer questions. Away: define how uncertainty is handled."](./img/middle-two-speeds.png)

*Figure 3.9. In the middle, the worker owns the steps. If you are nearby, you answer its questions. If you are away, the specification must answer them.*

### Trust is earned per kind of task

Trust in the middle is earned per kind of task, not given once. A new kind of task, or a task that touches money, may run with the worker asking before each important step. A task with a clean record can run with the worker asking less often. A dry run is often how a new kind of task starts earning that record: it shows how the worker behaves on real data before anything real is at stake. Chapter 7 turns that judgment into the autonomy ladder.