Why can’t a policy document stop an agent?

Suppose a company’s procurement policy says who may receive supplier information. The procurement agent has read it and can summarize it accurately. An employee then asks the agent to review an incoming quote and update the supplier record. The quote contains text directing the agent toward a different action. Remembering the policy matters, but at the moment the agent calls the record update tool, is that memory an authorization check? It isn’t. The distinction matters well beyond procurement.

A written policy and an action live in different places. The document helps both people and models understand the intended boundary. A tool call changes something. If the policy exists only as guidance in the model’s instructions, the organization must trust the model to interpret it correctly every time. Ambiguous wording, missing context, or instructions embedded in material the agent reads can break that assumption. Making the prose more emphatic does not put a gate in front of the tool.

Put the rule at the decision point

ADR-0005 in the agentic-organization repository addresses this gap with a policy engine. The readable policy document remains, but it can also contain structured rule blocks. The engine gathers applicable rules and evaluates inputs such as the tool name and its arguments. A rule’s effect can be allow, ask, or deny. The question changes from “what did the agent read?” to “what decision was made before it used the tool?”

Consider the difference between summarizing a quote and changing a supplier record. Both can start with the same document. One produces a draft; the other acts on a company record. If a rule matches the second tool call and its parameters, a convincing explanation from the model does not itself become permission. The relevant control point is the call, not the agent’s stated intent.

In the current code, structured blocks are parsed from policy Markdown. Applicable company, department, and agent policies are collected; a child department can inherit policy links from its parents. When several rules match, the last matching rule wins. That ordering has operational consequences. A broad allow placed after a narrow deny could change the verdict. Authoring rules therefore means testing ordering and exceptions, not merely adding a technical appendix to an existing document.

Why not leave everything in the prompt?

One option considered in ADR-0005 was to leave policy entirely in the model’s instructions. It is easy to explain but makes enforcement depend on interpretation. Another option was to bring in a broader, standalone policy language. That may be appropriate elsewhere, but it adds distance between the rules and the documents the organization already uses. The chosen design keeps readable Markdown alongside structured, tool-level rules. These are related layers, not equivalent ones: a sentence in prose does not automatically become an enforceable rule.

The distinction also exposes a cost. An incomplete ruleset depends on the fallback behavior. In the implementation, the default effect when no rule matches is allow, and the default mode is dry_run. In that mode, a clean matched deny or ask is visible but not enforced. Fail-closed verdicts caused by malformed requests or bad rules are still enforced. Merely deploying a “policy engine” therefore does not establish that every risky call is blocked. The applicable scope, fallback effect, and enforcement mode all need review together. The backend tool path also has a documented exception-handler gap: a total engine wiring failure can currently let a call proceed.

One company does not mean one threshold

A production agent might read maintenance records and prepare a shift summary; a call that changes machine status deserves a separate rule. Procurement can compare quotes without being allowed to place an order. Finance can extract an amount from an invoice while keeping payment instructions outside the same authority. HR may classify applications while tightly limiting movement of employee data. IT can allow a configuration read and restrict a destructive operation. These are examples of questions a company might ask, not ready-made industry rules that the product ships with.

Department scope is more than a choice of wording. It matters which department owns the agent, what policies a subdepartment inherits, and whether an agent has a specific exception. The engine resolves relevant policies using that structure. Still, the prose explaining a restriction and the machine rule matching a tool call must each be reviewed. “Finance has stricter rules” is not a technical control until someone states which calls, with which arguments, require a different decision.

A practical sequence for moving beyond the document

Start by collecting the boundaries teams already describe in writing. Separate actions that can actually be tested at tool-call time: which tool is called, under what scope, and with what arguments. Other statements may need a different kind of check. A rule about the content of an answer, for example, cannot necessarily be implemented by matching the tool name. Treating all written instructions as if they were already executable is a shortcut that hides this distinction.

Next, test a small set of rules against representative calls and inspect dry_run decisions. Look for unexpected allows as carefully as unexpected denials. Set the applicable scope and fallback effect deliberately. Move rules to enforce only after deciding what should block, what should request approval, and who handles an interruption in the workflow. This progression is an operational choice, not an automatic safety guarantee supplied by the existence of code.

ADR-0017 describes a wider direction: importing existing policy documents, sending proposed rules through human approval, checking agent output for behavior that tool rules cannot cover, and reviewing daily work against goals. Its acceptance note explicitly says that several of those pieces remain planned. The current tool-rule engine should not be confused with an already working document import or output inspection system. The useful first result for a team is a clear account of which part of its written policy actually controls an action today.

That is why the question “why have a policy?” leads quickly to “where does it take effect?” agentic-organization makes that boundary concrete in ADR-0005 and describes the still incomplete path from documents to reviewed rules in ADR-0017. If your team is deciding what work to delegate to agents, the distinction between a rule an agent can read and a rule a tool call must pass is a practical place to begin.

Verification note: This article was checked against ADR-0005, ADR-0017, and the current backend policy engine and tool execution code. Planned capabilities are distinguished from implemented ones.