The New Product Problem Isn't Autonomy. It's Supervision.

From Operating Instruments to Delegating Authority

Software has always been an instrument—and product excellence was fundamentally about friction reduction: fewer clicks, faster navigation, more efficient human execution. Under Clayton Christensen's classic Jobs-to-be-Done (JTBD) framework, customers "hired" products to make progress in a specific circumstance. A financial analyst hired a spreadsheet; an engineer hired an IDE; a sales leader hired a CRM.

flowchart TD
    subgraph Traditional["Traditional Software (Human-Operated Instrument)"]
        direction LR
        A1["Customer Need"] --> B1["User Operates Tool\n(Interaction Friction)"] --> C1["Deterministic Output"]
    end

    Traditional ~~~ Agentic

    subgraph Agentic["Agentic AI (Supervised Delegate)"]
        direction LR
        A2["Delegated Intent"] --> B2["Autonomous AI Delegate\n(Delegated Execution)"] --> C2["Proposed State Mutation"]
        D2["Supervision Plane\n(Verification Cost)"] -. Governs & Inspects .-> C2
        C2 --> E2["Accepted State Change"]
    end

    style Traditional fill:#FAF7F2,stroke:#CBD5E1,stroke-width:1px
    style Agentic fill:#FAF7F2,stroke:#1E293B,stroke-width:2px
    style B2 fill:#1E293B,stroke:#0F172A,color:#FFFFFF
    style D2 fill:#FEF3C7,stroke:#F59E0B,stroke-width:2px,color:#92400E
    style E2 fill:#ECFDF5,stroke:#10B981,stroke-width:2px,color:#065F46

Once software holds authority, a new product problem emerges:

How does the person responsible for the outcome supervise what the software is doing without having to redo the work themselves?

JTBD remains essential because it tells us what progress the customer wants. But agentic software requires a companion lens:

JTBD asks: What job is the customer hiring the product to do?
DTBS asks: What authority is the customer willing to delegate—and what evidence is required to supervise the result?

I call this companion product discipline Delegations-to-be-Supervised (DTBS).

The Core Thesis: Value as Accepted State Change

Much of the current AI product landscape optimizes for task generation. The more difficult product problem is delegated action.

The unit of value in agentic software is not task completion. It is safely accepted state change per unit of supervision.

Automation is not valuable simply because an AI generated code, drafted a memo, or planned a workflow. It is valuable only when the organization can safely accept the resulting state change without having to redo the work in order to trust it.

This exposes the fundamental economic disconnect in agentic AI:

Raw capability measures what an agent can attempt. Product value measures what an organization can safely commit.

An agent might possess the raw reasoning capability to refactor complex codebases, draft dozens of regulatory filings, or orchestrate multi-system workflows in seconds. But if the human supervisor must spend hours forensically auditing the output line-by-line to ensure it didn't violate critical business invariants, the product has delivered negative net productivity. The time saved on generation was entirely consumed by the cognitive friction of verification.

Therefore:

$$\text{Agent Capability} \neq \text{Product Value}$$

To measure the true economic benefit of an agentic product, product teams must evaluate Net Delegation Value:

$$\text{Net Delegation Value} = \text{Value of Accepted State Change} - \text{Supervision Cost} - \text{Expected Failure Cost}$$

Where:

$$\text{Supervision Cost} = f(\text{Verification Latency}, \text{Verification Burden}, \text{Approval Friction})$$

$$\text{Expected Failure Cost} = P(\text{Undetected Error}) \times \text{Blast Radius} \times \text{Remediation Multiplier}$$

1. Value of Accepted State Change: The operational value produced by state mutations (database commits, merged code, disbursed payments, approved claims) that are safely accepted into production.

2. Supervision Cost: The ongoing overhead paid to inspect work: elapsed human time (Verification Latency), cognitive load and domain expertise (Verification Burden), and workflow friction required to evaluate and authorize the proposed mutation.

3. Expected Failure Cost: The risk-adjusted liability of errors that slip past supervision into production. While traditional software fails deterministically, autonomous agents introduce non-deterministic tail risk. Because remediation (incident response, forensic audits, data restoration, legal compliance, and customer churn) is often $10\times$ to $100\times$ more expensive than manual execution, an agent with 99% accuracy can still destroy net economic value if its operational blast radius is unbounded.

The Supervision Tax: The Intrinsic Cost of Delegation

The Supervision Tax is the additional labor and cognitive effort required to safely accept an AI-generated action rather than performing the action directly.

When systems generate work without inspectable evidence, the product merely shifts human labor from execution to inspection:

$$\text{From: Doing the Work} \;\longrightarrow\; \text{To: Auditing the Work}$$

If the cost of supervision approaches or exceeds the cost of manual execution, the agent has not reduced labor—it has relocated it into a more stressful, error-prone auditing workflow.

Consider the economic reality of an uncalibrated enterprise workflow:

Deconstructing the Three Operating Models

1. The Authoring Baseline (Manual Execution: 45 Minutes)

When a credit underwriter manually reviews 80 pages of tax returns and drafts a memo in Excel, they build a continuous mental model of the company's financial health as they write. There is zero external auditing overhead because their own hands performed every calculation and verified every source number.

2. The Supervision Cliff (Naive Autonomous AI: 50.25 Minutes)

When an enterprise deploys an uncalibrated agent that simply outputs a finished 10-page document, it creates a net-negative workflow:

1. The Illusion of Speed: Generating the draft in 15 seconds creates the false perception of finished work in executive demos and benchmarks.
2. The Forensic Tax: Because the underwriter holds legal, regulatory, and fiduciary accountability for the loan, they cannot simply trust an opaque LLM. Without inspectable proof receipts, the officer must spend 50 minutes manually cross-examining footnotes against raw tax returns.
3. The Result: The product relocated human labor from authoring to forensic auditing—destroying 5.25 minutes of net value per loan file.

3. Verification Compression (DTBS Governed AI: 3.25 Minutes)

When product teams redesign this workflow around Delegations-to-be-Supervised (DTBS), they stop trying to make the model write faster and instead engineer the supervision surface across three capabilities:

1. Interactive Source Pinning: Every calculated debt ratio and adjusted EBITDA figure links directly to the exact bounding box in the source tax return PDF.
2. Deterministic Invariant Receipts: Pre-calculated policy compliance checks (e.g., Debt Service Coverage Ratio $> 1.25\times$) are validated by deterministic code assertions rather than probabilistic model text.
3. Escalation Highlighting: The UI explicitly surfaces the two ambiguous tax deductions requiring human credit judgment, rather than forcing the officer to hunt for them.

This compresses human verification from 50 minutes down to 3 minutes—transforming a $-\text{5 minute}$ value destroyer into a $+\text{42 minute}$ ($14\times$) net productivity gain.

Supervision $\neq$ Human Approval: Designing for Verification Leverage

The design goal is not to eliminate supervision. It is to make supervision fast enough that it imposes no meaningful delay on value delivery.

Good agentic systems minimize human approval by maximizing the quality of machine-verifiable evidence.

To evaluate verification efficiency, product teams should track Verification Leverage:

$$\text{Verification Leverage} = \frac{\text{Scope of Delegated State Changes Performed}}{\text{Surface Area of Evidence Required to Safely Accept It}}$$

The goal of Verification Leverage is not to hide evidence. It is to maximize the amount of delegated work that can be safely evaluated from a compact, high-signal evidence surface (e.g., deterministic invariant assertions, visual state diffs, and proof receipts).

Delegation is Not Binary: Three Dimensions of Authority

Delegation is not a binary switch ("is it autonomous or human-operated?"). In real-world software products, giving authority to software spans three distinct dimensions:

Supervision cost does not scale linearly. A system that is fully autonomous within a narrow, reversible boundary may require minimal oversight—but move all three dimensions toward their high-authority ends simultaneously and verification cost compounds exponentially.

The Governed Lifecycle: Bound → Detect → Verify → Recover

To make delegation safe and scalable, agentic systems should be structured as a closed-loop control system:

graph TD
    A[1. BOUND: Define Authority, Policies & Invariants] --> B[2. DETECT: Monitor Evidence Freshness, Permissions & Drift]
    B --> C{Safe to Proceed?}
    C -- Yes (Low Consequence / Invariants Validated) --> D[Staged / Isolated Execution]
    C -- No (Uncertainty / High Blast Radius / Policy Gate) --> E[3. VERIFY: Present Structured Evidence & State Diffs]
    E --> F{Supervisor Approves?}
    F -- Yes --> D
    F -- No --> G[Revise, Reject, or Escalate]
    D --> H[4. RECOVER: Commit, Compensate, or Roll Back]
    H -. Telemetry & Policy Learning .-> B
    H -. Reversibility Dictates Limits .-> A
    style A fill:#1B1917,stroke:#E65100,stroke-width:2px,color:#fff
    style B fill:#1B1917,stroke:#FBC02D,stroke-width:2px,color:#fff
    style E fill:#1B1917,stroke:#2E7D32,stroke-width:2px,color:#fff
    style H fill:#1B1917,stroke:#1565C0,stroke-width:2px,color:#fff

1. Bound: Define Authority Before Execution

Establish non-negotiable policy constraints before the agent touches production systems:

1. Authority Ceilings: Restrict mutation scope before runtime (e.g., "Can draft refunds up to \$200; cannot disburse funds").
2. Pre-Condition Invariants: Enforce deterministic rules that must evaluate to True before execution is permitted to begin.

2. Detect: Monitor Changing Conditions and Drift

Do not rely on self-reported model confidence. Continuously monitor telemetry in real time:

1. Detect Drift: Trigger alerts when assumptions, evidence freshness, credentials, or environmental conditions decay during execution.
2. Calibrated Friction: Ensure safe, reversible actions proceed smoothly while ambiguous actions trigger an explicit checkpoint.

3. Verify: The Escalation Test

When an agent pauses for human review, the system must not surface raw execution logs or opaque text dumps. It must pass The Escalation Test by answering three questions in under three seconds:

1. What was attempted?
2. Why did it stop?
3. What specific decision is required to proceed?

4. Recover: Reversibility as a Precondition for Delegation

Recoverability is not merely an afterthought—it is an upfront precondition for granting authority.

The Golden Rule of Delegation Authority:
The less reversible an action is, the less authority should be delegated without deterministic verification.

1. Staged Sandboxes: Execute mutations in preview or transactional sandboxes before permanent commits.
2. Compensating Actions: Provide tested, reliable rollback mechanisms for multi-system side effects.

Product Strategy: DTBS Meets the Architecture of Proof

To build defensible enterprise systems, product managers must connect the product-management layer to the systems-engineering layer:

DTBS is the product-management layer: It determines what authority users are willing to delegate and what evidence a supervisor needs to safely accept the result.
The Architecture of Proof is the systems-design layer: It provides the concrete technical infrastructure that makes supervision fast, legible, and reliable.

A Note on "Proof":
In agentic systems, "proof" does not mean formal mathematical certainty. It means inspectable, verifiable operational evidence that connects an action to its authority, inputs, policies, assumptions, and observed effects.

Implementation Reality: What Teams Can and Cannot Do Today

The recommendations in this framework are not uniformly achievable at the same cost or timeline. Each design principle differs in implementation maturity, technical complexity, and organizational prerequisite. This section maps each recommendation to what is deployable now, what requires investment, and what remains genuinely difficult.

1. Net Delegation Value: Directional Framework Today, Actuarial Over Time

The formula Expected Failure Cost = P(Undetected Error) × Blast Radius × Remediation Multiplier requires probability data that most teams deploying novel agentic workflows don't yet have. This is not a reason to abandon the framework—it is a reason to use it as a design pressure test rather than a precise KPI.

What is being done today: Financial institutions already operate risk-adjusted return frameworks that incorporate probability-weighted failure costs. JPMorgan Chase's model risk governance teams require formal Expected Loss calculations—including remediation cost estimates—before any automated credit decisioning system is promoted from pilot to production. Palantir requires blast-radius impact assessments as part of its deployment gate process for autonomous data operations. For teams without that institutional maturity, qualitative estimation still changes decisions: "If this agent is wrong 1% of the time and each remediation takes 4 hours at 100 autonomous decisions per day, that's 4 hours of incident response daily before we've shipped a single feature."

What remains hard: Precise P(failure) estimates for tasks the model has never performed in production require instrumented pilots—you cannot estimate what you haven't measured. The right posture is a phased authority expansion: start with human-in-the-loop for all decisions, instrument failure rates, then use that telemetry to calibrate autonomous authority thresholds.

2. Interactive Source Pinning: Practical and Available Now

Of all the DTBS design capabilities, this is the most immediately implementable and the most frequently skipped.

What is being done today: AWS Textract, Azure Form Recognizer, and Google Document AI all return bounding-box coordinates for every extracted field as part of their standard API response. Legal AI platforms Harvey and Klarity surface citation-level provenance—every AI-generated claim links to the specific clause in the source document—as a core product feature. Glean's enterprise search links every AI-generated answer to the specific source chunk it drew from. These products exist in production at enterprise scale.

Where it breaks down: Bounding-box extraction degrades significantly on dense unstructured prose—heavily negotiated contract footnotes, clinical narrative notes, multi-column exhibit tables in annual reports, or free-form correspondence. In these contexts, AI citation accuracy depends on retrieval chunking quality, not raw extraction, and confidence degrades with document complexity.

The implementation gap is organizational, not technical: Most enterprise AI vendors generate answers without surfacing source coordinates in the UI. The capability exists in the underlying APIs; product teams simply don't specify it as a launch requirement. Treating source linkage as a P0 launch requirement—not a P3 enhancement—is the organizational shift this requires.

3. Deterministic Invariant Receipts: Correct for Rule-Based Domains; Does Not Replace Judgment

What is being done today: Open Policy Agent (OPA) is already used by Airbnb, Netflix, and Goldman Sachs to enforce deterministic policy rules before mutations commit. Stripe Radar enforces transaction risk rules deterministically before payment execution. In regulated lending, DSCR thresholds, LTV ceilings, and regulatory capital requirements are enforced by deterministic policy engines at most major banks—AI-generated credit memos must clear these invariant gates before reaching credit committee review. This pattern is not experimental; it is established infrastructure in production at regulated institutions.

Where it works without qualification: Any domain with well-defined numeric or categorical thresholds: credit underwriting ratios, pharmaceutical dosing weight-adjusted limits, financial transaction authorization amounts, regulatory reporting field formats, data retention policy violations.

Where it breaks down: Judgment-intensive decisions resist reduction to boolean assertions. "Is this vendor contract commercially favorable?" cannot be encoded as an invariant. DTBS does not claim that invariants replace human judgment. It argues that the verifiable subset of business rules should be handled deterministically, shrinking the judgment surface to only what genuinely requires expert human assessment. Ambiguity about where judgment ends should not become an excuse to skip encoding the rules that can be encoded—which, in most enterprise workflows, is more than teams assume.

4. The Escalation Test: Fully Achievable Today—It Is a Product Design Specification

The Escalation Test is not a technical constraint. It is a product design standard that requires no new infrastructure—only deliberate design intent.

What is being done today: Linear's AI blocker surface presents structured decision prompts with explicit context rather than raw status messages. Intercom's Fin AI constructs a pre-composed context summary for the human agent at every handoff, so the receiving agent does not need to re-read the conversation. GitHub Copilot Workspace presents an editable, reviewable plan before executing any code changes. These are partial, incomplete implementations of the Escalation Test—they answer one or two of the three questions rather than all three—but the pattern is validated at scale in production.

What most teams get wrong: Agentic workflows are wired to expose raw model output—chain-of-thought logs, verbose tool traces, JSON dumps—as the escalation surface. A supervisor receiving a 3,000-token agent trace is not receiving a supervision interface; they are receiving relocated labor. This is the Supervision Cliff problem manifested in the UI layer.

The right posture: Define the escalation template before writing the first line of agent code. What was attempted? Why did it stop? What specific decision is required to proceed? These are product requirements, not engineering afterthoughts. If the escalation UX cannot answer all three questions in under three seconds, the system is not ready for autonomous deployment.

5. Staged Sandboxes and Compensating Actions: Immediate for Cloud-Native Systems; Costly for Legacy Infrastructure

What is being done today: Stripe's test mode, Salesforce sandbox environments, Terraform's plan stage before apply, and database transaction rollback already implement the staged sandbox pattern in wide production use. Temporal.io and AWS Step Functions provide durable, fault-tolerant execution frameworks with built-in compensating transaction support. Kubernetes blue-green and canary deployment patterns implement staged commit for infrastructure mutations. These are mature, well-documented patterns with extensive tooling support.

Where it gets hard: Legacy enterprise systems—mainframe-backed payroll systems, on-premise ERP without API-level rollback, and bespoke databases without transactional semantics—cannot be wrapped in compensating transactions without significant custom engineering effort. There is no off-the-shelf solution for adding staged sandboxes to a 30-year-old COBOL billing system.

The honest limitation: This recommendation is immediately practical for any organization running on cloud-native infrastructure or modern SaaS APIs. For enterprise customers operating on-premise legacy systems, staged sandboxes are a medium-term architectural investment, not a quick win. Product teams should scope rollback surface coverage explicitly during technical discovery—before committing to autonomous execution authority over systems that cannot support it.

6. Authority Ceilings: The Highest-Return, Lowest-Effort Recommendation

Authority ceilings are simultaneously the most mature pattern in enterprise software and the most frequently skipped step when teams ship agentic products.

What is being done today: AWS IAM role scoping, OAuth 2.0 permission scopes, database row-level security, and Stripe restricted API keys have implemented authority ceilings at the infrastructure layer for decades. For AI-specific contexts, Anthropic's tool-use approval flows, OpenAI's function calling with schema-validated parameters, and LangChain's tool permissions implement runtime authority ceilings in production today. These are available at zero incremental cost to any team using these platforms.

What most teams skip: Teams define capability—what the agent can technically do—but not authority—what it is actually permitted to do in production, at what scale, and under what conditions. A model technically capable of sending emails should not be provisioned with production email-send credentials covering a $10M customer list on its first deployment. Capability and authority are distinct concepts; conflating them is the most common source of early-stage agentic deployment failures.

Implementation is immediate: Every team shipping an agentic product today can define and enforce authority ceilings before launch using infrastructure that already exists in their stack. This is the single recommendation with the best ratio of impact to implementation effort.

7. Verification Leverage: Design-Time North Star, Not a Runtime Dashboard Metric

$$\text{Verification Leverage} = \frac{\text{Scope of Delegated State Changes Performed}}{\text{Surface Area of Evidence Required to Safely Accept It}}$$

The denominator—surface area of evidence—is qualitative by nature and is not directly instrumentable the way latency or error rate is. This is intentional: the ratio is a design-time pressure test, not an operational KPI.

What teams measure today: Verification latency (time from agent task completion to human approval), approval rates, and escalation frequency are all proxy metrics already tracked in production at Intercom (human handoff rate), Salesforce (AI recommendation accept rate), and Linear (blocker resolution time). These are the runtime equivalents of Verification Leverage, and they are instrumentable from day one.

The right posture: Use Verification Leverage when designing a delegation boundary—"If we extend the agent's authority to cover these 12 actions, by how much does the evidence surface grow? Can a supervisor still evaluate the composite output in under 5 minutes?" Then use proxy metrics in production dashboards to detect when Verification Leverage is degrading in practice.

Practical Implementation Sequencing

These recommendations do not carry equal implementation cost and should not be treated as a uniform checklist.

The Strategic Imperative: The Assurance Moat

In high-consequence enterprise markets (financial services, healthcare, enterprise infrastructure, and legal workflows), raw reasoning capability is already commoditizing.

flowchart TD
    subgraph Moat["THE ASSURANCE MOAT (Enterprise Control Plane)"]
        L1["Layer 1: Supervision & Review Plane\n(Ergonomic Handoffs · Verification Telemetry · Audit Logs)"]
        L2["Layer 2: Calibrated Friction & Escalation Gates\n(Dynamic Risk Governors · Blast Radius Gates · Drift Detection)"]
        L3["Layer 3: Deterministic Verification & Proof Receipts\n(Invariant Assertion Gates · State Diffs · Registry Resolution)"]
        L4["Layer 4: State Isolation & Atomic Rollback Engines\n(Ephemeral Preview Sandboxes · Transactional Rollback)"]
        L1 --> L2 --> L3 --> L4
    end

    Foundation["Interchangeable Foundation Models & Agent Swarms\n(Commoditized Reasoning & Token Generation)"]
    Trust["▲ Built on Accumulated Domain Trust, Calibrated Policies & Operational Telemetry"]

    Foundation --> Trust --> Moat

    style Moat fill:#FAF7F2,stroke:#1E293B,stroke-width:2px
    style L1 fill:#FFFFFF,stroke:#CBD5E1,stroke-width:1px
    style L2 fill:#FFFFFF,stroke:#CBD5E1,stroke-width:1px
    style L3 fill:#FFFFFF,stroke:#CBD5E1,stroke-width:1px
    style L4 fill:#FFFFFF,stroke:#CBD5E1,stroke-width:1px
    style Trust fill:#FEF3C7,stroke:#F59E0B,stroke-width:2px,color:#92400E
    style Foundation fill:#1E293B,stroke:#0F172A,stroke-width:2px,color:#FFFFFF

The durable advantage in enterprise AI is not the mere existence of an approval screen or an audit log. The moat is the accumulation of domain-specific evidence, calibrated policy thresholds, operational failure history, proven recovery paths, and the institutional trust earned through repeated, safe delegation.

Synthesis

JTBD explains the progress a customer wants.

DTBS explains what authority the customer is willing to delegate, what evidence is required to supervise that authority, and what happens when the system is wrong.

The winning agentic products will not necessarily be the ones that perform the most work autonomously.

They will be the ones that create the most valuable state change with the least supervision burden—while keeping the consequences of failure bounded and recoverable.

When software becomes a delegate, product management becomes the design of accountable delegation.