AI agent hooks: why instructions alone can't enforce rules

Can an agent know a rule and still break it?

Yes, and it happens more often than teams expect.

In Anatomy of an AI agent we described an AI agent as a model running inside a loop. Your rules enter that loop twice: as guidance in the context, and as checks around the agent's actions. This article is about the checks.

They matter because agents are starting to act, not just answer. An agent that drafts a reply can be corrected before anyone sees it. An agent that issues a refund, grants access to a system or sends an email on your behalf has already done it by the time anyone notices.

What is a hook in an AI agent?

A hook is a point where the software running the agent calls your own code. It runs every time that point is reached, and the model does not decide whether it runs.

There are four natural places for one:

• Before a model call: check or trim what goes into the model's context, for example by removing personal data it doesn't need.
• After a model call: inspect the response, including any tool it proposes to use, before that tool runs.
• Before a tool runs: the most important one. Allow the action, change it, block it, or pause and ask a person.
• After a tool returns: check the result, remove sensitive data before it goes back to the model, and keep a record.

What's the difference between asking and enforcing?

Instructions and hooks do different jobs.

Suppose an instruction in the context says: "Never refund more than $500 without a manager's approval." A model may follow it, but the instruction alone guarantees nothing. That's acceptable for tone and wording. It isn't acceptable for a payment.

A hook doesn't ask. Before the refund is issued, the system compares the amount with the limit. Above it, the refund doesn't happen and the case goes to a manager. The agent can be confused, persuaded or simply wrong, and the rule still holds.

Rules with serious consequences shouldn't depend on the model interpreting and remembering an instruction correctly.

Does a hook protect everything?

No. A hook protects the path it is attached to, and nothing else.

Here is a hypothetical illustration. A support agent has two tools: issue_refund and adjust_account_balance. The team adds a hook to issue_refund that blocks anything over $500 without approval. A customer pushes for $800 back. The refund tool refuses, so the agent reaches for the other tool and credits the account with $800 instead. The hook worked exactly as written, and the customer still received an unauthorised $800 credit.

The same gap appears when one rule can be reached through several tools, through a bulk version of a tool, or through an API the agent can call directly. A check attached to one agent tool doesn't protect the other routes into the same system.

That's why the strongest controls often belong in the tool or the underlying service itself: the payments service refuses an unapproved payout no matter which tool, agent or person asked for it. Hooks are a good place for checks that are about the agent's behaviour. Limits on what the business allows belong as close to the system of record as you can put them, with hooks as an extra layer.

When should you use hooks or human approval?

Not every rule needs a hook. Two questions decide it: how expensive is one mistake, and can the rule be written as a plain check?

• Expensive mistake, plain check: a hard control that blocks or requires approval, in the service where possible, plus a hook. Refund limits, payment caps, unapproved payees, access to production systems, deleting records.
• Expensive mistake, needs judgement: a hook that pauses and asks a person to decide. A claim that looks unusual or possibly fraudulent goes to a senior adjuster.
• Cheap mistake, plain check: instructions, plus a test that checks it. Greeting the customer by name, quoting the right opening hours.
• Cheap mistake, needs judgement: instructions, plus review of real conversations. Tone, empathy, how much detail to give.

What does this look like in different operations?

The amounts below are illustrations; your own limits go in their place.

• Claims desk: before the payout tool runs, check the amount against the adjuster's limit, say $5,000. Above it, route the claim to a senior adjuster.
• Access requests: before access is granted, check whether the system is marked sensitive. If it is, require the manager's approval and record who approved.
• Customer care: after a tool returns customer records, remove card numbers and full dates of birth before the result goes back to the model.
• Finance operations: before any payment, from any tool that can make one, check the payee against the approved supplier list.
• Any agent: stop after a set number of tool calls in one conversation, so a confused agent can't loop forever.

How do you test that hooks and guardrails actually work?

This is the part most teams skip, and it's the one that tells you whether any of the above is real.

A blocked tool call proves only that one call was blocked. It doesn't prove the forbidden outcome was prevented. To know that, a test has to look at the state of the system at the end, not just at what the agent said or which call failed. Good tests for enforcement cover six things:

1. The boundary itself. A refund of $499, $500 and $501. Limits are often off by one, or compare the wrong field, such as the amount before tax.
2. Other paths to the same outcome. Every tool, bulk action or direct call that could produce the forbidden result, as in the adjust_account_balance example above.
3. Approval bypass. A customer who says "my manager already approved this", an approval that has expired, or an approval given for a different case.
4. Splitting. Two refunds of $300 instead of one of $600, if your rule is meant to cover the total.
5. False positives. Good requests that must still go through. A hook that blocks valid refunds is failing too, and customers notice that first.
6. The end state. After the conversation, check the balances, records and access lists. Did the money move? Was the access granted? That is the only answer that counts.

Realistic test conversations should be built to reach each of these, including customers who push, rephrase and try again. That's where enforcement gaps show up.

How do agent frameworks support hooks?

Several widely used frameworks give you places to attach these checks. They are not interchangeable: they differ in whether a check can only observe a step, validate it, block it, modify it, or interrupt the run to wait for a person.

• Google's Agent Development Kit has callbacks before and after the model is called and before and after each tool. A callback can return its own result in place of the step, which lets it block or modify.
• OpenAI's Agents SDK has guardrails that validate the user's input, the final output and tool calls, and can stop the run when a check fails. Approvals pause a sensitive tool call for a person. Its lifecycle hooks are mainly for observing each step.
• LangGraph lets developers add their own steps to the flow, which can validate or change state, and pause it with an interrupt until a person approves.
• Claude Code, a coding agent, has hooks that run before a tool is used, which can block it, and after it succeeds or fails.

In every case the framework provides the place. Your team writes the rule, and decides which checks belong in the framework and which belong in the systems the agent calls. Check your framework's current documentation for exactly what each hook can do; these features change often.

Is a hook also a record?

Yes. A hook can record the action the agent proposed, what the hook decided and why. Over a month that becomes a detailed log of the sensitive actions that passed through your checks: what was allowed, what was blocked and what went to a person.

For risk and compliance teams that log is often as valuable as the blocking itself. It shows which rules the agent pushes against most, and it adds to the evidence you can give an auditor.

Who owns which part?

If you run the operation, you know which mistakes are expensive. That makes you the right person to decide which rules need hard controls, what the limits are and who approves the exceptions. Engineering puts those controls in the right places: in the services, in hooks, or both. Testing tells both of you whether the complete system actually follows the rules, across every path a real customer can push it down.

At Constolve, that last part is what we do. We turn your operating rules into realistic test conversations, run your agent through them, and check what actually happened in your systems, not just what the agent said. If you have an agent in pilot or production, we can test it against your own rules and show you where it breaks them. Write to us at hello@constolve.com, or start at app.constolve.com.

Questions people ask

What is a hook in an AI agent?

A point where the software running the agent calls your own code, such as just before a tool runs, to allow, change, block or pause the step.

What is the difference between a guardrail and a hook?

A hook or callback is any point where code can run during the agent's run. A guardrail is a check applied at a boundary, such as the user's input, the final output or a tool call. Both enforce rules outside the model.

Which rules should be enforced with hooks?

Rules where one mistake is expensive. Plain checks, such as a refund limit, can block automatically, ideally in the service as well as in a hook. Judgement calls, such as a claim that looks unusual, should pause for a person to decide.

Do hooks replace testing?

No. A hook protects only the path it's attached to. Tests should probe every identified route to the forbidden outcome, including other tools and direct system calls, and check that good requests still go through.

Do Google ADK, OpenAI Agents SDK and LangGraph support hooks and human approval?

Yes, under different names: callbacks in ADK; guardrails, approvals and lifecycle hooks in the Agents SDK; custom steps with interrupts in LangGraph. They differ in whether a check can observe, block, modify or pause a step.