Human-AI Teaming Framework

• Human-AI Teaming Framework is a structured approach that integrates human oversight with AI autonomy through defined interaction modes and workflows.
• It employs contingency factors like task complexity, operational risk, system reliability, and human state to dynamically select the optimal team mode.
• The framework formalizes escalation and allocation policies using mathematical decision models to ensure safe, adaptive deployment in diverse operational settings.

A Human-AI Teaming Framework defines the structured principles, taxonomies, architectures, and mathematical decision policies that support collaborative, safe, and effective integration of humans and autonomous agents in complex task environments. Such frameworks are motivated by the operational brittleness of current autonomous systems, the persistent challenge of hallucinations, and the need to balance efficiency gains from automation with safety, quality, and trust through calibrated human oversight (Wulf et al., 18 Jul 2025).

1. Taxonomy of Human-AI Interaction Modes

Human-AI teaming is organized along an “autonomy spectrum” encompassing six canonical modes, each defined by autonomy level, locus of control, and workflow structure. Each mode is framed by two axes: who executes each process step, and the degree of AI independence. All modes share a five-stage workflow: (1) Receive & Understand, (2) Data/Gather/Diagnose, (3) Formulate Solution, (4) Review & Approve, (5) Communicate & Close (Wulf et al., 18 Jul 2025).

Mode	Autonomy Level	Human Role / AI Role	Architecture/Workflow Summary
Human-Augmented Model (HAM)	0–10%	Human leads; AI as passive assistant	Human executes all steps; AI offers suggestions (summaries/drafts)
Human-in-Command (HIC)	~30%	Human is validator/decision-maker	AI drafts up to step 3; human must approve at gate; then closure
Human-in-the-Process (HITP)	~50%	Human as operator at deterministic step	AI automates multi-step; process halts at predefined human intervention
Human-in-the-Loop (HITL)	60–80%	Human handles exceptions	AI processes all steps; low-confidence triggers escalation to human
Human-on-the-Loop (HOTL)	90%+	Human supervisor, discretionary intervene	AI runs end-to-end; human can seize control (dashboard/monitor only)
Human-Out-of-the-Loop (HOOTL)	100%	None in routine ops	AI operates autonomously; humans only update models offline/reviews

Block-diagram representations formalize these structures, showing approval gates or confidence checks at critical junctures.

2. Contingency Factors Governing Mode Selection

Appropriate matching of interaction mode to context is mediated by four central contingency factors (Wulf et al., 18 Jul 2025):

• Task Complexity & Novelty: HOOTL/HOTL for repetitive, low-complexity; HITL/HOTL for moderate; HIC/HAM for high-novelty.
• Operational Risk & Criticality: HIC for high-risk zero-tolerance; HITL/HOTL for medium; HOOTL for low-risk.
• System Reliability & Trust: HOOTL/HOTL if >95% accuracy; HITL/HITP for moderate trust; HIC/HAM for low trust.
• Human Operator State: HITL for high-volume with rare exceptions; HOTL for supervisory preference; HIC for full human review capacity; HOOTL for desire to eliminate human workload.

These factors directly inform the architectural choice. For example, a high-risk, moderately reliable system suggests a HITL or HIC design.

3. Formal and Semi-Formal Escalation and Allocation Policies

The framework formalizes handoff and escalation mechanisms to rigorously govern AI autonomy.

• Confidence-Based Escalation (HITL): Given a model confidence score $C \in [0,1]$ and threshold $\theta$, delegate as:

$$\text{Outcome}(C) = \begin{cases} \text{AI\_Complete}, & C \ge \theta \ \text{Human\_Handle}, & C < \theta \end{cases}$$

For example, in ServiceNow Virtual Agent, a confidence threshold of ~60% routes low-confidence queries to a human (Wulf et al., 18 Jul 2025).

• Risk-Reliability Rule (HOOTL): If normalized risk $R \leq R_{\mathrm{max, HOOTL}}$ and reliability $r \geq r_{\mathrm{HOOTL}}$, then select full automation:

$$\text{Select HOOTL if}\quad r \ge r_{\mathrm{HOOTL}},\quad R \le R_{\mathrm{max, HOOTL}}$$

• Mode-Selection Utility Function:

$$U_i = w_c f_{\rm complexity} + w_r (1-R) + w_t\,r + w_o f_{\rm operator}$$

Choose the mode $i$ with maximal $U_i$ under domain constraints.

These policies operationalize oversight as a function of real system state, not simply pre-set configuration.

4. System Architectures and Workflow Realizations

Practitioner architectures are derived directly from the interaction taxonomy, each with documented examples and UI/block structure:

• HAM: Microsoft Dynamics 365 Copilot’s “Ask a question” or “Draft a Chat Response”; AI as context suggester requiring human review.
• HIC: Salesforce Agentforce “Service Replies”; AI drafts, human must “Approve & Send.”
• HITP: ServiceNow — automated incident handling paused for human approval before dispatch.
• HITL/HOTL/HOOTL: Designs center on escalation gates, confidence triggers, dashboards, or removal of human path entirely, with examples from Salesforce, Dynamics 365 Field Service (Wulf et al., 18 Jul 2025).

5. Implementation Guidelines and Dynamic Monitoring

The framework recommends a cyclical practitioner approach for ongoing mode selection and dynamic adaptation:

1. Characterize Task: Assess complexity, risk, skills, volume.
2. Evaluate AI: Quantify reliability, trust profiles.
3. Match Mode: Map to taxonomy using contingency logic.
4. Design Architecture: Implement necessary block diagrams and interfaces (approval, dashboards, thresholds, etc).
5. Monitor & Iterate: Continuously collect error, cycle time, workload, and satisfaction metrics. Adjust modes, thresholds, and risk bounds as system performance/requirements evolve (Wulf et al., 18 Jul 2025).

This recursive evaluation enables responsive shift between, for example, HITL and HOTL as operator workload or system reliability changes.

6. Role in Developing Safer and Context-Aware Technical Service Systems

By connecting explicit interaction modes to task- and system-driven contingency rules, and by providing mathematical, architectural, and workflow-level selectors, the framework serves as a practical, theoretically grounded decision-support tool for balancing automation and control. Its core contribution is to supply practitioners and researchers with:

• A systematic shared vocabulary and formalism for designing and auditing Human-AI teams;
• Decision logic to select the minimal human oversight warranted by task and system properties;
• Architectural blueprints grounded in case studies and widely deployed platforms.

The result is a coherent structure for achieving safer, more effective, and context-aware technical service deployments, with explicit means for dynamic adaptation as system competence and operational requirements shift (Wulf et al., 18 Jul 2025).