Delegation Without Drift: Exception-Based Supervision in Human–AI Operations

Abstract

Delegating work to specialized human or AI workers does not by itself transfer responsibility for outcomes. A coordinator may route a task correctly while the task remains unowned after a blocker; a worker may report completion without evidence; and a manager may become a manual message bus by repeatedly reconstructing context and forwarding updates. This working paper examines a bounded, retrospective set of BOSS operating records available for an internal architecture review dated November 1, 2026. It asks how task ownership, tiered escalation, manager/worker roles, shared computer-use infrastructure, and evidence contracts can be described without overstating the observed system.

The evidence includes one isolated coordinator-to-headless-worker pass with a status report independently read back; one synthetic localhost browser-prefill pass in an isolated Chrome context; a real browser test stopped because browser tooling was unavailable; a preliminary systems diagnosis marked HOLD; two prepared employer-application review packets with no applications submitted; and a governance instruction assigning issue ownership and report-by-exception that was sent and read back. These records provide examples of bounded execution and explicit non-completion. They do not form a representative sample, controlled comparison, or longitudinal performance dataset. No production integration, autonomous repair, revenue, throughput gain, or successful external delivery is established.

We propose an exception-based supervision model in which a responsible owner remains attached to each task until a verifiable terminal state or explicit hold; the manager defines objectives and authority boundaries, then receives routine evidence-backed reports and escalations at decision thresholds. This model is a conceptual design, not a measured result. It is falsifiable through prospective evaluation of ownership continuity, unprompted exception reporting, evidence concordance, escalation accuracy, human intervention load, and consequential-action safety against a predeclared baseline. The paper is distinct from prior SignalRivet notes on governed completion, control planes, and deterministic architecture: its unit of analysis is the allocation of decision responsibility across a manager-worker boundary.

Keywords

Human–AI operations; delegation; task ownership; exception-based supervision; escalation; evidence contracts; computer use; internal architecture validation.

1. Question and scope

1.1 Research question

When a manager delegates work to specialized workers in an AI-assisted operation, what observable ownership and escalation rules could reduce routine manager-mediated handoffs while preserving human authority over high-consequence decisions?

The question concerns organizational responsibility, not whether a language model can complete arbitrary work. It asks who remains accountable for movement from an accepted task to a verified outcome or a clearly reported hold. “Exception-based supervision” means the manager does not need to relay every routine step, but receives a report when a decision, uncertainty, risk boundary, or failed dependency requires attention. The term does not mean unattended execution, unrestricted autonomy, or a presumption that workers can safely complete external actions.

1.2 Unit of analysis

The unit is a task episode at the handoff boundary: an objective is assigned to an owner, work proceeds or encounters a blocker, and a status is reported to a manager or record. We distinguish:

• Routing: a request reaches a proposed recipient or execution path.
• Acceptance: a named worker or service acknowledges responsibility within stated scope.
• Execution: a bounded action occurs.
• Evidence: an artifact, state readback, or observation supports a claim about execution or outcome.
• Escalation: a decision or hold is returned to an actor with authority to resolve it.
• Terminal state: the task is verified complete, explicitly held, rejected, or cancelled under an identified reason.

A conversational acknowledgement alone is not acceptance evidence; a process or port alone is not proof of a usable computer-use session; and preparation of an artifact is not execution of a consequential act.

1.3 Relationship to earlier notes

Research Note 001 discusses governed worker completion and machine-verifiable procedures. Note 002 frames orchestration and durable state as a control-plane concern. Note 003 studies AI at flexible edges and deterministic controls at the core. This note treats a related but separate question: how decision ownership is allocated among manager, coordinator, specialist, and human approver, and how that allocation is observed when a task stalls. It neither repeats the prior architecture argument nor claims that role labels alone solve coordination.

2. Method

2.1 Design

This is a retrospective descriptive case study for internal architecture validation. The source packet was the bounded set of internal events provided for editorial review on November 1, 2026. Events were selected because they illuminate different boundary conditions: a successful isolated route, a narrow synthetic computer-use interaction, unavailable tooling, unresolved diagnosis, preparation without external submission, and a governance instruction. They were not sampled randomly and were not selected under a preregistered protocol.

The analysis classifies each event by what it can support, what it cannot support, the decision boundary involved, and what an independent reviewer would need to inspect. We separate reported record facts from design interpretation. We do not infer rates, causal effects, or comparative performance from the event set.

2.2 Evidence handling

Internal event identifiers and row numbers were used in the source review but are not reproduced here. Sensitive system identifiers, private mailbox addresses, hostnames, local paths, personal details, account information, security configuration, and customer data are omitted. The records are represented at the minimum granularity needed to explain the operational distinction. “Independently read back” means the recorded status was retrieved after its write or delivery and checked against the intended report; it does not mean a third-party audit or independent replication.

The public references below are contextual prior art. They were reviewed to situate orchestration, observability, incident roles, and multi-agent coordination. They are not evidence about BOSS and were not used as a substitute for internal event records.

2.3 Analysis procedure

For each event, we applied five questions:

1. What task or instruction was in scope?
2. Which actor or path was responsible at the observed point?
3. What action or state was actually observed?
4. What evidence supports the reported state, and what independent readback exists?
5. What conclusions remain unsupported?

We then grouped the observations around ownership continuity, authority boundaries, shared computer-use capability, and evidence-bearing reports. Because only selected records were available, this is a structured interpretation rather than a comprehensive audit of every BOSS task.

3. Evidence matrix

The matrix intentionally records negative evidence. “No form modified,” “no application submitted,” and “HOLD” are outcomes relevant to the authority boundary, not missing successes to be filled in by interpretation.

4. Observations and interpretation

4.1 Observations

O1 — A bounded route can be evidenced without implying a system-wide capability. Case A has a defined path and a read-back report. Its evidential strength is local to that run. The case does not include a repeated series or evidence that another ingress route was involved.

O2 — Computer-use evidence is environment-specific. Case B shows a synthetic local interaction and snapshot check. Cases C and D show that the availability of a computer-use capability cannot be inferred from the existence of a listener or from success in a separate environment. Each environment needs its own current state evidence.

O3 — Preparation and execution are separable states. Case E records packet preparation and no external submission. Case C likewise stopped before any form modification. A status system that collapses “prepared,” “ready for review,” and “submitted” would misrepresent these records.

O4 — Governance instruction is observable separately from compliance. Case F verifies dispatch/readback of the order. The cited evidence does not report a subsequent repair or a series of worker-owned issues handled under the instruction.

O5 — The records include both positive and negative states. They document a narrow PASS alongside HOLD and explicit non-action. This mix allows a boundary discussion but does not provide denominators, a success rate, or a trend.

4.2 Interpretation

The records suggest that a “department” should be understood as a responsibility contract, not a persona label. A useful assignment should identify one accountable owner, bounded authority, expected evidence, escalation conditions, and a route for returning a final status. If any element is absent, a manager may be forced to reconstruct the task and forward each update manually.

The manager role should therefore be defined by decisions rather than message volume. Managers set goals, priorities, risk tolerances, and approval gates; reconcile cross-team conflicts; and act when an exception exceeds delegated authority. Workers and coordinators maintain task continuity within their scope, including reporting a block rather than silently abandoning it. This division does not make the manager uninvolved. It makes manager involvement conditional on information or authority that only the manager can provide.

“Report by exception” is only useful if routine states remain observable. A silent worker cannot be distinguished from a worker that has no exception unless there is a heartbeat, deadline, or terminal report contract. Conversely, reporting every intermediate event can recreate the message bus in a different interface. The design problem is to expose enough state to verify ownership and detect delay while reserving interruption for meaningful decisions.

5. Conceptual design: an ownership and evidence contract

We propose a task contract with six fields:

1. Objective: the outcome requested, phrased so that a reviewer can tell what would count as success.
2. Owner: one named role or worker accountable for the next action and continued status. Contributors may be multiple; accountable ownership remains singular at a time.
3. Scope and authority: permitted actions, environment, data limits, and explicit actions that require approval or are out of scope.
4. Evidence condition: the artifact or state readback that would support completion. Evidence must match the claim and identify its observation point.
5. Exception rule: conditions that require a hold or escalation, such as missing tools, ambiguous state, conflicting instructions, unavailable authority, external side effect, or a missed deadline.
6. Closure report: one of verified complete, held with reason and next decision, rejected/out of scope, or cancelled. It includes what changed, what did not, evidence references, and the next owner or decision when applicable.

A task may change owners, but the transfer should be explicit: outgoing owner records the current state and evidence; incoming owner accepts the next bounded action; the coordinator preserves correlation and history. If acceptance is absent, ownership is unresolved rather than implicitly transferred. For ambiguous external submission state, the task should be held as unknown and inspected before any retry.

5.1 Tiered escalation

The proposed tiers are conceptual and require validation:

• Tier 0 — Worker resolution: routine, reversible actions within the assigned scope; worker records evidence and closes the task.
• Tier 1 — Specialist decision: technical uncertainty or a dependency within a specialist's remit; specialist owns diagnosis and reports a bounded result or hold.
• Tier 2 — Manager coordination: cross-team priority conflict, resource allocation, unclear objective, or a dependency no single specialist controls.
• Tier 3 — Human approval: external, irreversible, financial, legal, privacy-sensitive, or otherwise high-consequence action; the authorized human reviews evidence and explicitly approves or declines.

The tiers do not presume that every task should climb a ladder. Escalation is triggered by the decision boundary, not by organizational prestige. A missing browser tool is a capability hold; it does not justify attempting another route against an account. A manager may clarify scope but cannot manufacture evidence that a step happened.

5.2 Shared computer-use infrastructure

Shared computer-use infrastructure creates a particular ownership challenge. A browser process, endpoint, or automation service may be available while the required tab, account, session, permission, or exact page is not. Capability claims should therefore include the current environment and scope: what browser context was used, which synthetic or approved target was in view, what action occurred, and what readback was observed. The manager needs the capability state and exception, not a stream of every keystroke. The worker must stop when the target or permission is uncertain.

This is a proposed evidence rule, not a claim that BOSS currently exposes a universal computer-use health contract or that the isolated synthetic test can be generalized to production.

6. Evaluation plan and falsifiable experiments

No experiment in this section has been conducted. The proposals are intended to make the design rejectable as well as confirmable.

Experiment 1 — Ownership continuity on blocked tasks

Question: Does an explicit owner field reduce tasks with no accepted next owner after a blocker? Design: Prospectively sample eligible, low-risk internal tasks over a fixed period. Compare a baseline group using the current documented process with a group using the six-field contract. Predefine inclusion rules and keep task classes comparable. Measures: proportion of blocked tasks with one recorded owner; time from block to accepted next action; number of manual manager forwarding actions; unresolved ownership at the end of the observation window. Falsifier: if explicit ownership does not reduce unresolved ownership or adds administrative burden without improving continuity, the contract needs revision. Controls: record task complexity, tool availability, and manager involvement; do not infer causality from raw before/after averages without accounting for task mix.

Experiment 2 — Exception-reporting reliability

Question: Can workers report material exceptions without routine manager prompting while still providing timely terminal status? Design: Define exception categories and deadlines before assignment. For each task, record time of exception occurrence, worker report, any manager prompt, and terminal state. Measures: unprompted exception reporting rate, time-to-report, false-negative exceptions found in later review, false-positive escalations, and overdue tasks without heartbeat or closure. Falsifier: frequent silent overdue tasks, or excessive false alarms that erase any reduction in routine updates, would reject the proposed threshold design.

Experiment 3 — Evidence-claim concordance

Question: Do closure reports accurately describe the observed state? Design: A reviewer blinded to the worker's status label compares a sample of claims with their referenced artifact or readback. Include complete, held, and not-started examples. Measures: agreement between claim and evidence; unsupported completion claims; evidence freshness; explicit distinction between preparation and external action. Falsifier: if reviewers cannot reliably reproduce status from the artifact, the evidence contract is too vague or the interface loses essential context.

Experiment 4 — Escalation calibration and authority safety

Question: Do the tiers route decisions to the right authority without encouraging unauthorized action? Design: Use tabletop scenarios first, then only approved low-risk tasks. Scenarios include unavailable tools, ambiguous submission state, conflicting instructions, and a requested external action. Have independent reviewers classify the correct escalation tier before comparing with worker behavior. Measures: correct tier, unauthorized attempts, unnecessary escalation, time to appropriate decision, and preservation of unknown states. Falsifier: any unauthorized consequential attempt is a safety failure; persistent misrouting or excessive escalation indicates the tier definitions are not operational.

Experiment 5 — Manager attention and service quality

Question: Does exception-based supervision reduce routine manager relaying without harming outcome quality? Design: Instrument manager prompts, forwards, review time, and decision time while evaluating a matched set of tasks under baseline and contract conditions. Establish a minimum quality and safety threshold in advance. Measures: manager minutes per task, number of routine forwards, completion/hold accuracy, missed deadlines, rework, and escalation latency. Falsifier: lower manager time accompanied by worse evidence quality, more missed exceptions, increased rework, or unsafe action is not an improvement. Any benefit must be assessed across both attention and outcome measures.

For all experiments, publish sample definitions, missing-data handling, task mix, and exclusions. Keep application, financial, customer-facing, or other high-consequence actions outside experimental automation unless separately authorized and reviewed. Do not treat absence of a report as success.

7. Limitations and threats to validity

Retrospective and selected evidence. The event set was chosen for explanatory value and may overrepresent memorable successes, holds, or edge cases. It cannot estimate normal performance or failure frequency.

Small, heterogeneous sample. The cases differ in route, environment, task, and consequence. They cannot be combined into a single pass rate or compared as if they were randomized trials.

Single organizational context. BOSS roles, tooling, and authority boundaries are specific to an evolving internal operation. Other teams may use different control structures, risk models, and interfaces.

Record-based observation. The analysis depends on the accuracy and completeness of internal records supplied for review. Independent readback verifies retrieval of a reported status in the described instance, not the truth of every underlying action or an external audit.

No longitudinal compliance data. The November 1 instruction was sent and read back, but sustained worker behavior under that instruction was not part of the evidence packet. Adoption and durability remain unknown.

No quantified business outcome. The records do not establish revenue, paid delivery, customer satisfaction, throughput improvement, cost savings, or increased autonomy. Operational clarity is a design objective, not a demonstrated commercial result.

Computer-use generalization is prohibited. A synthetic local interaction does not validate an actual portal, account, or production browser environment. Tool availability and permission are session-specific.

Confounding and learning effects. Workers and managers may improve because they know a process is observed. Task complexity, tool availability, and changing system versions may affect outcomes independently of the proposed contract.

8. Discussion

The central design claim is modest: delegation needs a visible owner and a verifiable closure path if a manager is to stop relaying routine work. The claim is plausible and testable, but the current records do not demonstrate its effect. A sent instruction is not adoption; a routed task is not accepted ownership; a PASS in one bounded route is not generalized capability; a prepared artifact is not external delivery.

Existing guidance provides useful context. Agent-building documentation describes handoffs, guardrails, and tracing as implementation concerns. Workflow frameworks distinguish sequential, concurrent, handoff, and manager-led patterns and can insert human approval. Incident-response practice emphasizes clear command, role definition, and an ongoing record. A published orchestrator-worker research system reports both the potential and coordination/evaluation costs of multi-agent work. These sources motivate design questions; their examples and measurements are not BOSS results and do not validate this proposal.

The manager-versus-worker distinction should not be conflated with human-versus-AI. A human specialist can own bounded execution; an AI coordinator can route within narrow authority; a human manager can approve a consequential action. Role and capability are separate axes. The contract should attach to the responsibility and evidence, not presume that a particular kind of actor is inherently reliable.

Likewise, exception-based reporting is not “less oversight.” It changes oversight from continuous conversational steering to explicit thresholds, deadlines, evidence checks, and escalation. Without these controls, silence can hide abandonment. With overly sensitive thresholds, every event becomes an interruption and the manager remains the bus. The design therefore has a calibration problem that must be measured on real, low-risk work before any claim of efficiency is justified.

9. Conclusion

This bounded internal review documents one isolated reported coordinator pass, a synthetic local browser interaction, several explicit holds or non-actions, and a governance instruction that was sent and read back. Together they show why an organization should distinguish routing, acceptance, execution, evidence, and approval. They do not show that BOSS has achieved autonomous operations or improved business outcomes.

We propose an ownership and evidence contract, tiered escalation, and prospective tests of continuity, exception reliability, evidence concordance, escalation safety, and manager attention. The proposal should be retained only if future observations show that routine ownership persists, material exceptions arrive on time, evidence supports closure claims, and high-consequence boundaries remain intact. Until then, “delegation without drift” is a design hypothesis and a research agenda.

References

1. SignalRivet. “Build Chronicle.” Chapters 01–07, August–September 2026. https://signalrivet.com/blog/ (public index; accessed November 1, 2026).
2. SignalRivet Research. “Research Notes.” Notes 001–003, September–October 2026. https://signalrivet.com/research/ (public index; accessed November 1, 2026).
3. SignalRivet Research. “Intelligence at the Edges, Determinism at the Core.” Research Note 003, October 2026. https://signalrivet.com/research/intelligence-at-the-edges-determinism-at-the-core/ (referenced as prior work; direct page retrieval was unavailable in this review).
4. OpenAI. “Building Agents.” Developer documentation. https://developers.openai.com/tracks/building-agents (accessed November 1, 2026).
5. OpenAI. “Integrations and Observability.” API documentation. https://developers.openai.com/api/docs/guides/agents/integrations-observability (accessed November 1, 2026).
6. Microsoft. “Workflow orchestrations.” Microsoft Agent Framework documentation, last updated August 25, 2026. https://learn.microsoft.com/en-us/agent-framework/workflows/orchestrations/ (accessed November 1, 2026).
7. Mace, J., Oertel, J., Thorne, S., Chakrabarti, A., Ma, J., and Yang, J. “Incident Response.” Google SRE Workbook, Chapter 9. https://sre.google/workbook/incident-response/ (accessed November 1, 2026).
8. Hadfield, J., Zhang, B., Lien, K., Scholz, F., Fox, J., et al. “How We Built Our Multi-Agent Research System.” Anthropic, June 13, 2025. https://www.anthropic.com/research/multi-agent-research-system (accessed November 1, 2026).

Version history

• 1.0 — November 1, 2026: Initial internal architecture validation draft. Retrospective evidence is bounded and selected; experiments are proposed, not conducted.

Suggested citation

SignalRivet Research / Fitzgerald, A. (2026). Delegation Without Drift: Exception-Based Supervision in Human–AI Operations (Technical Note 004, Version 1.0). Internal architecture validation; not peer reviewed.