AI Delivery Decision Frameworks: Type 1, Type 2, DACI

A bench mismatch, a scope gap, a stakeholder escalation: each gets treated as a hard blocker requiring structural intervention, when most warrant fast iteration instead. Four frameworks correct this: Type 1/Type 2 sets decision velocity; Eisenhower orders the queue; DACI assigns authority and prevents reversible decisions from stalling; PMBOK stakeholder management separates trust failure from delivery failure.

Table of contents

Why Are Staffing Mismatches Misclassified as Irreversible?

When a client challenges team competence mid-engagement, the reflex is to swap resources, open a requisition, or restructure. PMI data across 4,455 project management practitioners shows communication, requirements, sponsorship, and alignment failures as leading causes of project underperformance, ahead of personnel gaps.

Triage requires four parties: the account executive (client relationship), the practice lead (bench and capability decisions), the resource manager (internal re-allocation and capacity), and the vendor CSM (Customer Success Manager) if a technology partner is co-funding the engagement. Convening the wrong subset produces a decision without the authority to execute it.

Which Decision Types Are Most Often Misclassified?

A resistant client is more often a symptom of unmet expectations than a verdict on team quality. A bench mismatch signals a lead-time gap, not a capability ceiling. A CEO-level escalation over team conflict is an interpersonal dynamic, not a personnel failure.

Bezos identified this pattern at organizational scale: the primary failure mode in large institutions is applying Type 1 process to reversible situations.

What Is the Type 1/Type 2 Decision Lens?

Type 1 decisions are consequential and largely irreversible (“one-way doors”), warranting great deliberation before committing. Type 2 decisions are reversible and cheap to undo (“two-way doors”), warranting speed and high-judgment individuals or small groups.

Delivery Examples of Each Type

Signing a milestone SOW with vague scope is Type 1: contractually binding and hard to reverse. Proposing a paid inception phase is Type 2: time-limited and reversible. Treating a two-way door as a one-way door stalls decisions.

Table 1: Type 1/Type 2 classification for three common delivery decisions.

How Does the Eisenhower Matrix Add Triage Ordering?

Eisenhower determines the order of engagement; Type 1/Type 2 determines the decision velocity within each item.

Table 2: Eisenhower quadrant examples for delivery leaders.

Why Q2 Is the Real Leverage Point

In practice, many Q1 crises begin as neglected Q2 work, a framing consistent with Covey’s urgent-important model and with crisis-management literature emphasizing the cost of deferred preparation (Mitroff & Alpaslan, 2003): DACI not established before pursuit, stakeholder relationships not maintained, team capability not developed. These activities are never urgent, so they are chronically deferred.

Immediate vs. Deferrable Actions Across Simultaneous Crises

When multiple crises land at once, Eisenhower gives the sequence but not the split between stabilization and root-cause work. The immediate column stops the bleeding; the deferrable column addresses recurrence.

Table 3: Immediate vs. deferrable actions per crisis type (Eisenhower Q1/Q2 split).

Why Does Delivery Authority Collapse Without a DACI?

Without a DACI, no single role holds unambiguous decision rights. Decisions stall in silence across dotted-line relationships.

DACI assigns four roles to every significant decision: a Driver who owns moving the decision forward, a single Approver with final authority, Contributors who provide substantive input, and Informed parties notified afterward.

What Failure Mode Does DACI Prevent?

Its power is not taxonomic; it is a forcing function that requires organizations to name, in advance, who can say no. The Approver is the human-in-the-loop control point: the role that cannot be automated, delegated by silence, or assumed. Without that clarity, Sales commits to scope in a client meeting, Delivery identifies structural risks, and the client receives contradictory signals from the same firm. No individual owns the decision, so no individual acts. The tell: Sales and Delivery both believe they communicated clearly; the client received two different answers.

How Do You Exercise Authority Through Dotted-Line Relationships?

DACI works cleanly when authority is direct. When the Delivery Director has only dotted-line authority (informal influence without org-chart ownership), the Approver role depends on trust rather than structure. The mitigation: establish DACI expectations at engagement kickoff, before any crisis, so the dotted-line relationship carries decision-making weight when a scope dispute arrives. Silence is not agreement in dotted-line structures: the Delivery Director must confirm the Approver role in writing at engagement start.

Code Snippet 1: AGENTS.md delivery governance section. The Role block scopes agent authority; the Constraints block makes rules machine-checkable.

## Role
You assist the Delivery Director on scope, staffing, and client communication tasks.
You do not have authority to commit, approve, or communicate on behalf of Sales or the client.

## Constraints
- Scope changes to a signed SOW: flag for Approver sign-off before any client communication.
- Sales verbal commitments are not binding; require a written amendment before acting on them.
- Staffing proposals outside the AI capability frontier: classify Type 1 and flag for human review.
- Ambiguous decisions: output what information is missing; do not infer or assume.AGENTS.md

DACI in Practice: SOW Scope Disputes

When a client compresses a fixed-scope contract to a shorter timeline with vague milestones, the Delivery Director must be the named Approver on SOW structure. Without that delineation, Sales capitulates because no one has organizational standing to hold the boundary. Haleem et al. (2021) trace this failure to requirements uncertainty — missing, misinterpreted, or shifting stakeholder needs. The correct response is sharpening milestones before commitment, not compressing the schedule around them.

The distinction between T&M (Time and Materials) and milestone-based contracts is not cosmetic: T&M transfers schedule risk to the client; milestones transfer it to Delivery. Compressing T&M scope into a milestone structure without sharpening acceptance criteria turns a signed contract into a liability. The Delivery Director’s counter-proposal to Sales is not a refusal — it is a paid inception phase that sharpens milestones before risk transfers.

Code Snippet 2: DACI assignment template for SOW scope decisions. A single named Approver prevents Sales from committing on behalf of Delivery.

decision: sow_scope_approval
description: "Final sign-off on milestone structure and timeline before contract execution"

roles:
  driver: delivery_director
  approver: delivery_director
  contributors:
    - sales_lead
    - engagement_manager
    - client_cto
  informed:
    - account_executive
    - practice_lead

constraints:
  approver_veto: true            # Single approver; Sales cannot override  
  # Escalation ladder defined in AGENTS.md
  decision_deadline_days: 3

criteria:
  - milestones_are_specific_and_measurable
  - timeline_has_slack_for_ramp
  - acceptance_criteria_agreed_in_writingdelivery/daci-sow-template.yaml

How to Distinguish a Stakeholder Failure from a Delivery Failure?

When a client says “your team is bad,” that is a claim, not a diagnosis. Genuine delivery underperformance and a stakeholder engagement breakdown produce nearly identical surface symptoms. Treating them as the same problem leads to the wrong intervention.

How Do You Separate Perception from Delivery Record?

PMBOK stakeholder management provides the diagnostic frame: a high-power, low-trust client who is resistant to decisions and consistently critical of the team is a textbook stakeholder engagement failure (per PMBOK’s power/interest grid) until the objective delivery record proves otherwise. Separate the client’s perception from the sprint completion rate, defect density, and milestone adherence. If the team is delivering against agreed commitments, the problem is trust, not performance.

How Does Psychological Safety Aid Team Recovery?

When a lead engineer requests reassignment and multiple engineers are in open conflict, this is a psychological safety breakdown. Replacing the team validates the client’s framing and signals the pattern will recur. The correct response is the Delivery Director engaging directly to stabilize the relationship and create conditions for recovery.

When a Lead Engineer Requests Reassignment

A reassignment request from a lead engineer is a Type 1/Type 2 decision with team-wide visibility. Granting it immediately signals that opting out under pressure is acceptable; denying it without addressing the cause risks losing the engineer and worsening morale. The decision hinges on whether the engineer’s distress is rooted in the client relationship, recoverable with Delivery Director intervention, or in the team dynamic, requiring mediation first. Hold the reassignment open while the Delivery Director stabilizes the client relationship directly. Psychological safety reduces turnover intent: a meta-analysis of 136 studies found a negative correlation between psychological safety and turnover intent (Frazier et al., 2017).

When multiple engineers are at odds, the cause is rarely uniform. The diagnostic split: interpersonal conflict resolves with mediation and pairing rotation; technical disagreement resolves with an architectural decision record and a designated technical authority; structural conflict (competing priorities, unclear ownership) resolves with DACI. Applying the wrong intervention to the wrong cause extends the crisis.

The first direct Delivery Director-to-client conversation should follow a structured agenda:

1. Acknowledge the frustration without conceding the diagnosis.
2. Present the objective delivery record: sprint completions, defect density, milestone adherence.
3. Establish a direct cadence: weekly sync with the Delivery Director attending.
4. Name one concrete commitment with a short timeline, visible before the next sync.

How Does AI Tooling Shift the Staffing Reversibility Boundary?

A client requires a stack the available bench has not worked in directly. Traditionally, this is treated as Type 1: the wrong profile risks delivery failure and reputational exposure that cannot be undone mid-engagement.

How Does AI Tooling Reclassify Adjacent-Stack Decisions?

AI-augmented delivery changes this calculus. Engineers on an adjacent stack carry the mental models that matter: async concurrency patterns, component-based UI (User Interface) architecture, REST (Representational State Transfer) API design, client-side state management. The gap is syntax and ecosystem conventions, not architectural reasoning, and that is what agentic engineering addresses: code generation, documentation injection, and automated quality gates. Peng et al. (2023) found that developers completed an HTTP server implementation task 55.8% faster with GitHub Copilot.

When live framework documentation is injected into agent context, unfamiliarity with a specific library significantly reduces as a delivery constraint, narrowing the bottleneck to quality review — a role a senior engineer performs in any language. Zhou et al. (2023) found that injecting API documentation at inference time improved code generation on unseen APIs by 52% relative (CodeT5 pass@1); Chen et al. (2025) measured 83-220% pass-rate improvements on unfamiliar Python libraries with documentation injection. An internal Amazon pilot upgraded tens of thousands of production Java applications from Java 8 to Java 17 in two days. Manual effort would have required an estimated 4,500 developer-years (AWS, 2024).

Figure 1: Adjacent-stack bench mismatches route to Type 1 (specialist required) or Type 2 (augment with AI tooling) based on gap type and a quality gate.

How Do You Qualify the Boundary at Intake?

For adjacent stacks, bench mismatch is now a Type 2 decision when agentic tooling is available. The qualification step belongs at engagement intake: assess which engineers have the architectural mental models that transfer and confirm tooling access is in place before committing the profile to the client. One constraint applies uniformly: for tasks outside the confirmed AI capability frontier, Dell’Acqua et al. (2023) found the BCG (Boston Consulting Group) cohort using AI performed 19% worse than those without it. Map the frontier before staffing, not after.

Code Snippet 3: SKILL.md for delivery decision triage. The description is a neutral trigger condition; the Rules block prevents inference beyond provided intake data.

---
name: delivery-decision-triage
description: "Classifies staffing and scope decisions as Type 1 or Type 2. Use when evaluating an adjacent-stack deployment, a scope change, or a delivery risk at intake."
---

## When to use
- Evaluating whether to deploy an engineer on an adjacent stack
- Assessing whether to approve a scope or timeline change
- Triaging a delivery risk under time pressure

## Rules
- Use only intake data provided; do not infer missing context.
- Architectural gap (domain knowledge missing): Type 1, escalate to Delivery Director.
- Syntactic gap with active AI tooling: Type 2, require a written quality gate before committing.
- Tasks outside the confirmed AI capability frontier: Type 1 regardless of tooling.
- Classification ambiguous after intake: output "insufficient data" and list what is missing.skills/delivery-decision-triage.md

How Do the Four Frameworks Form a Single Decision Cadence?

The four frameworks operate at different levels and answer distinct questions. Treating them as alternatives produces analysis paralysis; used as complementary layers, they produce a coherent cadence.

The Four-Layer Stack

Table 4: Four-framework decision cadence — what each layer answers and when it fires.

What Operating Model Changes Prevent Delivery Failure Recurrence?

An AI operating model requires decision frameworks embedded at the pursuit stage, before any crisis arrives. Governance structures must be in place before the pressure that tests them.

All four failure modes share one structural root cause: decisions that should have been made upstream were deferred until pressure forced them.

Figure 2: Eisenhower sequences the queue, Type 1/Type 2 sets decision velocity, DACI assigns the Approver.

What Three Structural Changes Close the Gaps?

Three changes close those gaps:

• Establish DACI before pursuit. Document the Approver role for SOW structure at pursuit, agree an escalation ladder between Sales and Delivery, and communicate it to the client before contract execution.
• Protect Q2 capacity. Stakeholder investment, milestone sharpening, and team psychological safety are Q2 activities that Q1 crises crowd out; block Q2 time weekly.
• Qualify the AI capability frontier at intake. Map which tasks fall within AI range, classify which staffing decisions are Type 2, and flag which require a specialist match tooling cannot substitute.

Follow-On Sequence per Crisis Type

The operating model changes are structural; the follow-on sequence is tactical. The phases below reflect practitioner convention, not empirical prescription: timelines compress or extend based on client risk tolerance and relationship history.

Table 5: Follow-on sequence per crisis type (practitioner heuristic).

These frameworks do not eliminate hard conversations. They determine who has standing to have them, in what order, and with what authority. Most delivery failures trace to one deferred upstream decision: a DACI never written, a stakeholder relationship never invested in, a scope boundary never held (PMI, 2018). The delivery leader’s leverage is in Q2 work, not crisis response.

For a deeper look at how agentic tooling changes the architecture of delivery work itself, see Orchestrating AI Agents: A Practical Guide to Subagent Architecture.

References

• AWS, “Amazon Q Developer Just Reached a $260 Million Dollar Milestone” (2024) — https://aws.amazon.com/blogs/devops/amazon-q-developer-just-reached-a-260-million-dollar-milestone/
• Bezos, J., “2015 Letter to Shareholders” (2016) — https://s2.q4cdn.com/299287126/files/doc_financials/annual/2015-Letter-to-Shareholders.PDF
• Chen, Y. et al., “When LLMs Meet API Documentation” (2025) — https://arxiv.org/abs/2503.15231
• Covey, S.R., “The 7 Habits of Highly Effective People” (1989) — https://www.simonandschuster.com/books/The-7-Habits-of-Highly-Effective-People/Stephen-R-Covey/9781982137274
• Dell’Acqua, F. et al., “Navigating the Jagged Technological Frontier” (2023) — https://doi.org/10.1287/orsc.2025.21838
• Edmondson, A.C., “Psychological Safety and Learning Behavior in Work Teams” (1999) — https://doi.org/10.2307/2666999
• Frazier, M.L. et al., “Psychological Safety: A Meta-Analytic Review and Extension” (2017) — https://doi.org/10.1111/peps.12183
• Haleem, M. et al., “Cognitive Approach to Handle Requirements Uncertainty in Software Projects” (2021) — https://www.sciencedirect.com/science/article/pii/S2666307421000218
• Mitroff, I.I. & Alpaslan, M.C., “Preparing for Evil” (2003) — https://hbr.org/2003/04/preparing-for-evil
• Peng, S. et al., “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot” (2023) — https://doi.org/10.48550/arXiv.2302.06590
• PMI, “Pulse of the Profession” (2018) — https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2018.pdf
• Zhou, S. et al., “DocPrompting: Generating Code by Retrieving the Docs” (2023) — https://arxiv.org/abs/2207.05987