The Recommendation Is Ready. The Authority Is Missing.

2026-10-07 · Agentic Operations

Revenue teams can produce the right recommendation and still lose the decision window because approval authority is unclear. Leaders need explicit decision rights before agents can turn intelligence into accountable action.

Topics: Agentic Operations, Revenue Intelligence, Decision Governance, Revenue Operations, AI Governance

Intelligence can arrive before permission

The account signal is clear. The agent has assembled the customer history, contract terms, product usage, support friction, payment status, delivery constraints, and likely economic impact. It recommends a specific action while the recovery window is still open.

Then the work stops.

No one knows whether the account executive can offer the concession, whether finance must approve the credit, whether customer success can change the service plan, whether product can promise the capability, or whether the agent may execute any part of the response.

The recommendation is ready. The authority is missing.

This is a decision-rights problem, not an intelligence problem. Connecting more systems and producing better recommendations will not create accountable action if authority remains scattered across job titles, informal habits, outdated policies, and one-off executive approvals.

An enterprise brain needs to know not only what should happen, but who may decide, under which conditions, for how much value, using what evidence, and for how long that permission remains valid.

An approver name is not an authority model

Many workflows treat approval as a routing field. Send the request to the regional vice president, finance leader, legal team, or product owner. That is necessary, but it is incomplete.

Authority depends on context. The same person may approve a five-percent discount but not a change to payment terms. A customer success leader may authorize temporary service recovery but not recurring custom scope. A finance manager may approve a credit within policy but not waive an unresolved contractual obligation. An executive may have authority above a value threshold but lack the technical evidence required to judge delivery feasibility.

A usable authority model must answer more than who. It must also define:

Which decision class is involved.
Which thresholds change the approval path.
Which facts must be present before approval.
Which policies or commitments constrain the choice.
Which actions are reversible and which create lasting exposure.
Who may act when the primary authority is unavailable.
What must be recorded, monitored, or reviewed afterward.

Without this structure, escalation becomes the default substitute for governance.

Separate recommendation, authorization, and execution

Three roles are often collapsed into one. They should be explicit.

Recommendation authority determines who or what may propose an action and assemble the evidence. An agent may be highly capable here.

Authorization authority determines who may accept the economic, customer, legal, operational, or policy consequences of the decision.

Execution authority determines who or what may carry out the approved action in CRM, billing, contracting, customer communication, delivery, or another operating system.

These roles can belong to the same person for a low-risk decision. They should separate when the consequence is material, difficult to reverse, or vulnerable to conflict of interest.

The separation also prevents a common automation failure: a system has technical access to perform an action and is therefore assumed to have business authority. Access is not authorization.

Build a decision-authority contract

A practical authority contract should travel with each decision class. It can include eleven elements.

Decision class. Is this pricing, credit, payment terms, delivery scope, service recovery, product commitment, data access, customer communication, or another action?
Business purpose. What outcome is the authority intended to enable?
Recommender. Which person, team, model, or agent may prepare the recommendation?
Authorizer. Which role has the right and accountability to approve, reject, or modify it?
Executor. Which actor may perform the resulting action, and in which systems?
Thresholds. What value, duration, margin, risk, customer tier, or policy boundary changes the authority level?
Required evidence. Which facts must be current and complete before a decision is valid?
Constraints. Which terms, regulations, promises, segregation rules, or nondelegable rights limit the decision?
Delegation and absence. Who acts when the primary authority is unavailable, and what remains prohibited?
Validity and revocation. When does the approval expire, and what change invalidates it?
Decision record. What rationale, evidence, approval, execution, and outcome must be preserved?

The contract should be machine-readable enough for routing and human-readable enough for challenge. If the accountable leader cannot explain the boundary, the agent should not infer it.

Use an autonomy ladder instead of one AI policy

A single rule such as "AI may recommend but humans decide" is too broad for real operations. Some decisions are safe to automate. Others require judgment and authority.

An autonomy ladder can distinguish six levels.

Observe. The agent detects and records a condition without changing work.

Inform. It explains the issue and supporting evidence to the responsible team.

Recommend. It proposes an action, expected impact, alternatives, and uncertainty.

Prepare. It drafts the approved artifact or system change but does not release it.

Execute within authority. It performs a reversible, policy-bounded action below a defined threshold and records the result.

Require explicit authorization. It pauses for approval when the action is consequential, exceptional, customer-facing, or difficult to reverse.

A prohibited category should also be explicit. Some actions should never be delegated to the agent, regardless of confidence, until policy or law changes.

The level belongs to the decision class, not to the agent as a whole. The same agent may autonomously refresh a risk summary, prepare a credit memo, and be prohibited from issuing the credit.

A hypothetical renewal decision

Consider a hypothetical $1.2 million software renewal. Product usage has fallen, two implementation milestones are late, and the customer has asked for a 12 percent discount plus three months of premium support.

The agent concludes that price is not the primary cause. It recommends an executive recovery meeting, a thirty-day technical plan, and a smaller service credit tied to delivery milestones. The analysis is strong and the intervention economics favor the targeted response.

But the company has no explicit authority map. Sales believes the regional vice president can approve the package. Customer success believes premium support requires the service leader. Finance views the credit as a pricing exception. Delivery will not commit specialists without an operations decision. Legal asks whether the original implementation promise changed the customer's rights.

Five days pass while the request is forwarded. The customer interprets the delay as lack of commitment.

A decision-authority contract would have separated the package into classes. The executive meeting can be scheduled by the account owner. The technical plan can be approved by delivery within documented capacity. The service credit requires finance authority above a threshold. Any new customer commitment must connect to the commercial promise record.

The agent can assemble one decision packet while routing each action to the correct authority. The customer receives a coordinated answer instead of an internal approval chain.

Authority must follow the current facts

Approval is not permanent. A decision can become invalid when value, evidence, scope, customer status, policy, or time changes.

A concession approved for a $200,000 renewal should not remain valid if the package expands to $600,000. A communication approved before a security incident may need review afterward. A delivery commitment can become unsafe when specialist capacity changes. A risk action based on stale evidence should not execute simply because its approval remains open.

The system should recheck authority and evidence at execution time. Material changes should return the decision to the appropriate level, preserving the prior approval rather than silently overwriting it.

This is also where temporary approvals can become exception debt. Every exceptional authority should have a scope, expiry, owner, and return path.

Where agents should help

An agent can identify the decision class, retrieve the current authority contract, verify thresholds, gather required evidence, and route the request to the right person. It can explain why approval is needed, which conditions remain unmet, and how the path changes if value or scope changes.

After approval, it can confirm that execution matches the authorized action, preserve the evidence, and monitor the outcome. It can also detect recurring requests that indicate a policy or authority boundary is outdated.

The governance logic aligns with the NIST AI Risk Management Framework. Its Govern function calls for clear roles, responsibilities, communication, policies, and accountability across the AI lifecycle. The framework is broader than revenue operations, but the principle is directly useful: human-AI teams need explicit responsibility and oversight, not implied permission.

Measure decision latency and authority quality

Executives should measure whether authority enables timely, accountable action. Useful indicators include:

Time from complete recommendation to authorization.
Requests rerouted because the original approver lacked authority.
Decisions waiting on missing evidence versus missing authority.
Percentage of actions executed within defined thresholds.
Exceptional approvals that expired, expanded, or became recurring.
Unauthorized or mismatched executions caught after the fact.
Override rates by decision class, reason, and outcome.
Decisions that missed their intervention window during approval.

The goal is not the fastest possible approval. It is the shortest defensible path to the right authority.

Accountable action requires explicit permission

A strong recommendation can still become revenue leakage if it waits in the wrong inbox, crosses an unclear threshold, or reaches a person with responsibility but no actual authority.

Agentic operations make this gap more visible because intelligence can move faster than organizational permission. The answer is not to slow the agent or remove human control. It is to design decision rights that both can understand.

The enterprise brain should know what is recommended, who may authorize it, what the approval covers, when it expires, and whether execution stayed inside the boundary.

Recommendation without authority is analysis. Authority without evidence is exposure. Accountable action requires both.

Related PATH AGI pages

Canonical article URL