# From plan to worker: the four promotions (/docs/agent/from-plan-to-worker) --- type: Procedure title: "From plan to worker: the four promotions" description: "How a counted, proven workflow becomes an agent: the readiness signal, and the four things you already did by hand that get promoted into a spec, an eval, exits and a runtime, from The AI Agent Factory." status: stable order: 4 generated: { by: "process:claude-code", at: 2026-09-15T11:48:08Z } verified: - { by: "human:rrizwan98", at: 2026-09-03T08:20:00Z } - { by: "human:rrizwan98", at: 2026-09-09T07:47:26Z } - { by: "human:rrizwan98", at: 2026-09-15T11:48:08Z } sources: - id: af-30 title: "From One-Off to Worker: The Handoff to Manufacturing. The AI Agent Factory, Panaversity, 2026" resource: https://agentfactory.panaversity.org/docs/from-one-off-to-worker ksor: audience: [public] owner: human:rrizwan98 approval: { by: "human:rrizwan98", at: 2026-09-15T11:48:08Z } trust_tier: human-reviewed build_id: sha256:4d4bff09bd0a1dcff0a0a50f20f7ef514fc471e2b1f9e81e0e7b6150b93c0793 dirty: true --- The rule that makes building an agent smaller than it sounds: **you do not build a worker from scratch; you promote a solution you have already proven.** [^af-30] Every time the run was done by hand, it was, without anyone noticing, working out exactly what the worker would need to do. Manufacturing is taking that proven solution and making it permanent. [^af-30] ## The signal: is it ready to cross? Gate 2 gave half the signal: often, same shape, worth it. The other half is the one people skip: **has the task actually been solved well yet?** The full signal has two parts: [^af-30] 1. Gate 2 says Mode 2, and 2. the task has been solved cleanly, by hand, enough times that **the method has stopped changing**. The test is plain: the last three times, was it done the same way? If yes, the shape is stable and the worker has been found. If each run still differs, keep solving it by hand; those repetitions are the research, not the waste, because each one turns up an edge case, a better step order, a check that matters. [^af-30] When the person has no runs written down, or the business is too new to have three, [understand the work](understand-the-work.md) says what to do: draft three runs from their own words and have them corrected or replaced. A proposed run is labelled as proposed and counts toward this signal only once the person has confirmed it as something they actually did. In this record's terms: the step table you counted is that research written down. If the AI, DECISION and TYPING tags on it stopped moving between runs, it is ready. ## The reframe: the worker is hiding in the work A good by-hand run already produced a brief, an output in a clear shape, a check, and a saved result. Manufacturing is two moves: **harvest** those pieces, then **harden** each one so it can run without you. The book is clear-eyed about the second move: designing the exits, building an eval that grades itself and standing up a runtime are genuine engineering, not just writing down what you already do. The reframe spares you the blank page; it does not make the build trivial. [^af-30] The economics flip at the same point: labour as a **task** is spent every time; labour as an **asset** is spent once and produces results again and again. [^af-30] ## The four promotions | What you had by hand | What it becomes | This room's page | | --- | --- | --- | | Your brief (works from, want at the end, done when) | A **spec** the worker reads on every run | [write the spec](write-the-spec.md) | | Your own eyeball check | An **eval** that grades the worker automatically | [evals before shipping](evals-before-shipping.md) | | You watching and redirecting | The worker runs the loop and **escalates** at the edges | [build the text agent](build-the-text-agent.md), [loop and harness](loop-and-harness.md) | | A session you open and close | A **runtime** the worker lives on | [FastAPI, Docker, Vercel](fastapi-docker-vercel.md) | Four upgrades, each one a thing you already understood from doing it by hand. [^af-30] Two of them deserve their own warning from the book: **Promotion 3 is about the edges, not the routine.** The routine is the easy part; your by-hand method already handles it. The hard part is the unusual input the method never met, and the answer is almost always: stop and call a human. A worker that writes code stops and asks when its change breaks the tests; a worker that pays invoices flags anything above a set amount instead of paying it. Handle the routine, escalate the exception. Skip this and the worker will one day handle the one case it should have flagged, confidently and wrongly. [^af-30] **Promotion 4 is what makes it a worker at all.** Without a runtime that keeps it alive and remembering when nobody is there, there is no worker, only a session opened by hand, which is where you began. [^af-30] Those exits are the same thing this record calls gates: the DECISION rows of your step table are where the worker stops and a person decides. ## The fork: who is the worker for? Making it permanent forks two ways, decided by one question: **who relies on the worker?** For you alone, the lighter road is a personal harness, where the spec is your own notes and the escalation is the worker messaging you. For an organisation, the road is a Digital FTE, where the spec is shared and reviewed, the eval is a gate the whole team trusts, the escalation goes to a named person and the runtime is real infrastructure. [^af-30] This room builds the second road in its **basic** form: one text-only agent on the OpenAI Agents SDK, one job, with a spec, a small eval, named exits and a runtime you can reach over HTTPS. What it does not do is on the [overview](overview.md). ## Budget for one thing before you cross A durable worker runs on the API, where every model call is metered and paid for, on both roads. Crossing turns "thinking" from something bundled into a chat subscription into a real per-call cost, so the worker has to repay not just the build time but the model bill it runs up every time it works. [^af-30] The agent this room builds runs on your own API key. ## Your blueprint, four lines Before the next page, fill this in for the run you counted: 1. **Proven?** The last three times, same way? If not, say so and keep solving by hand. 2. **The four promotions, one line each:** brief to spec; check to eval (two or three example inputs with known-good answers); you to exits (the one case it must stop and call a person); session to runtime (where it lives). 3. **The fork:** for you alone, or for an organisation. If all three fill in, you are holding the blueprint for a worker. [^af-30] Before line one becomes a spec, [choose the shape](choose-the-shape.md) says what kind of worker fits, and [design the experience](design-the-experience.md) says what a person will need to trust it. [^af-30]: From One-Off to Worker: The Handoff to Manufacturing. The AI Agent Factory, Panaversity, 2026.