The unit of intelligence is the decision loop

01 / Start with the phenomenon that needs explaining

Suppose an organization improves the accuracy of a planning model, but its decisions do not improve. The forecasts are better. The recommendations arrive sooner. Yet plans still stall between functions, or people commit to incompatible actions. What, exactly, became more intelligent?

One explanation is that the model remains insufficiently capable. Another is that the binding constraint sits elsewhere: objectives conflict, critical assumptions are unshared, or nobody has authority to resolve a trade-off. These explanations imply different investments. A theory that treats every failure as a model limitation cannot help us distinguish them.

My proposal is to evaluate enterprise intelligence at the level of a decision loop: the connected process by which an organization forms a view of a situation, chooses an action, authorizes a commitment, observes consequences, and revises what it will do next.

02 / Define the object before measuring it

I use enterprise intelligence to mean a capacity for justified, coordinated action under incomplete knowledge, with the ability to learn from consequences. This is a working definition for organizational analysis. It does not imply that a company is one mind or that its intelligence has a single numerical score.

“Justified” means the decision has a defensible basis in the evidence and constraints available at the time. “Coordinated” means the commitments made by different participants can be carried through together. “Learning” means the organization retains and uses a warranted change in its beliefs, procedures, or decision rules.

These distinctions prevent an easy mistake: equating a good result with a good decision. A careful decision can encounter an unlikely adverse event. An unjustified decision can succeed through luck. Evaluation needs both the basis for the choice and a pattern of outcomes, rather than one convenient success.

03 / The mechanism: local competence meets institutional constraints

Herbert Simon’s work on bounded rationality provides a useful starting point: accounts of rational choice need to take limited information and computational capacity seriously. [1] My extension here is an organizational question: where, across the entire decision loop, does a consequential limitation sit?

Consider an illustrative inventory decision. Two teams share the same forecast. One prioritizes reducing committed capital; the other prioritizes resilience to disruption. A more accurate forecast may narrow uncertainty, but it cannot by itself decide how much resilience the organization should buy. That choice needs a stated objective, constraints, and an authorized way to resolve disagreement.

The distinction is between uncertainty about the world and disagreement about what to do in it. More evidence can help with the first. It can inform the second without settling it. Treating a disputed objective as a missing fact can send the team into an endless search for a prediction that will make the disagreement disappear.

04 / A counterexample that limits the claim

Now consider extracting identifiers from standardized documents into an existing, well-controlled process. The objective is clear, the downstream action is settled, and extraction errors are the dominant source of rework. In that setting, improving model accuracy may be exactly the right investment. Additional governance layers could simply add cost.

This counterexample matters. I am not claiming that organizational redesign always dominates model improvement. The narrower proposition is that improving a component has limited value when an independently identified constraint elsewhere prevents its gains from reaching the outcome. The practical task is to locate that constraint, not assume it.

05 / A test that could change my mind

Select a bounded workflow with evidence of a specific coordination or decision-rights bottleneck, such as cases repeatedly waiting for an unresolved owner. Define acceptable decisions, relevant costs, and evaluation criteria before the trial. Then compare four conditions using comparable cases:

• The current model and the current workflow.
• A more capable model with the current workflow.
• The current model with the identified bottleneck addressed.
• The more capable model with the bottleneck addressed.

06 / Measure the mechanism as well as the result

Start in a simulation or authorized replay when live experimentation could create consequences. Keep case difficulty, staffing, available information, and time budgets comparable. Prevent or account for learning between conditions. Independent reviewers should assess decision quality without knowing which condition produced the work, where feasible.

Measure accepted outcomes, total effort, time waiting for decisions, unresolved conflicts, and recovery work. Also check whether the proposed bottleneck actually changed. Otherwise a positive result could come from an unrelated process improvement, and a negative result could mean the intervention was never implemented. Report policy or safety violations separately from speed and cost, rather than hiding them inside a net-value score.

The hypothesis predicts a meaningful benefit from removing the bottleneck in the selected workflow, potentially amplified by the better model. If a model upgrade alone consistently resolves the supposedly institutional problem, the diagnosis needs revision. If the verified intervention removes the bottleneck without improving the defined outcome, the local hypothesis is not supported. Any explanation involving a different constraint should be tested separately, rather than used to rescue the original prediction.

07 / The implication for AI leadership

A decision-loop perspective changes the conversation from “Which model should we deploy?” to “Which limitation prevents this organization from acting better, and what evidence would identify it?” The answer may still be a better model. It may also be a clearer objective, a maintained source of knowledge, or a different allocation of authority.

The leadership responsibility is to make those explanations compete against evidence. That is a more demanding standard than counting tools, and a more useful one than assuming capability will automatically become organizational value.