Workflow Automation With Hard Stops: What Microsoft's New Agent Hooks Mean For Financial Firms

What are agent hooks in Copilot Studio?

On 7 October 2026 Jason Moore, Vice President of Product for Microsoft Copilot Studio, announced that hooks are “now in preview for agents powered by the GitHub Copilot harness”. Makers can use them to “inspect, modify, or block a tool call before it executes”, and to “transform results after a tool runs”.

Microsoft's documentation, last updated on 30 September 2026, describes the mechanics. A hook has two parts: an event, which is the point in the agent's life it listens for, and an action, which “Today, the action is always a workflow.” When the event fires, Copilot Studio runs the workflow and reads its response back into the conversation.

The supported events include a session starting, a user prompt being submitted, an error, a tool about to run, a tool finishing and a tool failing.

How do hooks differ from tools?

The difference is who decides when they run. Microsoft's documentation puts it simply. A tool runs “Only when the agent judges it relevant.” A hook runs “Every time the event occurs.” A tool “Gives the agent information it might use”, while a hook “Changes what the agent does next.”

That makes hooks the place for rules that must always apply, such as logging every tool call or checking a request against a policy before a tool runs.

Why does deterministic control matter in financial workflows?

A language model decides what to do next from context, which is what makes agents flexible. It also means an agent may not apply a rule the same way every time. In a financial firm, some rules cannot be left to judgement: a payment file is not released without approval, a transaction report is not submitted with a missing field, and a client message is not sent without a check.

Workflow automation has always handled these with fixed steps. Hooks bring a version of that to agents. The model reasons about the work, and a rule outside the model decides whether a particular action is allowed to happen.

This matches a wider pattern. When Nvidia launched its agent safety platform in September, the principle was the same: controls must sit where the agent cannot override them. We covered it in our analysis of agent safety controls.

How would hooks fit a reconciliation or reporting workflow?

Here is an illustrative design for an agent that prepares trade confirmations or transaction report corrections. It is our example, not one from Microsoft:

1. At session start, a hook loads the day's cut-off times and the list of counterparties, so the agent always works from the same reference data.
2. Before any tool that sends or submits something runs, a hook checks for an approval reference from a named person. With no approval, it returns a denial and the action is blocked.
3. After each tool runs, a hook writes an audit record of what was done, by which agent, for which user, and removes sensitive values before they reach the model.
4. On an error, a hook stops the run and tells the user plainly, instead of letting the agent retry its way around a problem.

The same pattern suits trade confirmation automation for trade allocations and confirmations, where every chaser should be approved before it goes, and transaction report checks, where a person approves every correction and the submission.

What should never rely on a hook alone?

Microsoft is candid about the limits. Its documentation says: “Hooks don't stop the agent when they fail. If a workflow fails, times out, or returns something the agent can't read, the agent continues as though the hook returned nothing. Don't rely on a hook as your only safeguard for a business-critical rule.”

It also notes that “Pre tool use is the only event that can block an action.” The other events can add context or change values, but they cannot stop the agent.

For a financial firm, the answer is layers. Limit what the agent can reach in the first place. Put the approval step inside the workflow itself, so nothing can be released without it. Use hooks for consistency and logging on top. Keep a manual fallback so the work continues if the agent is switched off.

How do you design workflow automation a compliance lead will sign?

Start from the controls and choose the tool after. A compliance lead will want to know what the agent does and does not do, who owns it, how client data is handled, how it was tested and what happens if it stops. BraivIQ, a workflow automation agency for UK financial firms, writes those answers into an evidence file before anything goes live.

Every engagement starts with a 14-day Proof Run on the firm's own exports, read-only. For teams comparing workflow automation in London and across the UK, see the six workflows our agents prepare. For the engineering underneath, our Playbook covers triggering automations reliably with events and queues.