CCAR-F 1.4 — Enforcement and handoff in multi-step workflows

Guidance versus enforcement

A system prompt that says “always verify the customer before processing a refund” will be followed most of the time. The guide's point is that most of the time is not good enough when the rule is a compliance requirement: prompt instructions have a non-zero failure rate. When ordering must be deterministic, enforce it programmatically.

Anthropic's Claude Code guidance makes the same distinction in its own words: instructions in CLAUDE.md are advisory, while hooks are deterministic and guarantee the action happens. The same logic applies to any agent. If you can state a rule as a condition your code can check — a verified id exists, an amount is under a limit, a status is “approved” — then check it in code and let the prompt handle everything that is a matter of judgement.

	Prompt-based guidance	Programmatic enforcement
How it works	Instruction in the system prompt	A hook or prerequisite gate in code
Reliability	Probabilistic	Deterministic
Right for	Style, tone, preferred order	Identity checks, financial limits, compliance
Failure looks like	Occasional skipped step	Blocked call with a clear reason

Instruction or enforcement?

What happens if the step is skipped once?

Money moves or law is broken
Gate it in codeblock the tool until the prerequisite holds
Wrong person's data is exposed
Gate it in codecheck identity before any lookup
The reply is slightly worse
Prompt guidancetone, format, preferred order

Ask what a single skipped step would cost. If the answer involves money, law or someone else's data, a prompt alone is the wrong tool.

Prerequisite gates

A gate blocks a downstream tool until an upstream step has completed. The canonical example: process_refund is refused unless get_customer has already returned a verified customer id in this session.

A prerequisite gate in the tool dispatcherpython

def run_tool(name, args, session):
    if name == "process_refund":
        if not session.verified_customer_id:
            # returned to Claude as a tool_result with is_error set
            return tool_error(
                category="validation",
                retryable=False,
                message="Verify the customer with get_customer before a refund.",
            )
        if args["customer_id"] != session.verified_customer_id:
            return tool_error(
                category="permission",
                retryable=False,
                message="Refund target does not match the verified customer.",
            )
    result = TOOLS[name](**args)
    if name == "get_customer" and result.get("verified"):
        session.verified_customer_id = result["id"]
    return result

The blocked call returns a structured error the model can act on — here, by calling get_customer first. In the Messages API that means a tool_result with is_error set and a message that says what to do next; the tool-use documentation specifically recommends instructive errors over a bare “failed”. Structured tool errors are covered properly in 2.2, and the Agent SDK's hook-based version of the same gate is covered in 1.5.

Notice two details. The gate records state from a successful upstream call (verified_customer_id) rather than trusting the model's claim that it verified someone. And it checks that the refund is for the same customer who was verified — a gate that only asks “has anyone been verified?” can be satisfied by the wrong person.

The gate in action

Claude

Your dispatcher

Refund system

process_refund(C-20931, 2499)

Error: verify customer first

get_customer(C-20931)

Verified · id recorded

process_refund(C-20931, 2499)

Execute refund

Refund reference R-5521

The model tried to skip a step; the dispatcher refused and said why; the model recovered on its own. Nothing reached the refund system until the rule held.

Multi-concern requests

Customers bundle problems: a late delivery, a double charge and an address change in one message. Decompose them into distinct items, investigate each — in parallel where they are independent, using shared context such as the customer record — then synthesise one resolution. Handling them as a single blob tends to resolve the loudest issue and drop the rest.

Worked example · Three problems in one message

A retailer's support agent receives: “My parcel is four days late, I've been charged twice for it, and please send future orders to my new flat.”

Verify once. The agent calls get_customer; the gate records the verified id, which every later step reuses.
Split. It lists three items: a delivery delay, a duplicate charge, an address change.
Investigate in parallel. The tracking lookup and the payment lookup do not depend on each other, so both are requested in the same turn. The address change needs no lookup.
Act within limits. Tracking shows the parcel at the local depot; the payment log confirms two captures. The refund is under the automatic limit, so the gated process_refund runs. The address is updated.
One reply. The customer gets a single message covering all three, with the refund reference and the expected delivery date.

Takeaway: Decompose, investigate, then synthesise. A reply that fixes the double charge and ignores the address is a failed resolution even though every tool call succeeded.

Structured handoff

When the agent escalates to a human mid-process, the human usually cannot see the transcript. A handoff that says “customer is upset about a refund” forces them to start again. A structured summary lets them act immediately.

What a human agent needsjson

{
  "customer_id": "C-20931",
  "issue": "Charged twice for order 88412",
  "root_cause": "Payment retried after a gateway timeout; both captures succeeded",
  "actions_taken": ["Verified identity", "Confirmed duplicate capture"],
  "recommended_action": "Refund one capture of INR 2,499",
  "why_escalated": "Refund exceeds the agent's automatic limit"
}

Checking a weak handoff note

Missing: Who the customer isno customer id
Check: What the issue is“refund” — for which order?
Missing: Root cause found so far
Missing: Actions already takenwas identity verified?
Missing: Recommended next action
Missing: Why it was escalatedlimit, policy, or anger?
Passes: Customer sentimentthe one thing it does say

The note “Customer upset about refund, please help” checked against what the receiving human needs. Only one item survives.

Worked example · An escalation at a telecom help desk

A customer disputes a roaming charge of 180 euros. The agent's automatic credit limit is 50 euros, so policy requires a human.

Before escalating, finish the investigation. The agent verifies the account, pulls the usage log and finds data sessions registered on a foreign network while the customer's phone was in airplane mode according to the device report.
Compile the handoff. Customer id, the disputed charge, the root-cause hypothesis (likely network misattribution), the evidence retrieved, actions taken, the recommended action (full credit pending network check) and the reason for escalation (amount over limit).
Tell the customer the truth. “I've passed this to a specialist with everything we found; you won't need to explain it again.”
The human acts in minutes. They read one structured note, confirm the network record and approve the credit — without reopening the investigation.

Takeaway: Escalation is part of the workflow, not an admission of failure. A good handoff moves the case forward instead of back to the start.

Traps the wrong answers are built from

Tempting but wrong	Do this instead
Relying on the system prompt for a compliance-critical order of steps	Block the downstream tool until the prerequisite has completed.
Escalating with a one-line summary	Hand off customer id, root cause, actions taken and a recommended action.
Treating a multi-issue message as one problem	Split into items, investigate each, then synthesise one reply.
A gate that trusts the model's claim that a step happened	Record state from the upstream tool's actual result and check it.
A bare “failed” when the gate blocks a call	Return an instructive error naming the step that must come first.

You should now be able to

Implement prerequisite gates that block a tool until an earlier step has succeeded.
Decompose multi-concern requests and investigate the parts before one resolution.
Compile structured handoff summaries for humans who lack the transcript.
Decide when a rule needs enforcement rather than instruction.
Write gate errors that let the model recover by itself.

Enforcement and handoff in multi-step workflows