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 100 minutes. The six parts are 75 of those: Part 1, 10 minutes. Part 2, 20 minutes. Part 3, 8 minutes. Part 4, 11 minutes. Part 5, 14 minutes. Part 6, 12 minutes. The rest is the opening, the recap, the one-page map, and the glossary. Plus about 40 minutes for the two graded exercises, the prompts, and the project. It is longer than most crash courses in Foundations, and it is designed to be read in two sittings: Parts 1 to 3 build the map, Parts 4 to 6 run it.

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?
Operate	Who owns the map, and what happens in the hour after it goes wrong?
Communicate	What does it do, and where exactly is the human gate?

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

Where this sits in Foundations

Read AI Fluency first. That course teaches Delegation as a personal competency: deciding what AI should do and what stays with you, on your own work. This course takes the same competency to a workflow that a team runs, where the decisions are per-step, the stakes belong to other people, and a wrong split accumulates quietly instead of failing loudly.

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.

Topic	AI Fluency	This course
Who decides the split	You, for one task	A criteria set, for every step
The unit	A task	A workflow step
What is at risk	Your own result	An irreversible action, on someone else
When it goes wrong	You notice	A gate nobody staffed goes unnoticed
When output is poor	Mostly out of scope	A diagnostic sequence

The 4Ds do not get replaced here. Delegation gets a method, and Discernment gets a procedure.

One question this course 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 as a reminder, 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:

A confident, well-organised redesign can be wrong in exactly the place that matters most, and it will not look wrong.
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

Twenty-two questions, answered in order. Each entry in Answered in jumps straight to the section that closes it, so this table doubles as the map: read it through now, and come back to it later 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 is over-delegation, and why does good drafting invite it?	Concept 7	D4.4
8	What are the three ways a delegation map goes wrong?	Concept 8	D4.4
9	Once the map is done, where do Skills and code execution go?	Concept 9	D4.4
10	Who keeps the map true after the workflow moves underneath it?	Concept 10	D4.4
11	What does an iteration loop look like, and what does a broken cycle teach?	Concept 11	D4.3
12	When has something outgrown prompt-and-iterate?	Concept 12	D4.3
13	How do I tell four different causes of bad output apart?	Concept 13	D7.1
14	What order should I check things in, and why that order?	Concept 14	D7.1
15	How do I know when the task itself is the problem?	Concept 15	D7.1
16	How do I turn "this isn't quite right" into something actionable?	Concept 16	D7.2
17	Where does a fix belong so it survives past this conversation?	Concept 17	D7.2
18	How do I find friction I have stopped noticing?	Concept 18	D7.3
19	What do I measure, what does it cost, and when do I stop?	Concept 19	D7.3
20	What do we do in the hour after a bad output reaches somebody?	Concept 20	additive
21	How do I state what AI does without overstating it?	Concept 21	D4.5
22	How does the same description change for three different audiences?	Concept 22	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, 8, and 13 produce the most useful wrong answers.

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. They are included because a workflow you cannot operate is not really integrated, and they are marked so nobody mistakes them for exam coverage. A learner studying against the exam can read this course by that column instead of front to back. 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.

Where this leads in Agent Factory

Step-level ownership decisions are the first draft of an agent's boundary. When you build a Digital FTE, the list of what it may do, what humans keep, and what must escalate is not written at deployment time. It is the delegation map, formalised and made inspectable.

Continue in Spec-Driven Development.

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.

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 the client is asking us to address. For each one give me:
a short label, the exact RFP 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 system should handle a large number of concurrent users" reads like a requirement. It is not one. A hundred users, ten thousand, and a million imply three different systems, so two engineers reading that sentence build two different things 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.

Put those three in the right places and the next RFP costs one sentence instead of one setup. Leave them in a chat and you rebuild the setup every time, slightly differently. Which of the three homes a piece belongs in is Concept 17.

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 code-executed analysis of the actual timesheet data is a plan 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.

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

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 maintains or explains the map.

Three decisions, in this order

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, next in Foundations. The second is the window test from Concept 4.

2. Ownership. Who owns it? Reversibility, stakes, accountability. Concept 5, worked through in Concepts 6 to 8.

3. Implementation. What carries it? A Skill, project knowledge, code execution, a standing instruction. Concept 9.

Keep the third out of the second. "This has to be computed" is true and it belongs at layer 3. 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.

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. Eligibility has already been settled at the gates above, and how the step is carried comes later:

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 when somebody asks? Accountability does not delegate. It can sit alongside AI doing the drafting, but it cannot move onto the machine, because the machine cannot be asked.

Note what is deliberately absent from the list. 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. Any one of them can decide a step on its own.

A step that is perfectly reversible and low-stakes still stays human if a named person has to answer for it. A step nobody is formally accountable for still stays human if it cannot be undone. The criteria are three independent vetoes, not three inputs to a total.

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	High stakes, and nobody else can answer for it	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.

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	Low stakes, and the manager's voice cannot be supplied	Named reviewer
Confirm compensation matches the approved req	Human	High stakes, and nobody else can answer for 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. Over-delegation: drafting quality is not a licence

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. AI drafts the redline well, week after week, so letting it approve the low-risk clauses feels like the obvious next step. It is not a next step. It is a different kind of step, and the drafting quality says nothing about it.

That is exactly where the second team in the opening went wrong. They were not reckless. They were responding, reasonably, to evidence. The evidence was just about the wrong thing.

Drafting quality is evidence about the draft. It is not evidence about the decision.

When your map hands an irreversible or high-accountability step to AI, you have over-delegated, regardless of how well the surrounding steps have gone.

There is a quieter version worth naming, because it does not feel like a decision at all.

The gate nobody staffed

"AI drafts, human reviews" is a collaborative step. It 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. Nobody changed the map. But the step is now automated, and the written map still says collaborative.

A collaborative step with no real reviewer is an automated step. The map does not tell you this has happened, because the map records what you designed rather than what is running. You find out from the outcome, which is the expensive way.

This failure has a twin in Part 5, where a standing instruction goes stale and degrades output silently. Both are a control you designed decaying while everyone assumes it still holds. Neither announces itself. If you take one habit from this course, make it the periodic question: are the gates I designed still actually being staffed?

8. Three ways a map goes wrong

Three errors account for most bad maps. All three are reasonable-looking 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, against the three criteria, with no credit carried forward.

Collapsing collaborative into automate. The unstaffed gate above. The design says two owners, the practice has one, and the difference is invisible from the document.

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 errors 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 somebody answers for that. 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.

9. From map to redesign: put the feature where the step is

A map is a decision. The redesign is what you build from it, and the mapping does most of the work of telling you what to build.

At each AI step, the classification points at a feature:

What the step is	What carries it	Why
A repeatable procedure with fixed steps	A Skill	The steps run the same way for everyone
Rules and reference the step always needs	Project knowledge	Available every run without being pasted
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

And at each human-retained step, the classification points at something less exciting and more important: an explicit review gate. A named person, a named moment, and a named thing they are checking. Not "a human looks at it," which is how the unstaffed gate gets built.

Consistency from a configured Skill beats heroic prompting that depends on remembering the right wording every time.

That sentence is the practical argument for configuration over cleverness, and it is the same argument Part 5 makes from the other end, where the fix you discovered on Monday is lost by Friday because it lived in a conversation.

Where this splits from AI Fluency

AI Fluency has a task-delegation table that looks similar to the maps above: a task, an owner, and a reason. The similarity is real. The level they work at is not.

	AI Fluency	This course
What gets classified	A task in your own work	A step in a workflow a team runs
Who decides	You, using judgement	Anyone, using three fixed criteria
What happens if it is wrong	You get a poor result	An irreversible action happens to somebody else
What makes it durable	Nothing, it is a habit	A written map, a Skill, and a named gate

Read that course for why the split matters at all. Read this one for how to produce a split somebody else can check.

10. Who owns the map, and when is it 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. A 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.

This is the same decay you will meet twice more in this course, and it is the reason all three failures are worth naming as one:

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

Three controls, none of which announce their own failure. 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:

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? If nobody can answer, the step is automated and the map is wrong.
Has anything changed the volume or the stakes? A gate sized for the old numbers is a gate that fails at the new ones.
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.

This is what makes the map an operating document

A map with no owner and no review date is a design artifact. It records a decision somebody made once and it will describe your workflow accurately for about a quarter.

A map with an owner and a date is an operating document. It is the thing an auditor asks for, the thing you hand to whoever takes over the workflow, 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

11. 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 totals 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. It looks the same as a calculated one, because on the page it is the same kind of thing: 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. Ask for the arithmetic to be computed and the numbers to come from that computation, and the totals row becomes trustworthy.

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: 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.

Grounding note

The cycle-2 failure and the description-versus-feature contrast are this book's construction, written to connect the design loop to the diagnostic material in Part 4. The loop itself, the artifact example, and the escalation signal in Concept 12 come from the source material. See Sources and grounding.

12. 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 different signals, two different destinations

The book has a second signal that sounds similar and points somewhere else. Do not merge them.

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
I am not sure this needs AI at all	You are upstream of both	Is This an Agent Problem?

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

13. 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. The Four Layers says the same thing about its own model: the map is a search order, not a proof.

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

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

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 analysis on a task that needs depth means a model tier chosen for speed. The fix is the right tool, and more prompting will not buy what the tool cannot produce.

Stale configuration shows up as "it used to work." The same setup that produced good output last month does not now, because a standing instruction, knowledge source, or Skill it depends on has drifted. Nothing errors. 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 of the sequence needs you to have done.

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.

14. The sequence runs cheapest first

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

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

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.

Run end to end, the sequence takes a minute or two and lands in one of two places: a specific cheap fix, most of the time, or a reasoned "this task needs reshaping" occasionally. Either is a win, because both replace a reaction with a decision you can explain to somebody else.

The habit worth building is reaching for the sequence automatically the moment output disappoints, before forming an opinion about whose fault it is.

Where this splits from The Four Layers

The Four Layers teaches a different map for a related problem, and both are worth having.

	This course	The Four Layers
What it taxonomises	Causes of a disappointing output	Parts of an agent system
The categories	Specification, context, feature, configuration	Prompt, context, harness, loop
How you tell them apart	When the symptom appeared	Which layer's unit of work broke
Who it is for	Anyone using AI for work	Anyone building or debugging an agent

Use the timing read here when you are working in a chat or a Project and something came back poor. Use the layer model there when you are building something with a harness and a loop, and need to know which part of the system to open. The shared instruction underneath both is the same: name the cause before you reach for a fix.

15. The fifth answer: when the task itself is the problem

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. 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 between the two 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, which is 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 of the complaint tells you which one you are in, which is exactly why the sequence exists.

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

16. 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.

17. 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.

A worked case: a marketer notices every campaign brief needs the same two corrections, because it omits the target segment and buries the call to action. Rather than fixing both by hand each week, she adds two standing instructions to the briefs Project. The next draft arrives correct. One round of feedback, captured once, removes a recurring weekly cost.

The contrast is an analyst who, every month, reminds the assistant that the report should exclude internal test accounts. He found the right instruction in month one and kept it in the conversation. Six months later he is still typing it, and when a colleague covers for him the colleague does not know to, so a report ships with test data in it.

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.

Where this splits from Claude and ChatGPT 101

Claude and ChatGPT 101 gives the rule of thumb for what lives where: instructions for stable rules, memory for evolving context, Projects for scoped work. That is the configuration map, and it is the prerequisite for this section.

	Claude and ChatGPT 101	This course
The question	Where does context live?	Should this specific fix be promoted, and where to?
The trigger	Setting up your workspace	A correction you just made for the second time
What it adds	Skills as the third home	The rule / reference / procedure test
The failure it prevents	Context in the wrong place	A fix that works and does not survive the week

How to configure and maintain those homes is that course's subject and belongs there. This section stops at the promotion decision.

18. 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 17 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 17 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.

19. 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

The question your manager will actually ask: what does it cost?

Time saved is an internal metric. The question that decides whether a redesign survives a budget review is different: what does this cost to run, and what does it save?

You do not need precision, and you should not invent numbers. You need the method.

What it costs. The subscription or usage cost attributable to this workflow, plus the human time still in it, which is the review gates you deliberately kept. A workflow whose gates consume more reviewer time than the old process consumed doing the work is not a saving, and this is a real outcome rather than a hypothetical one.

What it saves. The baseline above, multiplied by how often the workflow runs and by how many people run it. A twenty-minute saving on a weekly task run by three analysts is roughly fifty hours a year, which is a sentence a manager can act on. "It feels faster" is not.

What it risks. Name the residual honestly. Not every risk, just the one that survives your gates: the failure your review would not catch, and what it would cost if it happened. Leaving this out is how a business case stops being believed the first time something goes wrong.

The reason to write all three down is not the arithmetic. It is that a redesign nobody costed gets removed in the next cost review by somebody who never saw the saving.

Prove the workflow, not just the fix

The caution at the end of this concept says prove a fix over a few cycles before relying on it. The same applies one level up, to the redesign itself, and the stakes are higher because more people are affected.

Run the new workflow in parallel with the old one for a few cycles. Both produce output, and you compare. It costs real duplicated effort for two or three rounds and it buys three things you cannot get any other way: evidence the new way is actually better on your chosen metric, a working fallback if it is not, and the agreement of the people whose work changed.

That last one is the one to plan for. A workflow redesign changes what somebody does all day, and nobody consulted you about whether they wanted it. A parallel run turns "we are changing your job" into "we ran both and here is what happened", which is a conversation with evidence in it rather than an announcement.

Switch fully when the comparison is clear. Keep the old process documented for one more cycle after that.

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.

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

20. 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.

That hour has two halves, and this course owns one of them. 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 rather than improvise, 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.

Four things, decided in advance and written next to the map:

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? For a scheduled process this may be pausing a job. For a queue it may be turning off the automated step and reverting to manual. 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. Being able to answer this quickly is the practical reason to keep a record of what ran when.

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, and this is where Part 4 comes back. Which of the four causes was it? Was a step misclassified, or was it classified correctly and the gate not staffed? Then make the change to the map, with a date, so the fix persists past the week everyone was paying attention.

Why this belongs in the same course as the mapping

It is tempting to treat incident response as somebody else's job, and in a large organisation part of it is. But steps 1 and 4 are yours, and they are decided at design time or not at all.

There is also a practical argument. A team that can say what it does when the workflow is wrong is a team that gets permission to run the workflow. The next concept is about earning stakeholder trust, and nothing earns it faster than a plan for the failure they are already imagining.

21. Value and limits in the same sentence

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.

Overstated	Accurate
"Our new AI system reviews contracts automatically."	"AI drafts the redline and flags playbook departures. Our legal lead reviews and approves every change before anything is sent. Review time is down about half, at the same approval standard."

The right-hand version is longer and it is the one that survives contact with an error. It sets an expectation the workflow can actually meet, and it names the gate, so when something does go wrong the response is "the gate caught it" rather than "you told us it was automatic."

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.

Why this part comes last

Concept 21 asks you to name your workflow's known failure modes to a stakeholder. You could not have done that in Part 1, because you did not yet know what the failure modes were.

Parts 4 and 5 are what make the honest version of this sentence available: it can miss obligations implied indirectly, so the flags are a prompt for your read rather than a substitute for it. That is a Part 4 sentence, said out loud to somebody who is deciding whether to trust the workflow.

Accurate stakeholder communication is downstream of diagnosis. That is why it closes the course rather than opening it.

22. Calibrate to the audience, and name the gate

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

To the legal lead. High literacy, wants the mechanism and the failure modes.

"AI extracts clauses, flags playbook departures, and drafts the redline. It does not approve changes. That gate stays with you. Known failure mode: it can miss obligations implied indirectly, so the flags are a prompt for your read rather than a substitute for it."

To the practice executive. Outcome-focused, wants the result and the oversight.

"Review time is down about half at the same approval standard. Every change is still approved by a lawyer before it leaves the building."

To the client's risk function. Assurance-focused, wants the control.

"AI assists drafting. A qualified human reviews and approves every term. No contract is sent without human sign-off."

Same facts, three levels of detail. A technical stakeholder wants the feature detail and the failure modes. An executive wants the outcome, the oversight, and the risk posture. A risk function wants one sentence about the control and does not want the feature list.

What none of the three versions does is drop the gate. The gate appears in all three, because it is the thing that makes the workflow defensible.

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 is the Description competency from AI Fluency pointed outward. The same precise specification of what the tool does and does not do, aimed at people instead of at the machine.

A short recap before you practise

One line per concept. Carry the last sentence. Come back for the rest.

Concept 1. The unit is the step, not the session. A session is judged afterwards. A step is decided in advance.
Concept 2. Ask for structure with a source column, then attack the list. Extraction finds what was written, not what was meant.
Concept 3. If the plan rests on a number, compute it. A written number is a plausible number.
Concept 4. Synthesis steps run on information you can supply. Judgement steps stay human because their inputs are not in the window, and anything current needs a checkable source rather than a confident answer.
Concept 5. Reversibility, stakes, accountability. Three independent vetoes, not three inputs to a score.
Concept 6. Two unrelated workflows produce the same pattern, because the criteria decide it rather than taste.
Concept 7. Drafting quality is evidence about the draft, never about the decision.
Concept 8. Halo delegation, the unstaffed gate, and mapping the tool instead of the work.
Concept 9. Procedures become Skills, references become knowledge, calculations become code, human steps become named gates.
Concept 10. A map with no owner and no review date is a design artifact. Only a scheduled read catches a failure that gives no signal.
Concept 11. Ideate, prototype, feedback, refine, in a Project. A description problem and a feature problem look identical and are not.
Concept 12. Dependency is the escalation signal. Others relying on it means it has outgrown prompt-and-iterate.
Concept 13. Timing gives you a leading hypothesis and a cheap way to confirm it, not a diagnosis.
Concept 14. Cheapest fix first. Most people start at the bottom of the ladder.
Concept 15. Expectation mismatch is a conclusion when reached last and an excuse when reached first.
Concept 16. A reaction names how it feels. An instruction names the lever. If you cannot name the lever, keep going.
Concept 17. Rule to instructions, reference to knowledge, procedure to a Skill. The wrong home is why fixes do not stick.
Concept 18. Repetition, correction, variance. Variance is the one nobody feels individually.
Concept 19. Measure what the workflow was for, and stop when that metric is good enough.
Concept 20. Decide in advance how it gets stopped, what is already out, who is told, and what changes in the map.
Concept 21. State what it does, then name the checkpoint. Two clauses.
Concept 22. Same facts, three altitudes, and the gate is in all three.

And the one sentence worth keeping:

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.

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          high stakes, answerable        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? Who is answerable for the outcome? 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.

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.
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.
Run one step for real. Pick the most mechanical AI step and actually run it on real input.
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 13 before you fix it.
Promote one fix. Take something you corrected in step 3 or 4 and put it in its correct home.
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.
Fill in the one-page map, including the owner, the next review date, and the four lines under "if it goes wrong".
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, on purpose

Real topics, deliberately set aside, so you know they exist.

How to configure and maintain Projects, knowledge, and Skills. This course teaches you to decide that a fix should be promoted and where it belongs. Building and maintaining those configurations is Skills & Connectors and Claude and ChatGPT 101.

Choosing a model. Concept 13 says a speed-tier model on a depth task is a diagnosable cause. It does not tell you which model to pick, because that changes faster than any course can track. Which AI Employees in 2026 is the book's current map.

Evaluating output in depth. Pressure-testing requirements is here. Systematically judging whether output is correct is a larger subject, in AI Fluency and then Trusting the Checker.

Governance, privacy, and data handling. Part 2 opens with the gate that asks whether the data may enter the tool at all, and then stops. How to answer that question, what your regulator requires, and what an organisational AI policy should contain are the subject of Governance, Risk & Responsible Use, which is the next course in Foundations.

Incident response beyond your own workflow. Concept 20 covers the four decisions that are yours at design time. Organisational incident management, breach notification obligations, and anything with a legal clock attached belong to your compliance function, not to this course.

Building the thing after escalation. Concept 12 tells you when something has outgrown prompt-and-iterate. What to build instead is Spec-Driven Development, From One-Off to Worker, and the Mode 2 track.

Whether the task needed AI at all. This course assumes you have decided to use AI on this workflow. Is This an Agent Problem? is the gate upstream of that assumption.

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. Who is answerable for a step's outcome. It does not delegate.

AI-appropriate. A step AI may own, because it is reversible, low-stakes, and carries no personal accountability.

Human-retained. A step a person owns outright, usually because it is irreversible, high-stakes, or attributable.

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.

Where this leads

You can now map a workflow, defend the map, diagnose it when it misbehaves, make fixes permanent, and describe the result accurately.

Next in Foundations, Governance, Risk & Responsible Use answers the question Part 2 opens with and then refuses: whether AI may do this work at all, whether this data may go in, and what to do in the first hour when something reaches somebody. It is the last Foundations course, and it is what makes the map you just built safe to run at your job.

Then the question upstream of this course: Is This an Agent Problem? asks whether a task should involve an agent at all, and Problem Solving with General Agents teaches you to hit the target once you have chosen it.

Later, when a workflow has outgrown prompt-and-iterate:

The Four Layers replaces the four-cause read with a system model for anything with a harness and a loop.
Spec-Driven Development turns a delegation map into an engineering specification.
From One-Off to Worker is the crossing into manufacturing.
Trusting the Checker and Eval-Driven Development turn review gates into evaluation infrastructure.

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.

Sources and grounding

The delegation criteria, the two worked maps, the mapping errors, the four root causes, the diagnostic sequence, the promotion test, and the stakeholder framing in this course follow Anthropic's Claude Certified Associate course material for Workflow Integration and Solution Design and for Troubleshooting and Optimisation. This is an independent explanation in this book's own words and examples, not a copy or an adaptation.

Two things in this course are the book's own extension rather than the source material, and are marked here so nobody mistakes them for it:

The failing cycle in Concept 11. The source demonstrates the iteration loop through its first cycle. Cycles 2 and 3, the plausible-but-uncomputed totals, and the description-versus-feature contrast are written for this book, to connect the design loop to the diagnostic material in Part 4.
The unstaffed gate as a pair with stale configuration. Both failures are in the source material, in separate modules. Naming them as the same failure seen from two sides, in Concepts 8 and 14, is this book's observation.

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...

📚 Teaching Aid​

Try it before you read it​

The questions this course answers​

Part 1: Design the work before you place the tool​

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

2. Extract the requirements, then attack them​

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

4. Where AI insight actually changes a plan​

Part 2: The delegation map​

5. Three criteria decide every step​

6. Two workflows, same criteria, different answers​

7. Over-delegation: drafting quality is not a licence​

8. Three ways a map goes wrong​

9. From map to redesign: put the feature where the step is​

10. Who owns the map, and when is it read again​

Part 3: Build it, and watch it​

11. The loop: ideate, prototype, feedback, refine​

12. When it has outgrown prompt-and-iterate​

Part 4: When it misbehaves​

13. Four causes, told apart by when the symptom appeared​

14. The sequence runs cheapest first​

15. The fifth answer: when the task itself is the problem​

Part 5: Make the fix stick​

16. Turn a reaction into an instruction​

17. Rule, reference, or procedure​

18. Find the friction before you optimise​

19. Measure the thing you actually care about​

Part 6: Operate it, and explain it​

20. When a bad output gets out​

21. Value and limits in the same sentence​

22. Calibrate to the audience, and name the gate​

A short recap before you practise​

Map your own workflow​

The one-page map: copy this​

Try this now: five prompts​

1. Extract and then attack​

2. Find the step you cannot undo​

3. Diagnose by timing​

4. Promote one fix​

5. Say it three ways​

A project: map, break, fix, and explain​

What this course leaves out, on purpose​

Terms this course adds​

Where this leads​

Sources and grounding​

Flashcards Study Aid​

Test Your Understanding​