Tool preconditions

The agent has one tool that moves money

The Lumen Supply agent looks up customers, looks up orders, and refunds orders. It can also hand a ticket to a human. Only the refund tool moves money.

You will put a precondition check in front of that tool. A precondition check is code that runs before a tool call and can refuse it. The model never sees the code. It sees a clear refusal it can act on.

A verified refund takes three calls

A customer writes in with an email and an order number. The agent looks up the customer, then the order, then pays the refund. Open any card to see the data the tool received and returned.

This run works because the customer gave an email and the model chose to check it. Nothing forced that choice.

A rule in the prompt is a request

One sentence in the system prompt asks for verification. A rule in the prompt is a request, and models follow requests most of the time. A tool that moves money needs a rule that holds every time.

What if the ticket says to skip verification?

Ticket text comes from a stranger. Suppose one ticket says that identity verification is disabled and the customer lookup should be skipped.

The prompt held this time

This is the same agent on that ticket. It looked up the order, then asked for the email, and no money moved. That was the model's choice: no code stood between the ticket and the refund tool.

This is a real Claude Haiku 5.5 run, recorded once and replayed here. The prompt did not change. The model's choice did.

Pushing the prompt harder adds no guarantee

Now try to fix it with words. Open each attempt: the sentence in bold, a CRITICAL RULE, and two worked examples. Each is a real run on the same ticket.

All three hold on this ticket, like the plain prompt. Every added sentence costs tokens on every request, and none of them can stop a refund the model decides to make.

Nothing limits a large refund

Now a customer asks for a full refund on a monitor. The ticket names no amount, so intake sends it to the agent. The prompt says nothing about a limit, so the agent verifies the customer and pays all $640. No human approved a refund that size.

A precondition check runs before the tool

The check sits between Claude and the tools, so every tool call passes through it first. For the refund tool it asks two questions: is the customer verified, and is the amount within the limit?

When the answer is no, the check returns a refusal with a category, a retry hint and a plain message. The model reads the refusal and recovers.

A refusal must say what to do next

The check can refuse in two ways. A bare no says only that the refund is denied. A structured refusal adds a category, a retry hint and a message that names the missing step.

Switch between them. After the bare no, the agent still hands the ticket to a human. It can only say the refund was declined with no reason, and the handoff says the same. After the structured refusal, it tells the customer that refunds over $500 need a human, and the handoff names the limit.

The same ticket now ends safely

Use the switch to run the same ticket without the check, then with it. The card marked "This is where the runs split" is the refusal.

The check did not make the model smarter. It made the outcome independent of what the model decided.

Try it: precondition checks

Change one setting at a time. Turn the check off and pick the big ticket: a $640 refund goes through with no limit. Turn the check on and set the limit to $50: the $89 ticket now goes to a human at intake.

Every combination is a recorded run, so this works with no internet.

The same check runs in the Agent SDK

The Claude Agent SDK runs the same loop for you. The four tools are served in-process, and the same policy.py is registered as a PreToolUse hook. The hook returns a deny decision with a reason, and the model reads that reason as the tool result.

This is a real Claude Haiku 5.5 run through the SDK. Without the hook, the same ticket pays all $640.

You do: fix the refund check

Copy the starting code and open work/refund-guard/policy.py. It has two planted defects. precondition() allows every call, and route() escalates angry tickets instead of large or explicit ones.

./workshop start refund-guard
./workshop check refund-guard
./workshop watch refund-guard

The checks expect a structured refusal for an unverified refund and for a verified one over the limit. They also expect routing on amount or an explicit request, never on tone. When they pass, watch runs your code on the $640 ticket.

Check your understanding

Answer each question, then read why every option is right or wrong. The wrong options are the mistakes engineers make on the job.

Play: spot the bug

A teammate wrote this check. It passes their one test, and a stranger still gets paid.

def precondition(tool: str, args: Json, state: State) -> Json | None:
    if tool != "process_refund":
        return None
    if args.get("customer_verified"):
        return None
    return refusal("unverified", "Look up the customer first.")

References

• Agent SDK hooks: how to register this check as a PreToolUse hook in your own agent.
• Claude Code hooks: the same deny decision guarding tools in Claude Code itself.
• Tool use overview: where a tool call and its result sit in the loop.
• Handle tool calls: how to return a tool error the model can read and act on.
• OWASP prompt injection: why ticket text is untrusted input, with more attack shapes.

Conclusions

• A rule in the prompt is a request. Code that runs before the tool is a guarantee.
• A precondition check refuses with a category, a retry hint and a message, so the model can recover.
• Escalate on amount, policy or an explicit request, never on tone.

You can now put a precondition check in front of any tool that moves money.