1.4 Workflow Enforcement & Handoff

There's a question that quietly runs underneath this entire certification, and Task Statement 1.4 is where you meet it head-on: when is it enough to ASK the model to do something, and when do you have to FORCE it? Get this distinction right and a surprising number of exam questions answer themselves.

Think about the difference between a sign and a lock. A sign on a door that says "Staff only, please" works most of the time — most people respect it. But if what's behind the door is dangerous or expensive, "most of the time" isn't good enough; you fit a lock. A prompt instruction to the model is a sign: "please always verify the customer before issuing a refund." The model will usually comply. But 'usually' means a small fraction of refunds go out to unverified accounts — and when that's real money, a sign isn't enough. You need a lock.

In agent design, the 'sign' is prompt-based guidance and the 'lock' is programmatic enforcement — actual code that makes the unsafe path impossible. This lesson is about knowing which one a situation demands, and how to build the lock when you need it. We also cover what to do when the agent has to hand a problem off to a human — another moment where being deliberate matters.

Let's make 'the stakes decide' precise, because that's the actual decision rule the exam rewards. Every workflow requirement sits somewhere on a spectrum from 'nice if it happens' to 'must happen, always.'

At the low-stakes end — formatting, tone, style — a prompt is perfect. If the model occasionally formats a date differently, nobody is harmed; the cost of an occasional miss is trivial, and few-shot examples nudge it into line. At the high-stakes end — anything financial, security-related, or compliance-bound — a prompt is a liability, because its non-zero failure rate, multiplied across thousands of transactions, guarantees some failures, and each one matters. There, you need code that cannot be talked out of doing its job.

So the rule is simple and worth memorising: financial, security, or compliance requirement → programmatic enforcement; low-stakes formatting or style → a prompt is fine. The reason a prompt can't carry the high-stakes end is fundamental, not fixable by better wording: the model is probabilistic by nature, so 'follow this instruction' always carries some chance of not following it. No amount of prompt-polishing turns a probability into a guarantee.

What does a 'lock' actually look like in code? The most important pattern is the prerequisite gate: code that refuses to let a downstream action run until a required earlier step has genuinely completed. It's the agent equivalent of a checkout that won't let you pay until you've entered a shipping address.

Here's why it's bulletproof, and it connects straight back to Lesson 1.1. Recall the division of labour: the model only PROPOSES an action; your code decides whether to actually run it. A prerequisite gate lives in that 'whether to run it' step. When the model proposes process_refund, your gate checks: has get_customer returned a verified ID this session? If not, the gate refuses — and the model has no way around it, because the model never had the power to execute the tool in the first place. You can prompt the model however you like; the lock is in the code, not the conversation.

Contrast this with the tempting-but-wrong alternatives. A stronger system prompt? Still a sign. More few-shot examples showing verification first? Still a sign — you've made compliance more LIKELY, not certain. A routing classifier that picks which tools to enable? That changes which tools are AVAILABLE, not the ORDER they're called — it doesn't address sequencing at all. Only the gate gives a guarantee.

Real users rarely send tidy single-issue requests. They send: "My order is three days late, I think I was double-charged, and I want to update my shipping address." A naive agent latches onto the first problem, resolves it, and forgets the other two — leaving the customer to come back twice more.

The pattern that handles this well has three beats. First, DECOMPOSE the message into its distinct concerns (late order, double charge, address change) — this is the same decompose instinct from multi-agent orchestration, applied within one conversation. Second, INVESTIGATE each concern, ideally in parallel, using the shared context of who this customer is. Third, SYNTHESISE one unified response that addresses all three, rather than three disjointed replies. The customer experiences a single, complete resolution.

Sometimes the right move is to stop and hand the problem to a human — a policy exception, a sensitive dispute, an explicit request for a person. The danger here is subtle: the human who takes over has NONE of the context. They can't see the conversation transcript, the tools the agent called, or what it figured out. To them, a bare 'escalating to a human' is almost useless — the customer has to re-explain everything from scratch, and the agent's work is wasted.

This is the same problem as briefing a subagent in Lesson 1.3, just pointed at a person: the receiver starts blank, so you must hand them a complete, self-contained brief. A good structured handoff carries the customer ID and account, a concise summary of what was asked and tried, the root-cause analysis the agent reached, the concrete recommended action, and any partial results already gathered so the human doesn't redo them. Done well, the human picks up exactly where the agent left off.

• •Customer ID and the verified account in question — so the human isn't re-identifying anyone.
• •A concise summary of what the customer asked and what's already been tried.
• •The root-cause analysis — what the agent determined is actually wrong.
• •The concrete recommended action (e.g. a specific refund amount or the policy exception requested).
• •Any partial results already gathered, so the human continues rather than restarts.

Every 1.4 trap has the same shape: a question describes a high-stakes reliability problem, and three of the four answers offer a probabilistic fix dressed up to look thorough. The fourth — the deterministic one — is the answer. Train yourself to spot the lock among the signs.

One distractor deserves a special callout because it's so common: the routing classifier. It sounds sophisticated, but it only decides which tools are AVAILABLE for a request — it never controls the ORDER in which the model calls them. So for a 'verify before refund' sequencing problem, a routing classifier is simply aimed at the wrong target. The prerequisite gate is.

You can now distinguish signs from locks, place a requirement on the enforcement spectrum, build a prerequisite gate, handle multi-concern requests, and design a structured handoff. The exercise drives home the central truth: prove to yourself that the prompt-only version eventually slips, and the gated version never does.

This lesson introduced enforcement in general — code that guarantees behaviour. The next lesson, 1.5, zooms into the most powerful enforcement mechanism Claude gives you: hooks — code that fires at precise moments in the loop to transform data or block actions.