Multi-step workflows with enforcement and handoff

Prompt instructions have a failure rate

A prompt can tell the model to verify identity before issuing a refund, but it cannot guarantee that the step will occur on every run. Prompt-based ordering is probabilistic and has a non-zero failure rate.

Where the consequence is financial, legal, or safety-critical, that is not good enough. Programmatic enforcement — a hook, a prerequisite gate — is deterministic. It cannot be talked out of the rule.

An online form can ask you politely at the top to include your student ID, or it can refuse to submit without one. Only the second is a guarantee, and it is only as good as the field it actually checks.

So the word sometimes is the diagnostic. When an agent skips a required step some of the time, the fix is structural. Rewording the prompt, adding few-shot examples of the correct order, and restricting the tool list are all answers to different problems.

This is also why "state it again, nearer the end" is not a fix. Repeating an instruction or moving it somewhere more prominent can lower the failure rate, and it cannot take the rate to zero, because the mechanism is still guidance either way. A smaller non-zero number is not a guarantee.

What a prerequisite gate looks like

Block process_refund until get_customer has returned a verified customer ID. Not "instruct the agent to call get_customer first" — block the call. The gate holds regardless of what the model decides.

Illustrative shape. A gate is ordinary code on the calling path, not a sentence in a prompt:

function mayCallProcessRefund(session): boolean {
  // Gate on the verified result, not on the agent's claim to have verified.
  return session.verifiedCustomerId !== null;
}

def may_call_process_refund(session) -> bool:
    # Gate on the verified result, not on the agent's claim to have verified.
    return session.verified_customer_id is not None

The model cannot override this condition. Changing which requests pass the gate requires changing the predicate in code.

Two things can go wrong with a gate, and they need different fixes. If it blocks work it should allow, widen the predicate — the mechanism is sound and the condition is not. What it must never gain is an exception the model can invoke, because that hands the decision back to the model it was protecting against.

Decomposing multi-concern requests

A customer message often contains several problems at once. Split them into distinct items, investigate them in parallel against shared context, then synthesize one coherent resolution rather than answering serially and repeating yourself.

When to escalate

Escalate for ambiguity and for gaps in policy — a case the rules do not decide, or one where acting would exceed what the agent is permitted to do. Volume is not a trigger: three concerns in one message are three investigations, not a reason to hand the message to a person.

Create a useful handoff document

A human picking up an escalation doesn't have the conversation. Give them what they need to act: customer identifier, root cause, amounts involved, what has already been tried, and a recommended action. Structured, so it can be scanned in seconds.