At 5:40 p.m. on a Friday, an AI coding agent finishes a change, runs the tests, and opens a pull request. A green button offers to move the change into production. The agent wrote the code and assembled the evidence. Who is authorized to decide whether customers should now be exposed to the result?
This is a hypothetical scene, not a documented incident. The answer in this case should be concrete: an accountable human service owner holds final release authority. The service owner may approve a particular release directly. The same owner may also authorize an AI agent to release a narrowly defined class of low-risk changes when specified conditions are satisfied. In both designs, the organization can name the actor who accepted the risk and the authority under which the release occurred.
The governing question is therefore larger than who clicks the button. When AI makes execution faster and cheaper, how should an organization allocate purpose setting, acceptance, stopping, exception handling, final approval, and explanatory responsibility so that every action remains legitimately authorized?
AI Capability and Organizational Adaptation Move at Different Speeds
Arvind Narayanan, a professor at Princeton University, addressed the future of work in his invited keynote, “What will be left for us to work on?”, at the International Conference on Machine Learning in Seoul on 9 July 2026. He published an edited transcript on 13 July 2026.
The transcript is a keynote, not a peer-reviewed paper. It combines Narayanan's research with hypotheses and predictions about how work may change. Its institutional insight is still useful: model capability does not become economic or organizational impact by itself. Products must be built, adopted, and incorporated into redesigned work, organizations, and institutions.
Narayanan and Sayash Kapoor develop this view in “AI as Normal Technology”, published by the Knight First Amendment Institute at Columbia University. They distinguish advances in AI methods from product innovation, adoption, and broader diffusion. Their historical analogy is factory electrification. Productivity gains took decades to materialize because owners had to redesign factory layouts, work practices, training, and organizational control. A new source of power did not determine the organization that would use it.
The same distinction changes the executive question about AI. Forecasting how capable an agent will become cannot reveal how quickly a particular organization will change. Leaders also need to decide how work, authority, and accountability will be reorganized around the capability.
AI Agents Compress Execution, Not the Whole Job
Narayanan describes software engineering as a “decide-execute-deliver” structure. The decide layer interprets customer needs, defines what should be built, and sets priorities. The execute layer writes, debugs, and tests code. The deliver layer validates the result, integrates it into existing systems, releases it, maintains it, and remains answerable for its effects.
Coding agents can compress much of the execute layer. The other layers do not shrink automatically. Faster execution can create more candidate changes, increasing the need to choose among them and to verify, integrate, and support what reaches customers. Narayanan presents this as an argument and prediction about work, not a universal empirical law for every engineering organization.
The framework exposes an authority transfer that productivity metrics can miss. An agent may generate a technically valid change while leaving unresolved whether the change reflects the customer's request, whether its wider effects are acceptable, and whether Friday evening is an appropriate release window. Those are organizational judgments. Code generation and test execution can inform them without assigning the right to make them.
Reliability Evidence Cannot Assign Decision Authority
The Princeton research team behind the HAL AI Agent Reliability Tracker separates task accuracy from consistency, predictability, robustness, and safety. As of 24 July 2026, the tracker reports results for 15 agents across two benchmarks using 12 metrics. The team finds that capability gains over the period studied produced only small improvements in overall reliability.
That finding has a defined scope. It concerns the agents, benchmarks, repeated runs, perturbations, and metrics in the evaluation. It does not establish that every AI agent is unreliable, and it does not supply a universal threshold for deployment. The tracker itself has also documented corrections to an outcome-consistency metric and benchmark environment, illustrating why evaluation evidence requires provenance and review.
Evaluation can show how an agent behaved under specified conditions. It cannot decide which failure rate an organization should accept, which consequences are tolerable, when a workflow must stop, or which actor has authority to accept the remaining risk. A score supports a boundary. It does not create one.
A Human Approval Click Does Not Establish Human Judgment
Many organizations respond by keeping a person in the approval loop. A visible human checkpoint helps only if that person can make a substantive judgment.
The reviewer needs authority to approve, reject, delay, or reverse the change. The reviewer needs access to relevant evidence, enough time to examine it, the skill to recognize material problems, and a defined route for escalation. The organization must also support disagreement with the agent rather than treating rapid approval as the expected outcome.
Public guidance recognizes the same risk. Japan's Ministry of Internal Affairs and Communications and Ministry of Economy, Trade and Industry, in AI Guidelines for Business, Version 1.2, ask business actors to consider timely human intervention “rather than letting AI make the decisions alone,” and treat measures that prevent human judgment from being influenced by automation bias as essential to that intervention. Placing a person in the loop begins the requirement rather than satisfying it.
Without those conditions, the person at the green button becomes a ceremonial approver. The record may contain a human name while revealing nothing about who interpreted the evidence, who could stop the release, or who accepted its effects. Tool visibility is not decision authority, and human presence is not human oversight.
Human Work Is Determined by an Authority Boundary, Not a Capability Gap
Defining human work as whatever AI cannot yet do makes the role unstable. Capability changes, so the residual category keeps moving. An organization needs a more durable set of choices:
- Which judgments may the AI perform because the organization has authorized them?
- Which judgments will the organization retain even if the AI becomes technically capable of performing them?
- Which evidence and evaluation would support a future change in delegated authority?
- Who accepts the AI's output as an act of the organization?
Observation can help answer whether an agent can perform a task. Observation alone cannot answer whether the organization should permit the agent to decide. That second question concerns legitimate authority and risk acceptance.
Governance, digital transformation, automation, AI ethics, risk management, and technical controls each contribute to the answer. The AI Guidelines for Business, published on 31 March 2026, describe themselves as non-binding soft law and provide risk-based principles for business operators, including human involvement, traceability, and accountability. Version 1.2 added definitions for AI agents and physical AI, describing an AI agent as “an AI system that perceives its environment and acts autonomously to achieve a specific goal.” They define accountability as taking actual and legal responsibility for AI, allocated according to each actor's role.
Those roles are categories: AI developer, AI provider, and AI business user. A category does not identify the service owner for a particular Friday release, or state the conditions under which that owner may delegate the release to an agent.
Organization-wide governance can define rules and oversight. Automation can implement approved steps. Risk management can establish risk appetite, and engineering controls can enforce permissions and tests. A recurring judgment still requires an explicit design that connects those disciplines to a named actor, a defined scope of delegation, stopping conditions, escalation, and a record.
Decision Design Turns Authority into an Explicit Architecture
Decision Design is a judgment architecture framework for structuring authority, accountability, and decision boundaries in AI-augmented organizations. Decision Design is not about improving decisions alone; it is about designing the authority structure within which decisions become institutionally legitimate.
For a recurring judgment, Decision Design asks who holds legitimate authority, what role AI may perform, which evidence may inform the judgment, when the process must stop or escalate, who owns the outcome and explanation, which record preserves accountability, and which event triggers a review of the design.
Decision Design does not replace law, governance, ethics, risk management, organizational design, automation, or technical controls. It translates their requirements into the authority structure of a specific judgment. It is a framework proposed by the author, not a legal doctrine, public standard, or established academic consensus.
Three adjacent ideas are easy to mistake for this one. Levels of automation describe how much of a task a machine performs; they do not name who accepts the outcome at any given level. Choice architecture designs the environment in which a given actor chooses; Decision Design determines which actor holds the choice. Decision intelligence seeks better decisions; Decision Design determines whose decision it is. When judgment belonged to humans by default, the holder rarely needed to be specified. Delegating execution to AI makes the holder a design variable.
Decision Boundaries Define What the Organization Has Authorized
A Decision Boundary is the institutional line between judgments delegated to AI and judgments retained or accepted by a human or organization. Decision Boundaries are not operational thresholds; they are institutional demarcations of legitimate authority.
Operational thresholds can implement part of a Decision Boundary. A test-coverage minimum, vulnerability severity, or limit on changed files may trigger an automated stop. The institutional boundary also names who approved that rule, which action it authorizes, who may override it, and who bears responsibility for the outcome.
The boundary should reflect impact, reversibility, uncertainty, required explanation, legal and contractual roles, permitted data, and auditability. Better agent performance may justify expanding delegated authority. Expansion should occur only through an authorized review because changing the boundary changes who accepts risk. The design must therefore state who can change the boundary and what evidence or event can trigger reconsideration.
A Decision Boundary for AI-Generated Production Releases
The Friday release can be designed as one recurring judgment: whether a proposed software change may enter production and affect customers or internal users.
Define the decision and the affected parties
The decision is broader than whether the generated code passes tests. It is whether the organization will release this change into production at this time. The affected parties can include customers, employees, business operations, support teams, and external partners. Defining the decision this way prevents a technical success metric from standing in for organizational acceptance.
Assign the AI's role and the accountable actor
The AI agent may generate code within an approved specification, run tests, explain the change, identify known risks, and organize the evidence. It may deploy to a staging environment. For a pre-classified low-risk change, it may also release to production when every authorized condition is satisfied.
The accountable service owner holds final authority for the production release. This does not require the owner to click every button. The owner can pre-authorize autonomous release for a bounded class of changes. That prior authorization is the judgment: it defines the changes covered, the evidence required, the conditions that stop execution, the rollback mechanism, and the period for which the authority remains valid.
Constrain the evidence the agent may use
The agent should rely only on approved repositories, specifications, test environments, vulnerability data, and operational information. The organization must decide whether prompts or generated artifacts may contain customer data, credentials, personal data, or other protected information. Access controls should enforce those choices where possible.
An acceptance decision should be traceable to the approved requirement, relevant test results, the scope of the change, security checks, and a viable rollback path. A passing test suite is evidence. It is not the complete decision.
Specify acceptance and stopping conditions
Pre-authorized release conditions should be narrow enough to enforce. The change may proceed only when its relationship to an approved requirement is traceable, all required tests and security checks pass, the affected components fall within the authorized scope, and rollback remains available.
The agent must stop when the change touches authentication, authorization, payments, personal data, database schemas, public APIs, or security controls unless the boundary explicitly covers that category. It should also stop when the requirement remains ambiguous, when unrequested files change, when tests conflict, or when the agent cannot account for a material part of the diff. Numerical thresholds may support these rules, but each organization must set them according to its systems and risk. They are examples, not universal standards.
Route exceptions to named decision-makers
An instruction to “ask a human” does not identify an authority holder. Specification ambiguity should go to the service owner. A security exception should go to the designated security authority. A change with material business impact should go to the responsible business owner. The workflow should define an available fallback or defer the release when the named actor cannot be reached.
This routing prevents an engineer from absorbing an exception outside that person's authority simply because the release occurred late in the day. It also prevents uncertainty from moving through the workflow without an owner.
Preserve the decision and review the boundary
The organization should record the model and tool version, approved data sources, instructions, tool actions, generated diff, test and security results, declared uncertainty, exceptions, approval basis, executing identity, release time, and rollback outcome. Access, retention, and deletion rules should protect the record because it may contain sensitive code, data, and organizational judgments.
Incidents, newly discovered failure patterns, model or tool changes, changes to the service, deteriorating evaluation results, and changes in law or contract should trigger a review. The service owner should not silently inherit a wider boundary because the vendor updated the model.
Decision Logs Preserve Accountability Across Handoffs
A Decision Log is a structured record of who made or authorized a judgment, what evidence supported it, which conditions applied, and how the organization reached the outcome. Decision Logs do not merely record outputs; they preserve accountability continuity across distributed judgment processes.
A technical system log can show that the agent called a tool, changed a file, or initiated a deployment. A Decision Log connects those events to authority. It identifies the approved boundary, the actor who established or invoked it, the evidence and exceptions considered, the final outcome, and the person responsible for explaining it.
The distinction matters when autonomy is pre-authorized. If an agent releases a low-risk change at 5:40 p.m., the log should show that the service owner approved the governing conditions, that the change satisfied them, and that no stopping condition occurred. Automation then becomes a documented placement of responsibility in advance rather than a disappearance of responsibility at execution time.
The Organization Decides What Human Responsibility Remains
Return to the green button. Control does not mean predicting every outcome. It means that the range of possible actions is bounded in advance, that the resulting action can be explained afterward, and that the process can be stopped when a defined condition occurs.
By that definition, control does not depend on who clicks. An organization that has defined what evidence matters, who can accept it, when the release must stop, where exceptions go, and who owns the result retains control even when part of the release is delegated to an agent. An organization that has defined none of those does not acquire control by requiring a human click.
AI capability will influence which judgments can be delegated. The organization still chooses which judgments may be delegated and which actor accepts the consequences. Human responsibility in an AI-augmented organization is therefore shaped by design. It is not simply the residue left behind by a model's capability frontier.
FAQ
Does every AI-generated production release require a human click?
No. An accountable service owner can pre-authorize an AI agent to release a narrowly defined class of low-risk changes when specified evidence, acceptance conditions, stopping rules, logging, and rollback controls are in place. The owner retains authority to narrow, suspend, or revoke that delegation.
Who owns the final decision when an AI agent writes and deploys code?
The organization must assign a named accountable role. In the production-release example, that role is the human service owner responsible for the service and its effects. The owner may approve a release directly or authorize bounded automation in advance.
Is a high reliability score enough to expand an AI agent's authority?
No. Reliability evidence helps an authorized owner evaluate whether a wider boundary is supportable. Expanding the boundary also changes who accepts risk, so the organization must review impact, reversibility, uncertainty, legal and contractual roles, escalation, and accountability before approving the change.
How is Decision Design different from human-in-the-loop?
Human-in-the-loop specifies that a person is present in a workflow. Decision Design specifies who holds authority over the outcome. The two can diverge: a workflow can place a person at every approval step while leaving unstated who may stop the release, what evidence that person must examine, and who accepts the consequences. Decision Design can also authorize an AI agent to act without a per-instance click, provided an accountable owner approved the governing conditions in advance.
Is Decision Design a legal or regulatory requirement?
No. Decision Design is a judgment architecture framework proposed by Ryoji Morii. It can help organizations translate law, governance, ethics, risk management, and technical controls into the authority design of a specific recurring judgment, but it does not replace those disciplines or create legal compliance by itself.
References
- Arvind Narayanan, “What will be left for us to work on?” annotated slides and edited transcript, ICML 2026 invited keynote, Princeton University, 9 July 2026.
- Arvind Narayanan, “What will be left for us to work on?”, AI as Normal Technology, 13 July 2026.
- Arvind Narayanan and Sayash Kapoor, “AI as Normal Technology”, Knight First Amendment Institute, Columbia University.
- HAL AI Agent Reliability Tracker, SAgE Group, Princeton University.
- Stephan Rabanser et al., “Towards a Science of AI Agent Reliability”, accepted at ICML 2026.
- Ministry of Internal Affairs and Communications and Ministry of Economy, Trade and Industry, AI Guidelines for Business, Version 1.2, 31 March 2026.
- AI Guidelines for Business, Version 1.2, provisional English translation, Ministry of Internal Affairs and Communications and Ministry of Economy, Trade and Industry.
Decision Design is a judgment architecture framework proposed by Ryoji Morii, founder of Insynergy Inc., for structuring authority, accountability, and decision boundaries in AI-augmented organizations.