Understand the work: five components, the window test, the delegation map

The three gates said whether the run should become a worker at all. This page is about the work itself, before any tool is placed in it. The AI Agent Factory opens with one sentence and this room keeps it: the output is not the verdict. A good result does not prove a step was safe to hand over, and a bad one does not prove the work is impossible. What decides is the structure underneath: which step, what an error there costs, who answers for it, and when a symptom started. ¹

Every page after this one assumes you did this work. The spec needs the task definition, the tool bodies need the numbers, the approval gates need the ownership decisions, and the evals need the steps written down.

The unit is the step, not the session

"I use AI" is a personal habit. It varies by mood and time, and it leaves when you are on leave. "Our workflow uses AI" is a repeatable process where AI does specific named steps every time, the same way, whoever is at the keyboard. Only the second one compounds, and only the second one can be wrong in a way that keeps being wrong. ¹

So the unit here is the step. A session is judged afterwards, by whether you liked the result. A step is decided in advance, on grounds that do not change when the output happens to look good. ¹

Turn the request into a task definition

Real work rarely arrives as a clean brief. It arrives as a long document, a thread of half-formed messages and something said in a meeting. Sometimes it is one sentence: "we need better reporting", which nobody can build and nobody can check afterwards. ¹

A business need becomes a task definition once five things are settled: ¹

Each answer is something you can build against and check completion on. Each one still missing is a clarifying question you owe somebody before the work starts, not a blank for the model to fill. The book's prompt for this ends with the instruction that carries the weight: "Where I have not told you, say so instead of filling it in." Asked to define a task, a model will define one, and every slot you never specified closes quietly at a plausible default. ¹

Ask for structure, not a summary. A summary tells you what a document says. A structure gives you rows other people can work from. The book's extraction prompt asks, for every requirement, a short label, the exact section it comes from, whether it is already answered, and whether it is ambiguous enough to need a clarifying question, returned as a table. The source column is what lets somebody who was not in the room check the list. ¹

Then attack it. Extraction finds what was written, not what was meant. Review the list: which requirements are ambiguous as written, which could two people read differently, which imply a requirement the document states only indirectly. An ambiguity caught here costs a question. Caught after the build, it costs the build. ¹

The test for a requirement is decidability: if you cannot write a check for it, it is not decidable yet, however specific it sounds. "Delivered promptly after month end" reads like a requirement and is not one, because two days and two weeks are both prompt to somebody. ¹

This is where the spec comes from. Its acceptance criteria are these checks, written down.

How to ask for the blanks

The blanks are questions, and the person answering them is usually not an engineer. Ask them the way the spec page runs its interview: nothing skipped, gathered into rounds rather than one question per message, and three answers offered with each question, the third always "in your own words". Two more rules belong to this step:

• Plain words, and the technical blanks last. Ask what the work is, who does it, how often, what done looks like and where a person must say yes, in the person's own language. Do not open with which system holds the data, which platform the shop runs on, a repository path or a key. Those are connection details: write a placeholder into the map ("the ticket system", "the store"), mark it as a connection to confirm, and ask for the real name only when the tools are wired, which is the deploy step.
• Proven runs: propose, then correct. The gates on the next page want three runs done by hand. When the person has none written down, or the business is new, draft three runs from what they have told you, in their words, and ask them to correct each one or replace it with a real one; a rough date, or a screenshot of the conversation, is enough. A proposed run is labelled PROPOSED in the map until the person confirms it, and a golden case built from one carries that label in its origin. What you may never do is present a proposed run as a real one, or proceed on three runs the person has not confirmed.

If a result matters, compute it. Never write it.

Planning mixes two things a model handles very differently. Synthesis it does well: gathering considerations, structuring options, holding many factors at once. Calculation is different, not because models cannot add but because you cannot tell from the page whether they did. A written figure and a calculated one look identical, and neither shows its working. ¹

So the rule is about consequence, not capability: a rough figure in a brainstorm can be written; a figure somebody will act on gets computed. The book's prompt separates computation from recommendation, in that order, and asks for the assumptions, so that somebody can disagree with the recommendation without redoing the arithmetic. ¹

In this room that rule has a home: a number the worker's answer depends on is computed inside a tool body and returned in the tool's result, never produced by the model in prose. That is rule 9 of the skill and the reason the worked example never lets the model do money arithmetic. The prompting guide says the same from the other side: when numbers are involved, make it run code and show the code.

The window test

An operations lead once asked for a whole capacity plan in one request: the trend, the throughput and next quarter's headcount. The answer was well structured, internally consistent, and recommended hiring three people. The team was under a hiring freeze announced two weeks earlier. Nothing in the data was wrong. One step of the plan needed an input that existed nowhere the machine could reach: a decision made in a meeting. ¹

That is the boundary. Synthesis steps run on information you can supply, so they delegate well. Judgement steps run on information you cannot supply, or would not: risk appetite, a freeze, which client will tolerate one more delay. They stay human, not because judgement is sacred but because the inputs are unavailable, and a model with unavailable inputs does not stop; it fills the gap with what such a decision usually looks like, at the same confidence as the part it computed. ¹

The question to ask of any step: ¹

Could I put everything this step needs into the window? If not, the step is mine.

The reciprocal matters just as much and is the half people drop. Passing the window test makes a step eligible for AI. It never makes it owned by AI. A step whose inputs all fit still has to survive the three criteria below, and plenty do not. ¹

Research is a synthesis step, so run the test on it too. A model's knowledge stops at a date; everything after that date is outside the window in exactly the same sense, and asking for it produces the freeze failure again: not a refusal, a confident answer built from what such a fact usually looks like. Split research questions before you ask them: ¹

The rule: for anything current, ask for a source you can open. Never a confident answer. ¹ It is also the rule this record is built on, and the reason every page here names the page it came from.

Three decisions for every step

This is the core of the method. Every step takes three decisions, and mixing them is what builds a map that looks reasonable and is wrong. ¹

1. Eligibility. May AI touch this at all? Two gates. May this data enter this tool? Can everything the step needs be supplied? A no at either ends the question, however mechanical the step looks. The first gate is the subject of govern it; the second is the window test above. ¹
2. Ownership. Who owns it? Reversibility, stakes, accountability. The next section. ¹
3. Implementation. What carries it? Decided last, and only for steps that passed the first two. ¹

Keep the third decision out of the second. "This has to be computed" is true and belongs in the implementation column. It is not a reason to hand the step to AI, and using it as one is how a high-stakes calculation ends up unreviewed. ¹

The last row is the one teams skim. A human-retained step is not finished when you write "human" next to it. It needs a named person, a named moment and a named thing they are checking. "A human looks at it" is how a gate goes unstaffed. ¹

In this room the five rows land in known places: a procedure becomes a skill or a tool body, reference becomes the knowledge the worker reads, a calculation becomes a tool body, a standing constraint becomes a line in the constitution or the instructions, and a person's step becomes needs_approval on the tool that would act, with the reviewer named in the spec.

Three criteria decide ownership

Write the steps down in order and classify each one as AI-appropriate, human-retained or collaborative. Ownership is decided by three criteria, and only these three: ¹

• Reversibility. Can the step be undone if AI gets it wrong? A draft can be rewritten; a sent email cannot be unsent. Reversible steps tolerate delegation because the cost of an error is a redo. Irreversible ones do not, because the cost of an error is the error.
• Stakes. What does a mistake at this step cost, not on average, in the bad case? A misfiled label costs a minute. A miscalculated penalty exposure costs whatever the penalty is.
• Accountability. Somebody answers for every step, so the sharper version is the one to use: is this step the call they answer for, or an input they judge before it acts on anything? A step that produces an input somebody judges can be delegated, because the accountability sits at the judging. A step that is itself the decision, or that commits the organisation to something, cannot, because nothing downstream is left to carry it. Accountability never moves onto the machine, because the machine cannot be asked.

Note what is deliberately absent: how well AI performed on this step in your test run is not a criterion. It feels like the most relevant fact available and it is the one that misleads most reliably. ¹

These are three questions, not a score. Usually one of the three decides the step and the other two agree with it. Name that one. Naming the criterion that carried the row is what makes the classification checkable by somebody who was not there, and it is the column an auditor reads. Where the three disagree, the strictest wins: a reversible, low-stakes step that is still the decision somebody answers for stays human. ¹

Two maps, same criteria, different work

The book maps contract review first, because it is the workflow most business teams map first. ¹

Look hard at the penalty-exposure row. Being arithmetic does not make a step low-stakes: that figure feeds the approval, and if it is wrong the approval is wrong. What makes it delegable is that the result is reversible and lands in front of a human at the very next row. Take the approval gate away and the step stops being AI-appropriate, even though the arithmetic has not changed. ¹

The playbook row runs on the same logic. Flagging departures is AI-appropriate here because somebody reads the flags at the next row, where a wrong flag surfaces as a wrong redline and gets caught. Move the same step into a workflow where nothing downstream reads the flags, and it is collaborative instead. The step did not change. What changed is whether anybody is standing after it. ¹

The same three criteria on onboarding documents produce the identical pattern: the mechanical and draft steps delegate, the figure-confirmation step and the irreversible action stay human, and the manager's own voice in the welcome note stays collaborative because it cannot be supplied. Nobody decided that by taste. The criteria decided it, twice, in two domains. That repeatability is the whole argument for having criteria: a map produced by judgement is one only you can produce, on a good day; a map produced by three questions is one your colleague produces the same way and one you can defend a year later. ¹

For a software team the same rows appear under different names: extracting the change list from a ticket, flagging departures from the style rules, drafting the code and the tests, computing the coverage or the cost, approving the plan, approving the release. The worked example is that map for one delivery run, and its two human rows are the two the criteria put there.

Three ways a map goes wrong

Over-delegation almost never happens through carelessness. It happens through reward: the drafting is good week after week, so the next step feels safe. It is not a next step; it is a different kind of step, and drafting quality says nothing about it. Drafting quality is evidence about the draft. It is not evidence about the decision. ¹

Three errors account for most bad maps, and all three look reasonable at the moment they happen: ¹

• Halo delegation. A step gets handed to AI because the previous step went well. The competence was real; it belonged to a different step. Each step is judged on its own, with no credit carried forward.
• The unstaffed gate. "AI drafts, human reviews" stays collaborative only while somebody actually reviews. When the queue is long or the drafts have been good for two months, the review becomes a glance and then a click. A collaborative step with no real reviewer is an automated step, and the map does not say so, because a map records what you designed, not what runs.
• Mapping the tool instead of the work. A team builds a good skill, so the workflow acquires a step shaped like that skill. The hardest to spot from inside, because the workflow genuinely uses the tool well. It is just not the work.

The book's customer-complaint map carries all three at once, and every stated reason in it is true: the summarising skill really is good, the summaries really were accurate, the write really is mechanical. Bad maps are not built from false statements. They are built from true statements about the wrong step. Severity classification handed to AI because the summaries were accurate is halo delegation. "Send without review, low severity only" is over-delegation, because severity was set by the same system that is now deciding it may skip the gate: a step cannot supply its own permission. ¹

The order to check them in: map the work with no tools in mind, classify each step independently, then ask of every collaborative step who specifically is doing the reviewing and when. If you keep one habit from this page, keep that question, asked periodically: are the gates I designed still actually being staffed? ¹

Who owns the map, and when it is read again

A delegation map is written once and then quietly becomes wrong. Not because anybody changed it; because the workflow moved underneath it. A step got added, a reviewer changed roles, volume doubled and the gate that worked at twenty cases a week stopped working at fifty. Three controls decay the same way and none of them produce a signal at the moment they fail: a review gate, a standing instruction, and the map itself. There is exactly one countermeasure for a failure with no signal, and it is not vigilance. It is a scheduled read. ¹

So the map carries two lines most maps do not: ¹

• An owner. One named person, not a team. The owner does not do the work; the owner is answerable for whether the map still describes reality.
• A review date. Quarterly is a reasonable default; sooner if volume, staffing or the regulatory position changes.

The review is four questions and about twenty minutes: has a step been added or removed that is not on the map; for every collaborative step, who reviewed it last week and how long did they spend; has anything changed the volume or the stakes; is every configuration the map depends on still current. The second question is the one that finds real problems, because it asks about last week rather than about policy. ¹

Two signals that sound alike

The book keeps two escalation signals apart, and they call for different work: ¹

The first is about who is exposed. The second is about whether the method has stopped changing. You can hit either without the other. ¹

The one-page map

Everything above fits on one page, and this is the artefact you hand to a colleague, an auditor or whoever takes the workflow over. Copy it and fill it in for a real workflow. ¹

DELEGATION MAP: [workflow name]
Owner: [one named person]   Last reviewed: [date]   Next review: [date]

ELIGIBILITY (both must pass before any step below is mapped)
  Data gate:  [may this data enter this tool? who confirmed, and when?]
  Input gate: [can everything each step needs actually be supplied?]

STEPS
  #  Step   Owner          Criterion (reversibility / stakes / accountability only)   Carried by
  1  ...    AI             reversible, low stakes                                    skill
  2  ...    AI             reversible, checked at step 4                             code execution
  3  ...    Collaborative  high stakes, human judges                                 skill + gate
  4  ...    Human          this step is the decision                                 named reviewer
  5  ...    Human          irreversible                                              named signer

GATES (one line per collaborative or human step)
  Step 3: reviewed by [name], at [when], checking [what specifically]
  Step 4: approved by [name], before [what happens next]

BASELINE (measured before any change)
  Time per run: ___   Revision rounds: ___   Manual steps: ___
  Metric this workflow optimises for: [time | consistency | accuracy | variance]

IF IT GOES WRONG
  Stopped by: [who, and can they act without permission?]
  Scope check: [how do we find out how many outputs were affected?]
  Told: [who, within what time]
  Map change: [recorded here, with a date]

CONNECTIONS TO CONFIRM (placeholders now; real names when the tools are wired, at the deploy step)
  Data lives in: ["the ticket system", "the store", "the billing provider"]   Confirmed by / when: ___

Three lines on that page do most of the work, and they are the three most often missing: the owner, the next review date, and the specific "what they are checking" on each gate. A map without them describes a decision. A map with them describes an operation. ¹

What this page hands to the rest of the room

• The step table from count your own workflow gains three columns: owner, criterion, carried by. The AI and TYPING steps are the candidates; the DECISION steps are where the criteria usually put a person.
• The data gate goes to govern it, which decides whether the information may enter the tool at all.
• The ownership decisions go into the spec as rules and acceptance criteria, and every human row becomes an approval gate the harness enforces.
• The baseline goes into the eval work on evals before shipping, because a worker with no "before" has no improvement to report.

If the map comes out with at least one AI row and a proven run behind it, continue to from plan to worker.