AI Agent Hooks: Automatic Checks Before and After Actions

AI agent hooks are automatic checks that run immediately before or after an agent takes an action, such as sending a message, updating a record or calling a tool. They live in the surrounding system rather than in the prompt, so they run every time, whatever the model decides. Use them for any rule that must hold without exception, because instructions alone can only ask the model to comply.

Key takeaways

• A hook is ordinary code or configuration attached to a moment in the agent's work, and the agent cannot skip it.
• Instructions describe intent. Hooks enforce limits. Any rule that is costly to break belongs in a hook.
• Before hooks prevent harm through permissions, validation and approval. After hooks verify results, scrub data and keep records.
• Start with the few actions that change something outside the agent, and write each rule as a question a program can answer with yes or no.
• Log every hook decision with its reason, so you can review blocks, overrides and gaps over time.

What is an AI agent hook?

A hook is a small piece of software attached to a specific moment in the agent's work. When the agent is about to do something, or has just done it, the surrounding system pauses, runs the check and decides what happens next. The outcome is usually one of four: continue, change the action, block it, or ask a person.

The agent does not choose whether the hook runs. That is the whole point. The model proposes an action, and the system around the model intercepts it. If the proposal passes, it goes ahead. If not, the hook returns a clear reason, and the agent can try a different route or hand the case to a human.

Hooks can attach to many moments. The most useful ones are these:

• Before a tool call, when the agent is about to read, write, send or delete something.
• After a tool call, when a result comes back and the agent is about to rely on it.
• Before a reply leaves the company, such as an email or a message to a customer.
• At the end of a task, when the agent says the work is finished.
• When something fails, so the failure is recorded and routed instead of quietly retried.

If you want to see how tools are invoked in the first place, what tool calling means in plain terms is a useful companion. Hooks sit exactly on that boundary between a decision and its effect.

Why can't instructions alone guarantee a rule?

An instruction is a request written in natural language. The model reads it, weighs it against everything else in its context, and usually follows it. Usually is not a control. For a business, the cases where a rule matters most are often the cases where the model is most likely to drift.

There are several ordinary reasons a written rule fails:

• The context is long, and an instruction written early gets less weight than a request made late.
• Two instructions conflict, and the model resolves the conflict in a way nobody anticipated.
• Untrusted text enters the conversation, such as a customer email that tells the agent to ignore its rules. Prompt injection is a recognized risk category in the OWASP guidance for language model applications.
• The model believes it complied. It reports a check as done when it only intended to do it.

None of this means instructions are useless. They set intent, tone and judgment, and a well-kept set of them makes the agent far better at its job. The question of where to invest first is covered in prompt engineering versus harness engineering. The short version is that prompts shape behavior, while the harness limits what behavior can do.

A practical rule of thumb: if breaking a rule would cost money, trust or legal standing, do not rely on the model remembering it. Write the rule as a hook, and keep the instruction only as an explanation of why the rule exists.

Which checks belong before an action, and which after?

The split is simple. Checks that prevent a bad outcome run before the action. Checks that confirm what happened, clean up, or leave evidence run after it. Some rules need both.

Before hooks are best for actions that are hard to undo, such as sending, paying, publishing, deleting or sharing outside the company:

• Permission check: is this agent allowed to use this tool, on this record, on behalf of this person?
• Input validation: are required fields present, are formats correct, is the recipient on an approved list?
• Policy check: does the content avoid promises, advice or commitments the company has ruled out?
• Approval gate: does this action fall above a risk boundary that needs a named person to say yes?
• Duplicate check: has this exact action already happened, for example the same message to the same person?

After hooks are best for confirming, protecting and remembering:

• Result validation: did the system actually confirm the write, and does the returned data have the expected shape?
• Data scrubbing: are secrets and personal details removed before the result is logged or passed to another step?
• Audit record: who or what acted, on which record, when, and why. The requirements for regulated settings are discussed in AI agent audit trail requirements.
• Evidence capture: is proof of completion attached to the task so that done means something?
• Alerting: does an unusual pattern, such as repeated blocks or repeated failures, reach a person?

A useful decision guide is to ask one question about each action: if this goes wrong, can we take it back? If not, put the check before. If we can, a check after plus a clear alert is often enough.

What does this look like in practice? An illustrative scenario

This scenario is illustrative, not a description of a real company. Imagine an agent that sends appointment confirmations for a small services business. Its instructions say to confirm only open slots and to message only the phone number on the client record.

Without hooks, the agent relies on remembering both rules. A client forwards a message from a family member with a different number and asks for a confirmation to be sent there. The agent, trying to be helpful, complies. Later, two bookings land on the same slot because the calendar changed while the agent was drafting.

With hooks, the same day goes differently. A before hook compares the destination number with the client record and checks the slot against the live calendar at the moment of sending, not the moment of drafting. Both checks fail, so the message is blocked and a short note goes to a staff member: number differs from record, and slot no longer available. An after hook records the outcome and, for messages that do go out, confirms delivery status and writes it to the client file.

The agent did nothing differently. The system around it made the rules real. The staff member sees a clear reason, resolves it in a minute, and the agent continues. For a broader view of which protections to put in place first, see which guardrails a business needs first.

How do you add hooks, step by step?

You do not need to hook everything. Begin with the actions that change something outside the agent, and work outward.

• List every action the agent can take that sends, writes, deletes, pays, publishes or shares.
• Rank those actions by how hard they are to reverse and who would be affected if they went wrong.
• For each high-ranked action, write the rule as a yes or no question that a program can answer, with no room for interpretation.
• Decide what happens on a no: block, correct automatically, escalate to a named person, or log only.
• Build the check outside the model, in code or configuration the agent cannot edit or switch off.
• Test with cases that should pass and cases that should fail, including text written to trick the agent.
• Record every decision with the reason, the rule that fired and the action involved.
• Review blocks, overrides and near misses on a regular schedule, and adjust the rules.

The fifth step is the one teams most often skip. A check that the agent can see and modify is a suggestion. A check that sits in a layer the agent cannot reach is a control. The OWASP authorization guidance makes a related point: permission decisions should be enforced consistently on the server side, not left to the caller.

What makes a hook trustworthy?

Good hooks share a few properties. They are deterministic, so the same input gives the same answer. They are fast enough that nobody is tempted to disable them. They explain themselves, so a block says which rule fired and what would make the action acceptable. And they fail in a deliberate direction: closed for high-risk actions, open with an alert for low-risk ones.

Several mistakes come up repeatedly:

• Too many hooks. If every action triggers a question, people learn to approve without reading, and the control becomes theater.
• Vague block messages. An agent that receives a bare refusal may retry the same thing in slightly different words. A specific reason lets it change course.
• Using a model to enforce a hard rule. A second model can be a reasonable advisory check for fuzzy matters such as tone, but keep the non-negotiable rules in plain code.
• Blocks that leave work in a broken state. When a hook stops an action halfway through a task, the work should be left in a condition that can be picked up again. This is the same concern as in resuming unfinished agent work with checkpoints.
• No review. Rules go stale when the business changes. A hook nobody reads will eventually block the wrong thing or miss the right one.

Also watch for retries. If an after hook sees a failure and the agent tries again, make sure the action cannot be applied twice. Payment providers solve this with idempotency keys, and the same idea works for messages and records.

How does Be Human handle hooks?

Be Human treats hooks as part of the infrastructure around an agent, not as an add-on. In a first engagement, the useful role, the memory and tools it needs, and the approval boundaries are defined together with an observable success criterion. The hooks are then built to match those boundaries: permission checks on tools, approval gates where a person must decide, and records of each decision. Under managed operations, hook decisions are monitored, permissions are reviewed, and changes to the rules are made in a controlled way and tested before they reach live work.

Frequently asked questions

Are AI agent hooks the same as guardrails? Hooks are one way to implement guardrails. A guardrail is the rule or limit, such as never send external email without approval, while a hook is the automatic check that enforces it at a specific moment in the agent's work. Guardrails can also include permissions, budgets and scoped access that do not run as a check at all.

Do hooks slow the agent down? Simple checks on permissions, formats and lists add very little delay, because they are ordinary code. The delay that matters comes from approval gates, where a person must respond, so reserve those for actions that are hard to reverse. Everything else should run without anyone noticing.

Can the agent write or change its own hooks? It should not. If an agent can edit the check that constrains it, the check is no longer a control. Keep hook definitions in a layer that only named people can change, and make every change reviewable.

Where should a small company start? Pick the one action that would hurt most if it went wrong, such as sending a message to a customer or changing a financial record. Write its rule as a yes or no question, add a before hook, and log the result. Once that works and the team trusts it, extend the same pattern to the next action.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.