Workflow Design & Diagnosis

Which steps AI should own, what to do when the work starts going wrong, and how to say what it actually does.

Two teams adopted the same AI assistant for the same job: contract review.

The first team mapped the work step by step. AI extracted the clauses, flagged departures from the company playbook, and drafted the redline. A lawyer approved every change. Review time dropped by about half, and the quality held.

The second team pointed AI at the whole process. It drafted well, so they let it approve low-risk clauses unsupervised. Within a month an approved clause created an obligation nobody caught, and the team pulled the tool entirely.

Same product. Same process. Same model. The difference was which steps each team chose to hand over.

Now hold that next to a much smaller failure you have probably had yourself. You asked for something, the answer came back disappointing, and you did one of two things. You concluded the tool could not do it. Or you started changing words at random until something worked.

These look like opposite problems. They are the same mistake, running in two directions.

The second team read a good draft as proof that the step was safe to delegate. You read a bad output as proof that the task was impossible. Both of you took one result and treated it as a verdict on the system that produced it.

The output is not the verdict.

A good result does not tell you the step was safe to hand over. A bad one does not tell you the work cannot be done. What tells you is the structure underneath: which step this was, what it costs if it goes wrong, who is answerable for it, and when the symptom first appeared.

This course teaches you to read that structure. You will map a real workflow step by step and decide who owns each one. You will build something, watch it misbehave, and diagnose it instead of guessing. You will make the fix permanent instead of rediscovering it every Monday. And you will learn to describe the result to a manager, a client, or a risk function in a way that survives the first visible error.

Reading time: about 55 minutes, plus about 40 for the two graded exercises and the project at the end.

The whole course in one minute

Six questions, in the order you will need them:

Stage	The question that decides it
Design	What are the actual requirements, and which numbers must be computed?
Map	For this step: can it be undone, what does an error cost, who answers?
Build	Does this still fit in a prompt-and-iterate loop, or has it outgrown it?
Diagnose	When did the symptom first appear?
Persist	Is this fix a rule, a reference, or a procedure?
Communicate	What does it do, and where exactly is the human gate?

The rest of the course is how to answer each one well.

Before you start

Read AI Fluency first. It teaches Delegation as a personal competency, deciding what AI should do on your own work. This course takes that competency to a workflow a team runs, where the decisions are per-step and a wrong split lands on somebody else.

You should also have met Projects and standing instructions in Claude and ChatGPT 101, Skills in Skills & Connectors, and code execution in Code You Never Write. This course uses all three constantly and teaches none of them.

One question it deliberately does not answer: whether AI may touch this work, or this data, at all. That is Governance, Risk & Responsible Use, the Foundations course straight after this one. This course assumes the answer is yes, and asks how the work should then be split.

📚 Teaching Aid

Click through the slides once before you read, quickly, for the shape. Come back to them afterwards one slide at a time, and use them to teach this material to somebody else. Explaining a delegation map out loud, from slides you did not write, exposes the steps you were still fuzzy about.

Open Full Slideshow

View Full Presentation for Workflow Design & Diagnosis

Try it before you read it

Two minutes, and it will misbehave in a way the rest of the course explains.

Pick a real workflow you or your team runs regularly. An expense approval. A weekly report. Responding to a customer complaint. Onboarding a new client. Anything with more than three steps and at least one decision.

Open an AI assistant and paste this, filling in your workflow:

Here is a workflow my team runs every week: [list the steps in order, roughly, in your own words].

Redesign it with AI inside. For each step, tell me whether AI should do it, and what the new workflow looks like.

Read what comes back carefully, and look for one specific thing.

Find the step in your workflow that cannot be undone. The payment that goes out. The message that reaches the customer. The document that gets signed. The record that gets written to a system other people read.

Now look at what the assistant said about that step. There are only two possibilities, and both teach the same thing.

It handed the step to AI, or was vague about who owns it. Then you have just watched a confident redesign go wrong in the one place that matters most.

It flagged the step and kept it human. Good. Now ask it why:

Why did you keep that step human? What specifically about it made you decide that, and how sure are you?

You will get a reasonable-sounding answer built from what that kind of step usually looks like in general, not from anything about your organisation. It does not know what an error there costs you, whether your regulator cares, or who signs it off. It guessed well.

Either way the missing information is the same. You never told it which step was irreversible, what an error there would cost, or who has to answer for it. It optimised for the only thing it could see: which steps look mechanical.

Hold on to two things you just watched happen:

1. A confident, well-organised redesign can be wrong in exactly the place that matters most, and it will not look wrong.
2. The information it was missing is not information about AI. It is information about your work, and only you have it.

That gap is the subject of Parts 1 to 3. What to do when the output disappoints you rather than quietly over-reaching is Parts 4 and 5. How to describe the finished thing to somebody who was not in the room is Part 6.

The questions this course answers

Eighteen questions, answered in order. Each entry in Answered in jumps to the section that closes it, so this table doubles as the map: read it now, and come back when you want one answer rather than the whole course.

#	Question	Answered in	Objective
1	What actually changes when a personal AI habit becomes a team workflow?	Concept 1	D4.4
2	How do I turn a messy document into requirements, and then break them?	Concept 2	D4.1
3	When must a number be computed rather than written?	Concept 3	D4.2
4	Which steps can AI be given everything they need, and which research needs a source?	Concept 4	D4.2
5	What three criteria decide who owns a workflow step?	Concept 5	D4.4
6	Why do two unrelated workflows produce the same delegation pattern?	Concept 6	D4.4
7	What are the three ways a delegation map goes wrong, and why is good drafting the trap?	Concept 7	D4.4
8	Who keeps the map true after the workflow moves underneath it?	Concept 8	additive
9	What does an iteration loop look like, and what does a broken cycle teach?	Concept 9	D4.3
10	When has something outgrown prompt-and-iterate?	Concept 10	D4.3
11	How do I tell four different causes of bad output apart?	Concept 11	D7.1
12	What order should I check things in, and when is the task itself the problem?	Concept 12	D7.1
13	How do I turn "this isn't quite right" into something actionable?	Concept 13	D7.2
14	Where does a fix belong so it survives past this conversation?	Concept 14	D7.2
15	How do I find friction I have stopped noticing?	Concept 15	D7.3
16	What do I measure, what does it cost, and when do I stop?	Concept 16	D7.3
17	What do we do in the hour after a bad output reaches somebody?	Concept 17	additive
18	How do I state what AI does, to three different audiences, without overstating it?	Concept 18	D4.5

For teachers using this table

Before. Ask the group to answer three of these cold, in writing, before anyone reads. The wrong answers are your lesson plan, and questions 6, 7, and 11 produce the most useful ones.

During. Each numbered concept closes exactly one row. If a session runs short, the rows you did not reach are what to assign rather than what to skip.

After. Any question a learner cannot answer without scrolling up marks the section that did not land. That is a better retention signal than a quiz score, because it is specific.

The Objective column maps each row to the CCAO-F exam blueprint: D4 is Workflow Integration and Solution Design, D7 is Troubleshooting and Optimisation. Rows marked additive are not blueprint objectives, and they are marked so nobody mistakes them for exam coverage. See Certifications.

Part 1: Design the work before you place the tool

1. The unit of value is the step, not the session

There is a real difference between "I use AI" and "our workflow uses AI."

The first is a personal productivity habit. It lives in your head, it varies by mood and by how much time you have, and it disappears when you are on leave. The second is a repeatable process a team runs, where AI performs 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.

That is why the unit of this course is the step, not the session. A session is something you judge afterwards, by whether you liked the result. A step is something you decide about in advance, on grounds that do not change when the output happens to look good.

The two teams in the opening had the same product and the same process. What separated them was that one team made step-level decisions and the other made a session-level judgement.

2. Extract the requirements, then attack them

Real work rarely starts from a clean brief. It starts from a forty-page document, a thread of half-formed emails, and something somebody said in a meeting.

Before you build anything, that has to become requirements: specific, traceable, testable. AI is strong at this translation, and it is the right first use in almost any redesign.

Sometimes there is no document at all, only a sentence somebody said in passing. "We need better reporting" is not a requirement. Nobody can build it, and nobody can tell you afterwards whether it was met.

The same translation fixes it. A business need becomes a task definition once five things are settled: what is produced, for whom, how often, from what data, and in what format. 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.

Here is how the request reached me, in the words I was given: [paste it].

Turn it into a task definition. What exactly is produced, who is it for, how often does it run, what data does it draw on, and what format does it arrive in? Where I have not told you, say so instead of filling it in.

That last instruction carries the weight. Asked to define a task, a model will define one, and the slots you never specified close quietly at plausible defaults.

Ask for structure, not a summary. A summary tells you what the document says. A structure gives you rows other people can work from.

From the attached RFP and the email thread, extract every distinct requirement we are being asked to address. For each one give me a short label, the exact section it comes from, whether our thread already answers it, and whether it is ambiguous enough to need a clarifying question. Return it as a table.

Notice what that asks for and a summary request would not: a source column. Traceability is what lets somebody who was not in the room check the list.

Then attack it. Extraction is the first pass, not the trustworthy one. The requirements that cost teams the bid are rarely stated plainly. They sit in a subordinate clause, or behind an evaluation criterion, or in a sentence two people would read differently. Extraction finds what was written. It does not find what was meant.

Review the requirements you extracted. Which are ambiguous as written? Which could two people on our team interpret differently? Which imply a requirement the document states only indirectly?

This is Discernment moved forward, from the output stage to the requirements stage, where it is far cheaper. An ambiguity caught here costs a clarifying question. The same ambiguity caught after the work is built costs the work.

An ambiguous requirement does not look ambiguous

"The report should be delivered promptly after month end" reads like a requirement. It is not one. Two days and two weeks are both prompt to somebody, so two teams reading that sentence build two different processes and both believe they were told to.

The tell is that you cannot write a check for it. If you cannot say what evidence would prove the requirement met, it is not decidable yet, however specific it sounds.

Why this is a Project rather than a one-off chat

Requirements extraction is recurring work with stable context. Past winning proposals belong in the knowledge base. The extraction format belongs in the standing instructions. The formatting procedure belongs in a Skill.

Two of those three live in the Project and one does not. The knowledge base and the standing instructions are configured on the Project and apply inside it. A Skill sits at the account level, so it is available everywhere you work, this Project included. The asymmetry cuts both ways: a Skill you build here is not fenced into this workflow, and a Skill somebody else edits is edited for every Project at once.

Put those three in the right places and the next RFP costs one sentence instead of one setup. Which of the three homes a piece belongs in is Concept 14.

3. A plan is only as good as the numbers under it

Planning work mixes two things that AI handles very differently.

Synthesis it does well. Gathering considerations, structuring options, laying out trade-offs, holding many factors at once without losing the thread.

Calculation is different, and not because models cannot add. They can. The problem is that 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:

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

A rough figure in a brainstorm can be written. A figure somebody will act on gets computed.

Upload the data and have the numbers produced by code execution rather than written into a sentence. A staffing plan built on a guessed utilisation rate is a guess in a table. The same plan built on a computed analysis of the actual timesheet data is one you can defend line by line, because each line traces to a calculation somebody can re-run.

Using code execution on the attached ticket data, calculate quarterly volume growth and average tickets resolved per analyst. Then, from those figures, recommend the headcount needed to hold our current resolution time next quarter, and show the assumptions.

Two things about that prompt. It separates computation from recommendation, in that order. And it asks for the assumptions, which is what lets somebody disagree with the recommendation without re-doing the arithmetic.

This is also a diagnostic habit you will use in Part 4. When numbers come back subtly wrong, the cause is usually not the prompt. It is that a calculation was asked for in prose.

4. Where AI insight actually changes a plan

Not every step of a planning workflow benefits equally, and getting this wrong produces a plan that is confidently useless.

Here is one that did.

An operations lead asked for the whole capacity plan in a single request: analyse the ticket data, work out the growth trend, and recommend next quarter's headcount. What came back was well structured, internally consistent, and recommended hiring three analysts.

The team was under a hiring freeze that had been announced internally two weeks earlier.

Nothing in that failure is about data quality. The trend analysis was fine. The recommendation followed from it. The plan was useless because one step of it required an input that does not exist anywhere the machine could reach: a decision made in a meeting, not written in the dataset.

That is the boundary, and it is sharper than "AI is good at some things."

Synthesis steps run on information you can supply. Gather the considerations, structure the options, weigh the documented trade-offs. Everything they need can be put in front of the model, so they delegate well.

Judgement steps run on information you cannot supply, or would not. Risk appetite. A hiring freeze. Which department the CFO is protecting this quarter. Whether this client will tolerate one more delay. These 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, and returns it at the same confidence as the part it actually computed.

So the useful question about any planning step is not "can AI do this?" It is:

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

The reciprocal matters just as much, and it 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 in Part 2, and plenty of them do not.

Run that on the capacity plan and the split falls out immediately. The trend, the throughput, and the options are all supplyable. The hiring decision is not, and asking for it in the same request is what produced a recommendation nobody could use.

The test also catches the work people describe as needing a human touch. A condolence note to a long-standing client, a difficult conversation with somebody's manager, a judgement call about how much bad news a team can absorb this week: these fail the window test for the same reason the hiring freeze does. What they need is not in the window and cannot be put there.

Research is a synthesis step, so run the window test on it too.

Gathering what bears on a decision is breadth work done without fatigue, and it is one of the clearest early wins in any redesign. But research fails in a way planning does not.

A model's knowledge stops at a date. Everything after that date is outside the window in exactly the sense above, and asking for it produces the hiring-freeze failure again: not a refusal, a confident answer built from what such a fact usually looks like. Nothing on the page tells you which side of the line you got.

So split research questions before you ask them:

The question is about	Where the answer must come from	What you ask for
A stable concept or method	The model's own knowledge is fine	The explanation, and the reasoning behind it
Anything current, priced, or dated	An external source you can open	The answer and the link, so you can check it

Two surfaces do that second row. Web search in chat covers the quick lookup, a price or a date you need inside the work you are already doing. Research is the deeper pass, where the answer has to be assembled across many sources rather than found in one, and it sits on the paid plans. Both hand back links, which is the entire reason to reach for either.

Which is the research version of the same rule:

For anything current, ask for a source you can open. Never a confident answer.

A vendor comparison built on recalled prices is the staffing plan built on a guessed rate. Same defect, different column.

That question is the informal version of what Part 2 turns into a method.

Part 2: The delegation map

This is the core of the course. Everything before it prepares the map, and everything after it runs, maintains, or explains the map.

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 whole subject of Governance, Risk & Responsible Use. The second is the window test from Concept 4.

2. Ownership. Who owns it? Reversibility, stakes, accountability. Concepts 5 to 7.

3. Implementation. What carries it? Decided last, and only for steps that got past the first two:

What the step is	What carries it	Why
A repeatable procedure with fixed steps	A Skill	It runs the same way for everyone
Rules and reference the step always needs	Project knowledge	Available every run without pasting
A calculation the output depends on	Code execution	Computed rather than generated
A standing constraint on every output	Standing instruction	Applies without anyone remembering it
A step a person owns	A named review gate	A person, a moment, and a thing checked

Keep the third decision out of the second. "This has to be computed" is true and it 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 first four rows all say the same thing in different materials: consistency from a configured Skill beats heroic prompting that depends on remembering the right wording every time. Configuration is what makes a step run the same way for the colleague who inherits it.

That 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 the gate in Concept 7 goes unstaffed.

5. Three criteria decide every step

Before you redesign a workflow around AI, 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 actually cost? Not on average, and not usually. In the bad case. A misfiled label costs a minute. A miscalculated penalty exposure costs whatever the penalty is.

Accountability. Who is answerable for this step's outcome? The trap is stopping at that question, because somebody answers for every step, and read that way accountability would keep every step human. 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 rather than at the drafting. A step that is itself the decision, or that commits the organisation to something, cannot, because nothing downstream is left to carry it. Either way 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. Concept 7 is about why.

These are three questions, not a score

You are not adding the criteria up, and you are not waiting for three yeses.

Usually one of the three decides the step and the other two agree with it. Name that one. In the contract map below, "sign and send" is decided by reversibility, and "approve each change" by accountability, even though both are also high-stakes. Naming the criterion that carried the row is what makes your classification checkable by somebody who was not there, and it is the column an auditor reads.

Where the three disagree, the strictest one wins. A reversible, low-stakes step that is still the decision somebody answers for stays human.

6. Two workflows, same criteria, different answers

Contract review is the workflow most business teams map first, so it is worth seeing in full.

Contract review

Workflow step	Owner	Criterion that decided it	Carried by
Extract clauses from the contract	AI	Reversible, low stakes	Skill
Flag departures from the company playbook	AI	Reversible, and errors surface at the redline	Skill
Draft the redline and the rationale	Collaborative	High stakes, so a human judges each edit	Skill + gate
Compute financial exposure of a penalty clause	AI	Reversible, and checked at the approval gate below	Code execution
Approve or reject each change	Human	This step is the decision somebody answers for	Named reviewer
Sign and send	Human	Irreversible and externally binding	Named signer

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

That is the whole reason to keep the two columns apart. "Must be computed" belongs under carried by. It never belongs under criterion.

The playbook row runs on the same logic, and it is the one people generalise wrongly. Flagging departures from a written policy is AI-appropriate here because somebody reads the flags at the very 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 where an edge case has to be called rather than caught, and it is collaborative instead. Checking expenses against a travel policy is usually that second shape.

The step did not change. What changed is whether anybody is standing after it.

Read the middle of that table rather than the ends. AI is doing real work here, including the redline draft, which is the substantive legal writing. This is not a summarisation workflow with a lawyer added at the end. The human owns the decisions and the irreversible actions, and everything else moved.

Now the same three criteria on work that has nothing to do with law.

Onboarding documents

Workflow step	Owner	Criterion that decided it	Carried by
Pull new-hire details from the HRIS export	AI	Reversible, and checked at the confirmation step	Code execution
Draft the offer letter from the approved template	AI	Reversible draft, low stakes until it is sent	Skill
Personalise the welcome note	Collaborative	The manager's voice cannot be supplied	Named reviewer
Confirm compensation matches the approved req	Human	This step is the check, nothing follows it	Named reviewer
Send the signed offer	Human	Irreversible and externally binding	Named signer

The pattern is identical, and the work is unrelated. Mechanical and draft steps delegate. The figure-confirmation step and the irreversible action stay human. Nobody decided that by taste. The criteria decided it, twice, in two domains.

That repeatability is the whole argument for having criteria at all. A map you produce by judgement is a map only you can produce, and only on a good day. A map produced by three questions is one your colleague produces the same way, and one you can defend to an auditor a year later.

7. Three ways a map goes wrong

The second team in the opening was not careless. They watched AI draft redlines well for weeks, and then let it approve the easy clauses. That is a reasonable response to evidence. It is also the most common way a workflow acquires a risk nobody chose.

Over-delegation is giving AI more than the risk profile justifies, and it 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 the 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 just 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 reviewer is busy, or the queue is long, or the drafts have been good for two months, the review becomes a glance and then a click. Nothing was decided and nobody changed the map, but the step is now automated. A collaborative step with no real reviewer is an automated step. The map does not tell you this has happened, because a map records what you designed rather than what is running.

Mapping the tool instead of the work. A team maps around the features they like. They built a good Skill, so the workflow acquires a step shaped like that Skill. This is the most flattering of the three and the hardest to spot from inside, because the resulting workflow genuinely does use the tool well. It just is not the work.

Here is a map with all three in it. Read it before you read the diagnosis. It is a customer-complaint workflow at a mid-size software company, and it looks like a reasonable piece of work.

Workflow step	Owner	Stated reason
Pull the complaint and the customer's ticket history	AI	Mechanical retrieval
Summarise the complaint into our issue template	AI	Our summarising Skill is very good at this
Classify severity (low, medium, high)	AI	The summaries have been accurate for three months
Draft the customer response	Collaborative	AI drafts, the duty agent reviews before it goes out
Send the response	AI	Low severity only, and the drafts have been strong
Log the outcome in the CRM	AI	Mechanical write

Find the three problems before continuing.

The diagnosis

Row 3 is halo delegation. The stated reason is that the summaries have been accurate. Severity classification is a different step, and it decides whether a customer is escalated or ignored. Judged on its own: reversible in theory, but a missed high-severity complaint is not recovered by reclassifying it a week later, and nothing downstream re-reads the call. It is at best collaborative.

Row 5 is over-delegation, and row 4 is where it came from. "Low severity only" sounds like a control, but severity was set in row 3 by the same system that is now deciding it may send without review. A step cannot supply its own permission to skip the gate. Sending is also irreversible and external.

Row 2 is mapping the tool instead of the work. The reason given is that the Skill is good, not that the step needs doing this way. This is the most flattering row in the table and the least examined. If the issue template exists because the summarising Skill produces that shape, the workflow has grown around the feature.

Row 4 is the one to watch, not fix. As written it is correct. But the duty agent reviews every draft including the ones row 5 will now send without them, and nobody has said how many drafts per shift that is. This is a gate with a plausible design and no capacity check behind it.

Notice what all four have in common. Every stated reason is true. The Skill really is good, the summaries really were accurate, and the write really is mechanical. Bad maps are not built from false statements. They are built from true statements about the wrong step.

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 take one habit from this course, make it that last question, asked periodically: are the gates I designed still actually being staffed?

8. 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. Quarterly volume doubled and the gate that worked at twenty cases a week stopped working at fifty. The document on the shared drive still describes the workflow you designed, which is now not the workflow that runs.

Three controls in this course decay the same way, and it is worth seeing them as one failure:

What decays	Looks like	Signal at the moment it fails
A review gate	Reviews become glances, then clicks	None
A standing instruction	Output quietly stops meeting a rule	None
The map itself	Describes a workflow nobody runs any more	None

There is exactly one countermeasure available for a failure with no signal, and it is not vigilance. It is a scheduled read.

So the map needs two things written on it that most maps do not have:

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, which is a different job from any step in it.

A review date. Quarterly is a reasonable default. Sooner if the workflow's volume, staffing, or regulatory position changes, because all three break gates without touching the document.

The review itself is four questions, and it takes about twenty minutes:

1. Has a step been added or removed that is not on the map?
2. For every collaborative step: who reviewed it last week, and how long did they spend? If nobody can answer, the step is automated and the map is wrong.
3. Has anything changed the volume or the stakes? A gate sized for the old numbers is a gate that fails at the new ones.
4. Is every configuration the map depends on still current? The Skills, the knowledge sources, the standing instructions.

Question 2 is the one that finds real problems. It is deliberately about last week rather than about policy, because policy is what the map already says and last week is what actually happened.

A map with no owner and no review date is a design artifact, and it will describe your workflow accurately for about a quarter. A map with an owner and a date is an operating document: the thing an auditor asks for, the thing you hand to whoever takes the workflow over, and the thing that catches the unstaffed gate before the outcome does. The difference is two lines at the top of the table.

Part 3: Build it, and watch it

9. The loop: ideate, prototype, feedback, refine

AI is a design collaborator, not a vending machine. You will not get a solution by asking for one. You get one by running a loop.

Ideate produces options. Prototype makes one of them concrete enough to react to. Feedback exposes what is wrong with it, which you could not have known in advance. Refine fixes that. Then round again.

Run the loop inside a Project so the context, constraints, and prior decisions stay stable. Each iteration then builds on the last. Run it across scattered chats instead and each round restarts from a slightly different understanding, which is how you end up with a pile of drafts rather than a solution.

A worked example: three cycles, no code written.

A business analytics team needed a small internal tool to track a maintained set of metrics. Rather than commission a build, they had AI produce it as a web artifact and iterated by asking.

Cycle 1 · Build.

Build a simple dashboard artifact that shows these five metrics from the attached data, with a chart for each.

An artifact comes back, working. Five charts, readable, roughly right. This is the cycle that makes people overconfident, and it is worth noticing why: the first cycle is the one where you have not yet asked for anything hard.

Cycle 2 · Filter and totals. The team asks for a date-range filter and a totals row.

The filter works. The totals are wrong.

Not obviously wrong. The figures are the right order of magnitude, formatted correctly, and sitting in a row that looks exactly like a totals row should. One analyst notices that a column does not add up, and only because she happened to know roughly what one of the five numbers should be.

Nothing broke. The totals were written rather than computed, and a written number is a plausible number. On the page it is the same kind of thing as a calculated one: text.

The fix is not a better prompt. It is Concept 3, arriving in the middle of a design loop: the totals row is a calculation, so it belongs in code execution rather than in prose.

Cycle 3 · Colour and print. The team asks for the brand palette and a print-friendly layout. It works first time.

The contrast between cycles 2 and 3 is the lesson of the whole loop. Both were one-sentence requests. Cycle 3 was a description problem, and describing it better solved it. Cycle 2 was a feature problem, and no amount of describing would have solved it, because the thing being asked for was not the kind of thing prose produces.

Telling those two apart is the skill. Part 4 is the procedure for doing it.

Why the failing cycle is in the middle

Cycle 2 fails quietly, which is the point. A cycle that failed loudly would teach you nothing, because an error message tells you where to look.

The realistic failure in an iteration loop is the one that passes review, because the output was fluent, formatted, and confident. It reaches production not because anybody was careless but because there was nothing to catch. The catch has to be structural, and that is why the fix is a feature choice rather than a prompt improvement.

10. When it has outgrown prompt-and-iterate

The dashboard artifact worked because it served one small team's internal need. Six months later, three departments open it every Monday and one of them puts its numbers in a board pack.

That is a different object now, and nobody decided it should be.

Dependency is the escalation signal. The moment other people rely on something as infrastructure, it has requirements it never had before: uptime, access control, someone to call when it breaks, and a guarantee that it still does today what it did in March. Those are not prompt-and-iterate problems. That work belongs with developer or architect expertise, and recognising the handover point is itself the skill this concept teaches.

Escalating is a correct answer, not an admission. The failure mode is the opposite one: continuing to run something by prompt long after other people's work depends on it, because it started small and nobody marked the moment it stopped being small.

Two signals that sound alike and point elsewhere

The book has a second signal worth keeping separate from this one.

The signal you notice	What it means	Where to go
Other people now depend on this	It is infrastructure and needs engineering	Developer or architect expertise, past Associate scope
I have solved this the same way three times	The shape is stable and can be manufactured	From One-Off to Worker

The first is about who is exposed. The second is about whether the method has stopped changing. You can hit either without the other, and they call for different work.

Part 4: When it misbehaves

11. Four causes, told apart by when the symptom appeared

When output disappoints, most people do one of two unproductive things. They give up and conclude the tool cannot do this. Or they thrash, changing things at random until something works.

Both skip the only question that actually narrows it down: when did the symptom first appear?

Four causes produce bad output that looks broadly similar on the page. The timing narrows it down fast, and the timing is free information you already have.

One thing before the four, because it decides how you use them:

Timing tells you where to look first. It does not tell you what the cause is.

A first answer can be poor because the prompt was thin, because the source material was bad, or because the same prompt run twice gives two answers. "It used to work" usually means configuration drifted. Sometimes it means the task quietly changed shape. So each signal gives you a leading hypothesis and a cheap way to test it.

Under-specification shows up from the very first response. The output was never right, because the prompt never carried what it needed. It is the most common cause and the cheapest to fix.

Context overload shows up partway through a session that started fine. The conversation approaches its limit, earlier content gets compressed to make room, and early instructions lose force. A better prompt does not help, because the problem is not the prompt you just wrote.

Wrong feature or model shows up as a specific, repeatable error type rather than general poorness. Numbers subtly off means a calculation was asked for in prose. Persistently shallow work on a task that needs depth means a tier chosen for speed. More prompting will not buy what the tool cannot produce.

Stale configuration shows up as "it used to work." Something the setup depends on has drifted. Nothing errors, and output just quietly degrades.

When the symptom appeared	First hypothesis	Cheap confirmation	Fix if confirmed
Wrong from the first answer	Under-specification	Re-read the prompt. Is the missing thing actually in it?	Add what it left out
Started fine, then degraded	Context overload	Restate the instruction in a fresh session. Does it hold?	Restart or summarise
One repeatable error type	Wrong feature or model	Run the step once with the right feature or a stronger tier	Change the feature or the tier
Used to work, now does not	Stale configuration	Open the instruction or knowledge source and check its date	Maintenance on the configuration

Every confirmation in that third column takes under a minute, and each one can come back negative. When it does, you have not wasted the minute. You have eliminated the most likely cause, which is exactly what the next step needs you to have done.

When you hand the problem to somebody else, say it the other way round: the failure lives in the prompt, the context, the feature choice, or the task itself. That sentence names what they should open. The four causes above are what you run while diagnosing, because timing points at them.

Stale configuration is the one that fails silently

The other three announce themselves. This one does not.

There is no error, no warning, and no moment where something visibly stops. Last quarter's figures sit in the Project knowledge base and this quarter's report quotes them, formatted perfectly. The model has no way to know that what you gave it is out of date.

That makes it the twin of the unstaffed gate in Concept 7. Both are a control you set up correctly, decaying while everyone assumes it still holds, with no signal at the moment of failure. Both are found by scheduled review rather than by noticing.

12. The sequence runs cheapest first

Run these in order, before concluding the task is not a fit:

1. Re-read the prompt against its five components. Is anything under-specified?
2. Check the conversation length. Is context overloaded and in need of a restart or a summary?
3. Check the feature and the model. Is this a calculation that needs code execution, or a complex task on a speed tier?
4. Check the configuration. Are the instructions, knowledge, and Skills current?
5. Only then, question whether the task is a fit at all.

Step 1 asks for something more specific than reading it again. Hold the prompt against its five components and check each one: the role you asked for, the context the model could not have known, the task as an unambiguous instruction, the constraints, and the output format. A prompt reads fine to the person who wrote it, because the missing piece is sitting in their head where it has been all along. Going slot by slot is what makes an absence visible.

The order is not arbitrary. It is cheapest fix first.

Re-reading the prompt costs seconds and resolves the most common cause, so it goes first. Restarting from a summary costs a little more. Switching feature or model, and auditing configuration, cost more again. Questioning the task is last because it is the most expensive conclusion available: it ends the attempt.

Most people invert this. The instinct on a disappointing output is to switch to the most capable model, or to declare the task impossible. Both are moves from the bottom of the ladder, made before anything at the top was checked, and both are usually unnecessary.

Each rung is a hypothesis plus its confirmation, not a guess plus a change. That distinction is what makes cheapest-first work. Confirming under-specification costs seconds, so a negative result costs seconds too, and you move down having genuinely ruled something out rather than having tried something.

Step 5 exists, and it is sometimes right. "I asked it to predict next quarter's exact sales figure and the number was wrong." No prompt, restart, feature change, or configuration audit fixes that. The task asks for something the tool cannot do, which is to predict a specific future number with precision. The fix is not to the setup. It is to the task: ask for a range with stated assumptions, or a model of the drivers you can adjust and re-run.

Recognising a genuine mismatch is as much a skill as fixing a fixable failure, and it stops you spending an afternoon tuning a prompt toward an output that was never available. But it is step 5 for a reason. Reached first it is an excuse. Reached last it is a conclusion. The difference is entirely whether the four cheaper causes were ruled out, and the only person who knows whether you did that is you.

Here is the full gallery, worth reading as a set because the diagnoses are what differ, not the complaints:

What you would say	Diagnosis	Fix
"The summary keeps missing key points."	Under-specification	Name the criteria for what counts as key
"It stopped following my format halfway through."	Context overload	Restart from a summary, or persist the format
"The numbers are subtly wrong."	Wrong feature	Move the calculation to code execution
"It worked last month, now it's off."	Stale configuration	Audit the instructions and knowledge sources
"It can't predict next quarter's exact figure."	Expectation mismatch	Reshape the task into one that fits

Five complaints that sound alike. Five different fixes. Nothing in the wording tells you which one you are in, which is exactly why the sequence exists.

Run end to end it takes a minute or two and lands on a specific cheap fix most of the time, or occasionally on a reasoned "this task needs reshaping." Both replace a reaction with a decision you can explain. The habit worth building is reaching for the sequence the moment output disappoints, before forming an opinion about whose fault it is.

1Your Work

Think of a real output that disappointed you recently. Answer from that one, not a hypothetical.

What you asked for, what came back, and crucially WHEN it went wrong: was it wrong on the first response, did it degrade over a long session, is it one repeatable kind of error, or did it used to work?

Which of the four causes is it, and what in the timing tells you that rather than one of the other three?

The specific fix for that specific cause. If your answer is 'write a better prompt', check that under-specification is really what you diagnosed.

2Get Your Score

Discuss with an AI. Question your scores.
Come back when you have your BEST evaluation.

Part 5: Make the fix stick

13. Turn a reaction into an instruction

Every disappointing output is diagnostic data about the setup that produced it. Most of it evaporates, because the fix gets made by hand and the lesson goes nowhere.

The first move is converting a reaction into an instruction.

A reaction names how the output feels. "Too generic." "Not quite right." "Missed the point." An instruction names what to change so the next output is different.

The reliable way to make the jump is one question: what specifically would have to be present for this to be right, and which part of the setup controls that?

Reaction	Instruction	Which lever
"Too generic"	Name the audience and the one action I want them to take	The prompt
"Wrong tone"	Add a tone constraint that applies to every draft	The instruction
"Missed the point"	State the single question the output must answer, up front	The prompt
"It's using old data"	Replace the source document in the knowledge base	The knowledge

If you cannot name the lever, the critique is still a reaction, and the next attempt will be a guess that looks like a revision.

14. Rule, reference, or procedure

Finding the fix is the easy half. The expensive failure is finding it and then losing it.

A correction discovered in Monday's session and left in that conversation will be rediscovered next Monday, and again by whoever covers for you, and each rediscovery costs what the first one cost. Multiply by every person and every cycle.

The test for whether a fix is worth promoting is short: will this correction be needed again, by me or by someone else? If yes, it belongs in configuration.

Then one more question decides where it goes.

Each home changes a different thing, which is why the sort matters more than it looks. A rule changes behaviour. A reference changes what is known. A procedure changes how the work is done.

Rules go to standing instructions. Something that should always apply within a Project. "Always state the target segment in the first line."

References go to the knowledge base. Material every run needs to consult. The brand voice guide. The current product list.

Procedures go to Skills. A repeatable sequence with steps. "Generate the weekly report in this exact format, in this order."

Putting a fix in the wrong home is why some optimisations do not stick. A procedure pasted as a one-line instruction loses its steps and produces a different result each time. Reference material crammed into a standing instruction bloats every single prompt whether or not that run needs it.

Two people, one habit apart. A marketer notices that every campaign brief comes back missing the target segment and burying the call to action. She stops fixing it by hand and writes two standing instructions into the briefs Project. The next draft arrives correct, and every draft after it, for everyone who opens that Project.

An analyst on the revenue report works out in his first month that the figures have to exclude cancelled orders, and types that reminder into the chat every month afterwards. It works every month. Then he takes two weeks off, a colleague runs the report, and the numbers go out with cancelled orders in them.

The fix existed the whole time. The failure was leaving it somewhere only one person could find.

Why memory is not the answer here

Assistants can pick up patterns you repeat, and it is tempting to treat that as the capture mechanism. It is not a substitute for configuration, for two reasons.

It is per-user. Whatever it learned about your preferences is yours, and the colleague covering for you starts from nothing. That is precisely the failure in the analyst's story, so the mechanism that feels like a fix is the one that cannot address it.

It is best-effort. It may pick a pattern up. It may not. You cannot point at it, inspect it, or hand it to somebody, and you will not be told when it stops applying.

Configuration is the deliberate, shared, inspectable home. Memory is a convenience on top of it. Use both. Rely on configuration.

15. Find the friction before you optimise

Friction is easy to live with and hard to see, because you absorb it one session at a time. Nobody notices a two-minute reformat. Everybody does it fifty times a year.

Three signals point at friction that configuration can remove:

Signal	What it looks like	The fix
Repetition	You paste or type the same thing every run	Saved context or a standing instruction
Correction	You fix the same flaw in every output	A configuration change so it stops appearing
Variance	Different people running the same task get different results	A shared Skill or knowledge base

Variance is the one teams miss, because no individual experiences it. Everyone's own output is fine and consistent. The inconsistency exists only between people, which means it shows up at the reviewer, not at the source.

If you cannot see the friction, run the workflow once with the explicit job of writing down every manual step. That list is your optimisation backlog, and it is usually longer than you expect.

Two moves remove friction, and teams reliably remember only the second.

Consolidate. Steps that can run together should run together, rather than as three separate prompts with you in between re-explaining context each time. Three prompts that each need the same background are one prompt. This costs nothing to do and it is invisible until you count the steps.

Promote. Move the repeated pattern into configuration, as Concept 14 describes.

Consolidation reduces the number of steps. Promotion reduces the cost of the steps that remain. Do them in that order, because promoting a step you were about to merge away is work you did not need to do.

A worked audit. A team's weekly reporting workflow takes about 45 minutes per analyst, and the outputs vary by who runs it. The audit finds three frictions: each analyst re-pastes the same background, each reformats the output by hand, and each catches different issues.

Sort them by the Concept 14 test. The background is a reference, so it goes to the shared Project knowledge base. The report format is a procedure, so it becomes a Skill. The verification step is a rule, so it becomes a standing instruction.

Result: about 25 minutes per analyst, a consistent format across the team, and one fewer revision round.

Notice that the audit produced a list of annoyances and the rule, reference, procedure test turned it into a set of specific changes. Without that sort, an optimisation backlog stays a complaint.

16. Measure the thing you actually care about

Optimisation you cannot measure is hard to justify and harder to sustain. And there is a step before measuring the improvement that almost everyone skips.

Measure the before. The worked audit above claims 45 minutes down to 25. That sentence is only sayable because somebody timed the workflow before changing it. Without a baseline you have an improvement you believe in and cannot state, which is the same as no improvement the first time a manager asks.

It costs one cycle. Run the workflow once, unchanged, and record three numbers: how long it took, how many revision rounds it needed, and how many manual steps you performed. Do it before you touch anything. You cannot reconstruct a baseline afterwards, because by then you know what you changed and your estimate of the old way will be wrong in the direction that flatters you.

Time saved is the easiest metric and often not the right one. Pick the metric that matches why the workflow mattered in the first place:

If the workflow is...	Optimise for	Because
An internal draft	Time	Speed is the point, and small errors are cheap
A customer-facing report	Consistency	Varying formats erode trust faster than delay
A compliance or finance output	Accuracy	One wrong figure costs more than an hour saved
Work done by several people	Variance	The cost lives between people, not within a person

Naming the metric up front also tells you when to stop. Optimisation has diminishing returns, and once the metric you care about is good enough, further tuning becomes its own kind of friction.

Two more habits make the change survive contact with other people.

Run the new workflow in parallel with the old one for a few cycles. It costs real duplicated effort for two or three rounds and buys three things you cannot get another way: evidence the new way is better on your chosen metric, a working fallback if it is not, and the agreement of the people whose work changed. That last one matters most. A parallel run turns "we are changing your job" into "we ran both, here is what happened." Switch fully when the comparison is clear, and keep the old process documented one more cycle.

Be able to answer what it costs. Time saved is an internal metric. What decides whether a redesign survives a budget review is cost against saving. The cost is the usage attributable to this workflow plus the human time still in it, which is the gates you deliberately kept. The saving is the baseline multiplied by how often it runs and by how many people run it: twenty minutes a week across three analysts is roughly fifty hours a year, which is a sentence a manager can act on. Then name the risk that survives your gates, because a business case that hid one stops being believed the first time something goes wrong. You need the method, not precision, because a redesign nobody costed gets removed by somebody who never saw the saving.

Prove the change before you rely on it

Not every change is an improvement. When you move a fix into configuration, run the workflow a few cycles with the old approach still available before you commit.

The compounding benefit of optimisation is real. So is the compounding cost of a bad change baked into a workflow everybody uses, and the second one is harder to notice because it is now the default.

Part 6: Operate it, and explain it

17. When a bad output gets out

Everything so far reduces the chance of a bad output reaching somebody. Nothing removes it.

A gate gets skipped on a busy Friday. A configuration goes stale between reviews. A step is classified correctly and still produces something wrong. Eventually a workflow you designed sends something it should not have, and the quality of the design is judged by what happens in the next hour rather than by the map.

Most teams have no plan for that hour, which is why the response is usually improvised, slow, and defensive. What you do the moment you find a bad output, which is stop the spread, record the facts, and report through your organisation's path, is the first-hour procedure in Governance, Risk & Responsible Use. What follows here is the other half: the four things the person who designed the workflow decides in advance, so that procedure has something to act on.

1. How it gets stopped. What is the fastest way to halt this workflow, who can do it, and does that person need anyone's permission? If the honest answer is "we would have to ask the person who set it up," that is the first thing to fix, because it makes every other step wait.

2. What is already out. Not "did this one output go wrong" but how many outputs did this affect, and where did they go? A stale configuration does not produce one bad result. It produces every result since it went stale, and nobody notices which day that was.

3. Who is told, and by when. The customer, the internal owner, the risk or compliance function if your organisation has one. Decide this before it happens, because in the moment the incentive to delay is very strong and the cost of a late disclosure is much higher than the cost of an early one.

4. What changes in the map. Every incident is diagnostic data about the design. Which of the four causes was it? Was a step misclassified, or was it classified correctly and the gate not staffed? Make the change to the map, with a date, so the fix persists past the week everyone was paying attention.

Decisions 1 and 4 are yours, and they are made at design time or not at all. There is also a practical argument for doing it: a team that can say what it does when the workflow is wrong is a team that gets permission to run the workflow. Nothing earns a stakeholder's trust faster than a plan for the failure they are already imagining.

18. Say what it does, then name the gate

Integrating AI into a team workflow means describing it to people who did not build it: a manager, a client, a risk function, an auditor.

Credibility here comes from accuracy, which means stating the limits as clearly as the value. Overstating capability is how teams lose stakeholder trust on the first visible miss, and there is always a first visible miss.

Three phrases quietly overstate, and all three are common:

"Fully automated." Almost never true, and the first visible error exposes it publicly.

"AI handles X." Collapses the human gate out of the sentence. Whoever hears it now believes there is no gate.

"It's basically as good as a person at Y." Sets a standard the tool will eventually miss in front of somebody who remembers you said it.

The repair is the same every time: state what the tool does, then name the human checkpoint. Two clauses. It costs one extra sentence and it is the difference between a claim you can defend and one you cannot.

A third clause is worth adding when the audience is deciding whether to trust the workflow at all: say what it refuses. Every well-designed workflow has cases it is built to decline and hand to a person: the ambiguous clause, the non-standard contract, the request outside the playbook. Naming that list out loud is the strongest trust signal of the three, because it proves the boundary was designed in advance rather than discovered by an incident.

Now the same workflow, described three ways. The workflow does not change. The gate does not change. What changes is the detail each audience needs in order to trust it.

To the legal lead, who wants the mechanism and the failure modes:

"It pulls the clauses out, marks anything that departs from our playbook, and writes the first redline. Approving a change is still yours. The one to watch is an obligation implied rather than stated, which it can miss, so treat the flags as a prompt for your read rather than a substitute for it."

To the practice executive, who wants the outcome and the oversight:

"Turnaround on a standard contract has gone from two days to about half a day, with the same approval standard. A lawyer still signs off every change before it leaves the building."

To the client's risk function, who wants the control:

"Drafting is AI-assisted. A qualified lawyer reviews and approves every term, and nothing is sent without that sign-off."

Same facts, three altitudes. The technical stakeholder gets the mechanism and the known failure. The executive gets the result in the units they care about, which is turnaround time, not product names. The risk function gets one sentence about the control and nothing else.

What none of the three does is drop the gate.

Stakeholders trust an AI workflow more, not less, when the human checkpoints are explicit.

That is counterintuitive to most teams presenting one for the first time. The instinct is to minimise the human involvement, because it sounds like the tool is doing less. The effect is the opposite: an unexplained gap between "the AI does it" and what happens when the AI is wrong is exactly where a risk function stops listening.

This part comes last for a reason. The honest sentence in the legal lead's version, the one naming what the tool misses, is a Part 4 sentence said out loud to somebody deciding whether to trust the work. You could not have written it in Part 1, because you did not yet know what your failure modes were. Accurate communication is downstream of diagnosis.

The sentence to carry

The output is not the verdict. Judge the step by what it costs and who answers for it, and judge a failure by when it started.

Everything above is how to act on that sentence. The flashcards at the end are the concept-by-concept version, and the question table near the top is the index.

Map your own workflow

Reading a delegation map is easy. Producing one is the skill.

1Your Work

Use the same workflow you used in the opening exercise, now that you have the criteria.

Your workflow, as an ordered list of steps. Five or six is enough. Plain language, the way your team actually describes them.

One step you would give to AI, and which of the three criteria makes that safe. Reversibility, stakes, or accountability, named explicitly.

One step you would keep human, and which criterion decides it. If your reason is 'it feels important', push until you can name which of the three you mean.

If any step is collaborative: who specifically reviews it, at what moment, and what are they checking? If you cannot name a person and a moment, that step is automated.

2Get Your Score

Discuss with an AI. Question your scores.
Come back when you have your BEST evaluation.

The one-page map: copy this

Everything above fits on one page. Copy the block below into a document and fill it in for a real workflow. This is the artifact you hand to a colleague, an auditor, or whoever takes the workflow over.

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 /     Carried by
                                          stakes / accountability only)
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]

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.

Try this now: five prompts

You do not need to do all five in one sitting.

1. Extract and then attack

Take a real document you need to act on: a brief, a policy, a long email thread.

From the attached document, extract every distinct requirement or action it asks for. For each one: a short label, the exact section it comes from, and whether it is stated directly or only implied. Return it as a table.

Then, in the same conversation:

Now review your own list. Which of these are ambiguous as written? Which could two people on my team read differently? What did you extract as one requirement that is really two?

What to notice: the second pass usually changes the list. If it does not, ask whether the document was unusually clear or the pass was unusually shallow.

2. Find the step you cannot undo

Here is a workflow: [your steps].

For each step, answer three questions and nothing else. Can it be undone? What does an error cost in the bad case, not the average case? Is this step the decision somebody answers for, or an input that somebody else judges afterwards? Do not recommend anything yet.

What to notice: withholding the recommendation is the point. Ask for the analysis and the recommendation together and you get a recommendation with analysis written to support it.

3. Diagnose by timing

Next time an output disappoints you, before changing anything:

Before we fix this, help me diagnose it. I will describe what happened and when. Ask me one question at a time to work out whether this is under-specification, context overload, a wrong feature or model, stale configuration, or a task that does not fit. Do not suggest a fix until you have a diagnosis.

What to notice: how often it lands on under-specification, and how often your instinct had been to change the model.

4. Promote one fix

Find a correction you have made more than twice.

I keep making this correction: [the correction].

Is this a rule, a reference, or a procedure? Then write it in the form its home needs: a standing instruction, a knowledge-base entry, or the steps of a Skill.

What to notice: procedures are the ones people misfile. If your answer has an order to it, it is a procedure, and a one-line instruction will lose the order.

5. Say it three ways

Here is an AI-assisted workflow my team runs: [describe it, including the human review step].

Write three descriptions of it: one for a technical colleague, one for an executive, one for a risk or compliance function. Each must name the human checkpoint. Do not use the phrases "fully automated", "handles", or "as good as a person".

What to notice: whether the executive version still contains the gate. That is the version where it most often quietly disappears.

A project: map, break, fix, and explain

One workflow, all six parts, about an hour.

1. Map it. Take a real workflow and produce the table: step, owner, reason. Every row's reason must cite reversibility, stakes, or accountability by name.
2. Place the features. For each AI step, name what carries it. A Skill, knowledge, code execution, or a standing instruction. For each human step, name the person and the moment.
3. Run one step for real. Pick the most mechanical AI step and actually run it on real input.
4. Break it deliberately. Ask for a figure in prose that should have been computed. Watch a plausible number appear. Diagnose it out loud using Concept 11 before you fix it.
5. Promote one fix. Take something you corrected in step 3 or 4 and put it in its correct home.
6. Measure the before. One unchanged run: time, revision rounds, manual steps. Do this even though you have already started, and note that you are estimating rather than measuring, which is the cost of not having done it first.
7. Fill in the one-page map, including the owner, the next review date, and the four lines under "if it goes wrong".
8. Write the three descriptions. Technical, executive, risk. Each with the gate named.

You will finish holding one page somebody else could run, one working step, one diagnosed failure, one permanent fix, and three sentences you can say in a meeting. That page is the deliverable. The rest of the course exists to make it correct.

What this course leaves out, and where it lives

Real topics, deliberately set aside, so you know they exist and where to find them.

Left out here	Where it lives
Whether AI may do this work, or touch this data, at all	Governance, Risk & Responsible Use, next in Foundations
Whether the task needed AI in the first place	Is This an Agent Problem?
Deciding what to delegate in your own personal work	AI Fluency, the competency underneath this course
Configuring and maintaining Projects, knowledge, Skills	Claude and ChatGPT 101 and Skills & Connectors
Judging in depth whether an output is correct	Trusting the Checker
Choosing a model, which changes faster than any course	Which AI Employees in 2026
Debugging a system that has a harness and a loop	The Four Layers, a different map for a related problem
Building the thing once it has outgrown prompt-and-iterate	Spec-Driven Development and From One-Off to Worker
Turning review gates into evaluation infrastructure	Eval-Driven Development
Incident response with a legal clock attached	Your compliance function, not a course

You can now map a workflow, defend the map, diagnose it when it misbehaves, make fixes permanent, and describe the result accurately. The next course in Foundations is Governance, Risk & Responsible Use, which answers the question Part 2 opens with and then refuses, and which is what makes the map you just built safe to run at your job.

If you are collecting credentials, this course covers the Workflow Integration and Solution Design and Troubleshooting and Optimisation domains of the Associate exam. See Certifications.

Terms this course adds

Delegation map. A workflow written out step by step, with each step classified as AI-appropriate, human-retained, or collaborative, and a stated reason.

Reversibility. Whether a step can be undone if AI gets it wrong.

Stakes. What an error at a step costs in the bad case.

Accountability. Whether a step is the call somebody answers for, or an input a named person judges before it acts on anything. It never moves onto the machine.

AI-appropriate. A step AI may own, because it is reversible, low-stakes, and produces an input somebody judges rather than the decision itself.

Human-retained. A step a person owns outright, because it is irreversible, high-stakes, or is itself the decision.

Collaborative. A step where AI produces and a named person judges. It stops being collaborative the moment nobody judges.

Over-delegation. Giving AI more than the risk profile justifies, usually because the drafting has been good.

Halo delegation. Handing a step to AI because the previous step went well.

The unstaffed gate. A collaborative step whose review is no longer actually performed. Functionally automated, still documented as collaborative.

Under-specification. Output wrong from the first response, because the prompt never carried what it needed.

Context overload. Output that degrades as a session grows, because earlier content has been compressed to make room.

Stale configuration. Output that quietly degrades because a standing instruction, knowledge source, or Skill has drifted out of date.

Expectation mismatch. A task that asks for something the tool cannot do, correctly identified only after the cheaper causes are ruled out.

The diagnostic sequence. Prompt, context length, feature and model, configuration, then task fit. Cheapest first.

Promotion. Moving a fix out of a conversation into configuration so it persists.

Rule, reference, procedure. The test for where a promoted fix belongs: a standing instruction, the knowledge base, or a Skill.

Map owner. The one named person answerable for whether the delegation map still describes the workflow that actually runs.

Scheduled read. A periodic review of the map, because a gate, an instruction, and a map all fail without producing any signal.

Baseline. The measurement of a workflow taken before it is changed, without which no improvement can be stated.

Parallel run. Operating the old and new workflow together for a few cycles, to produce evidence and keep a fallback.

Escalation signal. Other people depending on something, which means it has outgrown prompt-and-iterate.

Sources and grounding

This course is built on Anthropic's Claude Certified Associate material for Workflow Integration and Solution Design and for Troubleshooting and Optimisation. The framework is theirs: the delegation criteria, the three classifications, the contract-review and onboarding workflows, the mapping errors, the RFP and capacity-plan examples, the iteration loop, the dependency escalation signal, the four root causes, the cheapest-first diagnostic sequence, the reaction-to-instruction move, the rule, reference, procedure test, the friction signals, the reporting audit, and the stakeholder framing all come from that material. The prose, the explanations, the diagrams, the exercises, and the assessment here are this book's own work, and the worked scenarios have been rewritten rather than reproduced.

Four things are extensions rather than restatements, marked so nobody mistakes them for the source:

• The window test in Concept 4, and the hiring-freeze failure it is built on. The source distinguishes synthesis from judgement steps. Framing that distinction as a question about what can be supplied is this book's.
• The failing cycle in Concept 9. The source demonstrates the iteration loop through its first cycle. Cycle 2's plausible-but-uncomputed totals and the description-versus-feature contrast are written for this book, to connect the design loop to Part 4.
• The unstaffed gate as a pair with stale configuration. Both failures are in the source material, in separate modules. Naming them as one failure seen from two sides, in Concepts 7 and 11, is this book's observation.
• Map ownership and the scheduled read in Concept 8, and the incident decisions in Concept 17. The source covers maintenance of a configuration that has drifted. Giving the map itself a named owner, a review date, and four review questions, and deciding the stop-and-scope questions at design time, are this book's additions. Both are tagged additive in the questions table for that reason.

Product behaviour described here, including context compression in long sessions and the role of code execution, was current in the source material as of mid-2026. Verify against current documentation before relying on any specific behaviour.

---

Flashcards Study Aid

---

Test Your Understanding

The delegation map was easy to read and is hard to actually run. These scenarios drop you into somebody else's workflow with a decision already waiting. Answer from the reasoning rather than the wording, and notice which criterion or which cause each one is really testing.

Checking access...