Most business AI tools write: emails, summaries, reports. Two new products do something different. They read an item, such as a customer email or an invoice, and choose one answer from a list you give them. TypeSafe AI released Jev on 15 September 2026. OpenAI announced its Decisions API on 29 September. Both are aimed at the routine "read this and decide where it goes" work that staff do thousands of times a month.

Both are new. Jev is in early access and OpenAI’s product is in limited preview, with no published price. The figures below are the vendors' own claims from launch coverage, and you should test them on your own data before building a plan around them.

What they do, in plain terms

You give the system three things: the item (an email, a contract, a form), a question ("which team should handle this?"), and a fixed list of allowed answers ("billing, technical, complaints, sales"). It returns one answer and a measure of how sure it is.

Jev can also rate something on a scale you define (low, medium or high risk) or give the probability that a statement is true ("is this email a phishing attempt?"). OpenAI’s version can also read images. Because the answer must come from your list, the system cannot invent an unexpected reply the way a writing tool can.

Why this matters to the business

  • Cost per decision. TypeSafe quotes about four cents to read a million tokens, which is roughly 750,000 words, with no charge for the answer. If that holds, a decision costs a fraction of a penny. OpenAI has not published a price.
  • Speed. Both vendors claim answers in well under a second (TypeSafe: 0.07 to 0.5 seconds, OpenAI: about 0.15 seconds). That is fast enough to sit inside a live customer interaction, not only a back-office batch.
  • Consistency. Two people reading the same ticket often choose different queues. A system applies the same list and the same question every time, and you can change the rule in one place.
  • A record of every decision. Each call can be logged with the input, the options and the answer, which is harder to get from a person’s judgement.

Where it fits

The pattern is any step where a person reads something and picks a path. These are examples of that pattern. They are not claims about what either vendor has proven.

Operations and customer service (CEO)

Route incoming tickets and emails to the right team, flag complaints and refund requests, and spot likely phishing before staff open it. Jev’s own example does three of these in a single call. The benefit is shorter waiting times and fewer people spending the first hour of their day sorting.

Finance (CFO)

Sort incoming invoices and supplier emails by type, suggest a cost code, check an expense claim against policy, or flag a payment request that does not match the usual pattern. The system makes the first pass and your team handles the exceptions.

Product (CPO)

Tag customer feedback, support conversations and app-store reviews by theme and severity, so the product team sees what customers are actually raising without reading every item. A decision step can also direct each request in your product to the right workflow or support path.

Safety checks on other AI tools

If you already use an AI assistant that writes to customers or takes actions, a decision step can check each output first: does it quote a price, make a promise, or step outside policy? Anything it flags goes to a person. For many companies this is the quickest way to use AI in customer-facing work with a control in place.

The control that matters: how sure is it?

The useful feature is not the answer. It is the confidence figure that comes with it, because it tells you when to trust the system and when to ask a person. A typical set-up has three bands:

  1. Very confident: the workflow proceeds without review.
  2. Moderately confident: it proceeds, and a sample is checked each week.
  3. Not confident: it goes to a person.

Where you draw those lines is a business decision, not a technical one. It sets how many errors you accept and how many items still need a person. A cautious setting is safer but may send most work back to staff and save little. A loose setting saves more and lets more mistakes through. Your team should set it from measured results on your own past cases, and the executive who owns the process should approve it. One caution: the sources disagree on which Jev outputs carry a confidence figure, so confirm this in the vendor’s current documentation.

What it will not do

  • Write or reason. It chooses from a list. Drafting a reply or working through an unusual problem still needs a writing model or a person.
  • Replace exact rules. If the rule is "orders over a set value need approval", ordinary software does that perfectly and at no per-decision cost.
  • Explain itself. You get an answer and a confidence figure, not reasoning. If a customer or regulator asks why a decision was made, you rely on the log of what went in and what came out.
  • Be right every time. It will make mistakes, and the question is whether it makes fewer, or cheaper ones, than the current process.

Risks to raise with your team

  • Data protection. Where is customer data processed, is it kept, and is it used to train the vendor’s models? Settle this before any personal data is sent.
  • Accountability. A named executive owns the process and the error rate, in the same way they do for a human team.
  • Regulatory exposure. If the decision affects a customer’s access to credit, insurance, employment or housing, automated decision rules may apply, and a person should review adverse outcomes. Take legal advice for those cases.
  • Vendor stability. Both services are new. Ask whether the vendor will freeze a model version, because an unannounced update can change results and move your accuracy.
  • Unverified claims. Speed and price figures come from the vendors. Nobody has independently compared the two.

A sensible first step: a 60 to 90 day pilot

  1. Pick one process with high volume, a clear right answer and a low cost of error, such as routing support tickets or sorting incoming invoices.
  2. Measure today’s position: items per week, time spent, cost, and how often the current process gets it wrong.
  3. Run it in the background first. The system makes its choice, staff carry on as normal, and you compare the two for a few weeks. Nothing changes for customers during this stage.
  4. Agree the success test in advance, for example "at least as accurate as staff, and at least 40% of items handled without review". Pick your own numbers.
  5. Automate only the high-confidence band, keep sampling it every week, and expand only if the results hold.

Pilot cost should be small: some technical time to connect the service, and staff time to check results. The measure that matters is hours of staff time released and errors avoided against that cost.

Questions to put to your team

  • Which process wastes the most skilled time on reading and sorting?
  • How accurate is that process today, and how do we know?
  • What does a wrong decision cost us, and who is affected?
  • Who owns the error rate and the confidence settings?
  • What customer data would be sent, and to whom?
  • How do we explain a decision to a customer or regulator?
  • Can we switch supplier if the price or terms change?

These tools turn a read-and-choose task into a low-cost, fast and logged step with a confidence figure. The business gain depends on accuracy measured on your own cases, confidence settings that an accountable executive has approved, and a person reviewing what the system is unsure about.

Sources

Launch coverage used for this article. Vendor figures are unverified.