On November 6, Salesforce introduced Koa Decisions, a model designed to choose from supplied categories, return a yes or no, or assign a score in a single step. The company describes decisions in milliseconds and plans to extend the model into additional development tools and an API. For executives, that speed raises a slower question: who decided what the choices should be? [1]
These are vendor descriptions, not independently established operating results. Availability depends on region and customer agreements, and the planned extensions should not be treated as delivered. The useful management idea is narrower: when AI selects from a menu, the menu becomes part of the business decision. [1]
A beautifully printed menu still cannot serve a dish the kitchen forgot to include.
The awkward request is the useful one
Consider a hypothetical equipment rental company sorting incoming requests into new bookings, billing and repairs. A customer writes that a rented machine stopped working, an invoice is still running and tomorrow’s crew needs a replacement. All three departments can recognize part of the request. None of the labels, by itself, settles who should act first.
The company could buy a quicker classifier and still leave the customer waiting while departments debate ownership. That is an illustrative possibility, not observed behavior of Koa Decisions. It separates two questions that a demonstration can blur: can the model select a label, and does that label send the work somewhere useful?
I would ask the operating owner to review ambiguous requests with the teams receiving them before approving a wider rollout. Write down what each category includes, what it excludes and who owns a request that spans categories. This is my management application of the defined-choice design and classification research, not a practice tested by Salesforce. [1][2]
The meeting need not become a naming convention festival. Put a handful of difficult requests on the table. If experienced colleagues disagree about the destination, resolve the business ambiguity before asking a model to conceal it with a confident answer.
A wrong answer has a destination and a cost
An October 22 arXiv paper by independent researcher Sachin Gupta examines IT ticket classification with an option to defer cases for human triage. It uses a public dataset and illustrative costs for correct routing, review and misrouting. Those are modeling assumptions, not measured production savings. The paper supports comparing the consequences of routing and deferring, while leaving the local economics to the organization. [2]
Separate research by Kabir Kang and Stephen Mussmann, revised July 5, proposes evaluating classifiers with costs attached to individual examples. Its studied tasks are not rental operations or Salesforce deployments. The useful principle is that two errors can count equally in an accuracy score while carrying different consequences. The paper does not establish the dollar value of your mistakes. [4]
For the fictional rental business, a booking query sent to billing might create a short delay. A machine failure sent into an ordinary invoice queue could require more urgent attention. These are scenarios to investigate, not assumed losses. Ask the receiving teams what happens after the mistake, how long correction takes and which commitments are affected. My recommendation applies the cost-sensitive research to an operating review. [2][4]
That discussion gives finance something more useful than a faster-model headline. Compare processing expense with the staff time and consequences attached to correction. Keep estimates visible as estimates, and test the assumptions that could reverse the investment decision. [2][4]
Make review a real route
A system that must always pick a department may produce a tidy answer to an untidy request. A review route offers another possibility, provided someone is actually assigned to receive the work. This is a proposed workflow design, not a claim that Koa Decisions supplies a particular escalation mechanism. [1][2]
Gupta’s study also distinguishes confidence calibration from the ability to rank likely errors. A score should not be treated as a guarantee. Its results come from one public ticket corpus, with limitations in category information supplied to the models. They do not establish a universal confidence threshold for enterprise work. [2]
A review route also needs evaluation. An August 28 preprint by Dario Pesenti and University of Trento colleagues studied 226 participants classifying galaxy images. Participants given heavily imbalanced sets were less accurate on the majority class than those given more balanced sets. These were nonexpert participants, curated images and artificial class proportions, not enterprise routing or a Salesforce deployment. The proposed cognitive explanation is exploratory. My application is to examine reviewer accuracy and the mix of cases reaching review alongside workload, not assume that handing work to a person corrects it. The study does not validate that rental-company practice. [5]
In our example, the company might test whether mixed repair-and-billing requests should go to an experienced coordinator. The test should count both errors caught and review work created. Routing every case to a person would preserve the triage workload; routing nothing there would make the safeguard decorative. The question is which arrangement earns its place in this operation. [2][4]
My practical starting point is a small decision trial:
- Define the choices and their receiving owners. Include examples that cross category boundaries, and make unresolved cases visible. This is an application of the launch design and ticket-study limitations. [1][2]
- Agree on costly mistakes before scoring the model. Estimate correction work and distinguish ordinary inconvenience from consequential delay. [2][4]
- Set the review policy on development examples, then evaluate it on separate cases. Compare useful routing, error consequences and review burden, rather than celebrating accuracy alone. [2][3][4]
Keep the menu connected to the business
NIST’s February 17 publication summary distinguishes accuracy on a fixed benchmark from accuracy generalized to similar possible items. That is a reminder to ask what a test result actually represents. The summary does not validate this proposed trial, and a local sample cannot guarantee future performance. [3]
After a limited rollout, I would revisit the categories when services, customer language or receiving teams change. Inspect misroutes and cases sent for review, then revise deliberately and test again. This applies the ticket paper’s discussion of drift and limits to a management responsibility; it is not a proven monitoring schedule. [2]
Salesforce’s announcement makes a credible topic for the next operating meeting: which small decisions merit automation, and how will we know they are useful? The fastest choice can be valuable. First make sure the organization has offered the right choices and is prepared to live with the answer.
Questions for executives
- Who can change our AI’s decision categories, and who receives the consequences?
- Which wrong choice would matter most even if it rarely occurs?
- What evidence would justify routing a case automatically instead of asking for review?
Sources and further reading
- Less Reasoning. More Doing. Meet Koa Decisions.Salesforce · 2026-11-06
- Cost-Aware Abstention for LLM-Based IT Ticket ClassificationSachin Gupta, arXiv · 2026-10-22
- Expanding the AI Evaluation Toolbox with Statistical ModelsNIST · 2026-02-17
- Instance-Level Costs for Nuanced Classifier EvaluationKang and Mussmann, arXiv · 2026-05-04
- Too Much of the Same: From Algorithmic to Human Bias in Learning to DeferPesenti, Bogani, Teso and Pugnana, University of Trento, arXiv · 2026-08-28