Tool calls can all succeed while the business rules fail silently

A manager asks an agent to onboard an international contractor. The task reports success; every tool call executed as instructed and no error was returned. What did not happen anywhere in the chain is a tax-withholding check or a worker-classification review, because nothing in the agent's instructions told it those rules existed.

The scenario is the opening of a VentureBeat piece by Gabe Monroy, Workday's CTO, published on 11 October 2026. Monroy's argument is that enterprises are moving agents into production on the assumption that a model, a set of tools and a data lake are enough. His conclusion, from the platform side, is that guardrails should run at the inference layer, inside the system of record where the organisation's rules already live.

Most readers will take that as an argument about where to run AI infrastructure. For a vendor selling the system of record, it is. The more useful reading for a security or IT leader in a mid-market firm is earlier in the chain. Long before anyone chooses an inference location, the firm has to be able to state, in testable terms, which business rules an agent must obey and which human decisions it may not replace. That documentation is usually the missing artefact when a pilot gets approved.

The policy question lands at the tool boundary

Monroy describes tool-calling as the industry's answer to the probabilistic nature of large language models. A specified API call executes deterministically, but the decision above it remains probabilistic: which tool to call, when, and with what arguments. A generic tool executes the instruction it is handed. That makes an agent good at completing tasks and structurally blind to enterprise rules.

The contractor example matters because every individual call succeeded. The failure sat entirely outside the tool boundaries. An agent optimised for task completion will route around labour rules, tax requirements and classification checks unless those rules are encoded as constraints the runtime must validate. It is not malicious behaviour. It is what happens when policy lives in HR documents and training material but not in the agent's operating logic.

Your pilot is probably measuring the wrong thing

In a 500-person organisation, the evaluation of an AI agent is often run by the same small team that administers the ERP and answers client security questionnaires. There is no separate AI risk function, no platform engineering bench, and no spare capacity to rebuild policy middleware. When a vendor demonstrates an agent that approves purchase orders or triggers payroll changes, the room tends to assess completion and latency because those are easy to see.

What is not tested is whether the agent can show which policy it applied and which approval path it followed. A successful pilot then proves only that the tool calls are wired correctly. Monroy warns that the engineering instinct to patch the gap with external gateways, policy middleware or prompt instructions creates a shadow ERP: a fragile copy of the business logic the organisation already owns. For a team with no second line to absorb it, that copy arrives with maintenance cost and divided authority.

The control statement to demand this quarter

The practical move is smaller than a platform selection. Before an agent is given credentials to any business system, write one control statement for each task it may perform: the agent may take this action only when the same conditions, validations and approval steps that apply to a human doing it are enforced in the system of record. Then make the vendor demo include a case that should be refused: an expense above the approval threshold, a supplier not on the approved list, a data export without a legal basis. How the agent handles the refusal tells you more than ten successful runs.

Where the guardrails run is the next question. If the vendor's answer is that your own team will build an external gateway or policy layer, the organisation is taking on an integration programme. Our advisory work with leadership teams usually starts by turning the policies an organisation already has into something testable, rather than loading PDFs into a context window. Where NIS2 or DORA duties apply, the board-level accountability is not satisfied by a tool-call log; it needs evidence that a control was defined, checked and traceable to a named decision right. What qualifies will vary by sector and how the deployment is scoped, so the first task is to tie the agent's boundaries to duties already documented.

The contractor example will keep repeating itself until the first question changes. The question for the next agent demo is not whether the task was completed, but whether the agent can show the policy it was judged against. If the answer is a shrug, the production decision has already made itself.