Architecting Human-AI Cocreation for Technical Services -- Interaction Modes and Contingency Factors

Frank Hannich; Jochen Wulf; Jurg Meierhofer

REVIEW 5 major objections 6 minor 2 references

Architecting Human-AI Cocreation for Technical Services -- Interaction Modes and Contingency Factors

T0 review · 5 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper claims that human-AI collaboration in technical services can be structured along a six-mode autonomy spectrum, from passive AI assistance to full automation, with mode choice driven by task complexity, risk, reliability, and…

desk verdict A genuinely useful design heuristic for human-AI collaboration, but the empirical case-study framing overstates what the vendor documentation actually supports. read the letter →

arxiv 2507.14034 v1 pith:6IS3W7MT submitted 2025-07-18 cs.HC

Jochen Wulf , Jurg Meierhofer , Frank Hannich This is my paper · ORCID

classification cs.HC

keywords human-AIcollaborationtechnicalserviceshuman-in-the-loopautonomyspectrumcontingencyfactorsagenticAIhuman-autonomyteaminghuman-agentinteraction

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tries to give technical service organizations a systematic way to decide how much control humans should keep over AI agents. It proposes a taxonomy of six interaction modes, spanning from passive AI assistance (Human-Augmented Mode) through mandatory human approval, built-in human steps, AI-initiated escalation, and discretionary supervision, to full automation (Human-Out-of-the-Loop). The authors argue that the right mode is not arbitrary but depends on four contingency factors: task complexity and novelty, safety and risk, system reliability and trust, and the human operator's workload and vigilance. If correct, managers and system designers gain a common vocabulary and a decision aid for trading off automation benefits against the risks of unreliable AI. The taxonomy is derived from comparing how Microsoft, Salesforce, and ServiceNow describe their technical service AI products.

What carries the argument

The carrying object is the six-mode taxonomy itself: HAM, HIC, HITP, HITL, HOTL, and HOOTL, defined along a spectrum of AI autonomy. Each mode is distinguished by two questions: who owns each activity, and what triggers human involvement, whether mandatory approval, a fixed workflow step, AI-initiated escalation, discretionary supervision, or nothing. The taxonomy is anchored to a standard service process framework and to four contingency factors, namely task complexity and novelty, safety and criticality, system reliability and trust, and human operator state, so that a mode is not just a label but a design configuration. The case analysis of vendor documentation provides the empirical instantiations, such as Salesforce Agentforce for HIC and ServiceNow virtual agents for HITL.

What would settle it

Observe a real Dynamics 365 Field Service predictive-maintenance deployment and check whether every work order is approved by a human before dispatch or whether supervisors monitor the queue. If any human approval or monitoring is required, the paper's HOOTL classification, and therefore the empirical anchor of the autonomy spectrum, is contradicted.

Watch

Extended reading notes

Core claim

The central claim is that every human-AI collaboration in technical services can be described by one of six interaction modes that form an autonomy spectrum. In HAM the AI only augments a human who does all work; in HIC the AI drafts solutions but a human must approve before anything is sent; in HITP the AI runs a workflow that stops at pre-engineered human steps; in HITL the AI operates until its confidence drops and then escalates to a human; in HOTL the AI runs end-to-end while a human supervisor may intervene at will; and in HOOTL the AI completes the whole process with no human involvement. The paper maps these modes onto the technical service process of receipt, diagnosis, solution, approval, communication, and closure, and links them to contingency factors that should drive selection. The proposed payoff is a reusable, technology-agnostic framework that turns the choice of human oversight level from an ad hoc decision into a structured design step.

Load-bearing premise

The load-bearing premise is that public vendor documentation from April to May 2025 accurately describes how these AI systems actually behave in deployed technical service settings, specifically that Dynamics 365 Field Service operates without human oversight.

Editorial extensions

If this is right

Technical service teams can map an existing or planned process onto the six modes and use the contingency factors to justify a specific oversight level before deployment.
The same six labels apply across vendors and platforms, giving design conversations a common vocabulary that does not depend on a particular product's terminology.
High-risk, safety-critical services will tend to stay in HIC or HAM, while low-risk, repetitive, well-understood tasks can move to HOTL or HOOTL when measured reliability is high.
The taxonomy gives evaluators a fixed set of configurations for comparing error rates, completion time, and operator satisfaction in empirical studies.
Organizations can use the framework to run structured risk assessments, connecting a chosen mode to task complexity and operational risk rather than relying on vendor promises.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

A testable extension is to treat the contingency factors as a decision rule and validate whether organizations that follow it achieve fewer failures than those that choose modes ad hoc.
The same six-mode structure could be applied outside technical services, including customer support, healthcare triage, and logistics, since the triggers that define the modes are domain-neutral; this extrapolation goes beyond what the paper argues.
If vendor materials overstate automation, real deployments may sit at a lower-autonomy mode than the classification suggests, and a deployment-level audit would reveal mismatches that could refine the taxonomy.
A natural next design step, which the paper names only as future research, is a dynamic mode that shifts between HITL and HOTL in real time based on confidence scores and operator workload.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

You should know this paper is better than its packaging. The six-mode taxonomy (HAM, HIC, HITP, HITL, HOTL, HOOTL) is a reasonable, clearly explained extension of van Zoelen's three Team Design Patterns, and the contingency-factor mapping (task complexity, risk, reliability, operator state) gives practitioners something they can actually use to think about oversight levels. The writing is clean, the figures are helpful, and the authors have done their homework on the prior literature. If you need a shared vocabulary for agentic AI in technical services, this is a decent candidate.

The soft spots are real but concentrated in the empirical claims, not in the framework itself. Section 3.2 says the data are public vendor pages, blogs, and white papers—that is not case-study research on deployed systems, and the paper overreaches when it says the taxonomy is "empirically derived." The HITP mode (Section 4.3) is explicitly labeled a "composite use case" built from platform capabilities, not an observed workflow. HOOTL (Section 4.6) is inferred from a Microsoft blog plus partner posts; no source sentence shows an end-to-end process running without any human review. The >95% reliability threshold appears in Section 5.1 with no citation. And the case count is inconsistent: three providers are selected in Section 3.2, but the conclusion says "four major technology providers." These are fixable problems, but they need to be fixed.

The reader's stress-test note is on target about the empirical derivation. However, I do not think this sinks the paper. The taxonomy is internally coherent, and its value does not depend on the vendor cases being perfect instantiations. The authors should reframe the contribution as a design heuristic grounded in prior theory and illustrated by vendor materials, not as a case-study-derived empirical finding. They should also add a coding protocol or at least a transparent table of which sources support each mode, and they should drop or properly source the reliability threshold.

For whom? IS researchers working on human-AI teaming, and practitioners who need a structured way to choose an oversight model. It deserves a serious referee, but not acceptance as-is. I would send it to review with a clear request for major revision focusing on honest framing of the evidence base.

Recommendation: engage with it, but push the authors to distinguish the analytical contribution from the illustrative cases.

Referee Report

5 major / 6 minor

Summary. The paper proposes a six-mode taxonomy (HAM, HIC, HITP, HITL, HOTL, HOOTL) for human-AI collaboration in technical services, ranging from passive AI assistance to full autonomy. It claims to derive these modes from comparative case studies of three (or four) enterprise platforms — Microsoft Dynamics 365, Salesforce, and ServiceNow — using public vendor documentation collected between April and May 2025. The authors map each mode to contingency factors such as task complexity, operational risk, system reliability, and human operator state, and argue that the result is a reusable, technology-agnostic framework for selecting and designing human oversight in technical service systems.

Significance. If treated as a design heuristic rather than an empirically validated classification, the paper is a useful synthesis: it connects prior team design patterns (van Zoelen et al.) to concrete architectural primitives, offers a common vocabulary for practitioners, and makes falsifiable design conjectures, such as reserving HOOTL for low-risk, high-reliability tasks. The strengths are the clear conceptual organization, the process-level framing, and the explicit linkage between oversight modes and contingency factors. However, the evidence base is thin: the modes are illustrated with vendor marketing materials, one mode is explicitly a composite use case, and the autonomy pole is asserted rather than documented. The paper's value would increase substantially if these limitations were stated honestly and the framework labeled as a design heuristic rather than an empirical derivation.

major comments (5)

[4.3 and 4.6] The claim that the taxonomy is 'empirically derived' (Section 1) is not supported by the evidence. Section 4.3 explicitly introduces HITP as a 'composite use case' and says it is 'exemplified by the potential of enterprise workflow platforms,' not by an observed deployment; the cited sources (Winklix, 2025; ServiceNow, 2025a) describe platform capabilities rather than a running workflow with a human dispatch-approval step. Similarly, Section 4.6 asserts that the Dynamics 365 Field Service process 'operates without human oversight' in the authors' own voice; the cited O'Quinn (2024) and partner blogs do not document the absence of human review in a real deployment. Because two of the six modes rest on constructed or inferred examples, the empirical grounding of the taxonomy is incomplete. I recommend either reframing the contribution as a design heuristic grounded in illustrative vendor capabilities or adding evidence from actual deployments.
[3.2] The evidence base consists entirely of official product pages, technical documentation, promotional videos, white papers, and corporate blogs. These are vendor-generated materials that may systematically overstate the autonomy of deployed systems, particularly regarding whether human oversight exists in practice. The paper does not discuss this bias or triangulate with independent sources, and Section 4.6 in particular relies on the absence of a documented human step as evidence for HOOTL. This is a load-bearing limitation for the central claim that the taxonomy describes real-world collaboration modes; it should be acknowledged and mitigated by framing the results as a synthesis of vendor capabilities rather than observed practice.
[3.3 and 6] The case count is inconsistent: Table 1 lists three platform providers (Microsoft, Salesforce, ServiceNow), but Section 3.3 states that coding and comparison were performed 'across the four cases,' and Section 6 repeats 'four major technology providers.' This discrepancy is not merely typographical; it affects the claimed basis for the cross-case analysis. The authors should state the exact number of cases and align Table 1, Section 3.3, and Section 6.
[5.1] The statement that 'True HOOTL automation requires exceptionally high system reliability (>95% accuracy)' is asserted without a citation, derivation, or operational definition. This numeric threshold is used to justify the HOOTL mode and is therefore load-bearing for the selection guidance. Either provide a source or empirical basis for the 95% figure, or remove the specific threshold and discuss reliability qualitatively.
[3.3 and 5.1] Because the six modes are induced from the same three cases used to illustrate them, the taxonomy is at risk of circularity: the contingency factors in Section 5.1 are inferred from the same vendor materials that exemplify the modes. The paper should acknowledge this limitation explicitly and, ideally, test the framework on at least one independent case—for example, a non-vendor deployment or a different platform—before claiming it is 'reusable' and 'technology-agnostic.'

minor comments (6)

[1 and 4.1] The terminology for the first mode is inconsistent: the Abstract and Section 1 use 'Human-Augmented Model,' while Section 4.1 headings use 'Human-Augmentation-Mode.' Choose one form and use it throughout.
[2.3] The reference to Hartikainen et al. contains corrupted HTML entities ('V&#228, &#228, n&#228, & Nen, K.') and should be corrected to the proper author names and title.
[4.2] The sentence 'The AI can produce summaries of the customer query and prior and surface relevant knowledge articles' is grammatically incomplete; it appears to omit a noun such as 'conversations' after 'prior.'
[3.2] The data collection period is stated as April–May 2025, but one cited source (D365 Community, 2025) is dated July 2025; please clarify whether the collection period extended beyond May or whether this reference was added during a later revision.
[Figures 1–6] The figures are helpful, but the captions do not indicate whether they are the authors' own conceptual diagrams or adapted from vendor materials; add an explicit note in each caption or in the text.
[5.1] The citation formatting in the sentence 'The HITL model (ServiceNow) (Roethof, 2025; ServiceNow, 2025b)' has duplicated parentheses; it should be cleaned up for readability.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the six-mode taxonomy is a qualitative classification built from public vendor material, with no fitted parameter, equation, or load-bearing self-citation that reduces the result to its inputs.

full rationale

Under the stated hard rules, circularity requires exhibiting a specific reduction, such as an equation equaling itself by construction, a fitted parameter renamed as a prediction, or a load-bearing argument that reduces to an unverified self-citation. This paper contains no equations, no fitted parameters, and no uniqueness theorem. The six modes are presented as an interpretive taxonomy developed by coding publicly available vendor material, and the same cases are later used to illustrate the modes. That is a standard limitation of qualitative case-study research, not a circular derivation. The only self-citation is Wulf and Winkler (2020), which supplies a generic process framework (receipt, diagnosis, solution formulation, approval, closure); it is not load-bearing because the taxonomy's content does not depend on that specific citation. The paper itself flags evidentiary weaknesses: Section 4.3 describes the HITP example as a 'composite use case' based on 'the potential' of ServiceNow rather than an observed deployment, and Section 4.6 asserts that Dynamics 365 Field Service operates 'without human oversight' largely in the authors' voice while citing a vendor blog. These are legitimate concerns about empirical grounding and vendor-source overstatement, but they are not circularity: the classification does not define its categories in terms of the cases, nor does it claim to predict a quantity that was used to fit a parameter. The taxonomy largely reorganizes existing concepts such as HITL, HOTL, and HAM and adds one intermediate mode, which is incremental classification rather than circular reasoning.

Assumptions & free parameters 1 free parameters · 4 assumptions · 1 invented entities

The central claim rests on interpretive classification of vendor documentation; there are no fitted parameters, but the HOOTL reliability threshold is a hand-selected number. The main axioms are domain assumptions about the accuracy of vendor materials and the validity of the chosen process framework. The invented entity is the six-mode taxonomy itself, which lacks external validation.

free parameters (1)

HOOTL reliability threshold = >95% accuracy
Introduced in Section 5.1 as a requirement for full automation; no source or empirical justification is given, making it a hand-selected design heuristic.

assumptions (4)

domain assumption Public vendor documentation and marketing materials accurately represent deployed system behavior.
Section 3.2 uses only public webpages, docs, videos, and blogs as data; Section 4.6 takes vendor-adjacent descriptions of Dynamics 365 Field Service as evidence of fully autonomous operation.
domain assumption The service process framework from Wulf and Winkler (2020) is a valid common basis for comparing all cases.
Section 4 maps every mode onto the same process framework (receipt, diagnosis, solution, approval, communication, closure) without justifying that this process is universal.
ad hoc to paper The six modes are mutually exclusive and jointly exhaustive for technical service interactions.
Sections 4 and 5 assert the taxonomy without a derivation; modes like HIC and HITP can overlap in practice, as both require a human approval step.
domain assumption The authors' single-coder thematic coding is reliable.
Section 3.3 describes iterative coding by the authors but reports no second coder, codebook, or inter-rater reliability check.

invented entities (1)

Six-mode taxonomy (HAM, HIC, HITP, HITL, HOTL, HOOTL)
purpose: Primary contribution: classify and select human-AI interaction modes in technical services.
The modes are conceptual categories induced from interpreting three vendor cases; the paper provides no falsifiable prediction or external benchmark to validate the taxonomy, so its existence is asserted rather than measured.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Architecting Human-AI Cocreation for Technical Services -- Interaction Modes and Contingency Factors." pith.science (2026). https://pith.science/paper/6IS3W7MT

@misc{pith2026250714034,
  author       = {Pith},
  title        = {Pith review of: Architecting Human-AI Cocreation for Technical Services -- Interaction Modes and Contingency Factors},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6IS3W7MT}},
  note         = {Machine review of arXiv:2507.14034}
}

read the original abstract

Agentic AI systems, powered by Large Language Models (LLMs), offer transformative potential for value co-creation in technical services. However, persistent challenges like hallucinations and operational brittleness limit their autonomous use, creating a critical need for robust frameworks to guide human-AI collaboration. Drawing on established Human-AI teaming research and analogies from fields like autonomous driving, this paper develops a structured taxonomy of human-agent interaction. Based on case study research within technical support platforms, we propose a six-mode taxonomy that organizes collaboration across a spectrum of AI autonomy. This spectrum is anchored by the Human-Out-of-the-Loop (HOOTL) model for full automation and the Human-Augmented Model (HAM) for passive AI assistance. Between these poles, the framework specifies four distinct intermediate structures. These include the Human-in-Command (HIC) model, where AI proposals re-quire mandatory human approval, and the Human-in-the-Process (HITP) model for structured work-flows with deterministic human tasks. The taxonomy further delineates the Human-in-the-Loop (HITL) model, which facilitates agent-initiated escalation upon uncertainty, and the Human-on-the-Loop (HOTL) model, which enables discretionary human oversight of an autonomous AI. The primary contribution of this work is a comprehensive framework that connects this taxonomy to key contingency factors -- such as task complexity, operational risk, and system reliability -- and their corresponding conceptual architectures. By providing a systematic method for selecting and designing an appropriate level of human oversight, our framework offers practitioners a crucial tool to navigate the trade-offs between automation and control, thereby fostering the development of safer, more effective, and context-aware technical service systems.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

2 extracted references · 1 canonical work pages

[1]

M., Bottoni, P., & Pareschi, R

Borghoff, U. M., Bottoni, P., & Pareschi, R. (2025). A System-Theoretical Multi-agent Approach to Human-Com- puter Interaction. In A. Quesada -Arencibia, M. Affenzeller, & R. Moreno -Díaz (Eds.), Computer Aided Systems Theory – EUROCAST 2024 (pp. 23–32). Springer Nature Switzerland. https://doi.org/10.1007/978 -3-031-82949- 9_3 Bowman, S. R., Hyun, J., Pe...

arXiv doi:10.48550/arxiv.2211.03540 2025
[532]

https://doi.org/10.2307/258557 Gartner, Inc. (2024). Magic Quadrant for CRM Customer Engagement Center (Technical Report No. 6006703). Gartner, Inc. https://www.gartner.com/en/documents/6006703 Gartner, Inc. (2025). Market Guide for Field Service Management (No. 6311147). Gartner, Inc. https://www.gart- ner.com/en/documents/6311147 Gil, M., Albert, M., Fo...

work page arXiv 2024

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.

[1] [1]

M., Bottoni, P., & Pareschi, R

Borghoff, U. M., Bottoni, P., & Pareschi, R. (2025). A System-Theoretical Multi-agent Approach to Human-Com- puter Interaction. In A. Quesada -Arencibia, M. Affenzeller, & R. Moreno -Díaz (Eds.), Computer Aided Systems Theory – EUROCAST 2024 (pp. 23–32). Springer Nature Switzerland. https://doi.org/10.1007/978 -3-031-82949- 9_3 Bowman, S. R., Hyun, J., Pe...

arXiv doi:10.48550/arxiv.2211.03540 2025

[2] [532]

https://doi.org/10.2307/258557 Gartner, Inc. (2024). Magic Quadrant for CRM Customer Engagement Center (Technical Report No. 6006703). Gartner, Inc. https://www.gartner.com/en/documents/6006703 Gartner, Inc. (2025). Market Guide for Field Service Management (No. 6311147). Gartner, Inc. https://www.gart- ner.com/en/documents/6311147 Gil, M., Albert, M., Fo...

work page arXiv 2024