008 • W27–W28 • V//SR-03

VECTOR // SPECIAL REPORT 03

THE LAY DEPLOYMENT GAP

When Agentic Tools Outpace the People Deploying Them

DISPATCHES

READING PATH

REPORT CLASSIFICATION

Parent issue
VANGUARD SIGNAL 008 // The Confidence Gap
Layer
THE LAY DEPLOYMENT GAP / When Agentic Tools Outpace the People Deploying Them
Tool
Pre-Deployment Vetting Questions
Function
Determine whether a deployment decision is being made by someone who understands what they are authorizing
Failure prevented
Agentic workflows deployed by people who cannot identify scope, failure mode, accountable owner, stop threshold, or manual fallback — and the subsequent discovery of those gaps during an incident rather than during orderly vetting.
APPLIED TOOLPre-Deployment Vetting Questions

Determine whether a deployment decision is being made by someone who understands what they are authorizing

REPORT CONTENTS

  1. Executive Summary
  2. The Problem
  3. Why It Matters Now
  4. Core Diagnostic
  5. Framework
  6. Failure Modes
  7. Operator Test
  8. Technical Insert — Agentic Deployment Intake / Accountability Map
  9. Field Rule
  10. Example Application
  11. Limits / Boundary Notes
  12. Closing Assessment
01Executive Summary

VANGUARD SIGNAL 008 documents the confidence gap across multiple dimensions. The Lay Deployment Gap is the dimension that operates at the authorization layer: the structural condition in which the tools are broadly accessible but the knowledge required to deploy them accountably is not.

Microsoft Agentic Copilot is now embedded in Office. The accessibility floor for consequential AI deployment is anyone with an organizational Microsoft license. The accountability framework has not dropped to meet them.

This VSR delivers the Pre-Deployment Vetting Questions — five questions that must be answerable before an agentic workflow is authorized — and the Agentic Deployment Intake / Accountability Map, the structured record for documenting that authorization.


02The Problem

The tools are available to everyone. The knowledge required to deploy them accountably is not.

This is not a criticism of the people deploying them. It is a description of a gap that the structure of the current market has created and that no one in the supply chain has a structural incentive to close. AI providers are incentivized to expand adoption. Enterprise software vendors are incentivized to embed capability in platforms already in use. The organizations purchasing subscriptions are incentivized to demonstrate ROI. None of these incentives point toward slowing down to assess whether the people operating these tools understand what the tools are actually doing.

The deployment decision is made by someone who does not need to be a technologist. They need to know five things. Most deployment decisions are made without all five being known — because the interface did not ask, and no one required it before the workflow went live.


03Why It Matters Now

The DFEI.008 Table identified that lay users may deploy agentic workflows faster than they can learn accountable use — compressing the adaptation window before deployment literacy can form. Each agentic deployment authorized without the five vetting questions answered is a claim on future adaptation capacity: someone will eventually have to discover the scope, identify the failure mode, name an accountable owner, define the stop threshold, and find the manual fallback. The question is whether they discover those things during orderly review or during an incident.

Microsoft Agentic Copilot embedded in Office is the clearest instantiation of this gap at scale. Office is the most widely deployed enterprise software suite in the world. Its users span every level of technical sophistication from developer to executive assistant. Embedding autonomous, multi-step agentic workflows into that environment means the accessibility floor for consequential AI deployment is now: anyone with an organizational Microsoft license.

When a manager receives a report from a human employee, they evaluate it through an implicit model of that employee: their track record, their professional incentives, their relationship to the organization, their stake in being right. This model does not transfer to AI output. An AI system has no professional incentives. It has no relationship to the organization. It has no stake in being right. Past performance on similar tasks in stable conditions does not reliably predict performance on novel tasks or under changed conditions.

The output produced by an AI system is often more articulate than the human output that preceded it. It arrives faster. It projects confidence. And the implicit accountability model — built for human output — does not flag any of this as requiring additional scrutiny. The gap is structural, not moral.

In May 2026, Anthropic CEO Dario Amodei disclosed that more than 80 percent of the code merged into Anthropic's production systems that month was authored by Claude. Anthropic is among the organizations globally best positioned to evaluate that output. The question that follows is not whether Anthropic's deployment is appropriate. It is what happens when organizations without that evaluation infrastructure make equivalent decisions — which is the current condition across most enterprise deployments.


04Core Diagnostic
What can this workflow do without asking me, and who owns the result?

If the person authorizing the deployment cannot answer both questions specifically, they do not yet have sufficient information to authorize. The workflow's autonomous action scope is unknown. The accountability chain is undefined. The deployment decision is being made without the information the decision requires.


05Framework

5.1 The Accountability Model That Does Not Transfer

When a manager evaluates output from a human employee, they are not just evaluating the output. They are evaluating it through a model of that employee — their track record, professional incentives, relationship to the organization, and stake in being right. This model operates mostly implicitly, but it shapes how closely the work is read, what gets followed up on, and how much weight is assigned the conclusions.

This model does not transfer to AI output, because the conditions that justify it do not transfer. The AI system's output is articulate, confident, well-formatted. It arrives faster than a junior analyst. It does not hedge the way a subordinate with career risk would hedge. And the implicit calibration model — built for human output — does not flag any of this as requiring different scrutiny.

No malice is involved. The AI is doing what it was designed to do. The manager is applying a model that worked reliably until recently. The gap is structural.

Failure pattern:

The manager approves the AI-generated analysis in the same way they would approve a trusted analyst's work. The AI has no career risk. The manager has no way of knowing that.

5.2 The Scope of What Is Being Deployed

Agentic workflows are not document generation tools. They are systems capable of taking multi-step autonomous action: researching, synthesizing, drafting, submitting, scheduling, communicating, and modifying data — often without a human checkpoint between steps.

When a non-technical decision-maker deploys an agentic workflow, they are not adopting a productivity tool in the conventional sense. They are authorizing an autonomous process. That authorization should require knowing what the process can do without asking, what the failure modes are, who owns the results, what would stop it, and what the team does if it needs to stop.

Most deployment decisions are made without this information being gathered.

Failure pattern:

The department head approved the agentic workflow because the vendor demo looked useful and IT said it was available. Three months later, no one can answer what the workflow does between checkpoints, who would know if it produced a wrong output, or how to turn it off.

5.3 The Market Has No Structural Incentive to Close the Gap

AI providers are incentivized to expand adoption. Vendors are incentivized to embed capability in existing platforms. Organizations are incentivized to show ROI. The natural pressure of the current deployment environment runs toward activation, not toward informed authorization.

The interface will not ask the five questions. The deployment decision will happen. The accountability gap will be discovered during an incident if it is not resolved during vetting.

Failure pattern:

The interface offered the feature. The team enabled it. No one asked whether the people using it understood what it could do autonomously.


06Failure Modes

Action scope unknown

The authorizing person cannot specify what actions the workflow takes between human checkpoints. They do not know what the workflow does without asking. The deployment decision is made without this information.

Detection mechanism absent

There is no defined mechanism for knowing when the workflow has produced a wrong output. "I'll notice" is not a mechanism. The assumption is that fluent output is correct output.

Accountable owner unnamed

No person has been named as accountable for the workflow's outputs. The AI is not accountable. The vendor is not accountable in the operational sense. If no human owner is named, accountability diffuses to no one.

Stop threshold undefined

There is no defined condition under which the organization would stop using the workflow. Without a stop threshold, there is no rollback trigger — only a crisis that forces the decision under pressure.

Manual fallback missing

The workflow has become load-bearing without a documented alternative. When the tool is unavailable, unreliable, or producing outputs that cannot be trusted, the team does not know what to do instead.

Nontechnical authorization of autonomous workflows

A decision-maker without technical context authorizes a workflow capable of autonomous action in systems they cannot fully inspect. The authorization is made in good faith using the same judgment applied to human output. The judgment model is not calibrated for AI output.

Confidence output mapped onto human accountability assumptions

The AI's confident, fluent, well-formatted output activates the same trust responses as a trusted expert's output — without the conditions that would justify that trust. The authorizing person has no mechanism to recalibrate.


07Operator Test

Answer all five before authorizing any agentic workflow. They do not require technical expertise — they require the same accountability thinking applied to any other consequential operational decision.

Question What a satisfactory answer looks like Red flag
What can this workflow do without asking me? Specific list of autonomous actions between human checkpoints "I'm not sure" or "it depends on the task"
How will I know if it produces a wrong output? Named mechanism — not "I'll notice" "The output usually looks right" or no answer
Who is accountable when it makes a consequential error? A named person, not a team or the AI system "The team" or "the vendor handles that"
What are the conditions under which you would stop using it? Specific failure threshold defined before deployment "We'd know it if we saw it" or no defined threshold
What is the manual alternative? Documented fallback the team knows and can execute "We'd figure something out" or no fallback exists

No workflow should be authorized if any answer is unknown. Gather the information first. Deployment can wait for the five answers. Incidents cannot wait for the five answers.


08Technical Insert — Agentic Deployment Intake / Accountability Map

Purpose

Create a structured authorization record before an agentic workflow goes live — documenting scope, accountability, failure threshold, and fallback before deployment begins.

Use when

  • authorizing any new agentic workflow;
  • reviewing an existing agentic deployment that was activated without a vetting record;
  • assessing whether a team's current agentic tool deployment has adequate accountability documentation.

What it creates

A pre-deployment authorization record that names the scope, the accountable owner, the stop threshold, and the fallback — and makes those decisions visible and retrievable rather than informal and forgotten.

Technical version

agentic_deployment_intake:
  deployment_date:
  workflow_name:
  tool_or_platform:
  authorizing_person:
  department:
  scope:
    autonomous_actions:      # list every action taken between human checkpoints
    systems_accessed:        # list every system the workflow can read or write
    data_touched:            # what data types are in scope
    checkpoint_frequency:    # how often a human reviews or approves
  detection:
    wrong_output_signal:     # specific: how will a wrong output be identified?
    detection_owner:         # who monitors for quality signals?
    review_cadence:          # how often is output quality reviewed?
  accountability:
    output_owner:            # named person accountable for workflow outputs
    escalation_path:         # who does the output_owner escalate to?
    incident_log:            # where are quality failures logged?
  stop_conditions:
    failure_threshold:       # specific condition that would trigger stopping
    stop_authority:          # who can stop the workflow?
    stop_procedure:          # how is it stopped?
  fallback:
    manual_alternative:      # documented process if workflow is unavailable or unreliable
    fallback_owner:          # who executes the fallback?
    fallback_tested:         # yes / no / date_last_tested
  source_risk:
    consequential_outputs:   # yes / no — does output affect decisions, records, or people?
    review_required:         # yes / no — is independent human review required before action?
  authorization_status:      # approved / approved_with_conditions / pending / rejected
  review_date:               # when this record is next reviewed
  notes:

Manual / no-code alternative

Document with these headings before deployment:

Workflow Name | Autonomous Actions | Systems Accessed | Detection Mechanism | Accountable Owner | Stop Condition | Stop Authority | Manual Fallback | Authorization Status

Review at quarterly cadence or after any significant workflow change.

Output

A pre-deployment authorization record retrievable at any point — for incident review, compliance, escalation, or rollback decisions.

Failure prevented

Agentic workflows deployed by people who cannot identify scope, failure mode, accountable owner, stop threshold, or manual fallback — and the subsequent discovery of those gaps during an incident rather than during orderly vetting.


09Field Rule

Availability is not deployment literacy.


10Example Application

Microsoft Agentic Copilot embedded in Office becomes generally available to all M365 enterprise users. An IT department enables agentic capabilities organizationally. A department head, notified that the feature is available, enables it for their team's reporting workflow.

The Pre-Deployment Vetting Questions applied at the authorization moment:

  1. What can this workflow do without asking me? — Unknown. The authorizing manager has not mapped the autonomous action scope.
  2. How will I know if it produces a wrong output? — "The team reviews the reports before they go out."
  3. Who is accountable when it makes a consequential error? — "The team."
  4. What are the conditions under which you would stop using it? — Undefined.
  5. What is the manual alternative? — "We'd go back to doing it manually."

Three of five questions are unanswered or inadequately answered. Under the vetting framework, this deployment does not proceed until the scope is mapped, the team is named as a specific accountable person, and the stop condition is defined. The Agentic Deployment Intake / Accountability Map documents those answers before the workflow goes live.


11Limits / Boundary Notes

The Lay Deployment Gap is a structural condition, not a critique of individual deployers. Non-technical decision-makers deploying agentic tools are not acting in bad faith. They are acting on the signals available to them — and those signals (vendor confidence, IT availability, peer adoption) do not include the information the five questions surface.

The Pre-Deployment Vetting Questions address the authorization decision point. They do not address ongoing deployment quality, output evaluation, or incident detection — those belong to VSR-01 (verification burden), VSR-02 (incident recognition), and the Adaptation Throughput Test (Field Artifact).

The framework applies most directly to agentic workflows with write access or consequential output. Low-stakes, human-reviewed, non-autonomous uses of AI tools carry a different risk profile and may not require the full intake record.


12Closing Assessment

The interface will not ask the five questions. The vendor demo will not ask them. The IT deployment notice will not ask them. The productivity narrative will not ask them.

If the five questions are not asked before deployment, they will be answered during an incident — under time pressure, with less information, and at greater cost.

Agentic tools with autonomous action scope are not productivity features in the same category as document editors or search tools. They are authorized processes with no accountability structure unless one is built before deployment begins. The authorization decision is the moment that accountability structure is either created or deferred.

Availability is not deployment literacy. The button being there is not a signal that the person pressing it understands what they are authorizing.


DFEI.008 :: VSR-03 :: The Lay Deployment Gap Dispatches From Emerging Intelligence :: Vector Intelligence Studio