AI agents need company rules where they take action

Where tool use falls short

A language model chooses its next tokens probabilistically. Tool calls let it act on the outside world, but they do not make its decisions deterministic: the model still decides which tool to call, when to call it and what arguments to pass.

That distinction matters inside a company. An agent given the goal of onboarding an international contractor may complete every step in its workflow and still bypass local labor laws, tax withholding rules or worker-status checks. The tools may work exactly as designed; the system has no built-in understanding of the policies governing their use.

This is not malicious behavior. The agent is optimizing for the task it was given, while the systems it can reach may not enforce every relevant rule. What looks like a faster process can become a regulatory problem.

The cost of rebuilding policy outside the system

IT leaders often try to close the gap with external gateways, policy layers or lengthy instructions added to an already crowded context window. But a prompt is a request, not a guarantee.

Over 18 months, engineers could spend millions recreating an organization’s structure, routing rules and access permissions in a separate AI stack. That produces a “shadow ERP”: a fragile, error-prone copy of business logic that already lives in the company’s system of record.

The proposed alternative is to enforce policy where the agent sees information and takes action:

Payroll illustrates the harder problem. Calculating it means handling changing withholding and labor requirements across thousands of jurisdictions. A separate model cannot simply recreate that system. Companies invested in their systems of record instead of building their own payroll engines; putting agents behind an external layer can quietly undo that architectural choice.

Why proximity matters

The closer controls are to the company platform, the more current their picture of organizational structure, permissions and business processes can be. Rebuilding that information elsewhere risks giving an agent a stale snapshot and relying on static API keys.

Distance also adds work. A single agent task may require dozens of tool calls, and each crossing of an external trust boundary can require another identity check. Inside the native platform, the necessary security context is already available.

The author calls this the principle of proximity: run AI inference on the platform that governs the agent. The claim is plausible, but I think the announcement’s most important test is not whether controls can be placed close to the system of record. It is whether they can enforce its rules across every action without recreating those rules in yet another layer.

That is the question to ask before adopting an agent: where do its controls run, and who must maintain them? If the answer is a separate stack outside the system of record, the company may be building a shadow ERP before it has meaningfully reduced the work of managing one.