Workflow enforcement and handoff design

What you’ll be able to do

Distinguish programmatic enforcement (hooks, prerequisite gates) from prompt-based guidance, and know when guidance alone isn’t enough
Implement a prerequisite gate that blocks a downstream tool until an upstream step has returned what it requires
Decompose a multi-concern request into distinct items, investigate them in parallel with shared context, and synthesize one resolution
Compile a structured handoff summary for a human agent who has no access to the conversation transcript

What you need to know

Two ways to control ordering

Multi-step workflows usually have steps that must happen in a particular order: verify the customer before touching their orders, confirm eligibility before issuing a refund. There are two ways to make the agent follow that order.

Prompt-based guidance — system-prompt instructions, emphasis, few-shot examples showing the correct sequence. The model reads them and usually complies.
Programmatic enforcement — hooks and prerequisite gates in your application code that make the out-of-order action impossible. The model can attempt it; the system won't execute it.

Guidance is fine for preferences — tone, which of two acceptable approaches to try first. But prompt compliance is probabilistic: even a well-written instruction has a non-zero failure rate. When the rule protects money or identity — verifying who the customer is before a financial operation — "almost always" isn't the requirement. Deterministic compliance needs a mechanism that doesn't depend on the model choosing to comply.

Prerequisite gates

A prerequisite gate blocks a downstream tool call until a prerequisite step has completed with the result the downstream step depends on. In a support agent with get_customer, lookup_order, process_refund, and escalate_to_human, the gate on process_refund checks that get_customer has returned a verified customer ID in this session — not merely that it was called, and not that the model says it verified the customer.

before — ordering lives only in the prompt

SYSTEM: "IMPORTANT: Always call get_customer and verify the customer before calling process_refund."

after — the application refuses out-of-order calls

def execute_tool(name, args, session): if name == "process_refund": if session.verified_customer_id is None: return tool_error("Blocked: verify the customer with get_customer first.") if args["customer_id"] != session.verified_customer_id: return tool_error("Blocked: refund must target the verified customer.") result = run(name, args) if name == "get_customer" and result.verified: session.verified_customer_id = result.customer_id return result

The blocked call comes back as a tool result explaining why, so the model can recover by doing the prerequisite step. The gate doesn't replace the prompt instruction — keep that too, so the agent usually gets the order right the first time — but the gate is what makes it guaranteed.

Multi-concern requests

Customers often bundle several issues into one message: "My last order arrived damaged, I was charged twice for it, and I want to change my delivery address for the next one." Treating that as one issue tends to resolve the most prominent concern and drop the rest. Instead:

Decompose the request into distinct items — damaged item, duplicate charge, address change.
Investigate each in parallel, using shared context: the same verified customer, the same order data, so the items don't contradict each other or repeat lookups.
Synthesize one unified resolution that addresses every item in a single coherent response — for instance, noticing that the duplicate charge and the damaged-item refund apply to the same order.

Structured handoffs to humans

When an agent escalates mid-process, the human picking up the case typically does not have the conversation transcript. "Escalating — customer upset about refund" forces them to start over; forwarding a long raw transcript forces them to re-read and re-derive everything. A structured handoff gives them what they need to act immediately:

structured handoff summary passed to escalate_to_human

{ "customer_id": "C-48213", "issue_summary": "Duplicate charge on order 99120; customer requests refund of the second charge", "root_cause": "Payment retry after gateway timeout captured twice", "evidence": ["two captures of $184.50 on 2026-10-21, 14:02 and 14:03"], "actions_taken": ["verified identity", "confirmed both captures settled"], "refund_amount": 184.50, "recommended_action": "Approve refund of one $184.50 capture; amount exceeds agent refund limit", "open_items": ["customer also asked about loyalty points; not yet addressed"] }

The essentials are customer details, the root-cause analysis, the amount involved, and a recommended action — enough that the human can approve, adjust, or reject without reconstructing the case.

Key concept

If an ordering rule must hold every time, enforce it in code: a prerequisite gate that blocks the downstream tool until the upstream step has returned what it needs. Prompts reduce violations; gates eliminate them. When escalating, give the human a structured summary they can act on without the transcript.

When a scenario describes a critical step being skipped "occasionally" and offers a better prompt or more examples as fixes, the answer is almost always programmatic enforcement.

Practice scenario

ScenarioA support agent's prompt says to confirm the order belongs to the verified customer before calling process_refund. After a prompt rewrite, compliance in audits rose from 96% to 99%. Leadership asks whether one more round of prompt work can get it to 100%. Separately, human agents complain that escalated cases arrive as "please see conversation," and they can't see the conversation.

Work it through, then open this

No prompt revision can guarantee 100%; compliance with instructions is probabilistic, and the remaining 1% are financial errors. Add a prerequisite gate in the tool-execution layer that blocks process_refund unless get_customer returned a verified ID and the order belongs to that customer, returning an explanatory error so the agent can recover. For escalations, have the agent call escalate_to_human with a structured summary: customer ID, issue, root cause, amount, actions taken, and recommended action.

Build exercise — Gate a refund and structure the escalation

Intermediate · 30 min

What you’ll learn

Moving a must-hold ordering rule from the prompt into the tool-execution layer
Gating on returned results, not on calls made
Designing a handoff a human can act on cold

List every ordering rule in a support agent’s prompt and mark each as a preference or a must-hold rule (identity, money, compliance).
- Why: Only must-hold rules need deterministic enforcement; preferences can stay as guidance.
- You should see: A short list of must-hold rules, such as verification before process_refund.
Implement a prerequisite gate for one must-hold rule. Record the verified customer ID when get_customer returns it, and block process_refund with an explanatory error if it’s missing or doesn’t match.
- Why: The gate makes the out-of-order call impossible regardless of what the model decides.
- You should see: A test conversation that tries to refund first receiving a blocked result, then the agent calling get_customer and succeeding.
Define a handoff schema for escalate_to_human (customer ID, issue, root cause, amount, actions taken, recommended action, open items) and have someone unfamiliar with the case act on one using only the summary.
- Why: The human agent won’t have the transcript; the summary is all they get.
- You should see: The reviewer able to make a decision without asking what happened.

Exam traps

Strengthening the system prompt to fix an ordering rule that must hold every time

Better wording lowers the failure rate but can’t remove it. Must-hold rules need a programmatic gate.

Treating a high prompt-compliance rate as good enough for identity or financial steps

99% compliance on refunds still means wrong-account refunds. Deterministic requirements need deterministic mechanisms.

Adding few-shot examples of the correct order instead of a programmatic prerequisite

Examples are still prompt-based guidance with probabilistic compliance. They complement a gate; they don’t replace it.

Gating on whether the upstream tool was called rather than on what it returned

The gate should require the verified customer ID that get_customer returned, not just evidence the call happened.

Treating a multi-concern request as one undifferentiated issue, or splitting it with no shared context

Decompose into distinct items, investigate them in parallel with shared customer and order context, then synthesize one resolution.

Escalating with the raw transcript or a one-line note to a human who can’t see the conversation

Hand off a structured summary — customer ID, root cause, amount, recommended action — that the human can act on immediately.

Sources

Claude Developer Platform Docs
Anthropic, Claude Certified Architect – Foundations Exam Guide v1.0 (July 2026)