The first production question for an enterprise agent usually gets phrased as an access question:

What tools can it call?

Tool access is the outer edge of the problem. The question that determines whether the deployment is safe is:

What business process is this agent allowed to execute?

The answer to that question is rarely in one place. It lives across the systems the workflow touches, the approvals people know to ask for, the exception paths learned during incidents, the owners who inherit the work when something gets weird, and the evidence security expects to see later.

Without that model, the agent runs on the prompt's description of the happy path and whatever the service account happens to expose — neither tells the runtime whether a given action is inside the process.

The process has to become inspectable#

Before an agent executes a serious workflow, the enterprise needs an artifact set that can survive review:

Process map. Which systems, queues, records, and owners the workflow crosses.
Exception-path inventory. What happens when the normal path is ambiguous, blocked, stale, or high-risk.
Approval matrix. Which actions require human judgment, who can provide it, and when delegation is allowed.
Policy graph. The conditions the runtime evaluates before an action runs.
Agent runbook. What the agent is supposed to do, what it is not supposed to do, and how operators intervene.
Scope report. What the agent can reach before production.
Proof bundle. The evidence that a reviewer, auditor, or investigator can read later.

This is the control surface: once the process is explicit, the runtime can enforce it.

Field discovery is part of the product#

Most teams try to make the process explicit by asking the team that owns the workflow to write it down. That produces the official path, not the operational one.

The operational path comes from field work:

Ask the business owner where the work starts and ends.
Ask platform which systems are actually touched.
Ask security what would make the deployment unacceptable.
Ask operators what they do when the record is stale, the owner is gone, the approval is missing, or the customer is exceptional.
Compare the answers to logs, IAM, tickets, repos, and run history.

The mismatches are the product. They are where the control model has to be precise.

The runtime should evaluate the model at action time#

Once the operating model exists, each agent action can be evaluated against it:

Is this the right agent, run, operator, and scope?
Is this resource inside the workflow?
Is the action inside the approval matrix?
Is the policy version current for this deployment?
Does this action emit the evidence the reviewer expects?

The answer can be allow, require-approval, deny, scope, quarantine, or stop. The model decides. The audit row records the input bundle, policy version, decision, and outcome.

What changes for the buyer#

The buyer no longer has to accept a demo as proof that the agent is safe. They can inspect the operating model before the agent runs:

Platform can see which systems are in scope.
Security can see the policy graph and containment path.
Risk can see the evidence trail.
Business owners can see whether the actual workflow was captured.
Operators can see where they are still in the loop.

That's what changes for the buyer: instead of a demo, security gets the policy graph and containment path, risk gets the evidence trail, and the business owner gets confirmation that the workflow captured is the one people actually run.