How We Decide

From the early days of decision support to delegated agency in the age of AI.

Abstract

The history of decision support is a history of judgment moving from managers into the systems around them. Early systems organized information and modeled alternatives. Expert systems encoded narrow expertise. Business intelligence made operations visible. Predictive models estimated what might happen next. Automated systems began making bounded choices at scale.

Agentic AI extends that progression into action. Systems can interpret goals, plan steps, use tools, coordinate workflows, and act across connected environments. Each step moves authority closer to the machine. The limiting factor is no longer model capability. It is whether the organization has made its own operating judgment legible enough for machines to participate under clear authority.

A powerful model does not know how an operation works. It does not know which objective wins when goals conflict, which constraint cannot bend, when a routine case becomes an exception, or when uncertainty is high enough to stop. The agentic era therefore requires an explicit architecture for judgment: operational reasoning, ontology, logic mapping, decision rights, and human authority. Accuracy still matters. So do permissions, escalation, contestability, traceability, and named ownership.

1. Introduction: From Help to Delegated Agency

Decision support has steadily moved closer to the decision.

The first systems gave managers better information and better ways to explore alternatives. Later systems encoded expertise, predicted outcomes, optimized choices, and automated routine decisions. Agentic systems can now take the next step themselves. They can interpret a goal, decide what to do next, call tools, update systems, and coordinate work across a process.

That progression changes who, or what, is exercising judgment inside the organization. The design problem shifts with it. The question is no longer only which model to use. It is what system should surround the model so it can do useful work under clear limits.

The roots of decision support are usually traced to management information systems, operations research, and the spread of interactive computing in the 1960s and early 1970s. Gorry and Scott Morton’s 1971 framework helped distinguish structured operational decisions from the semi-structured and unstructured decisions that required managerial judgment.

By 1980, Sprague and Alter were describing decision support as a distinct class of systems designed around interaction between a decision-maker, data, and models (Gorry & Scott Morton, 1971; Sprague, 1980; Alter, 1980).

A classic decision-support system might help a credit manager compare borrower risk under different assumptions. An agentic system can gather the records, identify missing information, interpret policy, recommend a disposition, update the workflow, notify the customer, and escalate the exception. The prediction may be only one step in a much larger sequence.

Once systems can act, governance becomes part of system design. The practical questions become immediate: What may the system decide? What may it do? When must it stop? Who can overrule it? What evidence must it leave behind? Who answers for the result?

This paper follows that line from decision support to delegated agency. The central claim is that each technological step moved authority and therefore required more explicit architecture. The model is not the system. Agentic AI scales judgment only when the architecture preserves responsibility.

2. Intellectual Foundations: Decision-Making Before DSS

Herbert Simon provides the cleanest starting point. In The New Science of Management Decision, he described decision-making as a process with three recurring activities: intelligence, design, and choice. Intelligence searches for conditions that require a decision. Design develops and analyzes possible courses of action. Choice selects among them. Simon also made clear that execution generates further decisions rather than sitting outside the process (Simon, 1960).

This matters because decision support was never simply about producing an answer. It was about helping people search, frame, compare, and choose.

Simon’s work also sits inside the broader Carnegie tradition of bounded rationality. Managers operate with limited attention, incomplete information, competing goals, and finite capacity to evaluate alternatives. Organizations respond by using routines, decision rules, division of labor, and standard operating procedures to make action possible under those constraints (March & Simon, 1958; Cyert & March, 1963).

Operations research added another strand: mathematical models for allocation, scheduling, forecasting, simulation, and optimization. Its traditional posture was explicitly supportive. The model informed the decision-maker; it did not claim the decision (Gray & Lenstra, 1988).

Interactive computing then changed the practical relationship between manager and machine. Instead of waiting for static reports or specialist analysis, managers could query data, change assumptions, and explore alternatives directly. The computer became part of the decision process rather than a back-office processor.

These foundations established a durable division of labor: machines could expand analytical capacity while humans retained authority over ambiguous, consequential, or poorly structured choices.

3. The Classic DSS Era: Information, Models, Interaction

Classic DSS grew from that division of labor. The defining feature was interaction. Managers could inspect information, manipulate models, ask “what if,” and see how results changed when assumptions changed. The point was not to remove judgment. It was to make judgment better informed and more analytically capable (Gorry & Scott Morton, 1971; Sprague, 1980; Alter, 1980).

Three capabilities capture the era:

The architecture assumed a clear owner of the decision. The manager framed the problem, selected assumptions, interpreted the output, and made the call. The system widened the field of view.

4. Expansion: Expertise, Groups, and Executives

During the 1980s, decision support spread beyond the individual manager working with a model.

• Expert systems encoded narrow-domain expertise as rules and inference procedures. MYCIN became the canonical example of how expert knowledge could be represented and applied computationally (Buchanan & Shortliffe, 1984).
• Group decision-support systems combined communication, computing, and decision-support tools to help groups work through unstructured problems (DeSanctis & Gallupe, 1987).
• Executive information systems gave senior leaders direct access to high-level indicators and drill-down views. Rockart and Treacy documented this emerging pattern in 1982 as senior executives began working directly with online information systems (Rockart & Treacy, 1982).

The important shift was the representation of organizational knowledge inside the system. A model could embody assumptions. An expert system could embody rules. An executive system could determine which measures deserved attention.

That was the beginning of a deeper transfer. The system was no longer limited to carrying information. It increasingly carried a version of the organization’s reasoning about what mattered and how a problem should be handled.

5. Business Intelligence, Prediction, and Automated Decisions

In the 1990s and 2000s, decision support became infrastructure. Data warehouses consolidated historical data. Online analytical processing made multidimensional analysis practical. Business intelligence put measures, trends, and exceptions in front of managers at enterprise scale. Chaudhuri and Dayal described data warehousing and OLAP in 1997 as essential elements of decision support and a major focus of the database industry (Chaudhuri & Dayal, 1997).

The sequence matters:

• Business intelligence made the organization more legible to itself.
• Predictive analytics made future states more estimable.
• Decision automation made selected choices executable at scale.

Each capability moved the system closer to operational consequence. A dashboard could shape attention by deciding what appeared and how it was defined. A predictive model could rank risk or opportunity. An automated rule could approve, reject, route, hold, or escalate a case without waiting for an individual manager.

Measurement also became an instrument of management. Metrics looked objective because they were numerical, but the choices behind them remained contestable: what gets measured, how categories are defined, which thresholds trigger action, and which outcomes the organization optimizes. The technology made those choices faster and more scalable. It did not make them neutral.

6. The Agentic Inflection

Agentic AI changes the operational unit.

A dashboard presents information. A predictive model produces an estimate. A conventional automated system applies a predefined rule. An agentic system can move across the sequence. It can interpret a goal, decompose the work, use tools, retain state, choose a next step, act in another system, observe the result, and revise its plan. Contemporary surveys of LLM-based agents consistently identify planning, memory or state, and tool use as core components of this architecture (Zhao, Jin, & Cheng, 2023; Wang et al., 2024).

The model is not the system. A powerful model still does not know how an operation works. It does not inherently know which objective wins when goals conflict, which constraint cannot bend, when a routine case becomes an exception, or when uncertainty is high enough to stop. Those judgments live in the architecture around the model.

“Agentic” is therefore more useful as a description of delegated authority than as a binary label. Systems can sit at very different points on that spectrum:

Accuracy alone is an incomplete measure of such a system. Fluency is even less useful. The more authority a system receives, the more important its permissions, consequences, escalation paths, and evidence trail become.

This is the central break with classic DSS. The unit of analysis is no longer a manager using a tool. It is a decision-and-action system made up of people, models, data, policies, software tools, permissions, and escalation paths.

7. Architecture for Judgment

Human oversight can exist without meaningful human judgment.

A person who clicks “approve” at the end of a fast, opaque workflow may technically remain in the loop while contributing little to the decision. Recent work on meaningful human oversight makes the same point: human involvement can collapse into rubber-stamping unless people have the information, authority, and opportunity to evaluate and intervene (Zhu et al., 2026).

Call that accountability theater. The organization can point to a human checkpoint, but the architecture has already made the substantive decision elsewhere.

The better design principle is selective friction. Put human judgment where the stakes, ambiguity, novelty, or policy implications justify it. Let routine work move. Force uncertain or consequential cases into a different path. Give the human enough context to make the intervention real.

NIST’s AI Risk Management Framework treats governance, documentation, transparency, accountability, and defined roles as organizational responsibilities across the AI lifecycle, rather than properties that emerge from model accuracy alone (NIST, 2023). The framework is useful. The organizing unit remains the operating decision.

Five design concerns determine whether a model can be trusted to participate in real work:

• Operational reasoning. How changing conditions become governed decisions and actions over time. Observe, interpret, reason, decide, act, evaluate, learn.
• Ontology. How the system represents the entities, relationships, states, constraints, and authoritative sources that define the operating world. Whoever defines the entities defines the outcomes.
• Logic mapping. Which decisions belong to deterministic rules, probabilistic models, optimization, or human judgment. Put the right logic in the right layer.
• Decision rights. What an agent may observe, recommend, prepare, execute, defer, escalate, or refuse. Authority by consequence.
• Human authority. How accountability, review, override, escalation, and governance remain real rather than ceremonial. People retain the final say.

A practical test for agentic decision systems follows from these concerns:

• Authority. What may the system recommend, decide, or do?
• Visibility. Can affected people and accountable staff understand what happened and why?
• Contestability. Can a recommendation, decision, or action be challenged, corrected, or reversed?
• Escalation. What conditions require a human with real authority to intervene?
• Traceability. Can the organization reconstruct the data, policy, model behavior, tool calls, approvals, and people involved?
• Ownership. Which named role owns the outcome, not merely the operation of the system?

These are architecture questions. They cannot be repaired at the end with a generic “human in the loop” control.

8. Three Eras, Three Locations of Judgment

The progression becomes clearer when the same issue is viewed across eras.

Classic DSS, 1970s and 1980s. Interactive financial planning systems let managers change assumptions, explore scenarios, and inspect the consequences. IFPS, developed in the 1970s, is a useful example. It let managers work directly with financial models while leaving the decision with them. Contemporary accounts describe IFPS as an interactive planning language built specifically to support managerial modeling and “what-if” analysis (Williamsen & Wagner, 1976; Gray, 1984). Judgment remained with the manager. The system expanded analytical capacity.

Predictive and automated systems, 2000s and 2010s. Scoring models and rule engines increasingly ranked cases and automated bounded actions such as routing, approval, review, or holds. Authority moved into the system, but usually within predefined rules, thresholds, or model outputs. Human involvement shifted toward policy design, exception handling, and appeal. The system began to carry a version of the organization’s logic.

Agentic systems, present. Consider an airline network disruption. A traditional system might flag a delay or score recovery options. An agentic system can monitor the disruption, gather aircraft and crew status, weigh passenger connections against maintenance and regulatory constraints, draft a recovery plan, queue communications, and update downstream systems. At that point the meaningful boundary is authority: may the system rebook passengers, reassign crews, commit resources, or contact external partners? Or must it stop and escalate?

The same pattern appears in logistics exception management, industrial production recovery, financial exception routing, and complex claims or case operations. Decisions cross systems, functions, time horizons, and competing objectives. Simple automation stops being enough. The architecture has to represent the operating world well enough to assign each part of the decision to the right form of intelligence, then bound that intelligence with explicit authority.

The technology becomes more capable at each stage. More important, the location of judgment changes with it.

9. The Design Task Now

The history of decision support is a history of changing boundaries.

Managers once used systems to see more clearly. Then systems began to encode expertise, shape attention, rank options, and execute bounded choices. Agentic AI can now participate in the operating sequence itself.

That puts a new burden on design. Organizations have to specify where judgment lives, how authority moves, when the system must stop, and how responsibility remains visible after the work has passed through models and software.

The goal is not maximal autonomy. It is useful delegation with clear limits.

That requires more than a capable model. It requires an operational ontology that represents the relevant people, entities, states, policies, and relationships; logic that defines how decisions should be made; explicit decision rights; escalation rules; and evidence trails that allow the organization to reconstruct what happened.

Agentic AI becomes operational when the organization can make its own reasoning explicit enough for machines to participate in it. Agentic AI can scale judgment only if the architecture preserves responsibility. That is the design problem now.

References