Deterministic prerequisite and human handoff — Labs

Labs · Lab 3 of 10

60–90 minutes activeTask 1.4: Implement multi-step workflows with enforcement and handoff Task 1.5: Apply Agent SDK hooks for tool call interception and data flow Task 2.3: Distribute tools appropriately across agents and configure tool choice Task 5.2: Design effective escalation and ambiguity resolution patterns

The brief

Your assignment

Model a fictional campus bookstore return service with in-memory customer, order, and refund records. Gate order lookup on identity verification, require approval above a fictional refund threshold, and immediately honor an explicit request for a human.

Use fake people, identifiers, money, and transactions. The threshold is a lab constraint, not an Anthropic recommendation.

Before you build

Set up a safe workspace

Review the mapped authorization and handoff tasks.
Create fictional customer, order, and refund records.
Choose and document a fictional approval threshold.

Build in checkpoints

One observable behavior at a time

01Write the policy decision table.
02Place identity and approval gates before protected tools.
03Test ambiguous identity and above-threshold requests.
04Remove the prompt instruction and confirm the gates still hold.
05Produce a minimum-necessary human handoff and audit entry.

What you'll practice

Separate prompt guidance from enforceable policy.
Gate actions on explicit authorization state.
Clarify ambiguity instead of selecting an identity by guess.
Prepare a concise, minimum-necessary handoff.

Your lab files

Four files for each lab

01
decision.md
State the requirement, chosen pattern, rejected alternatives, and the reason for the tradeoff.
02
implementation/
Keep the smallest working example, configuration, diagram, or synthetic-trace analysis.
03
evidence.md
Record test cases, observed results, failure behavior, limitations, and evidence locations.
04
review.md
Explain what must be deterministic, what may remain model-directed, and where a human is required.

Download starter templates

What to save

A policy decision table and workflow diagram.
A fake-data tool implementation or trace analysis.
An adversarial test set.
A sample handoff and redacted audit-log entry.

Test bench

What good work includes

Removing prompt instructions cannot bypass identity or approval gates.
Ambiguous identity never selects a customer by guess.
Above-threshold refunds never execute without approval.
An explicit human request enters handoff immediately.
The handoff contains verified identifiers, attempts, state, and reason.

Review questions

Which policy belongs in code, a hook, a prompt, or human review?
How long should prior verification remain valid?
What must not appear in the handoff?

Strong solutions tend to

Enforcement close to the protected action.
Simulated or idempotent mutation and a clear recovery path.
Minimum necessary handoff data.

These are common strengths, not one required design.

Partial example

What useful evidence can look like

This is one small example, not a complete solution or a template you must copy. Use the notes to see why the evidence is useful.

Open annotated example from decision.md / policy row

Condition: refund > fictional threshold
Required state: approval.status = "granted"
Enforced by: issue_refund wrapper
Denied outcome: no mutation; return approval_required

Required state: Names the application state that must exist before the action.
Denied outcome: Makes the safe failure observable and testable rather than relying on prompt wording.

Review your work

Use evidence from your work—not confidence alone. For each area, run the check and choose the strongest stage your work fully demonstrates.

If you're between two stages, use the earlier one and treat the next stage as your revision goal. There is no total score.

Identity prerequisite

Order and refund tools cannot run until application state proves that identity verification succeeded.

How to check

Remove the prompt instruction, then try a protected lookup with missing, failed, expired, and ambiguous identity states.

Needs another pass

The prompt tells the model to verify identity, but code does not enforce it, or an ambiguous match can select a customer and continue.

Partly demonstrated

A gate exists, but it does not cover every protected tool or does not distinguish missing, failed, expired, and ambiguous states.

Demonstrated

Code checks explicit verification state before every protected tool. Ambiguity requests clarification, and prompt removal cannot bypass the gate.

Approval and side effects

Above-threshold refunds require recorded approval before any simulated or real mutation can occur.

How to check

Test values below, exactly at, and above the fictional threshold with approval missing, denied, and granted. Inspect whether any mutation occurred.

Needs another pass

The model decides whether approval is needed, or an above-threshold refund can execute before approval is recorded.

Partly demonstrated

The common above-threshold case is blocked, but boundary values, denied approval, or repeated requests have unclear behavior.

Demonstrated

Application code handles every threshold boundary, approval state, and repeat safely. No protected side effect occurs before approval.

Clarification and human handoff

Ambiguity is clarified, while an explicit request for a person creates an immediate, useful handoff.

How to check

Run one ambiguous-identity case and one explicit-human-request case. Compare the resulting question or handoff with the decision table.

Needs another pass

The system guesses an identity, continues investigating after a human request, or sends a transcript with unnecessary data.

Partly demonstrated

The system routes both cases correctly, but the handoff omits verified state, attempts already made, or the reason help is needed.

Demonstrated

Ambiguity produces a focused question. A human request immediately creates a minimum-necessary handoff with verified identifiers, attempts, current state, and reason.

Adversarial evidence and audit

The test packet proves that policy enforcement survives missing instructions and records protected decisions without exposing sensitive details.

How to check

Use the adversarial cases to attempt each bypass, then match the observed decision, side effect, and redacted audit entry to the expected result.

Needs another pass

Only the happy path is tested, or logs expose raw customer data without showing why a protected action was allowed or blocked.

Partly demonstrated

Several bypasses are tested, but at least one required state or audit outcome lacks observed evidence.

Demonstrated

Tests cover prompt removal, ambiguity, threshold boundaries, approval states, and human requests. Audit entries show the decision and reason with fake, minimum-necessary data.

Loading completion status…

Your assignment

Use fake people, identifiers, money, and transactions. The threshold is a lab constraint, not an Anthropic recommendation.

Four files for each lab

decision.md

State the requirement, chosen pattern, rejected alternatives, and the reason for the tradeoff.

implementation/

Keep the smallest working example, configuration, diagram, or synthetic-trace analysis.

evidence.md

Record test cases, observed results, failure behavior, limitations, and evidence locations.

review.md

Explain what must be deterministic, what may remain model-directed, and where a human is required.

What to save

A policy decision table and workflow diagram.

A fake-data tool implementation or trace analysis.

An adversarial test set.

A sample handoff and redacted audit-log entry.

What good work includes

Removing prompt instructions cannot bypass identity or approval gates.

Ambiguous identity never selects a customer by guess.

Above-threshold refunds never execute without approval.

An explicit human request enters handoff immediately.

The handoff contains verified identifiers, attempts, state, and reason.

What useful evidence can look like

This is one small example, not a complete solution or a template you must copy. Use the notes to see why the evidence is useful.

Open annotated example from decision.md / policy row

Condition: refund > fictional threshold
Required state: approval.status = "granted"
Enforced by: issue_refund wrapper
Denied outcome: no mutation; return approval_required

Required state: Names the application state that must exist before the action.
Denied outcome: Makes the safe failure observable and testable rather than relying on prompt wording.

Review your work

Use evidence from your work—not confidence alone. For each area, run the check and choose the strongest stage your work fully demonstrates.

If you're between two stages, use the earlier one and treat the next stage as your revision goal. There is no total score.

Identity prerequisite

Order and refund tools cannot run until application state proves that identity verification succeeded.

How to check

Remove the prompt instruction, then try a protected lookup with missing, failed, expired, and ambiguous identity states.

Needs another pass

The prompt tells the model to verify identity, but code does not enforce it, or an ambiguous match can select a customer and continue.

Partly demonstrated

A gate exists, but it does not cover every protected tool or does not distinguish missing, failed, expired, and ambiguous states.

Demonstrated

Code checks explicit verification state before every protected tool. Ambiguity requests clarification, and prompt removal cannot bypass the gate.

Approval and side effects

Above-threshold refunds require recorded approval before any simulated or real mutation can occur.

How to check

Test values below, exactly at, and above the fictional threshold with approval missing, denied, and granted. Inspect whether any mutation occurred.

Needs another pass

The model decides whether approval is needed, or an above-threshold refund can execute before approval is recorded.

Partly demonstrated

The common above-threshold case is blocked, but boundary values, denied approval, or repeated requests have unclear behavior.

Demonstrated

Application code handles every threshold boundary, approval state, and repeat safely. No protected side effect occurs before approval.

Clarification and human handoff

Ambiguity is clarified, while an explicit request for a person creates an immediate, useful handoff.

How to check

Run one ambiguous-identity case and one explicit-human-request case. Compare the resulting question or handoff with the decision table.

Needs another pass

The system guesses an identity, continues investigating after a human request, or sends a transcript with unnecessary data.

Partly demonstrated

The system routes both cases correctly, but the handoff omits verified state, attempts already made, or the reason help is needed.

Demonstrated

Ambiguity produces a focused question. A human request immediately creates a minimum-necessary handoff with verified identifiers, attempts, current state, and reason.

Adversarial evidence and audit

The test packet proves that policy enforcement survives missing instructions and records protected decisions without exposing sensitive details.

How to check

Use the adversarial cases to attempt each bypass, then match the observed decision, side effect, and redacted audit entry to the expected result.

Needs another pass

Only the happy path is tested, or logs expose raw customer data without showing why a protected action was allowed or blocked.

Partly demonstrated

Several bypasses are tested, but at least one required state or audit outcome lacks observed evidence.

Demonstrated

Tests cover prompt removal, ambiguity, threshold boundaries, approval states, and human requests. Audit entries show the decision and reason with fake, minimum-necessary data.