Skip to content
#small language model Open access

When to Escalate: A Cost-Aware Belief Policy for Conversational Agents Under Hidden Intent

Sep 2026 · Zenodo (CERN European Organization for Nuclear Research)

Abstract

A conversational agent replying to inbound sales leads must choose an action before it knows the lead’s intent. It can answer, ask a qualifying question, hold, or escalate to a human, but the true buying-readiness and whether a human is actually needed are hidden. The two ways of being wrong are not equally costly. A missed escalation, where a lead who needed a person did not get one, is far more expensive than a needless one, and some wrong answers are not a cost to trade off at all but a line the agent must not cross. We build a small agent that makes this trade-off explicit. It holds a belief over the hidden state, split into readiness (hot, warm, cold) and a separate probability that the case needs a human, and at each message it picks the action with the lowest expected cost under a cost matrix that encodes the asymmetry. Escalation is split into notify, where a human is told while the conversation continues, and pause, where the agent stops, because the two carry different costs. The hardest wrong answers, such as false legal or land claims, are enforced as a hard constraint rather than a priced term. We test on 100 synthetic cases with cached language-model beliefs, comparing the cost-aware policy against the same policy with a uniform cost matrix and against three fixed-action baselines. Two of those baselines give opposite answers, so both are named wherever the cost result appears. Against the uniform-cost version of the same rule — same belief, same feasible set, only the asymmetry removed — the cost-aware policy reaches 1.72 against 2.58 over all 100 cases, a reduction of a third; that gap is what cost-awareness buys, and it is against that baseline and no other. Against always-notify, which escalates every message, there is no cost win: 1.72 against 1.74 over the same 100 cases is a near-tie, a total of 172 against 174, so the cost-aware policy is not the cheaper policy and is not claimed to be. What it buys there is human load rather than cost — over all 100 cases it reaches the same cost while escalating 43 times rather than 100, at an escalation precision of 0.605 against 0.420. The uniform-baseline gap is also not all machinery: that baseline selects the same action as a plain 0.5 threshold on all 100 cases, and reweighting the case set toward the design’s own readiness prior moves the gap from 0.86 to 1.07 rather than closing it, so the direction is robust to reweighting even as the magnitude shifts. Every missed escalation traces to one cause: the belief under-estimated the needs-human probability rather than misreading readiness. Expected calibration error on that marginal is 0.142 (bootstrap 95% CI [0.100, 0.249]), concentrated in the bins adjacent to the escalation threshold rather than the bin containing it; recalibrating that marginal on the same 100 cases is an in-sample ceiling, and the body reports it as one. Held out, the result is different in kind. Re-eliciting bh from the model’s digit logprobs, fitting a map on 50 development cases and scoring the other 50, improves all three calibration measures named in advance — on those 50 test cases expected calibration error falls from 0.1526 to 0.0696, cross-entropy from 0.8546 to 0.8136 bits, and Brier from 0.2063 to 0.1962. Better calibration does not buy a better decision. The fitted map is isotonic, and the lowest block it pools sets a reachable-score floor of 6/23 ≈ 0.2609, above the 3/13 ≈ 0.2308 a belief must fall below for answering to be cheapest, so the threshold sits inside an interval the map cannot emit: on those same 50 cases the policy stops choosing answer at all, escalation precision falls from 0.667 to 0.463, and recall rises from 0.667 to 0.905. The cause is the map’s range rather than the scores it produced, and a calibration-quality gain that the range prevents from becoming a decision gain is the finding. We also report a failure the test set cannot produce by construction, a high-cost message dropped when it arrived batched with a routine one, observed in a live run. Code and data are available.

View source

Similar papers

#computer vision Open access Jun 2016

Software Development in Startup Companies: The Greenfield Startup Model

The results are packaged in the Greenfield Startup Model (GSM), which explains the priority of startups to release the product as quickly as possible, and the need to shorten time-to-market, by speeding up the development through low-precision engineering activities.

Carmine Giardino, Nicolò Paternoster, M. Unterkalmsteiner et al. · 178 citations · ⚡14
#computer vision Open access Oct 2016

Software Startups - A Research Agenda

Software startup companies develop innovative, software-intensive products within limited timeframes and with few resources, searching for sustainable and scalable business models.

M. Unterkalmsteiner, P. Abrahamsson, Xiaofeng Wang et al. · 157 citations · ⚡17
#machine learning Review Open access Oct 2016

“Failures” to be celebrated: an analysis of major pivots of software startups

This study conducts a case survey study based on the secondary data of the major pivots happened in 49 software startups, and demonstrates that customer need pivot is the most common among all pivot types.

Sohaib Shahid Bajwa, Xiaofeng Wang, Anh Nguyen-Duc et al. · 127 citations · ⚡15
#computer vision Review Open access May 2015

A survey study on major technical barriers affecting the decision to adopt cloud services

The comparison of adopter and non-adopter sample reveals three potential adoption inhibitor, security, data privacy, and portability, which underlines the importance of the technical and security perspectives for research investigating the adoption of technology.

Nattakarn Phaphoom, Xiaofeng Wang, S. Samuel et al. · 111 citations · ⚡8
#computer vision Open access Feb 2018

Lean Internal Startups for Software Product Innovation in Large Companies: Enablers and Inhibitors

This study investigates how Lean internal startup facilitates software product innovation in large companies and identifies its enablers and inhibitors, and shows the potential of the method-in-action framework to investigate the Lean startup approach in non-startup context.

Henry Edison, Nina M. Smørsgård, Xiaofeng Wang et al. · 78 citations · ⚡6
#computer vision Conference Sep 2010

Exploring the Sources of Waste in Kanban Software Development Projects

The application of agile software methods and more recently the integration of Lean practices contribute to the trend of continuous improvement in the software industry. One such area warranting proper empirical evidence is a project’s operational efficiency when using the Kanban method. This short paper takes a new angle and explores waste in the Kanban-driven software development project context. A preliminary research model is presented for helping the consequent replication of the study. The results from the empirical analysis suggest Kanban can be an effective method in visualizing and organizing the current work, but does not prevent waste from creeping in, although the overall project outcome may be successful.

Marko Ikonen, Petri Kettunen, Nilay V. Oza et al. · 67 citations · ⚡9

Related blog posts

MIT News · Artificial Intelligence Sep 14, 2026

New method enables AI for safety-critical situations

The “HardFlow” algorithm could help generative AI models produce high-quality outputs that obey strict requirements when “pretty close” doesn’t cut it.

GPT-Lab Sep 10, 2026

Responsible AI Must Consider Its Afterlife

AI may appear weightless, but every model depends on physical infrastructure. To understand responsible AI, we need to look beyond algorithms and consider the entire lifecycle of the hardware behind them. The post Responsible AI Must Consider Its Afterlife appeared first on GPT-Lab.

We use cookies to run the site and, with your consent, for analytics and to show ads. See our Cookie Policy.