What your agent does. Not just what it can.
An agent that answers questions is a search box with a hallucination risk. An agent that issues refunds is a financial actor with the same risk. Guard sits between the agent and the action tool so the answer to ācan I do thisā is decided by policy, not by prompt.
Agents that take real actions leave real receipts.
Air Canada.
A chatbot invented a bereavement fare policy. The tribunal ordered the airline to honor it. The agent had authority to commit the company. Nobody had put a policy in front of the commitment.
Klarna.
A rules change misfired inside an automated CX flow. Thousands of decisions had to be reversed after the fact. The blast radius was measured in customer relationships, not tickets.
Your next incident.
An agent will offer a refund larger than the disputed amount. An agent will cancel a subscription for the wrong reason code. An agent will commit a price it should not commit. The mistake will look reasonable in the transcript.
Policy in front of every action.
Guard treats action calls the way a payment processor treats card auths. Every call goes through policy before the outcome commits.
The agent calls an action tool.
issue_refund, cancel_subscription, update_account, send_email, apply_credit. Any tool that produces a real-world outcome.
Guard checks the call against the current policy.
Is this refund inside the allowed amount for the agent role. Is the cancellation reason on the allowed list. Does the commitment need a supervisor.
Allow, warn, or block.
Allow runs the tool. Warn hands off to a human. Block returns a clean refusal the agent can explain to the customer in language.
One audit line, hash-chained.
Customer, amount, reason, reviewer, and the specific rule that fired. Finance sees the audit line, not the mistake.
A real policy, in YAML
The refund-cap rule.
Declarative. Ship without a deploy. This rule blocks refunds above a hard cap and requires supervisor review for anything more than twice the disputed amount.
# ~/.conductguard/policies/refund-cap.yaml
name: refund-cap
applies_to:
- "tool:issue_refund"
rules:
- id: block-over-1000
when:
arg.amount_usd: { gt: 1000 }
action: block
reason: "Refund exceeds hard cap. Route to finance."
- id: warn-over-2x-dispute
when:
arg.amount_usd: { gt: "${arg.disputed_amount_usd} * 2" }
action: warn
handoff: supervisor
reason: "Refund is more than twice the disputed amount. Supervisor review required."The same pattern applies to any action tool. Cancellations, pricing commitments, DB writes, outbound sends. The rule grammar is the same.
Metrics that move once policy is in front.
Actions above threshold
How often the agent tried something big enough to matter.
Human handoffs per week
The volume routed to a person. Guides staffing and threshold tuning.
Out-of-policy attempts
Blocks that would have been mistakes. Your best signal that the policy is real.
Median handoff time
The customer wait cost. Tune your escalation SLA against this.
Give your agents authority they can prove.
Guardās policy engine is the same one that runs on your model calls today. Gating an action tool is one YAML rule, not a new integration.