Agent "hooks" are a reminder: if a rule matters, don't leave it to the model's judgment.

The difference between a tool an agent chooses to call and a step that runs every time is the difference between a suggestion and a guarantee.

Microsoft's Copilot Studio documentation now describes a preview feature called hooks. The definition is plain: a hook runs one of your workflows automatically when something happens in your agent, and you use it "when you need something to happen every time, rather than only when the agent decides it's relevant."

I haven't built anything with Copilot Studio, so this isn't a product review. The idea names a distinction most of us blur in agent workflows. A tool is something the agent can use; the docs say it runs only when the model judges it relevant. A hook is something the system does: the event fires and the workflow runs. Only the before-tool event can block an action. The others can add context or change values, but can't stop the agent.

Why this matters outside Microsoft's stack: many of us write the important rules as instructions in a prompt (never send without confirmation, always redact that field) and call it a safeguard. A prompt is a request. The model follows it nearly every time, and "nearly" is the problem for the rules you care about most.

The docs are honest about the limits. Hooks don't stop the agent when they fail: if the workflow errors or times out, the agent carries on as though the hook returned nothing. They also say not to rely on a hook as the only safeguard for a business-critical rule. So the deterministic layer has to fail closed on purpose, and that's your job, not the framework's.

What I'd do, whatever tools you use:

First, sort your rules into two piles: things the agent should decide (which tool, how to phrase it) and things that must happen every time (redact before calling a model, check permission before a destructive action, write an audit record). The second pile belongs in code that runs on an event, not in a paragraph of instructions.

Second, decide what happens when the guard itself breaks. If your redaction step times out, does the request go through unredacted or stop? Write the answer down.

Third, test the guard by trying to get around it. Feed it the awkward input, kill the workflow midway, and see what the agent does next.

For an app like Murror, where people write things they wouldn't say out loud, how a reflection is worded is a judgment call a model is good at. Whether an entry is handled according to the privacy rules we've promised shouldn't depend on a model remembering to behave. That part should be boring, deterministic and testable.

Source: Microsoft's Copilot Studio documentation on hooks, marked prerelease and subject to change.

Which of your agent's rules are currently just sentences in a prompt?