10 decision AI companies to know
From established decision platforms to new models built for typed answers, meet the companies supplying important pieces of the decision stack.
An editorial shortlist of ten companies with directly relevant decision platforms, model serving, rules, optimization, or structured-decision models. The numbering is a reading order, not revenue, market-share, or independently tested performance rank.
01
Enterprise decisioning, risk, optimization
FICO
FICO is a direct incumbent in operational decision technology. FICO Platform connects decisions across origination, customer management, fraud, and collections. Its product documentation describes a combination of predictive analytics, optimization, specialized AI, and business expertise, with decisions logged and explained. The Xpress Executor REST API separately shows how optimization can be exposed as a programmatic service through an OpenAPI-described interface. Together these products make FICO a useful reference for the mature meaning of a Decision API: software receives evidence, applies explicit objectives and constraints, and returns an operational outcome.
For DecisionAPI.com, the strongest editorial angles are loan decisioning, connected customer decisions, and the difference between prediction and optimization. Evaluation should examine policy ownership, data freshness, decision traceability, deployment integration, and the ability to reproduce an earlier outcome. A capable predictive model is one component of that system; the service contract and business controls determine how its output becomes an action.
What to evaluate: Policy governance, reproducibility, optimization constraints, lifecycle integration
Sources for this profile
Explore the idea: Decision APIs for Lending and Insurance: Faster Workflows, Accountable Outcomes
02
Real-time customer next-best-action decisions
Pegasystems
Pegasystems' Customer Decision Hub centers on selecting the next appropriate customer action across channels. Pega describes predictive and adaptive models that evaluate possible actions against customer context, relevance, value, and organizational limits. The same decision strategy can support web, mobile, email, contact centers, and agents, while the product records why an action was selected. This is a clear example of decision intelligence combining a learned estimate with eligibility rules and priorities.
The useful comparison with a decision LLM is architectural. A model might estimate intent or a customer's likely response; Customer Decision Hub provides the surrounding action catalog, arbitration, and governance. DecisionAPI.com can use Pega to explain why an API's best answer depends on the permitted choices and business objective. Buyers should inspect how feedback changes decisions, whether explanations faithfully represent the operative logic, and how channel consistency survives policy updates and exceptional cases.
What to evaluate: Action eligibility, arbitration objectives, feedback, consistency across channels
Sources for this profile
Explore the idea: How Decision APIs Could Become a Common Layer in Every App Stack
03
Rules, decision automation, mathematical optimization
IBM
IBM offers several distinct parts of the decision stack. Operational Decision Manager captures and governs rules-based business decisions, with testing, simulation, permission management, and multiple deployment choices. IBM positions Automation Decision Services as a way to incorporate machine-learning insights, while watsonx Orchestrate can provide conversational access to decision engines. IBM's Decision Optimization documentation also describes REST-based model deployment, job execution, and retrieval of solutions. These capabilities should not be conflated with a single new language model.
For DecisionAPI.com, IBM is especially useful for explaining how deterministic rules, predictive models, and constrained optimization work together. An approval rule may enforce an eligibility condition, a prediction may estimate demand, and an optimizer may allocate limited capacity. All can be delivered through APIs, but they answer different questions. The editorial emphasis should be the boundary between each component, how versions are managed, and which evidence is retained when a decision is reviewed.
What to evaluate: Separation of rules, predictions, and optimization; versioned deployment and decision traces
Sources for this profile
Explore the idea: What Is a Decision API? The Interface Between Evidence and Action
04
Governed model and rule orchestration
SAS
SAS Intelligent Decisioning is built on SAS Viya and combines AI models, analytics, business rules, and operational policies in governed decision flows. Its current product description supports real-time, batch, and API execution, including deployment through containers. It also emphasizes version control, change tracking, approvals, and the reuse of decision assets. SAS and open-source models can participate in the same flow, making the platform relevant to teams that already have substantial statistical and predictive-model portfolios.
The DecisionAPI.com opportunity is to explain decision services as reusable organizational capabilities. A claims workflow, inventory process, or customer recommendation can consume the same governed decision logic without rebuilding it in every application. The central questions are how models and rules are tested together, who authorizes a change, and how outcomes feed future improvements. API delivery improves integration; it does not remove the need to validate a model or justify an operational policy.
What to evaluate: Combined model/rule validation, deployment portability, approvals, outcome monitoring
Sources for this profile
Explore the idea: How to Build a Reliable Decision API: Schemas, Policies, and Evaluation
05
Credit data, identity, origination and decisioning
Experian
Experian connects a major data business with credit-decision technology. Its current U.S. credit-decisioning pages describe analytics, identity and fraud checks, origination, customer management, and collections, with real-time and batch results. The U.S. site emphasizes the Experian Ascend Platform. PowerCurve Strategy Management remains an explicit product name on Experian's Australian site, where it is presented as a cloud-based tool for building, testing, and executing decision strategies. Geography and product naming therefore matter when writing a company profile.
Experian fits DecisionAPI.com's lending, mortgage, prequalification, and identity topics. It illustrates that a decision service's quality depends heavily on its input data and the permitted use of that data. A website should distinguish a prequalification response from a final lending commitment, and a credit-risk estimate from an eligibility policy. Useful buyer questions include data provenance, regional availability, model validation, decision reasons, and the handling of inconsistent information.
What to evaluate: Regional product scope, data provenance, risk scores versus policy, prequalification versus approval
Sources for this profile
Explore the idea: Decision APIs for Lending and Insurance: Faster Workflows, Accountable Outcomes
06
API-first financial risk and customer decisioning
Provenir
Provenir describes an API-first decision intelligence platform combining data, AI models, analytics, and decisioning workflows for financial services. Its product pages cover credit risk, fraud, identity, customer management, collections, and referral case handling. The platform exposes RESTful real-time decisioning, batch processing, and webhooks, and emphasizes auditable, version-controlled strategies. These details make it a direct fit for an operational Decision API landscape rather than a generic chatbot roundup.
For DecisionAPI.com, Provenir is a useful case study in how a decision endpoint becomes a system: it needs data connections, policy logic, exception handling, and monitoring after deployment. The company also markets agentic capabilities, which should be described as vendor offerings rather than evidence that autonomous decisions are universally appropriate. Evaluation should focus on the exact authority given to each workflow, the path for human review, the evidence behind model improvements, and whether changes can be tested against representative cases before release.
What to evaluate: Data integration, controlled strategy changes, case referral, decision traces
Sources for this profile
Explore the idea: Decision APIs for Lending and Insurance: Faster Workflows, Accountable Outcomes
07
Financial workflows combining AI, rules, and review
Taktile
Taktile's current platform positions AI, business logic, and human judgment within one controlled decision workflow. The site describes an AI Agent Manager, Decision Engine, Case Manager, and Context Layer, with solutions spanning onboarding, credit underwriting, anti-money-laundering investigations, insurance underwriting, and claims. Its emphasis on deciding how these components interact is directly relevant to a Decision API publication: production decisions need a managed process around the model, not just a prompt.
Taktile is particularly useful for coverage of lender and insurer workflows where a single case may include document understanding, external data, policy checks, and a reviewer. DecisionAPI.com should explain that case-management automation and risk modeling solve related but distinct problems. Strong evaluation questions concern the evidence shown to reviewers, the handling of uncertainty, control over third-party providers, and whether changing a threshold or workflow can be evaluated without silently changing the institution's underlying risk appetite.
What to evaluate: Human-review integration, context completeness, uncertainty, workflow/policy separation
Sources for this profile
Explore the idea: Decision APIs for Lending and Insurance: Faster Workflows, Accountable Outcomes
08
Predictive models and tabular foundation-model APIs
H2O.ai
H2O.ai adds an important predictive-model perspective to a market often discussed only through language models. Its product family includes machine-learning development and deployment tools, and its 2026 TabH2O material describes a foundation model for tabular data exposed through a hosted prediction API. The interface accepts labeled and unlabeled data and returns predictions, with class probabilities for relevant tasks. H2O.ai describes in-context learning over data rather than a new training run for every request.
This makes the company relevant to DecisionAPI.com's coverage of demand, fraud signals, credit data, and structured business records. Vendor benchmark and speed claims should remain clearly attributed and tested on a buyer's own workload. A tabular prediction API also demonstrates an essential distinction: predicting an outcome is different from deciding what to do. Costs, constraints, eligibility rules, and review thresholds still belong in the surrounding application or decision service.
What to evaluate: Representative tabular evaluation, probability quality, deployment options, prediction/action boundary
Sources for this profile
Explore the idea: How to Build a Reliable Decision API: Schemas, Policies, and Evaluation
09
Model deployment, prediction APIs and monitoring
DataRobot
DataRobot provides a practical model-serving layer for decision systems. Its Prediction API supports real-time predictions through serverless or dedicated environments, while its broader API allows applications to create and manage platform assets. DataRobot's documentation describes deployed-model monitoring for service health, data drift, and accuracy, and offers ways to integrate scoring into a production application. The company also documents a gateway interface to external language-model providers.
For DecisionAPI.com, the key story is operationalizing model outputs over time. A successful initial demo says little about how a model behaves when data changes, request patterns shift, or labels arrive late. A decision API built on a platform such as DataRobot should expose a stable contract while preserving the underlying model version and relevant operational evidence. Buyers should compare supported model types, monitoring coverage, portability, and how predictive or generative outputs connect to their own policies and exception-handling process.
What to evaluate: Model lifecycle, drift and accuracy monitoring, serving contracts, portability
Sources for this profile
Explore the idea: How to Build a Reliable Decision API: Schemas, Policies, and Evaluation
10
Typed probabilistic decision models
TypeSafe AI (Jev)
TypeSafe AI is the company; Jev is its model. The company introduced Jev on September 15, 2026 as its first public System One Model, optimized for bounded decisions software can consume directly. Current documentation exposes Choice, Score, and Noul questions: selecting among options, scoring against a rubric, or returning a value from zero to one for a statement. Choice and Score include probabilities and confidence. Questions can be evaluated against shared state and their outputs combined through ordinary code.
TypeSafe calls its training approach Reinforcement Learning for Calibrated Decisions. Its output constraints are an architectural distinction, but a well-typed answer can still be wrong. The dramatic launch speed and cost comparisons are vendor-reported results with workload-specific caveats. On October 9, 2026, TypeSafe disclosed an $870 million Series A at a $7.5 billion valuation. This makes Jev a timely emerging-company spotlight for DecisionAPI.com, especially for routing, classification, scoring, and review thresholds. It does not establish TypeSafe as the world's tenth-largest AI company.
What to evaluate: Task accuracy, calibration, abstention thresholds, latency under real traffic, typed output versus truth
Sources for this profile
Explore the idea: Decision AI Models and LLMs: Why Typed Answers Change the Stack
Compare the role, then compare the product.
A frontier model, a policy engine, and a decision platform solve different parts of the workflow. Our company landscape guide explains how to evaluate them together.
Read the ecosystem guide →