In short
- An AI action can be right on every fact and still wrong for the company.
- Knowing the facts does not establish the company’s priorities, available capacity or permission to act.
- As agents take on more work, the operating model has to become explicit enough for people and software to use.
An AI system knows a customer renews in 43 days. It knows who owns the account. It can pull the correspondence, summarize the commercial history and draft a solid renewal email.
Meanwhile, the implementation is 18 days behind. The account owner is carrying more than the coverage model says one person should. The executive sponsor has gone quiet. Company policy requires senior review before outreach on a strategic renewal with unresolved delivery risk.
Every fact the system pulled was right.
The email was well written.
Sending it would still have been wrong.
The system knew how to do the task. It had not established whether the task belonged in the situation.
The operating model is what the company has decided about its work: its objectives, policies, approved capacity assumptions and decision authority. Evaluated against current facts, those choices determine which responses are permitted and supportable.
The part people supply without naming it
For much of the history of enterprise software, a human remained between information and action.
An experienced operator sees that the approaching renewal, delayed implementation, overloaded owner and weakening relationship form one situation.
The operator considers what the company is trying to protect, which policy applies, what the team can support and who may commit the organization. Only then does the operator decide whether the email should go out.
That interpretation had a home.
It lived in people.
I know because I was one of those people. As a Chief of Staff, I almost never used the CRM’s front end. I worked from a library of queries I had built up over years, because the records needed to be assembled into an operating picture. I carried much of that picture myself.
The workforce did two jobs at once: it executed the work, and it applied the company’s operating model to live situations.
- Finance held the economic thresholds.
- Delivery knew which delays were recoverable.
- Customer teams understood the relationship.
- Senior operators assembled the fragments when a situation crossed functional boundaries.
The model was real. It ran through people, meetings and spreadsheets. Enterprise systems could remain incomplete representations of the company because people stood in the gaps.
Legibility is not business reasoning
The current wave of enterprise AI is trying to close part of this gap.
Google Cloud’s July 2026 discussion of agent infrastructure identifies fragmented data and missing business context as obstacles for agents. It argues that effective action needs business logic alongside the data.
That is necessary infrastructure. An agent needs a reliable way to read the business.
An ontology can connect the delayed implementation to the approaching renewal. It can identify the owner, represent a business rule and retrieve its supporting records. It can also represent approval and authority.
Those representations still need to govern a live evaluation.
Which approved rule version applies? Which objective prevails when rules conflict? Can the company support the proposed response? Who may commit it?
A stored rule becomes useful in a decision when its applicability, approval and authority are established for that situation.
Inference is not an operating model
A capable model can infer a great deal: likely relationships, relevant precedent, possible trade-offs and the response a company would probably prefer.
Some operating premises require a company choice.
Intent is chosen.
Policy is adopted.
Authority is delegated.
Capacity is assessed against current demand, available capability and approved assumptions.
A model can predict who would approve an action. That prediction does not grant approval. It can infer the rule people usually follow. The company still has to decide whether that rule is binding here.
Time is part of the decision
A decision made on Monday must be assessed against what was known on Monday. A record corrected on Friday belongs to a later evidence state.
The distinctions matter.
- A plan records intent.
- A recommendation proposes a response.
- A decision records a choice.
- An outcome records what followed.
Collapse those states and a system can mistake hindsight for learning. The record may look precise while misrepresenting what the decision-maker could have known.
Feasibility is part of reasoning
Capacity is a relationship between demanded work and the capability available to carry it at a particular time. That capability may be human, automated or AI. Skill, load, timing, review requirements and authority constrain its use.
Consider a proposed account reassignment. The recipient has lower utilization, but lacks the required segment experience, already holds three renewals that week and has no relationship with the customer.
The reassignment is technically available.
Its feasibility remains unproven.
The same distinction matters with AI. A model may draft a brief in seconds and still consume scarce human review. It may perform well in aggregate while making errors in cases the company cannot afford to mishandle. It may be able to update a system while lacking permission to do so.
“AI can do this” is a capability claim.
“The organization can support this work through AI” is a capacity claim.
Each needs its own evidence.
The permissions an action needs
Data governance controls which information an actor may access. Operating a company involves further permissions:
See → Interpret → Recommend → Decide → Commit → Act
Different actors may stop at different levels. Deciding selects a course. Committing binds resources or external promises to it. Acting carries it out.
An agent may be permitted to see renewal exposure and recommend moving an account. Changing ownership, contacting the customer or reallocating delivery resources can require separate authority.
NIST’s February 2026 draft concept paper on agent identity and authorization asks how an agent can establish authority for a specific action, how authority is delegated and how actions can be traced to human authorization.
For a renewal workflow, those controls need to reflect the company’s choices about who may make a customer commitment.
The renewal email may be accurate, relevant and ready to send. The permission to send it still needs to be established.
Where the model runs now
People continue to define intent, negotiate contested priorities, hold relationships and govern exceptions that formal rules leave unresolved.
For decades, an experienced human executor could carry much of that operating judgment into each action.
Move the task to software and the judgment has to travel with it.
The record travels.
The task travels.
The company’s chosen constraints need a reliable way to travel too.
In Deloitte’s June 2026 study, 81% of surveyed technology executives said they could deploy and govern AI at scale. Nearly 75% said their operating model would need to change within 12 to 18 months.
Confidence in deployment leaves an operating question:
It needs to operate across people and software: grounded in current evidence, guided by chosen intent, constrained by available capacity and governed by authority.
Some situations will fit approved rules. Others will expose conflicting priorities, missing evidence or a judgment the company has yet to make. A useful runtime has to preserve those distinctions.
What this means for your team
Before a person or agent acts on a renewal, ask:
- Does it see the situation? The renewal date, delayed implementation, overloaded owner and quiet sponsor need to arrive together.
- Can the company support the response? Check the capacity of the people and agents who will carry the work afterward.
- Who may commit? Establish which actors can recommend, which can decide and which can bind the company.
If the answer is “someone just knows,” that is where part of your operating model runs today.
The decision runtime
That is what I’m building OpX to be: the decision runtime for customer operations.
It connects the work, the capacity to deliver it and the authority to decide. OpX starts in Customer Success, where a renewal can depend on delivery, coverage and decisions made elsewhere in the company.
The design keeps evaluation, recommendation and authority distinct. People decide how to respond. Access for an external agent needs an explicit scope; permission to read a result leaves the authority to act as a separate decision.
The question before action stays the same: does this response belong in this situation?
Sources
- Your AI agents are ready. Is your data?, Google Cloud, July 23, 2026.
- Accelerating the Adoption of Software and AI Agent Identity and Authorization, NIST NCCoE, initial public draft released February 5, 2026.
- Rewiring the enterprise operating model for AI scale, Deloitte Insights, June 29, 2026.
